Thanks for the information, Dave Dodge wrote: > I don't really have any answers, just comments: > > On Sun, Sep 24, 2006 at 04:32:18PM +0200, Jelle de Jong wrote: >> Output must result in a one file image that can be mounted and read with >> the mount tool. (like a dd image) > > This requirement complicates things, because it means the kernel has > to be able to read your backup format. Using an existing filesystem > format may not solve your problems because they're unlikely to have > the space efficiency that you're after. Your best solution here might > be a custom format with a custom FUSE backend. > >> All file stored in the image must come out like they came in (not like >> some standard iso image) > > I'll complicate this further by adding some special cases that can be > trouble: > > - Large sparse files. Many Unix-style filesystems will allow you to > create files that appear to be many times larger than all > available disk space. I used to have 1.44M floppy disks with > 30-40 gigabytes of files on each of them. If you try to copy > these by opening and reading them you have to be careful to not > converting the missing blocks from the original into real blocks > in the copy; otherwise you end up using more disk space or even > running out entirely. > > - Files with multiple hard links. Ideally your backup and restore > procedure should preserve the links. > > - If you back up on one machine and restore on another, what happens > when the UID and GID values don't match on the two machines? Do > you need to record the user and group names rather than (or in > addition to) the UID/GID values? > > - Extended attributes. These become important in situations such as > using SELinux. > >> But this will not cover the split an join function. > > Unionfs might help with that. > > -Dave Dodge >
-- xubuntu-devel mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/xubuntu-devel
