[Phenomic]

jaclaz, on 05 January 2012 - 06:40 AM, said:

Browncoat, on 04 January 2012 - 01:34 PM, said:

You've confused me Jaclaz, are you dissing or endorsing xxclone?
Because of its' properties I've used xxclone ever since 'discovering' it
over at majorgeeks. I like it.

Well, I produced the opposite effect than what I meant, then.

I try as much as I can to have EXACT descriptions of things/tools.
Often people tend to use (or recommend) something without really-really understanding (or clearly stating) WHAT it is.
I try to do the opposite.
There are TWO main approaches (different sources/target):

• disk based
  
• partition (or volume) based

Then there are THREE approaches (different HOW/WHAT to save/image/backup)

• sector based
  
• file based
  
• mixed mode

If you want an "integral" copy/*clone/image you use:

• disk based AND sector based <- this equates to "forensic sound"

this is the SAFER choice (though BOTH slower AND needing more space for the image/backup)

If you are dealing with DATA (and not with actual bootable volumes/OS/System volumes) you use:

• volume based AND file based <. this often equates to "backup"

Most apps use EITHER of the above approaches, with different levels of "added info" to the results.

XXCLONE (and also Norton Ghost as used by many people) use a "mixed mode" approach, where ALL the needed data is stored/saved/cloned, but NOT whatever is not visible in the filesystems AND the actual physical position of files in the filesystem may (or may not) be kept AND some NOT normally needed files are skipped/excluded (typically the pagefile/swap, just as an example).

A typical "forensic sound" disk image will hold each and every sector in the source, thus:

• MBR (and ALL data in it)
  
• hidden sectors (and ALL data in it)
  
• PBR's/VBR's (and ALL data in it)
  
• pagefile/swap
  
• deleted files
  
• broken filesystem elements
  
• actual physical position of EVERYTHING

A typical volume based and file based volume image will hold:

• NO MBR
  
• NO hidden sectors
  
• maybe or maybe not PBR's/VBR's (and ALL data in it) <- this depends on the particular app
  
• NO pagefile/swap and none of a few more normally unneeded files
  
• NO deleted files
  
• NO broken filesystem elements
  
• NO actual physical position of files

A typical file based ONLY image backup will hold:

• NO MBR
  
• NO hidden sectors
  
• NO PBR's/VBR's
  
• NO pagefile/swap and none of a few more normally unneeded files
  
• NO deleted files
  
• NO broken filesystem elements
  
• NO actual physical position of files

A typical "mixed mode approach" image will normally hold:

• MBR
  
• NO hidden sectors
  
• PBR's/VBR's (and ALL data in it)
  
• NO pagefile/swap and none of a few more normally unneeded files
  
• NO deleted files
  
• NO broken filesystem elements
  
• NO actual physical position of files

So, it all boils down on what you need in the resulting image, why you are making it (the scope it will be used later) you should choose an app based on what you need to do with it, knowing EXACTLY what it does and which problems the used approach may lead to and know HOW to solve issues (if ANY) that may arise.

As an example a lot of peeps think that using DriveIMageXML (a nice freeware for personal use) they are actually imaging a disk and are surprised when they find out that the app by itself does NOT store all the needed data (namely the MBR - but in some setups hidden sectors are also needed) to restore a disk or that further steps may be needed, like adjusting disk geometry:
http://www.911cd.net...topic=23408&hl=

A disk is NOT a drive, and a drive is NOT a disk:
http://www.911cd.net...showtopic=22984
(and you will also find in the above some nice reference to antigravitory cats )

jaclaz

It’s very straightforward to copy the running Win2K OS from one disk to another. No need to boot from CD or another OS. I’ve been doing it for years, to have a backup if the primary disk fails, or to boot the backup in order to experiment with software, or to restore accidentally deleted files, etc.

For example copying C: to D: on a different disk. The resulting backup is bootable, so there is no need to restore anything. I posted a summary here, but if anybody is interested I can post the code. Microsoft has a KB on this for the purpose of repairing a non-booting system but the same method works for cloning.


//