Storing Disk Images on CD?

[MMM]

Your web site says this about SuperDuper:

Please note that SuperDuper! is not designed to back up to CDs, DVDs or Tape, and needs a location to store the backup - typically a volume on an internal or external (FireWire) drive.

Does this mean that you can't store a disk image on a CD (for storage purposes only)? We do not want to run the disk image from the CD, just store (backup) the disk image on a CD, and then copy it back to the hard drive if it's ever needed. Can we do this?

[dnanian]

Although we're not designed to back up directly to optical media, you can certainly take an image -- which is, after all, just a file -- and burn it to a DVD or CD. The main problem is that the image might exceed the DVD or CD's capacity, and splitting it into multiple segments can be a hassle.

[MMM]

Our Mac is hooked up to our PC via firewire. Is there any reason why we couldn't store the disk image somewhere on the PC?

[dnanian]

If the PC's disk is formatted as NTFS, it should work. But not if it's FAT32: there's a 4 GB file size limit that you'll run into.

I'm not sure how you hooked these machines together with FireWire, though!

[MMM]

Yes the PC has XP Pro on it and is running NTFS. As for the firewire hookup, we bought a cable and connected both computers together. We did the same thing with Ethernet on both machines. We'd really love to buy SuperDuper, and that's saying a lot because we don't usually like buying software Plus, Dave seems to be not only a great coder, but a great human being The ONLY thing that's holding us back is the ability to backup to DVD's. We'd buy it now if we knew that this feature was going to be included in the new 2.0 version, but we can't find a list of new features that will be on 2.0. Any chance of this DVD dream coming true?

[dnanian]

No chance of the DVD dream coming true, MMM, sorry. We're trying to focus on bootable backups, since they give the user the easiest way to maintain their backup and the best way of restoring/recovering in the event of a failure...

Sorry to disappoint!

[Winston]

Originally Posted by dnanian

We're trying to focus on bootable backups, since they give the user the easiest way to maintain their backup and the best way of restoring/recovering in the event of a failure...

After running into a "not enough room" error when trying to create a disk image I have a couple of thoughts:

1. There should be an option within SD! to create sparse images.
This is important because sparse images can be easily updated, but do not need to run other things off of a backup drive, or add confusion to one.

2. SD! should check the size of the destination drive before "agreeing" to make a disk image backup. The disk image backup process creates two disk images, first a sparse image, then a DMG image. This takes twice as much space as the original being backed up.

As a result, you cannot make a disk image backup to a drive the same size as the original drive if the original is more than half full.

This has proved to be a big problem for me.

Automatically offering a sparse image as an alternative when there is not enought disk space to create a DMG would have saved me from several fruitless backups.

3. Why can't SD! let us use the sparse image it creates before it makes the DMG image if there is not enough room for the sparse image?

- Winston

[dnanian]

Thanks for the suggestions, Winston. While we don't check the disk space in v2.0 (to actually check the space, you need to know what's being backed up, and since the scripts can select an arbitrary amount of data, you'd have to simulate the script first, which would take a long time to do), we do allow sparse images to be created and updated right from the Disk Image panel...

[Winston]

Originally Posted by dnanian

... we do allow sparse images to be created and updated right from the Disk Image panel...

Thanks for the clarification. I thought from the FAQ here:
http://www.shirt-pocket.com/forums/showthread.php?t=81

So, as discussed in the last entry, you can't "update" a DMG created by SuperDuper! with additional files, because it's read-only. However, with a few additional steps, you can manually create an image that can be updated by SuperDuper! just like any other volume.

Here's how! (Note: I'm assuming that you're using Panther in the following instructions... the steps might be slightly different under Jaguar.)

This first set of steps need only be done one time, when you initially create the image:

1. Open Disk Utility (found in /Applications/Utilities).

that SD! did not create sparse images (independently of DMG images).

- Winston

[Winston]

Originally Posted by dnanian

... we don't check the disk space in v2.0 (to actually check the space, you need to know what's being backed up, and since the scripts can select an arbitrary amount of data, you'd have to simulate the script first, which would take a long time to do) ...

SD! appears to make a sparse image before it makes the DMG image. Since the size of the sparse image is known before the DMG image is created, could SD! check the space available before starting the DMG image?

Then SD! could offer the user a chance to stop, but keep the sparse image (assuming the sparse image is a workable backup).

- Winston

[dnanian]

Winston -- v2.0 allows sparse images to be created, but it's not released yet. v1.5.5 only allows DMGs.

The whole thing is that a sparse image is just that: sparse. We can guess high when we create it, because only takes as much space as the data that's eventually copied to it. Guessing high when actually "testing" for size would mean we'd reject legitimate creation.

[Winston]

Originally Posted by dnanian

Winston -- v2.0 allows sparse images to be created, but it's not released yet. v1.5.5 only allows DMGs.

The whole thing is that a sparse image is just that: sparse. We can guess high when we create it, because only takes as much space as the data that's eventually copied to it. Guessing high when actually "testing" for size would mean we'd reject legitimate creation.

I don't quite follow you. I don't understand about the "guessing high" on a sparse image vs. "when actually "testing" for size".

Let's say you are doing a complete backup of a drive. If you know the space used on the original drive, then don't you know pretty closely how much space the sparse image will take?

SD! does not have to reject creating a backup. It could give a warning to the user that a backup might fail to happen if there is not enough space. I have had a failure to back up happen about 5 times using SD! (in part because I did not know about the need for extra space).

I have several backup drives, each with varying amounts of other data backed up on them. This is why I like using disk images - they keep the backups neat and separate. They also leave me with varying amounts of free space.

I am glad you will add a direct way to back up to a sparse image. Needing to have double the space to make a disk image backup is a big limit on my ability to back up to the drives I have.


How close is the tolerance from the original to the DMG? The disk image backup I stopped two days ago had 7GB on the sparse image, and was at something around 5GB on the DMG image - at highest compression. I understand that it may be hard to estimate the exact size of the DMG. What is the range? Is it from 90% to 100% of the original, or 30% to 100%?

It seems like SD!'s main focus is on recovering from corruption on the original drive, rather than mechanical failure.

The only major problems I have had with a drive have been mechanical failures. A running backup to a sparse image strikes me as a far better backup than having fixed backup to a DMG image. Ditto vs. the "Safety Clone" backup.

Would a Safety Clone have helped with the two catastrophic drive failures I have had? These are the only situations where I lost a significant amount of stuff (and really lost it - drive recovery specialists could not get anything off of the drive).


Thanks.

- Winston

[dnanian]

No, we don't know how much space the backup is going to take. We know how much it's going to take at a maximum. But, the script can select out one or two files, or more, or whatever, and we don't know what it's going to do without running it, which involves scanning the entire drive. Does that make more sense?

Regarding compression, I truly have no idea. It's all Apple's code, and it does what it does. It's going to completely depend on what you've got in the source.

SD! main focus is twofold. Real "Backups" -- i.e. "Backup - all files" are absolutely designed to deal with mechanical failure. They're bootable, when stored on a supported boot device, and are easily restored in part or in full.

The Safety Clone/Sandbox, on the other hand, is designed to isolate your OS from unwanted changes during software installs (including OS upgrades). By running from the Safety Clone, you can easily boot back to the original OS without losing changes to your real data. But they're not backups, at all, and wouldn't help to recover from any sort of physical damage.

[Winston]

Sorry, I not be following something.

Let's say I want to do a full, uncompressed, back up of all files on the hard drive on one computer. I have (or can get) a very good idea of how much space is used by files on that drive.

How does SuperDuper!'s "script" leave things out that would significantly reduce the size of the backup?

Why would the backup not be very close to the size of the original?

How could the backup be significantly smaller than the original?

Thanks.

- Winston

[dnanian]

Virtual memory swap files and temporary files can be quite large. On top of that, we don't know that you're making a full backup. We just know you're running a script... and that script could be doing anything at all.