[Box Backup] System Backups?

[Ben Summers]

On 1 Dec 2004, at 00:54, Joe Krahn wrote:

> OK, it seems that boxbackup is not really a system backup tool, but a 
> "user data" backup tool, based on the fact that it recommends NOT to 
> backup the root directory. Is it intended NOT to be for full system 
> backups? Or is it just not that far along yet?

You can backup your root if you exclude the mounted directories, and 
then back those up as separate backup locations. The problem is that 
your backup locations shouldn't contain more than one filesystem, as it 
stops the renamed files and directory tracking working.

I really must write the code which detects when you've got it wrong and 
complains, so I can avoid repeating this. :-)

>
> Even though it's lacking in features, the core data design is very 
> good, and all of the mature backup systems are tape based (though I 
> can't understand why...)
>
> Here's my wish list:
>
> 1) Full system backups, including disk partitioning info, and 
> filesystem configuration data.

If you're careful, you can do that now.

>  (An advanced version of this could take advantage of redundancy 
> across systems, where the level zero backup is also a diff against 
> some reference system).

This sounds suspiciously like having a standard image which can be 
recreated automatically, and then only the user data is backed up. This 
is my preferred way of backing up systems, although it's less 
applicable to people with only one machine.

>
> 2) A utility for doing a full or partial restore from outside the 
> native OS (i.e. a mini-Linux recovery CD that can do full backups and 
> restores).

I don't think there would be any difficulty in creating such a thing. 
Box Backup is platform independent (as far as the build scripts allow) 
so should just be considered an element such a recovery CD could use.

My aim for the project is to provide the best backup _engine_, and then 
let others build it into the best _system_. I don't want to tackle more 
than I have time for.

>
> 3) An idea I just thought of: user-land RAID across separate servers. 
> I think of what would happen if a RAID server caught on fire and 
> burned multiple disks. That's why I like the idea of using RAID for 
> backups, rather than trying to set up a live RAID to run on.

You can do this now. Simply have one of the three RAID file systems on 
each server, and NFS mount the other two. Configure the bbstored 
daemons identically, and use round-robin DNS. You'll need fast network 
links between the servers though.

The other alternative is to use rsync on a regular basis to copy the 
encrypted store to a backup server.

>
> 4) don't use just "box" for boxbackup related filenames because it's 
> not very unique or descriptive.  -- /etc/boxbackup is better than 
> /etc/box.
> Actually, I would probably modify the project name to include 
> something about disk-based, redundant, secure backup. One could make a 
> nice acronym from "Scabbard", for example; more unique but also not 
> very descriptive.

There are other projects, all named Box <Something>. Although I admit 
that naming things is not my strong point.

>
> Are these in line with the general plans for the future of boxbackup?

Yes and no. At the moment I'm concentrating on producing a decent 
backup engine. But I will give anyone who wants to produce the tools in 
1 & 2 my full support and add features where required -- it's really 
just a configuration thing rather than something outside the ability of 
Box Backup.

(Apart from Windows, which is a whole different bundle of laughs. The 
native Win32 client will only realistically do data backups.)

> (Except #4 -- which is just an opinion.)

Opinions are welcome too!

Right now what I want to do next is

* Modify the stored files
   - add multiple streams for Mac OS X and Win32
   - support sparse files
   - include stronger cryptographic checksums to detect corruption
* Sort out the ports
   - debug and include Solaris
   - integrate native Win32
   - finish the Mac OS X port by backing up resource forks (I want to 
use it!)
* Emulate tapes
   - being able to efficiently mark multiple states of the file system 
as a check point
   - being able to restore from any checkpoint
* Improve system managements
   - see spec posted and commented in the list archive
* Bash through my list of feature requests

and I think then the engine will be basically complete, and I can then 
move on to looking at other aspects of the system like user UI.

The problem is, as always, time. Unfortunately I have to let projects 
which pay take priority over non-paying work.

Thanks for your enthusiasm for the project.

Ben