Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
1–7 of 7 posts
Re: Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
#2This was the same argument made about RAID backups. You won't lose a backup as long as you replace the right hard drive.
It can still corrupt if the local storage is/goes bad.
Re: Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
#3This was the same argument made about RAID backups. You won't lose a backup as long as you replace the right hard drive. It can still corrupt if the local storage is/goes bad.
Thanks for your comment. Actually, Client-Side-Encrypted-Backups is different in that a backup cannot be created unless tar, ccrypt and sftp on the user's machine execute smoothly. In your example, in the case of a user's local drive going bad during a backup, one of these (tar, ccrypt, sftp) would fail causing the backup to not be created. All files that show up in the completed_backups log file are golden backups and can be restored at anytime. For me, I have been exclusively using Client-Side-Encrypted-Backups to do all of my backups (since 2011). I don't ever recall seeing an issue in all of those years. It's been very reliable.
Re: Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
#4This was the same argument made about RAID backups. You won't lose a backup as long as you replace the right hard drive. It can still corrupt if the local storage is/goes bad.
Thanks for your comment. Actually, Client-Side-Encrypted-Backups is different in that a backup cannot be created unless tar, ccrypt and sftp on the user's machine execute smoothly. In your example, in the case of a user's local drive going bad during a backup, one of these (tar, ccrypt, sftp) would fail causing the backup to not be created. All files that show up in the completed_backups log file are golden backups a…
Why did you choose not to use rsync ?
( Also, you regarding the criticism you received: perhaps you are interested in using TAHOE-LAFS. )
Re: Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
#5Earlier quoted context omitted.
Thanks for your comment. Actually, Client-Side-Encrypted-Backups is different in that a backup cannot be created unless tar, ccrypt and sftp on the user's machine execute smoothly. In your example, in the case of a user's local drive going bad during a backup, one of these (tar, ccrypt, sftp) would fail causing the backup to not be created. All files that show up in the completed_backups log file are golden backups a…
Why did you choose not to use rsync ? ( Also, you regarding the criticism you received: perhaps you are interested in using TAHOE-LAFS. )
So corrupt backups weren't possible - just my personal preference.
Re: Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
#6Earlier quoted context omitted.
Why did you choose not to use rsync ? ( Also, you regarding the criticism you received: perhaps you are interested in using TAHOE-LAFS. )
So corrupt backups weren't possible - just my personal preference.
rsync can be applied as such. Either I don't understand you and am missing something or you could use the following link: https://linux.die.net/man/1/rsync
Anyhow: Good stuf you're making && godspeed at your venture. ^_^
Re: Show HN: Client Side Encrypted Backups – easy to use and no chance of corruption
#7Earlier quoted context omitted.
So corrupt backups weren't possible - just my personal preference.
rsync can be applied as such. Either I don't understand you and am missing something or you could use the following link: https://linux.die.net/man/1/rsync Anyhow: Good stuf you're making && godspeed at your venture. ^_^
Thank you kind sir.
When I was investigating backup solutions in 2010, I did read about rsync and had read a few negative reviews saying that user's had their backups corrupted (by rsync) and that they were unable to restore their backups. However, looking now I am unable to find those reviews. So, likely either those issues were fixed in a newer version of rsync or I am not remembering the posts correctly.