rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Proposal to fix long filenames


From: Ben Escoto
Subject: Re: [rdiff-backup-users] Proposal to fix long filenames
Date: Sun, 13 Nov 2005 11:16:53 -0600

>>>>> Sheldon Hearn <address@hidden>
>>>>> wrote the following on Sat, 12 Nov 2005 12:02:45 +0200
> 
> I think this is another edge case that speaks to the value of
> entirely virtualizing the backup store.  In other words, don't rely
> AT ALL on the capabilities of the filesystem used to store backups,
> except for those capabilities common to all documented as being
> supported for rdiff-backup servers.  In real terms, this leaves you
> with pretty short names and just about nothing else.
...
> At the extreme, every object gets a serial number which is used as
> its name in the backup store's filesystem.  That serial number is
> used to index into the metadata store, to discover the properties of
> the object as it should be restored, including ownership,
> permissions, extended attributes, NTFS permissions, creation,
> modification and access times and checksums.

This is the direction my original long-filename suggestion was moving,
since the repository filenames/paths don't have much to do with the
source filenames.  Also I think there could be a really great backup
program that worked like this.

But this is basically the way most backup programs work, and from the
beginning the premise of rdiff-backup was that it made a mirror.  The
best backup system that used your scheme would have a different
architecture, and might not have all that much in common with a
mirror+increment system.  (For instance, if I were to your scheme from
scratch I would optimize for random access of older data, so it could
be mounted with FUSE or similar with decent performance.)

> It sidesteps an entire family of problems that arises out of what I
> consider to be a design limitation -- rdiff-backup does not seem to
> have been originally designed to be as cross-platform a utility as
> people would now like it to be.

True, sticking with the "preserve everything, but also make a mirror"
idea leads to extra problems, but solving these new problems can also
be an advantage.  For instance, rdiff-backup has become a pretty
flexible copy/mirroring program that is better than rsync in many
ways.


-- 
Ben Escoto

Attachment: pgpDY0dWu6Ail.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]