If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
Ads |
#2
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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). |
#3
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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) |
#4
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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 |
#5
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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 |
#6
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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. |
#7
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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 |
#8
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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 |
#9
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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 |
#10
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partitionwould fail ?
|
#11
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partitionwould fail ?
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 |
#12
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partitionwould fail ?
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. |
#13
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partitionwould fail ?
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 |
#14
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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. ? |
#15
|
|||
|
|||
Any reason why a file-copy (and restore) of the OS partition would fail ?
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 |
|
Thread Tools | |
Display Modes | |
|
|