[Top][All Lists]
[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
pgpDY0dWu6Ail.pgp
Description: PGP signature