How shall I do backups?

[ciphergoth]

OK, I've used DAR long enough to know that it's fundamentally broken. I just gave up on it at the point where I'd written CD 1 of a two CD archive, and said "please test the integrity of this slice of the archive". It responded "last slice is not present, please provide before integrity can be tested".

So I'm not using that any more.

What the hell can I use that does proper multi-archive backups for CDs?

Comments

[ex-meta.livejournal.com]

I wish I knew. Most backup software is fundamentally badly designed. I keep thinking I should write some that actually works properly, based on my experience working in data recovery...

[zz]

if you find something, please let me know :)

time for dvd-r maybe?

[ciphergoth.livejournal.com]

I have been thinking myself about what a replacement should look like...

[lovingboth]

Ghost can cope with Linux partititions (although it writes them as a lump rather than just the 'useful bits' as it can with FAT etc) and I expect Drive Image can too.

But they both run on DOS...

[ciphergoth.livejournal.com]

You're full of helpful advice...

comment from DAR's author

[(Anonymous)]

I like your feedback! By mistake I found it here. Sorry to reply to it:

for information, DAR does the test of a *whole* archive. After the "long enough time you've spent", I don't know where you have seen that it can make the testing of a single slice (this is a non sense as a given file inside the archive could be split between two or more slices, and CRC is computed file by file). As usual, dar starts by the first slice, then it needs the last.

OK, I Promise, if I find again (by mistake of course) one of your feedback, I will not reply to it :-)

Denis Corbin.

Re: comment from DAR's author

[ex-meta.livejournal.com]

Technically, it's perfectly possible to test each chunk of archive as you go. Just MD5 checksum the chunk as you write it, go back and re-read the data and compare the checksum.

Nothing wrong with file-by-file checksums, but you might as well waste 128 bits per CD and do a chunk-by-chunk checksum too to make the user's life easier.

Re: comment from DAR's author

[ciphergoth.livejournal.com]

*egg on face*

I'll write up my thoughts on what I think the ideal backup utility would look like at some point but I tend to think that while it can be nice to write to authors to say "here, your program can be improved like this", there's not a lot of point in saying "your program has a mistake at the very deepest level of its design" because there's not a lot they can do about it...

Still I will write it and send it to you. Once I've got speech recognition going. Once I've reinstalled windows. Once I've backed up the laptop... you see my problem...

DAR is still the best there is - if I want something better, me and meta will just have to write it! :-)

[lovingboth]

The thought process went something like a) they work, b) it'd only take a couple of MB to have such a partition (in fact, at least one of them runs off a floppy boot disk), c) they work, d) I'm not aware of anything that properly backs up files in use, so you have to take the machine down anyway, e) they work.

Still, for some people, working is a low priority. I should know...

[ciphergoth.livejournal.com]

Making a raw dump of the partition can be done perfectly well with "dd"... I want something which supports eg extraction of individual files from the archive.

Re: comment from DAR's author

[(Anonymous)]

yes, you are right, it could be possible to add a secondary CRC global to each slice. This would allow the testing of each slice individualy.

For me it is just a simple feature to add, not really the "mistake at the very deepest level of its design" I 've read previously. 8^D

Anyway, thanks for feedback.

Denis Corbin.

[skx.livejournal.com]

 If you do have some idea's it'd be good to share.

 I've been thinking about decent backup software for the past few days - partly inspired by your difficulty in finding something, and partly as a result of not finding a good network backup tool.

 Currently I'm using a tape drive and rsync. IT doesn't scale well and gets intricate when you've got N hosts - contention is a real problem. I don't believe I could restore any single file easily; the tape drive is in use pretty much 100% of the day :(

 OK half the problem is host N copies to drive; then N+1; then we wait for tape change. I guess I should be getting all the hosts to copy to "server" then dump that to the drive - problem is $server doesn't have the diskspace for the complete contents of a tape :(

Re: comment from DAR's author

[ciphergoth.livejournal.com]

Sure, but I think it indicates that you and I think of slices in a different way. You mainly think about operating on all slices of the archive simultaneously. I generally don't have the disk space to store them all at once. You think of slices as fragments of a whole. I think of them as largely independent collections of file information that happened to come from the same archiving operation. I think my approach is the correct one because it makes an individual slice much more useful.

I thought you CRC'd each file separately, no?