Will backing up a game CD/DVD work like this?

Question

I recently heard that CDs and DVDs "go bad" after extended periods of time. Initially this was a problem for me because I couldn't write boot disks for new Linux distributions (at least until I get new writeable disks), but then I remembered some Windows games I have that might become unreadable by the time I get access to a Windows system again.

I decided to make compressed backup files using this command line:

dd if=/dev/cdrom | lrzip -l -H -o output.lzo

I've never actually done this before, and I can't test it, so I just want to know if I will be able to write this image to a new disk if the old one stops working.

Now that I've asked, I wonder how I'll be able to write it too. Will de-compressing this image result in an ISO file that I can write with wodim, or will I need some other method?

Answer 1

First, the simplest thing to do is to just use dd. So, skip the compression until you have it working with dd by itself.

dd if=/dev/cdrom of=/path/to/good_name_of_cdrom.img bs=64k

Then you should be able to test this img to make sure it copied well.

mkdir /path/to/mount_point/
mount -o loop /path/to/good_name_of_cdrom.img /path/to/mount_point/
cd /path/to/mount_point/

The files on the cdrom should be available at the /path/to/mount_point.

Answer 2

After further research I discovered that using dd to copy CDs is actually a very common practice. Normally people direct the output to a file with the .iso extention and set the block size to the disk's block size, but technically I was creating an LZO-compressed ISO file.

Now that I know this, I advise anyone who was in the same position I was in when I asked this question to use this command line instead:

dd if=/dev/cdrom of=/path/to/image.iso bs=2048

Creating the ISO file without immediately compressing it allows an opportunity to check the file's integrity first. In my original command line, I was using LZO compression because I heard it was faster than copying; I may have been mislead there, because the reader still operated in bursts. Either way, I now plan to compress in a second step.

The bs option seems to be mostly a formality, but matching the block size of the medium (which can be found by running isoinfo on the device) is generally a good practice.

If the disk is damaged and parts of it won't read, the program ddrescue can be used in place of dd. Without any extra options it should recover more data than dd. It also has more advanced options that could help in more serious situations, and would then be worth researching.

EDIT: ddrescue (or perhaps just the GNU version of ddrescue) now uses a different command-line structure than it did when my first source here was written, so it can't be simply swapped in to replace dd. It isused more like ddrescue -b 2048 /dev/cdrom /path/to/image.iso /path/to/log.log

sources:

http://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/How_To_Do_Eveything_With_DD?s=9f6a3b4e664ac979e8d3a1643ca253f5

http://www.linuxjournal.com/content/archiving-cds-iso-commandline