On Saturday 12 November 2005 08:22, Ben Escoto wrote: > So, any comments? Anyone see any other drawbacks/problems?
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. Instead, use the backup store's filesystem only to store the data associated with backed up objects (files, directories and links), and use metadata to express all other attributes of those objects. 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. Directories can be virtualized in the same way. This addresses more than just long filenames. It also addresses my "Write-once read-many problem" issue, as well as the issue of rdiff-backup losing permissions when backing up from NTFS to UFS and then restoring back to NTFS. 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. This is one of the challenges that successful software inevitably faces. :-) Ciao, Sheldon.
pgpQYBttH2lOy.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
