on the edge

computers & technology, books & writing, civilisation & society, cars & stuff


Greg Black

gjb at gbch dot net
Home page
Blog front page


If you’re not living life on the edge, you’re taking up too much space.


FQE30 at speed



Syndication / Categories

  All
   Announce
   Arts
   Books
   Cars
   Family
   House
   Meta
   People
   Places
   Random
   Society
   Software
   Technology
   Writing



Worthy organisations

Amnesty International Australia — global defenders of human rights

global defenders of human rights


Médecins Sans Frontières — help us save lives around the world

Médecins Sans Frontières - help us save lives around the world


Electronic Frontiers Australia — protecting and promoting on-line civil liberties in Australia

Electronic Frontiers Australia



Blogroll

(Coming soon…)



Software resources


GNU Emacs


blosxom


The FreeBSD Project

Fri, 15 Oct 2004

Linux dump(8)

Jason has written about some problems with dump(8) under Linux:

I am just now discovering why dump isn’t up to the task: It lacks a simple way to write a backup image to multiple destinations at once. […] My current workaround is something like this:

      dump -0aq -f - | tee /dev/ntape | bzip2 > file

Unfortunately this has the side effect of reducing the speed of the dump to about one quarter its usual speed; given that in general one wants to keep the tape moving to reduce wear, this is decidedly suboptimal.

While I can see that the proposed solution is far from ideal, I’m surprised that Jason has not, apparently, tried the canonical solution to the tape writing problem—dd(1). I would be trying something like the following:

      mkfifo /tmp/fifo
      dump -0a -f - / 2>/tmp/dump.log | 
          tee /tmp/fifo | nice -20 bzip2 >/tmp/dump.bz2 &
      dd if=/tmp/fifo of=/dev/ntape bs=8m

In the above, you’d substitute suitable paths and you’d experiment with the blocksize value for dd until you had your tape streaming.

It’s also quite possible that Jason’s particular hardware just cannot manage both the bzip2 work and the tape writing fast enough to stream the tape, no matter how clever we are with tricks such as the above. There is another solution, of course. Since any sane backup strategy involves reading back the tape to make sure that it’s usable, he could just stream to the tape with dd(1) and—while reading the tape back for his verification run—he could save the data to a file, test it, and only then compress it. This won’t work if the disk storage is inadequate, but that is at least easy and cheap to fix.