On 5/5/2011 11:11 AM, Lamar Owen wrote:
>
>>> I do dd imaging quite frequently, and as long as everything is LBA48 capable and setup, [snippage] .... using dd .... booted from rescue or live media of the OS that's installed...
>
>> Clonezilla-live is a handy, faster way to do this.
>
> I've recast my original message slightly, as you've missed a critical point: I use the cloning tool from the rescue or live media of the OS that's installed. There are a number of reasons for this, not the least of which is that LVM, RAID, and some other things behave differently depending upon the kernel, lvm tools, etc, that's running the clone.
I generally try to avoid layers that are likely to have breakage between
different versions. Backwards compatibility is a good thing, as is the
ability to move disks around among different hosts.
That said, Clonezilla doesn't deal with software raid in the disk image
mode - even raid1 where it should be simple. You can do single
partitions at a time though, and then it is agnostic about the
underlying layers but you have to deal with making it bootable yourself.
> I'm familiar with and have used clonezilla numerous times, but not for this purpose. The 'using dd ... booted from rescue or live media of the OS that's installed' part isn't as important during backup as it can be during restore. And I have been bit by that, using F12 (or 13) live media to do a C4 backup/restore; some metadata got farkled and the restore didn't 'take' until I did the restore with C4 media.
Yeah, I avoid fedora too...
But, how would you deal with a dual-boot disk with different OS's on the
same drive?
> [snip]
>
>> 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.
>
> I've actually thought about using DragonFly BSD and its HAMMER filesystem for the backup storage device...... quick restores rely on quickly finding what is needed, and many times I get requests like 'please restore the file that has the stuff about the instrument we built for grant so-and-so' rather than an exact filename; greppability of the backup set is a must for us. Complete, straight-dd, clones are mountable (RO, of course) and searchable, and rolling rsyncs and tarballs are searchable without a whole lot of effort. Deduplication would be nice, but it's secondary, as is the time and space spent on the backup, for our purposes.
With backuppc, just give them a login to the web side with access to
their own machine and let them pick any/all versions they want (you can
download through the browser or restore it back where it came from). If
you really need to manage versioning based on
content/differences/context the stuff should live in subversion or git
with an associated status tracking system. But then you have the
opposite problem of how to get rid of it when you really don't need it
any more...
--
Les Mikesell
lesmikesell at gmail.com