Question "Destination corrupted" error in HyperBackup

[BobA]

-r is for the directory and -t is for the backup name. So based on the info above:

nohup ./synoimgbkptool -r /volumeUSB3/usbshare -t THEONE_1.hbk -R detect > /volume1/\@tmp/recover.output &

Thank you, this looks like it's done the trick and this command is now running, fingers crossed for the completion now

 

[BobA]

Thanks to all contributions to this thread, my backups are up and running again

FYI Anyone following this guide my Hyperbackup config file was in a different location:

./volume1/@appdata/HyperBackup/config/task_state.conf

 

[morph27]

Old thread but I'm here because I'm experiencing the same problem. I did everything in BoxingHyena's post. I'm at the last step: edit task_state.conf using vi editor. My question is why are there 3 tasks in my .conf file?

Here's how it looks after editing and saving task_state.conf file.

[task_1]
last_state="Backupable"
state="Backupable"
[task_2]
last_state="Backupable"
state="Backupable"
[task_3]
last_state="Backupable"
state="Backupable"

Check backup integrity failed too. It starts for 3 to 4 second then stops. The log shows "Failed to run backup integrity check" and the task_state.conf file goes back to "ErrorDetect" after I ran check integrity.

 

[bidh]

I'm also having troubles with HyperBackup, it stopped during a version rotation/deletion.

Apparently 2 corrupt .index files and 2 corrupt .bucket files have now frozen the backup software. According to HBA log.
Synology helpdesk's answer is nuke everything and start anew.

I had a similar issue for a DS418j (source) and DS416 (destination). You could try the following steps. YMMV.

3. Check the status. You should get "detect-bad".
> sqlite3 Config/target_info.db "select status from target_info"

This is what I get.
$ sqlite3 Config/target_info.db "select status from target_info"
compacting

Would the nohup ./synoimgbkptool -r fix the problem and how long would it last on a USB disk ?

Or deleting the corrupt .index and .bucket files ?
Thanks for reading.

 

[maxspa]

I had a similar issue for a DS418j (source) and DS416 (destination). You could try the following steps. YMMV.

"Src" is the name for the source NAS and "Dst" is the name for the destination NAS.

Before proceeding,
a. Disable any backup schedules.
b. Check that your disks and memory are all performing well. If there is any hardware fault, fix it first.

SSH into Dst to perform the following steps.
1. Change to root.
> sudo -i

2. Change into backup directory.
> cd /volume1/backups/Dst/

3. Check the status. You should get "detect-bad".
> sqlite3 Config/target_info.db "select status from target_info"

4. Change to HyperBackup Vault's bin folder and run synoimgbkptool.
> cd /var/packages/HyperBackupVault/target/bin

nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &

You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.

5. Wait for synoimgbkptool to complete running. It can take a very long time, 3 to 4 days. You can check with the following command.
> ps aux | grep synoimgbkptool

If you see something similar to the following, it is still running.


Otherwise, you should see something similar to this.

You can now exit the SSH to Dst.

Next, SSH into Src.
1. Change to root.
> sudo -i

2. Change to HyperBackup's config directory.
> cd /var/synobackup/config/

3. Edit task_state.conf (using vi) to the following.
last_state="Backupable"
state="Backupable"

You can now exit SSH to Src.

Finally, log in to the admin portal. Start HyperBackup and choose "Check backup integrity". It can take a long time (3 to 4 days). Once that's completed without errors, you should be able to resume your backup schedule.

Hope that helps.

That worked for me. Thans so much!! Being on DSM 7 I hjust had to use "/volume1/@appdata/HyperBackup/config/" instead of "/var/synobackup/config/" as pointed out by others as well