Re: [rdiff-backup-users] SpecialFileError, UpdateError

[Chris Wilson]

Hi Felix,

> I intend to set up nightly backups as well, but often I work on sth. 
> important, and then I want to make quick backups, e.g. before taking my 
> laptop out of house.  They should not take more than about 5 minutes.

You might find it easier to have a different backup mechanism in that 
case, maybe combined with rdiff-backup. Something like Subversion or star, 
might suit you very well for small numbers of changed files, while being 
less convenient for whole system backups and restores.

> I haven't tried it yet, but it appears to be quite complex.

That's true, but it does include a remote server component. I would like 
to see the possibility to use DAV, FTP, SSH, NFS, local filesystem, etc. 
for the remote server, to reduce the amount of code in Box Backup itself. 
I hope that I can make some of those happen.

> "star" has numerous advantages:
>
> - It's stable and I've a little test suite that I created for it some
>  time ago.  I trust it very much.

Box Backup also has a test suite and a lot of users. I think there's no 
substitute for regularly comparing your backups and running test restores, 
whatever application you use.

> - Tar files are extremely easy to handle:

I would disagree - my 30 GB system backups would be completely 
unmanageable. I dropped Tar for this reason about 4 years ago and I'm 
still searching for a really good replacement, although rdiff-backup is 
close and Box Backup will be even better when I'm done with it :-)

>  - One can compress and encrypt them at will.

If one has time to compress and encrypt those 30 GB files, and also if one 
doesn't mind that a bad disk block will destroy the remainder of the tar 
file.

>  - The file system containing the backups can be something simple,
>    e.g. a Fat32 file system.

That's true. I'm very close to having Box Backup able to write to a local 
FAT filesystem, at least in principle (it works right now but not all the 
unit tests pass yet). You still need a separate server process for now. I 
hope to eliminate the need for that soon.

>  - One can easily write them to DVDs.

That is true, but the bad sector argument applies here too.

>  - One can easily send data over the Internet, say every week's dump,
>    compressed and encrypted.

But you can't send your full dumps over the Internet unless you don't mind 
tying up your connection for several days.

> - Since only the time stamp of the last backup is needed, one can create
>  incremental backups without having access to the lower level dumps.
>  For example one can create an incremental dump to a little USB memory
>  stick when sitting in the train.

True, and not many other solutions offer that option.

> - It's quite fast.

Box Backup may be faster over an Internet connection, because it uses the 
rsync algorithm to synchronise the (encrypted) data with the remote store, 
so it sends only changed (encrypted) data within files, and not the whole 
file.

> The disadvantage is that it's very cumbersome to get back to old data
> since one has to play back, say, three archives.

At least three, possibly many more, depending on your strategy. I find 
differential backups unworkable because if I make a significant change, 
say adding a few GB of files, it will be multiplied by the number of 
differentials. So I used to run a monthly full backup and daily 
incrementals. But in case of a disaster, I would have had to unpack about 
15 archives on average. In case of needing a particular file, I had to 
search 15 archives on average.

Extracting one file from a compressed or encrypted archive requires you to 
uncompress/unencrypt half the archive on average, which can be a lot of 
data, and makes restores very slow as well.

Cheers, Chris.
--
_ ___ __     _
 / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |