Hi there. I've been using rdiff-backup for a long time, but now seem to have a problem with it (shortly after upgrading our backup server from Debian Etch to Debian Lenny).
When the server that's being backed up has a large number of files (in the millions), rdiff-backup now takes a very long time (I've left it for 24 hours, and it was still busy), and uses up a huge amount of ram and CPU. I've tried turning rdiff-backup's verbosity to maximum, and there is no indication of what could be causing the massive resource usage/delay. The last log entry is something about removing some metadata file. Nothing about scanning the harddrive, or compressing or anything like that. Also, fwiw, the server's changed very little between the first rdiff-backup backup and the second. (I'm using rdiff-backup 1.2.8 on the server). This is causing problems, because earlier backups never complete, so the later backups never get a chance to run. At the moment I'm busy updating some of the backups so they use a hardlink snapshot-like method for storing history, instead of rdiff-backup. The disk usage will be greater, but at least it should work better... Another problem I've noticed is that rdiff-backup isn't very good with backwards compatibility, eg: 1) If two different versions of rdiff-backup communicate over the network, they will often fail. This makes it very hard to use rdiff-backup for over-the-network backups, unless you can ensure the same version is running on both sides. Instead, I use rsync for over-network transfers (it's very good with network reverse compatibility), and only ever use rdiff-backup locally to store increments. 2) Newer versions of rdiff-backup have problems reading the rdiff-backup store of older rdiff-backup versions. After upgrading our backup server, I had to delete the rdiff-backup data store for many of the backups, losing months or years worth of history (not so important, really, but I dlike to keep them around until disk space runs low on the backup server), because I couldn't get rdiff-backup working (it kept on getting assertion errors with the number of "current"-<something> files being incorrect), and Google searches & my experimentation couldn't solve the problem. I just thought I'd mention those problems. David. _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
