backup OEM OS or recovery partition for future reinstallation

[phaolo]

Hi, this is a generic question not limited to a single case, as I often have to deal with other people's computers.

 

What's the best method to backup an OEM OS to small images for future reinstallation? (even to a different hdd\ssd)

Possibly without user data, because that can be huge and it's better saved\updated elsewere anyway.

 

What about saving the recovery partitions? (as they contain smaller installers for everything)

 

 

I've checked the default programs, but:

- Win7 can only save the entire disk and so it needs an additional big external drive to store the images (not a cheap solution).

- Win8.x can backup the smaller recovery partition, but doesn't create images and thus needs a dedicated 16 GB USB device (basically always an additional purchase, even with available hdd or sticks).

- (no idea about Mac or Linux for now)

 

So I've tried Clonezilla and it seems good, but:

- I haven't tested a restore yet.

- cloning the entire disk to an image has the same problem of the huge size and the external drive requirement, so.. nope.

- cloning only the recovery partitions seems the best option, but I'm not sure if it will work! What about the original partition table?

  For example, I've seen a Win8 laptop with 7 default partitions .. how could I ever restore those to a new empty hard drive? (unless I only need 1)

 

 

Do you have any suggestion or advice?

Edited May 20, 2015 by phaolo

[jaclaz]

What about saving the recovery partitions? (as they contain smaller installers for everything)

I've checked various legacy options, but:

No, you haven't  or they were not "legacy" at all .

 

Basically a partition is (the name says it all) an area of the hard disk, that has a beginning and an end address.

These start and end address are recorded in an indexing structure that is a partition table (which is in the MBR or in the first few sectors after it for GPT).

So, if you need a part of a whole, you just copy that part and (advised, but not strictly necessary in all scenario's) the information telling you where that part is located (in order to re-collocate it in the same position when restoring or recovery).

All you really need is a program capable of copying the sectors from one device to a file, i.e. the traditional (if you want "legacy") UNIX program dd (or any port, derivative or tool having the same capabilities, under Windows I personally use dsfo/dsfi) and *any* program capable of interpreting the indexing data (the partition table).

 

 

Everything else or "more" that dd (+ a partition table viewer) are (often "nice" but also sometimes "not perfect") feature-filled "overstructures" (user friendly and what not) around these functionalities:

1. understand which and where is the area (i.e. be capable of reading and interpreting the information)
2. copy it
3. understand where it is needed to copy it back

More than the original partition table (which may or may not be relevant, as the information for the partition is anyway in the volume's filesystem BPB ) in the case of the MBR making a backup of it is often VITAL (in the case of these PC's with "recovery partitions") because besides the DATA (i.e. the partition table and the Disk Signature) the CODE contained in it may be "custom" and not easily replaceable, see as an example:

http://www.msfn.org/board/topic/131620-hp-notebook-the-recovery-partition-could-not-be-found/

 

As well some of the so-called "hidden sectors" in a MBR style disk may contain part of the booting code.

 

So the Rule of the thumb is:

• make a copy of the disk from sector 0 (the MBR) up to the beginning of first partition/volume
• make a copy of the desired partition/volume

with these data (in both MBR or GPT cases) you have all you need to restore.

 

jaclaz

 

[phaolo]

Oh hello Jaclaz!

We always meet in these forums XD

 

 

No, you haven't  or they were not "legacy" at all .

Uh.. oops, I've probably misused the term "legacy". I meant the default MS programs, not the obsolete ones

 

 

[..]Everything else or "more" that dd (+ a partition table viewer) are (often "nice" but also sometimes "not perfect") feature-filled "overstructures"

[..]in the case of the MBR making a backup of it is often VITAL (in the case of these PC's with "recovery partitions")

[..]As well some of the so-called "hidden sectors" in a MBR style disk may contain part of the booting code.

 

So the Rule of the thumb is:

• make a copy of the disk from sector 0 (the MBR) up to the beginning of first partition/volume
• make a copy of the desired partition/volume[..]

Ah, useful info, thanks.

 

However, are you saying that dd/dsfo/dsfi are more reliable than a tool like Clonezilla? Should I just use those instead?

I also wonder if CZ already saves the MBR\GPT automatically (I recall some sort of message). I'll have to check it.

[jaclaz]

Well, You Keep Using That Word, I Do Not Think It Means What You Think It Means ...

http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legacy-is-not-a-pejorative.html

 

What I tried to tell you is that while most, but not all, tools are (if you like bells and whistles) working fine, those are the essential things they need to do, while any given tool may fail to get all the relevant data or get too much of them, or fail to restore in the case of a "real" full recovery (i.e. a "bare metal" one).

 

Another thing that you should be aware of is the possible issue with the format in which the data is saved.

Many tools use their own "proprietary" format for the DATA, which implies that if - for any reason - the program itself fails in the recovery you cannot use another program instead.

 

As an example, for your intended use, one of the (nice) "features" of Clonezilla, that of saving ONLY used blocks for known filesystems, and then further compress it with gzip, thus providing very compact "images" makes it not so much suitable as it is possible that a recovery partition includes some files that you need to access without restoring the image or some "checks" in unmapped areas, or *whatever*.

 

As well - and as said - a disk may well contain custom MBR+hidden sectors boot code that a tool like Clonezilla may (or may not) save/include in the image.

 

What I would do if I were you would be to do a "real" dd clone of the whole disk, test the clone to be working, then image from the clone through Clonezilla (or other program under test) the parts that you believe are needed to do a "bare metal" recovery, then zap the cloned disk and attempt the bare metal recovery through the tool of choice.

If it works, good .

If it doesn't, place back the original disk and repeat the test with another tool.

 

jaclaz

[phaolo]

Well, You Keep Using That Word, I Do Not Think It Means What You Think It Means ...

 

I'm.. confused now. Just tell me! XD

 

 

[..]What I would do if I were you would be to do a "real" dd clone of the whole disk, test the clone to be working, then image from the clone through Clonezilla (or other program under test) the parts that you believe are needed to do a "bare metal" recovery, then zap the cloned disk and attempt the bare metal recovery through the tool of choice[..]

Ah.. that was a loooong wall of text for: "I don't know if Clonezilla works, you'll have to try it yourself"

Anyway, I cannot do such test for now, unless I want to mess with my own system and risk disasters.

[jaclaz]

Ah.. that was a loooong wall of text for: "I don't know if Clonezilla works, you'll have to try it yourself"

 

Actually the intended meaning was

"While I am actually pretty sure that I could use Clonezilla succesfully for doing that, I pretty much doubt that you will be able to do the same"

because I believe that what is done "automagically" in Clonezilla (unless you image the WHOLE disk) is not enough to later perform a "bare metal" recovery.

 

jaclaz

[dencorso]

Anyway, I cannot do such test for now, unless I want to mess with my own system and risk disasters.

 

  Well... With all due respect, I'm really sorry, but if you cannot trust yourself enough to acquire (= create) a true, full, byte-by-byte clone of your own *offline* main machine HDD, while it's in good working order, then you'll be fully useless to help yourself if ever things do go wrong !!!

[phaolo]

 

Anyway, I cannot do such test for now, unless I want to mess with my own system and risk disasters.

 

  Well... With all due respect, I'm really sorry, but if you cannot trust yourself enough to acquire (= create) a true, full, byte-by-byte clone of your own *offline* main machine HDD, while it's in good working order, then you'll be fully useless to help yourself if ever things do go wrong !!!

 

No no, I've already created a full backup disk image of my hdd.

I simply don't want to try to restore it now on a working system (if it ain't broke don't fix it!).

 

My doubt is about (correcly) saving only the smaller recovery partitions in other cases (I don't even have one on my pc).

I must first understand if Clonezilla copies that MBR\GPT info automatically or if it needs the programs suggested by jaclaz.

 

Maybe I could try some partial test with normal partitions in a virtual machine (even if it would be a pain, as my pc is very old and slow).

Edited April 27, 2015 by phaolo

[jaclaz]

Yep, a VM would be a perfect test bed.

 

As a side note 99.9999% of (please read as *all* )  "recovery partitions" are Primary volumes on MBR disks (and of course all volumes in GPT are primary partitions) so there won't be issues in the suggested "make a copy of the disk from sector 0 (the MBR) up to the beginning of first partition/volume", but in the extremely rare (please read as non-existing) case of a recovery partition being actually a logical volume inside extended one would need to additionally save the whole chain of EMBR's.

 

jaclaz

[phaolo]

Ok, the answer to the last problem is here in the official forums.

Unfortunately that place seems managed only by one person, so every reply currently takes minimum 7 days.

[jaclaz]

Ok, the answer to the last problem is here in the official forums.

Unfortunately that place seems managed only by one person, so every reply currently takes minimum 7 days.

Well, but you are (still) in the "wrong" attitude

 

You should trust NOONE and verify yourself how a tool behaves, this is not about -say - a text editor, it is about a program to which you are entrusting all your data, something that should an emergence occur may make the difference between a minor hassle and a catastrophic disaster.

 

Additionally saving a bunch of sectors (normally between 63 and 1024) takes less than 1 (one) second on a modern machine and even on the slowest hardware or storage subsystem it can take at the most a few seconds.

 

Consider it an additional (hopefully redundant) safety.

 

jaclaz

[phaolo]

You should trust NOONE and verify yourself how a tool behaves[..]

Additionally saving a bunch of sectors (normally between 63 and 1024) takes less than 1 (one) second[..]

Consider it an additional (hopefully redundant) safety.

jaclaz

Well, I'm still looking for info, because I cannot basically test that restore and I already have a full disk image of my system.

Anyway ok, until I'll able to do it, I'll save also the MBR\GPT.

Edited May 19, 2015 by phaolo

[Tripredacus]

If you make a disk image of a Windows OS on GPT disk, including the EFI partitions, you may experience a problem booting the OS if you redeploy the image to a disk of a different size. This happens (for sure) with Windows 7, not sure about Windows 8.x. There may be a way to fix that after the fact, I never looked into it.

[jaclaz]

If you make a disk image of a Windows OS on GPT disk, including the EFI partitions, you may experience a problem booting the OS if you redeploy the image to a disk of a different size. This happens (for sure) with Windows 7, not sure about Windows 8.x. There may be a way to fix that after the fact, I never looked into it.

Yes/No.

 

Of course (thanks to the stupid way GPT is designed) the secondary GPT tables will be m00t when you use "simple" or RAW imaging tools (since the GPT uses "relative negative addresses"   from the END of the device).

http://en.wikipedia.org/wiki/GUID_Partition_Table

 

These might need to be recreated in the appropriate location, as an example using gdisk 

http://www.rodsbooks.com/gdisk/repairing.html

commands r d

 

Very likely the Commercial "automagic" tools have provisions to move the tables where appropriate at restoring time.

 

Just another way to have something more complex than needed without any actual *need* or *benefit*.

 

jaclaz

Edited May 20, 2015 by jaclaz

[phaolo]

If you make a disk image of a Windows OS on GPT disk, including the EFI partitions, you may experience a problem booting the OS if you redeploy the image to a disk of a different size. [..]

Yes/No [..] the secondary GPT tables will be m00t when you use "simple" or RAW imaging tools [..] These might need to be recreated in the appropriate location, as an example using gdisk [..]

But.. if the system cannot find the duplicate GTP, what does it do? Do you mean that it doesn't simply recreate it from the first copy automatically? 

Edited May 20, 2015 by phaolo