Need some help with my backup idea.

[Dave Dodge]

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