On 5/5/2011 9:37 AM, Lamar Owen wrote:
>
>> Different block mappings will also give you grief.
>> .:. The drives must be identical manufacturer and model, down to the
>> firmware revision.
>> dd is not a backup tool in the general sense.
>
> I do dd imaging quite frequently, and as long as everything is LBA48 capable and setup, I don't have problems copying partitions or whole drives between multiple drives of different sizes and manufacturers; even in instances between different interface technologies. This gets better once you're on an OS rev that treats ATA drives as SCSI, and CHS is no longer in play at all, which is the case in EL6 and Fedora revs around EL6. (At least I think that's correct; but it has been an awfully long time since I've done a CentOS 4 or 5 install on an ATA/IDE system, as all of my server systems are either SCSI or FibreChannel, physical or virtual).
Clonezilla-live is a handy, faster way to do this. It boots from cd/usb
into a menu and generally uses partclone to do the work so on most
filesystems it only copies the blocks that are actually used. It also
has a mode to resize the partitions on the new disk but it isn't all
that useful because you can't control them individually.
> Having said that, I quarterly rotate two identical drives in this laptop; each quarter, I clone the currently operating drive to the secondary and to a dated whole-disk image file, and then swap the drives, putting the previous primary back into the fire safe for storage. This both wear-levels and tests the backups drives.
Besides disk->disk, clonezilla can save/restore compressed image copies
over the network to space mounted via nfs/samba/sshfs so if you are
making the copy as a backup or the source for future clones you can drop
it on some other filesystem instead of needing a matching disk.
> I use a three-tiered approach to backups of my own laptop:
> 1.) Quarterly swapping drive clones as described above, using dd (which is faster than the slightly more friendly ddrescue, unless a bad sector is found) booted from rescue or live media of the OS that's installed (this provides a fast bare-metal base recovery that I can then update and restore from the rolling rsync in item 3);
> 2.) Three quarters of kept images along with the partition mapping (I use GPT, and thus use gdisk for this, which works better in my particular case than parted does (parted puts an inappropriate partition type on one of my partitions when recreating the partition map)) on multiple disks;
> 3.) Frequent rsyncs of /home and /etc to multiple drives, in rotation. This does mean an SELinux relabel might be required on a restore, but that's ok.
>
> For servers I do the same, but with annual images and more rigorous scheduling of tarballs of important files, along with rolling rsyncs (I've looked at rsnapshot, and backing up the backup can be somewhat interesting in that case). Dump/restore has its advantages, too, however.
I always recommend backuppc for scheduled backups. It's pretty much
configure and forget and it compresses and pools all identical content
so you can keep much more history online than you would expect.
--
Les Mikesell
lesmikesell at gmail.com