Running Linux, 5th Edition - Matthias Kalle Dalheimer [475]
Here's how to create an ISO 9660 image and burn it to CD. Let's say you have a directory called /data that you want to put on CD. Enter:
# mkisofs -T -r -o /tmp/mycd.iso /data
#cdrecord -v -eject -fs=4M speed=8 dev=0,0,0 /tmp/mycd.iso
Some of the parameters of cdrecord are system-specific. You can run cdrecord -scanbus to search for the CD burner on your machine. On the machine used for testing the material in this section, the CD burner shows up as device 0,0,0. Even though the author has a 52 × burner, he still chooses to record CDs at only 8 ×, to make sure he doesn't underflow the drive and make a bad disk. Experiment with your hardware and determine what works—you may or may not be able to burn reliably at higher speeds.
A slick, if somewhat less reliable, way to create a CD without writing an image file first is to simply pipe the output of mkisofs directly to cdrecord:
mkisofs -T -r /data | cdrecord -v -eject -fs=4M speed=8 dev=0,0,0 -
That's not the only possible optimization. If, for some reason, you wanted to treat a CD like a tape, you could skip creating an ISO 9660 filesystem, and just write a tar file directly to a CD. This won't be mountable as a normal CD, and you won't be able to put it in a Windows system, but if you prefer this, it works:
tar -czf - /data | cdrecord -v -eject -fs=4M speed=8 dev=0,0,0 -
It is important to note that although CD burners are much better than they were a few years ago, it's still quite possible to produce a useless disk if there is anything more than a brief interruption in the flow of data from the source to the burner. These problems are even more apparent when burning from a pipeline as in the last two examples. For this reason, we urge you to check your backups after making them!
In addition to cdrecord, tar, and mkisofs, there are a large number of other programs available on the Web that provide an easy-to-use frontend for creating backups. Some of them are able to span multiple CDs, or manage a rotation of CD-RW disks. If you find that creating CD backups as we've described here doesn't fit your needs, chances are someone has created another program that will work for you.
Backing up to hard disks
As hard disks get bigger and cheaper, one problem is that backup media often don't keep up. Now that 500-GB hard disks are available and affordable by normal people, it may have occurred to you that the only thing you can back a disk that big up to is...another disk that big!
Just about all of the techniques you can use for media in general can apply to hard disks, but there are a few special considerations as well.
If you have a disk mounted at /data, and you want to back it up to a second hard disk (of equal or greater size) mounted at /backup, you could do a tar and un-tar pipeline, like this:
cd / ; tar -cvf - /data | (cd /backup ; tar -xf -)
If you have room on your backup disk, you can use the remaining space to store incremental backups using the techniques described elsewhere in this chapter. The nice thing about hard disk backups is that you can create any kind of directory structure that makes sense to you. You could have a disk mounted at /backup, with subdirectories /backup/full and /backup/incremental, or any other scheme you choose.
With a combination of find, cron, tar, and gzip, you could create a fairly small but powerful script that would mount your backup hard disk, tar up the files that have changed since the last time your backup ran, delete the backups older than the last full backup, and unmount the backup disk.
To compress or not to compress?
There are good arguments both for and against compression of tar archives when making backups. The overall problem is that neither tar nor the compression tools gzip and bzip2 are particularly fault-tolerant, no matter how convenient they are. Although compression using gzip or bzip2 can greatly reduce the amount of backup media required