>>>>> Chris Wilson <[EMAIL PROTECTED]> >>>>> wrote the following on Sat, 3 Sep 2005 00:22:24 +0100 (BST) > > Thanks for your help, the patch does seem to allow backups to finish, but > leaves a second (more minor) issue: it seems that device nodes are now > inremented on every backup, even when they haven't changed. I'm worried > about my backup history growing much faster than it should. > > Please could you explain this a little more? As I understand it, if the > device node information is stored in the metadata, instead of in files, > then restoring from the backup will recreate the device files? Then what > am I losing by backing up in this way? Does it matter if I exclude device > files or not, after applying this patch?
The way it works ideally is that all information is stored in the backup directory, and a copy of the metadata is stored in a separate file. In some cases the metadata is not necessary, and is only helpful to speed up backups. In cases where the backup directory is missing features of the source directory (like ACLs, ownership) the separate metadata files are necessary, and don't just make things faster. For device files, all the information about them is contained in it's metadata entry (device files don't have any extra data associated with them) so it's unnecessary to make device files in the backup directory. Also, it's usually unnecessary to backup device files at all, since usually there is some MAKEDEV script which will recreate all of them in case you lose your /dev directory. That patch didn't fix device files with python 2.2, which is still missing an os.mknod() function, it just prevented rdiff-backup from crashing when trying to make them. When you try to backup device files, no information is lost. However, you won't be able to restore device files without a newer version of python. So if you don't need device files it would be simplest to exclude them. If you need them backed up, you can include them, but realize to restore you'll need a newer version of python. Including them shouldn't make much difference in running time or the disk space taken up. > By the way, I found it quite a pain to install rdiff-backup from source > rpms: librsync rpm build is a bit broken, and requires manual patching, > plus all the compilers have to be installed. Are you interested in binary > RPMs of rdiff-backup and librsync? I can easily supply some if you are. Before I used to provide binary packages of librsync and rdiff-backup, but with all the distributions are architectures I'd have to provide binaries for i386, x86_64, Fedora, Suse, and various combinations and versions of these. So now I've just tried to make a source rpm that will work for many people, and leave the binaries up to the distributions. If you want to make a binary perhaps you could submit it to whatever distribution you are running. -- Ben Escoto
pgp3MQ6mK7YBX.pgp
Description: PGP signature
_______________________________________________ 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
