Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Yes! That really helped. Nobody on the Googles internet seems to know this.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
You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &
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.
3 years later and this was the life saver! No idea what caused my issue on a DS420+ to DS216 backup but this worked flawlessly, thanks so much for saving my current backup and avoiding all the hassle of creating a new oneI 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
You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &
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.
Just made a synoforum account to say thank you.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
You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &
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 had a similar issue for a DS418j (source) and DS416 (destination). You could try the following steps. YMMV.
[...]
Hope that helps.
task_state.conf
is located in /volume1/@appdata/HyperBackup/config/task_state.conf
instead.Yeah. Can't believe there's no feature to allow us to replace the corrupt file with the current copy or something. Pretty dangerous to completely disable the entire back-up. And it's not clear why I'm seeing so many corrupt backups. Is it RAM? It's near-impossible to run a RAM test remotely -- you need a machine on the same LAN. Why can't the backups be more resilient?It's crazy that this is what we are reduced to to fix what is clearly Hyperbackup problem. Kudos to @BoxingHyena for the fix, but this is kind of nuts.
IMO this is a software thing. @tjohns34 do you know if this started after 7.2 or 7.1 or something?
I never had this happen under the 6.x software. But I think somewhere around after the 7.2 update this started happening.
That said, I also had a weird memory error thing. I bought some ECC memory that passed the memory test. But after digging in the logs, I see a rare ECC error reported, usually just one per boot. I had the RAM replaced a day ago, and do not see that same ECC error, so perhaps it was related to that.
Which is a long winded way of saying the RAM can pass the memtest and still be bad shooting out ECC errors. So look for "ECC" in your logs to see if it threw any errors.
I keep getting more "destination corrupt" happening to my HyperBackup tasks. Hmmm... I'm assuming any possible memory corruption would be at the destination NAS, right?
Hi Ken830. That is a reasonable assumption for sure. In my case though, the destinations I was using were an external hard drive and Synology's own C2 Storage service. I kept getting "Destination corrupt" issues with both options. I hope I'm not mentioning it too soon, but I haven't had any of the errors when backing up to my external hard drive since I re-installed the original RAM that came with my NAS. It's only been a week now, but I am somewhat hopeful that fixed my problem. We shall see. Going from 8GB RAM back down to 2GB RAM had no impact whatsoever on performance, but I'm not running any containers or VMs on my NAS. Just file storage/backup, Plex, QuickConnect, HyperBackup, Download Station, Surveillance Station, and VPN Server. My Resource Monitor shows I still have ~200MB RAM still free!
Did you happen to have upgraded the RAM in your NAS? Just curious. That would be a common factor to these "Destination corrupt" issues if you have. If so, maybe replace the upgraded RAM kit with the original RAM that came with your NAS like I did and see what happens.
Tim
I signed up for an account here to thank you for this post. I had the same Destination Corrupted error, and running the synoimgbkptool with the recovery option fixed it. So, Thank You!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
You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &
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.
For me in the SrcI 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
You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &
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.
Does not exist/var/synobackup/config/
This is a god-sent. Thank you so much.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
You may get "nohup: ignoring input and redirecting stderr to stdout". It's ok to ignore this.nohup ./synoimgbkptool -r /volume1/backups -t Dst -R detect > /volume1/\@tmp/recover.output &
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.
cat /usr/syno/etc/synobackup.conf
We use essential cookies to make this site work, and optional cookies to enhance your experience.