02-24-2023, 02:09 AM
Oh man, that sucks. I really know how you feel because things like that have happened to me more than once.
So to answer your question, I have a plugin on my OpenMediaVault NAS that is set to rsync my nas drives whenever I plug in my external USB hard drive. One of the settings I made sure was off was the delete option. I just couldn't trust it completely for reasons you experienced. Or what if the USB drive is acting up and the backup doesn't see the file so it deletes it off the server. I didn't want to take that chance. Instead, I'll just manually go through the USB drive afterwards and prune it as I see fit. But lately, since hard drives aren't that expensive - when compared with my time of pruning a hard drive versus just slapping in a new bigger drive is quicker.
Now, when I backup my main rig to the NAS, I do run rsync with the delete option - however I always do a dry run first and I have everything logged where I'll go through that to see what it's going to do. In my backup shell I run, this is a snippet of the commands I'm using:
backup_path_home='nas-vm::Blaze/home/'
current_date=`date +%Y%m%d`
rsync --dry-run \
--archive --update --verbose --human-readable --itemize-changes --progress \
--recursive --perms --delete --delete-excluded \
--exclude-from='/home/blaze/backup_exclude.txt' \
--log-file='/home/blaze/Backup/rsync-home-x.log' \
/home/blaze/ ${backup_path_home} 2>&1 | tee /home/blaze/Backup/rsync-dry-output-home-${current_date}.txt
With my first NAS I lucked out when a drive failed since it was raided. It was a nice feature to just slap in a new drive and have it get built. Shortly after I did build a new one and put the old drives in the archive since if one failed of "old-age" it was only a matter of time before the others did as well. I also do a S.M.A.R.T. test every night on the drives and an extensive test on them once a month. These are all automated and scheduled from the server and I get e-mailed a report. And when the backups are happening, I get a little on edge and will constantly check the rsync logs on the server to see what the progress is and then do some spot checks to make sure files are truly getting backed up and nothing is going awry.
The big takeaway from this would probably be to do a dry-run before actually backing up to make sure everything is going as planned.
So to answer your question, I have a plugin on my OpenMediaVault NAS that is set to rsync my nas drives whenever I plug in my external USB hard drive. One of the settings I made sure was off was the delete option. I just couldn't trust it completely for reasons you experienced. Or what if the USB drive is acting up and the backup doesn't see the file so it deletes it off the server. I didn't want to take that chance. Instead, I'll just manually go through the USB drive afterwards and prune it as I see fit. But lately, since hard drives aren't that expensive - when compared with my time of pruning a hard drive versus just slapping in a new bigger drive is quicker.
Now, when I backup my main rig to the NAS, I do run rsync with the delete option - however I always do a dry run first and I have everything logged where I'll go through that to see what it's going to do. In my backup shell I run, this is a snippet of the commands I'm using:
backup_path_home='nas-vm::Blaze/home/'
current_date=`date +%Y%m%d`
rsync --dry-run \
--archive --update --verbose --human-readable --itemize-changes --progress \
--recursive --perms --delete --delete-excluded \
--exclude-from='/home/blaze/backup_exclude.txt' \
--log-file='/home/blaze/Backup/rsync-home-x.log' \
/home/blaze/ ${backup_path_home} 2>&1 | tee /home/blaze/Backup/rsync-dry-output-home-${current_date}.txt
With my first NAS I lucked out when a drive failed since it was raided. It was a nice feature to just slap in a new drive and have it get built. Shortly after I did build a new one and put the old drives in the archive since if one failed of "old-age" it was only a matter of time before the others did as well. I also do a S.M.A.R.T. test every night on the drives and an extensive test on them once a month. These are all automated and scheduled from the server and I get e-mailed a report. And when the backups are happening, I get a little on edge and will constantly check the rsync logs on the server to see what the progress is and then do some spot checks to make sure files are truly getting backed up and nothing is going awry.
The big takeaway from this would probably be to do a dry-run before actually backing up to make sure everything is going as planned.