Disk imaging, &@!#!!$ Partimage and Arconis

[beaker_]

I've been bouncing off the walls trying to recover a machine from a partimage (by partimage, yeah I did the mbr & 0'd it just for giggles) but it restores a busted partition. Chkdsk -f ends with win dumping bad hall.dll durring boot so I was about to jump onto the Acronis bandwagon (yes two images different formats) but it just dies when I try restore to the hd. It's funny, no problems in a virtual machine though. So I'm going to the moon and back; tib --to-- vdi --to-- RAW via dd --to-- /dev/sda via dd, and I'm racing it with another machine; tib --to-- vdi --to--RAW via VBoxManage --to-- /dev/sda via dd.

Anyway, what do you guys swear by? i.e., I'm about ready to start using dd and gzip as I don't see the wisdom of imaging with propitiatory formats and partimage isn't trustworthy on ntfs. Alteast 50% of the time i.e.,

[cadillackid]

I simply use ddrescue (not plain dd) and pipe it into gzip.. yes it takes a long time because it reads the whole disk and pipes it.. but ive never had an image that wasnt bootable on the new drive...


I had issdues getting partimage to do what I wanted it to do and getting images to boot... same also applied to just plain DD.. but ddrescue works good (both variants... ddrescue and dd_rescue)..

I boot my system using "system rescue cd" or from the network with a boot image of system rescue cd on my PXE server... mount my backup drive and ddrescue away..

-Christopher

[bodhi.zazen]

Personally I keep a /data partition and care less about making an image of the OS.

Far easier to re-install an OS and then restore the data.

If I want an image of a partition I personally use dd .

The "problem" with backups, you need to test them. Many people run some application or command and do not confirm the backup works, only to find the backup fails when then "need" to restore.

[stoat]

Originally Posted by beaker_

...what do you guys swear by? i.e., I'm about ready to start using dd and gzip as I don't see the wisdom of imaging with propitiatory formats and partimage isn't trustworthy on ntfs.

Hello everybody,

Consider tar for cloning partitions and systems. It doesn't create an image in the usual sense of the word. It just copies the files. But here's why I like it better than dd for cloning (and backing up) partitions and systems.

dd copies sectors including the superblock and all of the backup superblocks which have the wrong metadata for the cloned partition (unless it's a backup being restored to the same partition). Don't forget to fix those with the usual utilities after using dd to clone. tar just copies the files of the old system into a waiting new and healthy filesystem.

dd can't clone to a smaller partition. And when dd-ing to a larger partition (almost always the case), remember that you also need to resize the filesystem of the clone. BTW, I my experiments, resizing the filesystem after dd-ing a clone will fix all of the backup superblocks. fsck only fixed the primary superblock (in my experiments).

tar takes less time because it's copying files instead of all of the partition's sectors (comparable time to Acronis, IMO). And if you want to create a tarball to use as a backup and/or to create a clone (instead of piping directly to another tar command), then the tarball is smaller than the dd binary for the same reason and can be reduced further by zipping it.

Tarball backups of partitions easily can be browsed with Xarchiver in a file manager sort of like True Image can do to a .tib file. Not much you can do in that regard with a dd binary. Nothing actually.

I've used cp with good results in cloning systems, too. And other methods advocated by people are rsync, cpio, dump and restore. I haven't tried those, but I don't need to.

P.S.: I still use Acronis True Image to image Windows systems. I bought it, so I still use it. But only on Windows and NTFS partitions.

[droidhacker]

Actually, the solution to dd is to zero out all your free space prior to dd'ing.
dd if=/dev/zero of=/some/file/in/the/filesystem; sync

NOW, you may or may not use gzip -- your choice. What you DO do though, is create a SPARSE file....
dd if=/dev/thepartition | cp --sparse=always /dev/stdin /path/to/file
or
dd if=/dev/thepartition | gzip -f | cp --sparse=always /dev/stdin /path/to/file

A sparse file is one where all those long sections of empty 0's will be collapsed down into virtually nothing.

Since it is a sparse file, it is (unless the disk is really full) going to be small enough to manipulate, including SHRINKING if needed.


Note: filling empty space with zeros and storing sparse will take less space than NOT filling with zeros and gzipping. Applying both will obviously be the smallest.