backing up Windows OS partition

[mimosa]

This has nothing to do with Salix except in the sense that I am responsible for two computers where Salix coexists with That OS ...

Data is on a separate partition ("My Documents" or whatever it is points to it, so users don't have to do anything different ). The idea is, when Windows turns to mud and cobwebs, I can just reinstall it. I know it is theoretically possible to run Windows without it degrading, but that would mean educating the users to be more judicious clickers; also, I never use it myself, and any housekeeping is a chore.

What I would like to do is reinstall, add the right drivers, and customise according to the little tricks I've learned, such as turning off annoying messages: then back up the pristine fully working installation so that next time, I can just copy it into the partition without spending all that time. Then I could do it every week if necessary!

In the past, I investigated some tools for doing this, and tried some methods I found by searching, but could never quite get the hang of it - especially with members of my family suffering withdrawal symptoms from MSN and so on, pressing me to give them back their trusty Microsoft OS sooner rather than later.

Can anybody give me any suggestions?

My preferred method would be to just use dd or something equally basic from the command line. I don't mind keeping 10GB spare to house the backup. But when I looked into this a while ago, I was baffled by the finer points - for instance, exactly where to start and stop. The risk of screwing things up isn't too critical, because as I said, all data is on a separate partition.

I should mention that Windows (XP, but maybe I'll try 7 some time) is on the first partition. I'm somewhat hazy about how the bootloader is set up, but it's probably just what Salix does automatically when you ask it to include Windows as a boot option alongside Linux.

Thanks in advance!

[gapan]

Just use dd. It can't get any simpler than that.

Backup your windows partition (e.g. /dev/sda1):

Code: Select all

dd if=/dev/sda1 of=/path/to/sda1.img

Restore your windows partition from backup:

Code: Select all

dd if=/path/to/sda1.img of=/dev/sda1

You can even do that with an entire hard drive (/dev/sda) instead of just a partition if you like.

[mimosa]

Thanks gapan!

... but what about the MBR and other bootloaderish stuff that may be knocking around sda1?

My reading online leaves me with the impression that there are a few wrinkles to worry about.

Perhaps the reason there aren't is because all I want to do is put XP back exactly where it was before ...

[Shador]

Thanks gapan!

... but what about the MBR and other bootloaderish stuff that may be knocking around sda1?

My reading online leaves me with the impression that there are a few wrinkles to worry about.

Perhaps the reason there aren't is because all I want to do is put XP back exactly where it was before ...

This backs up the complete sda1 partition including PBR (Partition Boot Record) and Microsoft bootloader stuff. 1st partition usually starts at sector 64, so it backs up 64 to X. It doesn't back up anything before 64 including the MBR in sector 0. But I guess your bootloader is lilo/grub and installed to the MBR, I don't think you need to back up that one, it just loads the Windows bootloader (which you back up) when booting Windows.
Actually I recommend to be careful when backing up the MBR. Just backing it up is no problem, but when restoring the backup you need to be careful and know what you do, unless you don't care about part table damage/ data loss. It can be quite handy though to create a MBR backup after partition table changes.
But reinstalling lilo/grub is so simple that it's not worth backing up their MBR part.

[mimosa]

Thanks Shador. I think I feel confident enough now to try it. Wonderful that it is so simple!

One final question - I have read that using the bs=[multiple of some large power of 2] parameter speeds up dd. Is there anything I need to watch out for if I do this? For instance, what if the partition ends inside such a larger block of data?

[Shador]

Thanks Shador. I think I feel confident enough now to try it. Wonderful that it is so simple!

One final question - I have read that using the bs=[multiple of some large power of 2] parameter speeds up dd. Is there anything I need to watch out for if I do this? For instance, what if the partition ends inside such a larger block of data?

I'm not to sure about blocksize myself. But the doc says the following:

read and write up to BYTES bytes at a time

So dd doesn't seem to strictly keep to that value anyway.

But you shouldn't need to mess with bs or count anyway, when backing up whole partitions.

[mimosa]

Well, after a number of quite stressful hours, I've done it!

That is, I haven't actually tested restoring from the backup - it would have been too frustrating if it hadn't worked. But I'm sure it will. It's a wonderful feeling to think that I will never again have to install the printer and then uninstall the components it automagically installs to sell you printer cartridges.

I'd forgotten quite how unpleasant using Windows can be for extended periods.

Can anyone recommend a good, simple CD/DVD burn and backup program for WIndows, along the lines of Brasero or Xfburn? My daughter likes Nero, but I'd rather put something more lightweight as the default app for the task. In the same spirit, I have installed LibreOffice - and already received a complaint

[mimosa]

Yesterday I did a restore, and everything worked as expected (just needed to run Lilosetup to get Linux back)

One small point is that it is presumably essential to ensure the Windows partition is unmounted; some versions of Salix may mount it automatically (such as Salix Live 13.1, which seems to mount all partitions as /mnt/sdax) or you may have set up the mount with Lilo.

Compression is a useful way to save a lot of space, and doesn't take that much longer:

Code: Select all

dd if=/dev/sda1 | gzip > /path/to/sda1.img.gz

Also, increase compression by first ensuring blank space is filled with zeroes instead of junk (the partition needs to be mounted for this):

Code: Select all

dd if=/dev/zero of=/path/to/sda1/empty_file        # will eventually run out of space and say so
rm /path/to/sda1/empty_file
umount /dev/sda1

To restore:

Code: Select all

dd if=/path/to/sda1.img.gz | gunzip | dd of=/dev/sda1

For many more tips in no particular order, see

http://www.linuxquestions.org/questions ... nd-362506/

(I wouldn't advise following these blindly - for instance, the option conv=noerror might be good if you know there are errors on a partition, but for many tasks (such as this one) the default of failing on error might be better, alerting you to a problem.)

The information I needed *was* out there, just very well mixed up with a lot of bad information

EDIT

It's worth emphasising the potential for causing massive data loss through mistyping - simply because dd moves data by brute force from A to B. B can be anywhere, with no safeguards.

[JRD]

Good information and tutorial !