Re: [rdiff-backup-users] Prevent rdiff-backup from deleting?
On Mon, 14 Nov 2011, Grant wrote: Because of this, I think there is a gaping security hole in any automated rdiff-backup scheme that pushes backups to the server. Pulling to the backup server eliminates this problem, but if the backup server is compromised, the infiltrator has root read access to each system being backed up and can thereby compromise each of those systems as well. Is rdiff-backup ill-suited to automated backups? This topic has been discussed here many a time. There is always a trade-off between security and ease of use. If you do push-style backups, having root access on the main system gives an attacker access to the backup system, so the backup has to be considered compromised when the main system is compromised. Depending on what purpose you keep backups for, this may not be what you want. If you do pull-style backups, and the backup system is compromised, the attacker indeed has root access to all backed up systems (possibly more than one). If you do pull-style backups and the main system is compromised, you could restore from a 'clean' increment. However, a compromised main system can go unnoticed for weeks or even months. So backups may have become compromised as well, and when keeping less history than this detection period, there would be no way to go back to a clean state after that time. Again, it all depends on the exact use of the backup tool. You could e.g. use rdiff-backup for user's files, and some other tool for system backups. All in all, this is not very specific to rdiff-backup. Other push or pull style backups have the same 'problems'. The method I prefer is having a backup server that is not reachable from the outside. Currently a box behind a NAT gateway, but could as well be a fully firewalled IP address with only outgoing traffic allowed to the hosts that are to be backed up. (Possibly even one at a time.) Any automated system can be fooled when not supervised properly ;-) -- Maarten ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Hash doesn't match recorded hash
On 15/11/2011 00:23, Alex Schuster wrote: I need to restore an old VMware image, but I am getting LOTS of these errors: Error reading /backup/weird/home/wonko/os/vmware/xp/winXPPro-0.log, substituting empty file. Warning: Hash da39a3ee5e6b4b0d3255bfef95601890afd80709 of winXPPro-0.log doesn't match recorded hash db9943d0284382131b553cef380aae99871b0f2e! Any idea what has happened? rdiff-backup --check-destination-dir --force says nothing has to be checked, and option --verify does not find errors. The hard drive seems to be okay, no errors in the syslog, and a long SMART selftest also does not find any errors. I can restore some other directories I tried, but I need the backup of this VMware machine. Vmware files for a running vm may change while being backed up by rdiff-backup, in which case you don't have a consistent backup. Maybe this is why you have this inconsistent hash warning. Before using rdiff-backup on a VMware vm, my suggestion is to pause or suspend or stop the vm (e.g. with vmrun). Alternatively use the VMware snapshot facility and backup the snapshot rather than the running vm. None of this is much help if you have already lost your vm and are trying to recover it from backup. You might try recovering older versions of the vm (from your rdiff-backup repository), maybe you will find a consistent and usable vm there. Also the file you mention is only a log file and not critical. The critical files I think are *.vmdk, *.vmx and *.nvram. Regards Dominic ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Prevent rdiff-backup from deleting?
A simple solution is to edit the python source code for rdiff-backup on the backup server and restrict what it will accept for the --remove-older-than argument. You could also have two different versions of rdiff-backup on the backup server. One accessed remotely that has this option completely disabled (by editing the source). The other version would be the original code but can only be accessed from the local backup server. Sarel On 11/14/2011 9:03 PM, Grant wrote: The problem is that I run rdiff-backup in a crontab and one of the commands there includes --remove-older-than. That's a very creative solution though. Because of this, I think there is a gaping security hole in any automated rdiff-backup scheme that pushes backups to the server. Pulling to the backup server eliminates this problem, but if the backup server is compromised, the infiltrator has root read access to each system being backed up and can thereby compromise each of those systems as well. Is rdiff-backup ill-suited to automated backups? - Grantolutionsfirst.com.au/index.php/RdiffBackupWiki ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Prevent rdiff-backup from deleting?
Because of this, I think there is a gaping security hole in any automated rdiff-backup scheme that pushes backups to the server. Pulling to the backup server eliminates this problem, but if the backup server is compromised, the infiltrator has root read access to each system being backed up and can thereby compromise each of those systems as well. Is rdiff-backup ill-suited to automated backups? This topic has been discussed here many a time. There is always a trade-off between security and ease of use. If you do push-style backups, having root access on the main system gives an attacker access to the backup system, so the backup has to be considered compromised when the main system is compromised. Depending on what purpose you keep backups for, this may not be what you want. If you do pull-style backups, and the backup system is compromised, the attacker indeed has root access to all backed up systems (possibly more than one). If you do pull-style backups and the main system is compromised, you could restore from a 'clean' increment. However, a compromised main system can go unnoticed for weeks or even months. So backups may have become compromised as well, and when keeping less history than this detection period, there would be no way to go back to a clean state after that time. Again, it all depends on the exact use of the backup tool. You could e.g. use rdiff-backup for user's files, and some other tool for system backups. All in all, this is not very specific to rdiff-backup. Other push or pull style backups have the same 'problems'. The method I prefer is having a backup server that is not reachable from the outside. Currently a box behind a NAT gateway, but could as well be a fully firewalled IP address with only outgoing traffic allowed to the hosts that are to be backed up. (Possibly even one at a time.) The downside of pull-style backups is that if the backup server is compromised, the backed-up systems can be compromised easily since the infiltrator would have root read access to those systems. Your solution is to make it harder for the backup server to be compromised. That sounds pretty good, but how do you access that system remotely? - Grant Any automated system can be fooled when not supervised properly ;-) -- Maarten ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Hash doesn't match recorded hash
I note there was a similar plea last March on this list, you can see it here: http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/rdiff-backup-23/restore-fails-110831/. Unfortunately there was no published resolution. I wonder if the problem relates to the temporary folder being used on the server or (possibly) on the local machine? Try running the restore with --remote-tempdir and --tempdir pointed at locations with bags of space. Is it only this log file that gives the error message? What about the vmdk file? Dominic On 15/11/2011 12:27, Alex Schuster wrote: Maarten Bezemer writes: On Tue, 15 Nov 2011, Dominic Raferd wrote: On 15/11/2011 00:23, Alex Schuster wrote: Warning: Hash da39a3ee5e6b4b0d3255bfef95601890afd80709 of winXPPro-0.log doesn't match recorded hash db9943d0284382131b553cef380aae99871b0f2e! Any idea what has happened? Vmware files for a running vm may change while being backed up by rdiff-backup, in which case you don't have a consistent backup. Maybe this is why you have this inconsistent hash warning. If the contents changed during the rdiff-backup run, it bails out and doesn't save the (inconsistent) increment. So that shouldn't happen. I didn't know that, but I wonder if it always works like that or whether in extreme cases (such as huge vmdk files or corrupted source drive) it can break down. And I amusing a backup script which takes a LVM snapshot of my /home partition before rdiff-backupping it. Good thinking, but I doubt this guarantees that the vmdk file is consistent. Restoring other VMs seems to work, although I did not test many. But I cannot restore ANY backup of this special VM I need, I tried about six of my twenty backups. Well, it would be really nice to be able to restore this VM, but if not, I can (and have to) live with that. But I really would like to know why this happened, and if I can trust other backups I do. I successfully restored this VM in the past already, but that was an earlier snapshot I have deleted meanwhile. Yes I think we would all like an explanation for your problem, and a workaround. It could be our problem one day... Dominic ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Lost Connection
Hi, We are compiling rdiff on MAC, but it's giving many errors. Can you please clarify how we can compile it. Thanks and Regards, Sukhraj singh -Original Message- From: rdiff-backup-users-bounces+sukhraj.singh=sebiz...@nongnu.org [mailto:rdiff-backup-users-bounces+sukhraj.singh=sebiz...@nongnu.org] On Behalf Of D. Kriesel Sent: Saturday, September 24, 2011 1:30 PM To: Nicolas Jungers; rdiff-backup-users@nongnu.org Subject: Re: [rdiff-backup-users] Lost Connection Second that. I believe that a local rdiff, followed by an rsync to a remote destination might be the most resilient solution. Nicolas Jungers nico...@jungers.net schrieb: On 2011-09-23 21:50, Alex wrote: I will check, but just used rsync and it worked, I believe that is not network. Thank you so far rsync is very resistant to network flakiness and rdiff-backup is very sensitive to it. N. 2011/9/23 Greg Troxel g...@work.lexort.com mailto:g...@work.lexort.com Try running tcpdump and seeing what happens, and check /var/log/messsages or equiv on both systems. Is the network between flaky or reliable? ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
