Question "Destination corrupted" error in HyperBackup

Currently reading
Question "Destination corrupted" error in HyperBackup

10
2
NAS
DS-918+
Router
  1. RT2600ac
Hi, I have this problem in Hyper Backup for several days and I can't find a way to solve it. Hyper backup show this error:

246


I attach the error report generated. It says that a number of files are broken or something like that. Those files are reports generated by the Storage analyzer and I don't know how to restart the backups. The files mentioned in the report seems fine to me, the backup drive too. Any help will be appreciated. If you need some other detail or info, ask me. Thanks in advance.

Model name: DS918+
DSM Version: 6.2.2-24922
 

Attachments

  • error_report.txt
    22.8 KB · Views: 388
I really don't like the way this package works now. I'm sure it used to just copy the files as files instead of this nonsense that you have to mount and open?

Anyway, I had something similar to you. Mine said a file was corrupted. I did the mount and open thing and deleted the file. I ran backup again and it still said the file was corrupted. I ended up deleting the backup altogether, including the task. I recreated it and it's been fine.

I don't like it and I don't trust it tho!
 
Ah, I've found how to do this!

If you want, traditional, single, versions, of your backed up files. Select the second option from the wizards list in Hyperbackup.

"Local Folder and USB (Single Version)"
Capture.JPG

This gives you a single version of each file backed up. You can view them from File Station or over your network shares, in the usual way. Without the mounting and opening nonsense.
 
If you want, traditional, single, versions, of your backed up files. Select the second option from the wizards list in Hyperbackup.

"Local Folder and USB (Single Version)"
View attachment 266

This gives you a single version of each file backed up. You can view them from File Station or over your network shares, in the usual way. Without the mounting and opening nonsense.

Thanks for this tip! I will do that. First I will reformat the disk, since suspending my first 100 GB backup ended up with "destination corrupted", so I could not resume the backup, nor can I start a new backup. Luckily, there is nothing else on that disk, but a pity to use only 100 GB out of 4 TB...

I would never ever give Synology remote access to my NAS for "fixing" crappy software issues.

I would love to have multiple backups, but not at the cost of reliability. That should not be too difficult to achieve in my opinion, but apparently Hyper Backup is not a reliable solution. Does anyone know of some reliable alternative for getting multi-generation backups in the format of the original files (except for super-cumbersome USB Copy one folder at a time)?
 
Wow. This is actually a big improvement with how Hyperbackup used to deal with database corruption. Consider yourself lucky. You did not lose all the previous backups. My suggestion is that you abandon and "freeze" your current backup database and simply create a new Hyperbackup "job" moving forward. Call it something else. If filespace is a problem, copy the old backup database intact to a different drive that you can access using hyperbackup explorer on some machine. In fact make a backup of the backup just to ensure you don't lose it. Then start again.

The backup database is not repairable by mere mortals (especially if its encrypted). Best to essentially not touch it if you are able to view and retrieve your backed up files.

I had written up a tutorial on how I recovered my unreadable Hyperbackup database on the old forums, but it seems to have been deleted.
 
You are very cynical. Synology would not be able to sell large NAS units to business if they had access to your data. You can use encryption to ensure no one has access to your data.

I also refused to give Synology access to my NAS and Hyperbackup database to debug the problem and that basically ended my conversation with them other than suggesting that the Hyperbackup database become more resilient to errors. It sounds like they have done some of that, since your corrupted database still allows you to recover previous backups.

I have mixed feelings about Hyperbackup. I needed a journaling encrypted cloud backup and Hyperbackup does that well. It also allows you to restore individual files and versions and you can use Hyperbackup explorer to do that on another machine. BUT it is sensitive to file corruption and restore of an encrypted backup using the explorer tool is horribly slow. Like unusable slow. So, its a mixed bag and I hope they continue to improve it.
 
You are very cynical.
You must have lost track of the conversation. My point was... if you don't trust Synology for remote access, why would you trust DSM which they control (I'm presuming that you haven't audited DSM code... am I wrong?). It's inconsistent to accuse me of being "cynical" when your trust in their remote access morals is wanting.

Sheeesh! 😝
 
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.

admin 12451 34.0 0.6 390148 24976 ? S Nov28 3689:58 ./synoimgbkptool -r /volumeUSB1/usbshare -t Dst -R detect
root 15620 0.0 0.0 23148 2324 pts/23 S+ 02:57 0:00 grep --color=auto synoimgbkptool
Otherwise, you should see something similar to this.
root 15620 0.0 0.0 23148 2324 pts/23 S+ 02:57 0:00 grep --color=auto synoimgbkptool
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.
 
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 WAS THE SOLUTION for me.
I didn't have 2 different NAS but it worked the same backing up on an external HDD.
THANKS !!!
 
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.
I have the same issue with a DS1517+ (Src) and DS1513+ (Dst).
I tried your solution, but when I run the synoimgbkptool command nothing happens.
The name of my Src is DS1, the name of my Dst is DS3
I have a folder /volume1/NetBackup/DS1.hbk
I run the command:
nohup ./synoimgbkptool -r /volume1/NetBackup -t DS3 -R detect > /volume1/\@tmp/recover.output &

Is there anything wrong in this command?
Thanks
 
Hi Maxwell,
I had the same problem and solved it just by adding the extension of the target.
So in your command "...-t DS3.hbk...."
At least that is my extension of the backup.
 
Hi Maxwell,
I had the same problem and solved it just by adding the extension of the target.
So in your command "...-t DS3.hbk...."
At least that is my extension of the backup.
Hi e-loi,
it works! Thanks a lot.
Let's see now if I can recover the backup. It's 11TB large, it will take some days, I guess...
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Solved
Rusty! You made that too easy.... I was so close...
Replies
2
Views
1,674
had a quick read still unsure on what redundant storage ive created though it did take over 6 hours to add...
Replies
37
Views
2,040
It is a windows issue. Try to clear the network logins en clear DNS Go to windows credentials manager and...
Replies
1
Views
536
  • Solved
Hello everyone Thank you all for taking the time to reply with the information. Though as well as editing...
Replies
5
Views
2,154
Thanks for the uber fast reply. No, I didn't mix the bays up. 2-4 were 8 TB drives and 1 was the oldest...
Replies
2
Views
4,182

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top