cdbkup FAQ

CDBKUP Home

Contents

What is it?

cdbkup is a utility for backing up filesystems onto CD-Rs or CD-RWs.

Where can I get it?

Download the latest file releases from the Sourceforge download page, or browse the current CVS tree.

Where can I find more information?

Full documentation is available on the cdbkup Home Page. Be sure to read through the manual pages.

How much temporary disk space is needed?

Short answer:
About 700 Mb of free disk space (the size of one CD).

Long answer:
When backing up to CDs, cdbkup needs at most the lesser of

  1. the total size of the compressed backup image; and
  2. the maximum amount of free space on any of the target CDs.
When doing a remote backup, no free disk space is needed on the source machine. When backing up to disk (using the --test option), you'll need enough space to store the entire backup.

How reliable is the backup?

It's still a young program, and I haven't received too much feedback from users, but it seems quite reliable. The reliability is mostly dependent on the reliability of your CD writer. But for technical reasons, it can not be trusted for backing up live databases.

Can I use it to back up a live database?

No, you cannot. cdbkup uses tar to walk through the filesystem, archiving files as it goes. Any random access file, or system of interrelated files is likely to be backed up in an inconsistent state.

Why am I getting "Cannot stat: No such file or directory" errors?

This error occurs when you are backing up a filesystem that is in the process of changing. In particular, tar indexes certain temporary files of another process, then when it comes time to write them out, they no longer exist.

The problem is non-fatal, and it is only skipping files that were going to be deleted anyway, so it is nothing to worry about.

You can usually avoid these messages by scheduling your backups at a time when there are no other big jobs happening. Alternately, you can use the --exclude option to exclude whichever directory the temporary files are in.

Can I use it to back up a remote Windows machine?

The best way to back up a Windows machine is to share the drive, then mount it on your *nix machine using smbfs. That way, cdbkup sees it as a local disk.

The --host option is only for backing up via SSH at the moment, so it's not really useful for Windows machines.

Can I back up a filesystem onto my hard disk instead of to a CD-R?

The --test option causes cdbkup to write the tarball into one or more disk files in the current directory. The CD writer is not needed with this option. See cdbkup (1) for more details.

How can I get cdbkup to archive more than one filesystem?

This is a common request since many people have /home and /usr on separate partitions from the root partition, or other similar setups. By default, cdbkup skips over directories that reside on other filesystems.

The --cross-mp (-m) option tells cdbkup to include these mount points as though they were plain subdirectories. See cdbkup (1) for more details.

How do I restore individual files from a backup?

This is easy to do, but not very efficient, since the archives are in tar format, and usually compressed.

To restore /etc/file1 and /root/file2 into the directory /tmp/restore, use the following: 

   mkdir -p /tmp/restore
   cd /tmp/restore
   cdcat | tar xvfz - ./etc/file1 ./root/file2
This assumes that gzip compression was used. Otherwise, change the tar options to xvfj (for bzip2 compression) or xvf (for no compression).

How does cdbkup keep track of dump levels

cdbkup uses GNU tar's incremental backup facility in order to implement backup levels. It does this by storing .snar files for each backup level in /var/local/cdbkup.

Why did cdrstr delete files from my hard disk?

cdrstr restores its target directory to the exact state of the backed-up filesystem at the time of the backup. This may include either deleting or overwriting any files that were in that directory to begin with. Therefore, it is crucial that the target directory be initially empty.

Briefly, since cdrstr handles incremental restores, it must assume that the files in the target directory were created by an earlier stage of the incremental restore, and were deleted from the original filesystem between the times that the two backup levels were created. Hence, the higher level restore considers itself responsible for deleting those files.

Thanks to Michael D. Hughes for raising and diagnosing this issue.

SourceForge Logo