using dd to backup/restore windows partition
 

what's the best way to do this???


windows is /dev/hda1

linux is /dev/hda5

swap is /dev/hda6

/home is /dev/hda7


i'm doing this (inside my homefolder) to create the image:

dd if=/dev/hda1 of=backup.img


and then this to restore windows:

dd if=backup.img of=/dev/hda1



it works fine, but the problem is the restore is SUPER SLOW, and it's something i need to do quite often...

how can i speed things up a little???

Well dd does a byte for byte backup of the entire partition including free space. And therefore you are restoring byte for byte. Do you really need to do this often? What do you really need to backup?

Try this: http://www.partimage.org/.

BTW partimage is still experimental for NTFS

well, i need to be able to restore the entire windows to like-new whenever needed... sometimes this is needed a few times a day, but it depends... the reason is the usual round of viruses, spyware, adware, porn progz, etc. that the hostile users (cybercafe environment) install...

i've been doing alright with dd, but it's slow speed is causing me trouble cuz clients (the human ones, not the software ones) get fed-up of waiting for restores to finish after hostile user "X" vandalized the whole windows desktop or whatever... lol...

i'm taking a look at partimage, it looks real sweet... probably just what i need... i gotta read-up on it though... thanks a lot for that link...

i'm guessing there's no way to give dd a couple modifiers or something to make it skip free space???

thanks for your help guys, i really appreciate it...

You hint at something like the reading of the windows partition is faster than writing it back?!? Should that be the case, then there is something fishy going on, I mean it is all on the same physical volume (hda), isn't it, so it can't be disabled DMA or something.

Ever tried as a means to flush all buffers before writing back the windows partition?

ummm... i do??? well, the truth is the time it takes to make the image is not as important to me as the time it takes to restore it... i only create a new image about once a month or so...


i think it's been established that what makes dd so slow at this is the fact it restores everything, including blank space...



no, i haven't tried it... i just read the man page for sync and i'm not exactly sure that it's something that i really need...


-------------------------------------------
-------------------------------------------




i used to use tar to restore winblows, sorta like this:


CREATE (about once a month, after doing all the usual critical updates and stuff):

tar -cf /home/win32sux/backup.tar /mnt/windows/*


RESTORE (several times per day):

rm -fr /mnt/windows/*

tar -xf /home/win32sux/backup.tar -C /mnt/windows/


this also worked okay and was quite fast (WAY faster than dd), however it had some drawbacks... sometimes it seemed like the windows partition would get screwed-up (perhaps virus, hostile user or whatever) and then linux would have problems accessing the windows partition to copy the fresh files... so i'd have to re-format the windows partition and do the tar -xf again... and then i'd still have to use the winxp rescue cd recovery console thinggy to do a "fixboot" so windows could boot again... this happened a couple times a month and was a major pain...

with dd i never have to use fixboot or anything like that... even if a hostle windows user formats "c:", dd would take care of everything in one step...

i'm wondering if perhaps a "mixture" of the tar method with the dd method might work...

i'm thinking perhaps i can create an image, using dd, of the "boot sector" (is that what it's called?) of the windows partition ONLY (it's like the first 512 bytes or something, right???), and then a tarball of the files and stuff... so restoration would be three steps:

1- re-format fat32 partition

2- dump (using dd) the boot sector image into the partition

3- untar the files to the windows partition


does this sound plausible???

Sorry, my mistake.

No, not really. Fact is, that dd has some defaults, which do not necessarily fit with your hardware. E.g. you might want to optimize the block size dd is using with regards to the buffer size of your hard disk(s). Also, the physical place of the data on your hard disk determines how fast the access is (hardware specs of the manufacturer can help).

I suggested sync so that you flush the write-buffers of your system. dd can't achieve peak performance when your buffer-space is cluttered.

I'd consider that as proof that the parameters for dd are somehow suboptimal ;).

Yes. I would still try to get dd working as it should...

okay, you convinced me to use sync...

=)



a few questions:

1 - let's say the windows fat32 partition (/dev/hda1) is 10gb but the used space on it is 5gb... this means that a "tar" of /mnt/windows/* would weigh around 5gb, while a "dd" of /dev/hda1 would weigh 10gb... is this correct???

2 - what's the proper way to create/restore a backup image of the fat32 partition's boot sector only (using linux of course, but in a manner equivalent, or superior to windows xp's recovery console's "fixboot" command)???

3 - i've been googling around about backing-up/restoring fat32 partition images and a lot of folks suggest using "cp -a" (instead of dd)... does this sound like a good idea??? does it take care of the boot sector and stuff or just the files???

4 - "mkfs.vfat -b (sector-of-backup) selects the location of the backup boot sector for FAT32."

http://www.die.net/doc/linux/man/man8/mkfs.vfat.8.html

is this "-b" something i should be using???

5 - how does one optimize dd in relation to the size of the disk's buffer???




ps: these machines have lilo installed on the mbr...

Answers to the best of my knowledge:

1. Yes, correct. (Btw. I am supporting the use of dd, since it is low level and so might restore vfat's dirty secrets ;). And while writing 10 GB instead of 5 GB should be faster, dd doesn't have to restore thousands of file entries in the overhead of the filesystem, so I don't really think that dd just writing sequentially is that much slower since it hasn't to reposition the heads of the hard disk so often.)

2. Like you wrote, I too would use dd.

Re your Post Scriptum: This is a contradiction for a machine with only one HD: Either you use LILO or XP's Fixmbr and the NT Loader. If LILO: Just run /sbin/lilo to freshly install... :D

3. I don't see a real difference to tar in the use of cp -a (does this create an archive too?). Else the arguments from 1. apply too. Oh yes, tar preserves linux symbolic links ... that necessary for you? I don't think that cp cares much for the boot sector ;).

4. I don't really know, have never done it...

5. You can specify the blocksize in the dd command (man dd :D), which could be fit to the buffer size of your HDs (or their preferred size for "writing packages of data"; if I remember correctly, some devices don't write in a continuous byte stream but in bursts / packages). This is obviously a field for experiments.


BTW: A new installation of Windows should be unfragmented, i.e. much smaller than 10 GB. Why don't you dd just that part and forget about the empty rest??