Any reason why a file-copy (and restore) of the OS partition would fail ?

Hello all,

Assuming I can do a full file copy of the OS partition*, is there any reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

*using another OS ofcourse. :-)

Said differently: Does anyone *know* of any file on the OS partition which
will cause the OS to fail when its restored to another spot ?

Regards,
Rudy Wieser

On Thu, 2 Nov 2017 12:04:37 +0100, R.Wieser wrote:
Hello all,

Assuming I can do a full file copy of the OS partition*, is there any reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

*using another OS ofcourse. :-)

One thing I'm sure of is that the boot manager's BCD registry would still
refer to the old partition's volume ID.

Said differently: Does anyone *know* of any file on the OS partition which
will cause the OS to fail when its restored to another spot ?

If any file which are required to boot (before the kernel is loaded), is
compressed or encrypted.

Can be any file if the NTFS security attributes are messed up (after the
kernel is loaded).

In message , JJ
writes:
On Thu, 2 Nov 2017 12:04:37 +0100, R.Wieser wrote:
Hello all,

Assuming I can do a full file copy of the OS partition*, is there any reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

1. Why are you wanting to do this? (I'm just curious.)
2. When you say "wiping", what do you mean - just "deleting" all the
files, or formatting, or what?

*using another OS ofcourse. :-)

One thing I'm sure of is that the boot manager's BCD registry would still
refer to the old partition's volume ID.

But only the partition information - or any file _positions_?

Said differently: Does anyone *know* of any file on the OS partition which
will cause the OS to fail when its restored to another spot ?

If any file which are required to boot (before the kernel is loaded), is
compressed or encrypted.

Is what Rudy's proposing - which sounds to me like just a copy (or
move!) off, followed by a copy back - likely to compress or encrypt
anything? (I'm assuming nothing like the old "disc compression" ["drive
H: etc.] is involved!)

Can be any file if the NTFS security attributes are messed up (after the
kernel is loaded).

Would Rudy's copy and copy back change those? If it might, would a
global setting of all such attributes fix it, or do some files have to
have certain attributes set and other have to have those same attributes
cleared, for the OS to boot?
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

After I'm dead I'd rather have people ask why I have no monument than why I
have one. -Cato the Elder, statesman, soldier, and writer (234-149 BCE)

Hello JJ,

One thing I'm sure of is that the boot manager's BCD registry would
still refer to the old partition's volume ID.

It really does depend on that / will fail if it doesn't find it ? I have
not thought that far aahead I'm afraid/. But if that is so than I guess I
would need to backup (and restore) that ID too. Thanks for mentioning it.
:-)

If any file which are required to boot (before the kernel is loaded),
is compressed or encrypted.

Can be any file if the NTFS security attributes are messed up (after
the kernel is loaded).

Same as a above. The first thing I wanted to make sure of is if files are,
or aren't locked (for whatever reason) to a physical location. If some
files still are than that throws a serious wrench in my ideas/plans, and all
the other stuff becomes moot ...

Regards,
Rudy Wieser

Hello John,

1. Why are you wanting to do this? (I'm just curious.)

The reason I'm asking the question is twofold:
1) So that I can actually make a backup of the OS in the simplest way
available.
2) To find out if the OS still depends on finding certain files back at
exactly the same place where it left it the last time it powered off.
Curiosity on my side.

2. When you say "wiping", what do you mean - just "deleting" all the
files, or formatting, or what?

I ment it as a place-holder for several things, but wanted to express that
its none of the old sector data would be available anymore (No "Oh look, the
old data is still there!" shennigans :-) ) It definitily includes the
possibility of replacing the old drive with a brand new one.

Is what Rudy's proposing - which sounds to me like just a copy (or move!)
off, followed by a copy back

More-or-less, yes. But my intention is that the backup should be able to
be restored to a deep-erased partition or even a new disk, in case the old
one gets corrupted (mal/ransomware anyone ?) or simply dies on me.

But to be honest I did not (yet) consider encrypted files, which could
(would?) ofcourse cause a problem for any kind of duplication process (hey,
thats, among other things, what that kind of encyption is ment for, no ?
:-) )

Regards,
Rudy Wieser

On Thu, 2 Nov 2017 16:29:19 +0100, "R.Wieser"
wrote:

Hello John,

1. Why are you wanting to do this? (I'm just curious.)

The reason I'm asking the question is twofold:
1) So that I can actually make a backup of the OS in the simplest way
available.
2) To find out if the OS still depends on finding certain files back at
exactly the same place where it left it the last time it powered off.
Curiosity on my side.

2. When you say "wiping", what do you mean - just "deleting" all the
files, or formatting, or what?

I ment it as a place-holder for several things, but wanted to express that
its none of the old sector data would be available anymore (No "Oh look, the
old data is still there!" shennigans :-) ) It definitily includes the
possibility of replacing the old drive with a brand new one.

Is what Rudy's proposing - which sounds to me like just a copy (or move!)
off, followed by a copy back

More-or-less, yes. But my intention is that the backup should be able to
be restored to a deep-erased partition or even a new disk, in case the old
one gets corrupted (mal/ransomware anyone ?) or simply dies on me.

But to be honest I did not (yet) consider encrypted files, which could
(would?) ofcourse cause a problem for any kind of duplication process (hey,
thats, among other things, what that kind of encyption is ment for, no ?
:-) )

Regards,
Rudy Wieser


My bet is that a simple "copy" is just not getting all of the files
(boot sector etc)
I have not done it on XP but on 98 you could do a XCOPY /S/H/E/R/C
and move all the files but you still needed to do a SYS to get the
boot sector files and the partition needs to be set active.
Using an image program seems to be the best (only?) way to move the OS
after XP landed.

In message , R.Wieser
writes:
Hello John,

1. Why are you wanting to do this? (I'm just curious.)

The reason I'm asking the question is twofold:
1) So that I can actually make a backup of the OS in the simplest way
available.

I thought it might be that. On the whole, though, I think the idea of
just copying the files died with the '9x variants.

2) To find out if the OS still depends on finding certain files back at
exactly the same place where it left it the last time it powered off.
Curiosity on my side.

Good question! From the replies from others, it would appear not (at
least, no-one's mentioned it); was any version of Windows itself
protected in that way? I have come across other software (I think it
might have been a version of JAWS) that were, but not for a long time.

2. When you say "wiping", what do you mean - just "deleting" all the
files, or formatting, or what?

I ment it as a place-holder for several things, but wanted to express that
its none of the old sector data would be available anymore (No "Oh look, the
old data is still there!" shennigans :-) ) It definitily includes the
possibility of replacing the old drive with a brand new one.

Is what Rudy's proposing - which sounds to me like just a copy (or move!)
off, followed by a copy back

More-or-less, yes. But my intention is that the backup should be able to
be restored to a deep-erased partition or even a new disk, in case the old
one gets corrupted (mal/ransomware anyone ?) or simply dies on me.

Since I had my disc stall a year or two ago, I've been backing up using
imaging (I use the free version of Macrium 5, but I think they're all
similar).

You say "the simplest way available", and I grant imaging requires some
setting up (though your just-copying requires the other OS to be
installed!), but once you have (in my case, this just involved making
the mini-CD I use), the process is very simple. It also backs up the
hidden partition, which I'm not sure how easy it would be to do by just
copying.

Imaging also copies all the software I have as well, including
configuration - though I _think_ your copying would do that as well.

I keep my OS-and-software (with configurations) on one partition and
data on another (some people even split OS from other software; I don't
think I could manage to keep those separate!). I back up the data by
just copying (well, I use SyncToy to speed it by only copying the
changes, but it's in effect just a copy that results).

But to be honest I did not (yet) consider encrypted files, which could
(would?) ofcourse cause a problem for any kind of duplication process (hey,
thats, among other things, what that kind of encyption is ment for, no ?
:-) )

Indeed, for encryption-for-secrecy. As for encryption for other
purposes, I don't think e. g. compression is much used these days
(except within files like .zip and .jpg of course).

Regards,
Rudy Wieser


JPG

P. S.: FWIW, imaging _did_ allow me to restore to a disc of different
capacity (250G instead of 120G, IIRR). I restored only the C: and hidden
partitions (copying the data later); on first powerup the Samsung repair
kicked in, which I presume used the hidden partition information - but
after that had finished, my old desktop came back exactly as before. I
then resized C: up a bit (to take about the same proportion of the
bigger disc), and created D:, and copied the data back to D: from where
I'd put it. [I'd been able to unstick the old stuck HD enough to make
the image and save the data, fortunately. I now make a new image and
copy from time to time even with no indication of disc problems, of
course!]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"I am entitled to my own opinion."
"Yes, but it's your constant assumption that everyone else is also that's so
annoying." - Vila & Avon

gfretwell,

My bet is that a simple "copy" is just not getting all of the
files (boot sector etc)

Question: What is stored in that boot sector (etc.) that you think is
*absolutily neccessary* for the OS that I've currently got in the partition,
and cannot be recreated by having another OS create a partition and format
it ?

I have not done it on XP but on 98 you could do a XCOPY /S/H/E/R/C

That would work to copy files *from* the OS partition (as long as those
files are not in use ofcourse). The question is what would happen when you
copy those files back *to* that partition. Would the OS still be able to
run ?

You see, Win98 is what actually warranted my question: In there not even the
OS-es own 'defrag' would touch (the allocation units of) files with the
'system' attribute set. Regardless of if you booted into Windows or DOS.
And that makes it look as if the OS expected the (allocation units of the)
file to be at particular places on the partition.

.... which a simple copy action can ofcourse never guarantee.

Regards,
Rudy Wieser

John,

I thought it might be that. On the whole, though, I think the idea of just
copying the files died with the '9x variants.

Just regard me as someone who wants to re-introduce it (if only for myself).
:-)

Actually, I've got an (old) copy of 'ghost' here (which I used for Win98)
which seems to do its back-up-ing by way of copying files and disregarding
the "empty" space of the partition. No idea if it placed the files exacly
back where it found them though. But alas, although it was portable (which
I very much prefer), it could not cope with the USB drive I put it on, which
showed a partition which had more than 1023 sectors-per-track. :-\

Good question! From the replies from others, it would appear not (at
least, no-one's mentioned it);

True, but that could be because noone actually tried/did it that way ...
(Absense of proof != proof of absense)

was any version of Windows itself protected in that way?

I don't think it was a protection per-se, just "the way it worked"(tm). I
myself took it as a sign that some OS-related program created a private
cache of where it could find certain sectors, so it could access them fast.
Currently the only question (in this regard) is if that cache persists over
reboots.

Since I had my disc stall a year or two ago, I've been backing up using
imaging (I use the free version of Macrium 5, but I think they're all
similar).

Yes, I've been eying similar programs. But as I wrote a (simple) program
to back up my data partitions I was wondering if I could come up with
something simple for the OS partition too. Hence my question.

Imaging also copies all the software I have as well, including
configuration - though I _think_ your copying would do that as well.

As most, if not all of the configuration is stored in the registry and I
intent to copy that one as well I assume I would, yes.

I keep my OS-and-software (with configurations) on one partition and data
on another

Same here. Although problems with data are mostly easy to fix I don't
think I would be able to do the same for anything OS related (too
interdependant). There I want to be able to restore the whole kadoodle and
have a running OS again.

(some people even split OS from other software; I don't think I could
manage to keep those separate!).

For me it depends on the software. I've got FF installed on the OS
partition, but have the users profile stored on the data partition. Games
(the few that I have) I always install in their very own partition.

I back up the data by just copying (well, I use SyncToy to speed it by
only copying the changes, but it's in effect just a copy that results).

I do something similar: On an NTFS partition I'm creating a datestamped
folder which than either receives a full copy of any new or changed file,
and a hardlink from a file in a previous datestamped folder for the
unchanged ones. That results in a kind of incremental backup, but with
each datestamped folder seemingly containing a full one (allowing me to
throw older backups away at will).

Regards,
Rudy Wieser

wrote:
On Thu, 2 Nov 2017 16:29:19 +0100, "R.Wieser"
wrote:

Hello John,

1. Why are you wanting to do this? (I'm just curious.)
The reason I'm asking the question is twofold:
1) So that I can actually make a backup of the OS in the simplest way
available.
2) To find out if the OS still depends on finding certain files back at
exactly the same place where it left it the last time it powered off.
Curiosity on my side.

2. When you say "wiping", what do you mean - just "deleting" all the
files, or formatting, or what?
I ment it as a place-holder for several things, but wanted to express that
its none of the old sector data would be available anymore (No "Oh look, the
old data is still there!" shennigans :-) ) It definitily includes the
possibility of replacing the old drive with a brand new one.

Is what Rudy's proposing - which sounds to me like just a copy (or move!)
off, followed by a copy back
More-or-less, yes. But my intention is that the backup should be able to
be restored to a deep-erased partition or even a new disk, in case the old
one gets corrupted (mal/ransomware anyone ?) or simply dies on me.

But to be honest I did not (yet) consider encrypted files, which could
(would?) ofcourse cause a problem for any kind of duplication process (hey,
thats, among other things, what that kind of encyption is ment for, no ?
:-) )

Regards,
Rudy Wieser


My bet is that a simple "copy" is just not getting all of the files
(boot sector etc)
I have not done it on XP but on 98 you could do a XCOPY /S/H/E/R/C
and move all the files but you still needed to do a SYS to get the
boot sector files and the partition needs to be set active.
Using an image program seems to be the best (only?) way to move the OS
after XP landed.

I do Rudy's file copy thing, because my WinXP is on
a FAT32 partition. And it works. The trick is, you
need to boot the installer CD to its Command Prompt,
and do a Fixboot to put the boot sector back. If
you "format" the partition, to either FAT32 or
NTFS, that wipes the boot sector (PBR or partition
boot sector). To fix that one is "fixboot", only
available in the repair environment. The other
type of repair is "fixmbr", for putting the 446 byte
boot sector back in the MBR, after a whole disk wipe.

The repair environment (command prompt available via
the OS installer CD) expects to find an OS folder. It
also asks for the administrator password. Once you're
in there, you apply fixboot to the partition you logged
into, and that should do it.

Also, using ptedit32 or similar, you'd want to make
sure you put the boot flag 0x80 on the correct
partition, to make it boot. Just in case that
got blasted somehow.

WinXP uses boot.ini rather than a BCD file. The boot.ini
relies on an ARC path pointing at the partition with
the OS on it. There's no GUID like on a BCD on later
OSes (and as it turns out, you don't want to know
how GUID works).

Paul

J. P. Gilliver (John) wrote:
In message , R.Wieser
writes:
Hello John,

1. Why are you wanting to do this? (I'm just curious.)

The reason I'm asking the question is twofold:
1) So that I can actually make a backup of the OS in the simplest way
available.

I thought it might be that. On the whole, though, I think the idea of
just copying the files died with the '9x variants.

It actually works. Verified on FAT32 at least.

The machine I'm typing on, the C: partition has
been reformatted, many times. Fixboot puts back
the PBR, *after* you have restored the files.
You can't get fixboot to run, unless a file set
that looks like an OS is present. And fixboot
is only available on the installer CD and its
Command Prompt environment.

Paul

On 02/11/2017 11:04, R.Wieser wrote:
Hello all,

Assuming I can do a full file copy of the OS partition*, is there any reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

*using another OS ofcourse. :-)

Said differently: Does anyone *know* of any file on the OS partition which
will cause the OS to fail when its restored to another spot ?

Regards,
Rudy Wieser


I assume you really want to backup/restore an OS this way rather than
just wondering if it is possible.

As you intend to run from another OS anyway using the full file copy
approach is pointless. Apart from needing to recreate the boot
requirements on the "new" disk, both file copy operations would be far
slower than creating and restoring a full partition image.

You can't get much simpler than my system of running Powerquest Drive
Image 6 from MSDOS (with USB drivers for backup to a FAT32 external
drive). This will happily boot from floppy disk, CDROM, USB stick or SD
card depending on the boot options of the PC but regular backups are
even more convenient if you create a small MSDOS partition on the OS
drive as another boot option.

MikeS wrote:
On 02/11/2017 11:04, R.Wieser wrote:
Hello all,

Assuming I can do a full file copy of the OS partition*, is there any
reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

*using another OS ofcourse. :-)

Said differently: Does anyone *know* of any file on the OS partition
which
will cause the OS to fail when its restored to another spot ?

Regards,
Rudy Wieser


I assume you really want to backup/restore an OS this way rather than
just wondering if it is possible.

As you intend to run from another OS anyway using the full file copy
approach is pointless. Apart from needing to recreate the boot
requirements on the "new" disk, both file copy operations would be far
slower than creating and restoring a full partition image.

You can't get much simpler than my system of running Powerquest Drive
Image 6 from MSDOS (with USB drivers for backup to a FAT32 external
drive). This will happily boot from floppy disk, CDROM, USB stick or SD
card depending on the boot options of the PC but regular backups are
even more convenient if you create a small MSDOS partition on the OS
drive as another boot option.

The purpose of doing a copy to a freshly re-formatted C:
partition, is for defragmentation.

I've not encountered an application yet, that met its
billing and actually did a good job, of defragmenting
on restore or clone. Macrium "defragments a little bit",
if you restore a backed up partition, to a smaller space
when you restore it. But because of the handling of $MFT and
$MFT reserved areas, some of the last files are not defragmented.
Close, but no cigar. It was not their design intent, to
defragment, and it's just a side effect of squeezing the
files into the smaller space.

And an application, a cloning application billed to support
defragmentation during the clone, did not work. And one reviewer
noticed some shortcuts were missing from his desktop. I wouldn't
touch such a product, with a barge pole. All it takes is one
report of shenanigans, to take the fun out of it.

When I copy WinXP, I use ridgecrop fat32formatter to prepare
my FAT32 C: . And I use Robocopy to do the copy of the
saved files. In about 40 minutes, I can backup and restore,
and the result is fragment free (for files). Some directory
entries end up fragmented, due to their size. A final step,
using fixboot, and it is ready to boot again.

I've not tested this procedure on anything NTFS. As there
are a lot more variables there. For example, even with the
appropriate command line parameters passed to Robocopy, I
doubt Robocopy can clone a drive correctly and preserve
everything that should be preserved. The only thing I'd trust,
is backup software that supports cloning, and that will not
achieve anything, if it doesn't defragment at any step
in the process. Tools which are VSS based, *tend* to
preserve fragmentation exactly. And the one that was
*designed* to defragment, had issues. Which is probably
why it was free (at the time).

This is one of the reasons I'm applying this technique,
to a FAT32 volume. As I don't know where it would
fail on NTFS. Certainly junction points are going to
cause indigestion, and I think Robocopy has a command
line option to step over those.

Paul

R.Wieser wrote:
Hello all,

Assuming I can do a full file copy of the OS partition*, is there any
reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

*using another OS ofcourse. :-)

Said differently: Does anyone *know* of any file on the OS partition which
will cause the OS to fail when its restored to another spot ?

Regards,
Rudy Wieser

Is there any reason to not want to use an imaging program to do this? It
takes care of all that and all the messy details for you (even to a
different size drive).

I routintely make an image backup of my C: partition to another hard drive,
and occasionally restore its image to get everything back to the way it was,
without any hassle. Just wondering what the disadvantage in doing so might
be. ?

On Thu, 2 Nov 2017 12:04:37 +0100, "R.Wieser"
wrote:

Assuming I can do a full file copy of the OS partition*, is there any reason
why wiping the partition and than copying those files back will not allow
the OS to run again ?

In Windows XP the OS and programs cannot simply be copies file by file
and work again. Either an image of the OS, using a utility such as
Macrium or Acronus, has to be copies, or the OS has to be
re-installed, and all programs that use the registry and registered
DLL file have to be reinstalled too.

File copy will work with stand-alone programs, such as DOS programs,
but not with registry-dependent Windows programs or the OS itself.


--
Steve Hayes
http://www.khanya.org.za/stevesig.htm
http://khanya.wordpress.com