Re: [rdiff-backup-users] Possible python 2.3 dependency?

[Ben Escoto]

>>>>> Chris Wilson <address@hidden>
>>>>> 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

pgp_Em9mUjbmq.pgp
Description: PGP signature