Registry Backup Beta

[Shane]

It wont hurt anything. They will just make new snap shots when they need them. They do it already.

Otherwise the data in the snap shot becomes old

As you remember my program was deleting them before and caused no problems.

Try it out and let me know if clearing those works.

If it does I have to find out why it is passing the wrong info in the script.

Shane

[Shane]

And to help see what is showing on B: at the time I will add
"dir b:" to the logs. This will list the files on the root of B:.

This way if it is pointing to the wrong snap shot we will then see what it is pointing to

Shane

[Ztruker]

Same problem after deleting shadows on all volumes, C: D: and E:.

[5/23/2012 - 9:01:51 PM] Backing Up Files...:
[5/23/2012 - 9:01:51 PM] --------------------------------------------------------------------------------
[5/23/2012 - 9:01:51 PM] Backing Up File: C:\Windows\System32\Config\default
[5/23/2012 - 9:01:51 PM] Result: Failed - Error: Couldn't find the file on the volume snapshot.

[Shane]

Post the vss log for me. I need to see if it is still pointing to the wrong snap shot.

You can also do this, which the program will on the next update.

When you do a backup do not close the program yet, leave it open so the snap shot stays open.

Open a cmd window and put in

dir B:

That will list the files on B:

What does it pull up?

Shane

[Ztruker]

Code: [Select]

>dir b:
The system cannot find the path specified.

>dir b:\
The system cannot find the path specified.

Code: [Select]

C:\Users\rrkurtz>vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Servi
(C) Copyright 2001-2005 Microsoft Corp.

No items found that satisfy the query.

Code: [Select]

[5/23/2012 - 9:09:46 PM]
--------------------------------------------------------------------------------
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Program Files (x86)\Tweaking.com\Registry Backup>
--------------------------------------------------------------------------------
[5/23/2012 - 9:09:46 PM]
--------------------------------------------------------------------------------
CD /D C:\

C:\>
--------------------------------------------------------------------------------
[5/23/2012 - 9:09:46 PM]
--------------------------------------------------------------------------------
"C:\Windows\temp\vss_start.bat"

C:\>set path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files (x86)\Tweaking.com\Registry Backup\files

--------------------------------------------------------------------------------
[5/23/2012 - 9:09:46 PM]
--------------------------------------------------------------------------------

C:\>"C:\Program Files (x86)\Tweaking.com\Registry Backup\files\vss_7_64.exe" -script="C:\Windows\temp\vss-setvar.cmd" -exec="C:\Windows\temp\vss.bat" C:

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:31 PM]
--------------------------------------------------------------------------------

C:\>set path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files (x86)\Tweaking.com\Registry Backup\files

C:\>call "C:\Windows\temp\vss-setvar.cmd"

[This script is generated by VSHADOW.EXE for the shadow set {4badf327-19f7-4d78-9ed1-fe60194e7642}]

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:31 PM]
--------------------------------------------------------------------------------

C:\>SET SHADOW_SET_ID={4badf327-19f7-4d78-9ed1-fe60194e7642}

C:\>SET SHADOW_ID_1={624b581a-5d69-4377-a6f8-0fca2ec61188}

C:\>SET SHADOW_DEVICE_1=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8

C:\>"C:\Program Files (x86)\Tweaking.com\Registry Backup\files\dosdev.exe" -a B: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:31 PM]
--------------------------------------------------------------------------------
Current definition: B: = \??\GLOBALROOT\Device\HarddiskVolumeShadowCopy8

C:\>"C:\Program Files (x86)\Tweaking.com\Registry Backup\files\dosdev.exe"
--------------------------------------------------------------------------------
[5/23/2012 - 9:10:31 PM]
--------------------------------------------------------------------------------
B: = \??\GLOBALROOT\Device\HarddiskVolumeShadowCopy8 [NoRootDir] *** LOGICAL DRIVE BIT NOT SET ***
C: = \Device\HarddiskVolume5 [Fixed]
D: = \Device\HarddiskVolume1 [Fixed]
E: = \Device\HarddiskVolume2 [Fixed]
F: = \Device\HarddiskVolume3 [Fixed]
G: = \Device\HarddiskVolume6 [Fixed]
H: = \Device\HarddiskVolume7 [Fixed]
I: = \Device\HarddiskVolume8 [Fixed]
O: = \Device\CdRom0 [CDRom]

C:\>start "" /wait "C:\Program Files (x86)\Tweaking.com\Registry Backup\files\vss_pause.exe"

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:52 PM]
--------------------------------------------------------------------------------

C:\>"C:\Program Files (x86)\Tweaking.com\Registry Backup\files\dosdev.exe" -r -d B:

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:52 PM]
--------------------------------------------------------------------------------
Current definition: B: = \??\GLOBALROOT\Device\HarddiskVolumeShadowCopy8
B: deleted.

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:54 PM]
--------------------------------------------------------------------------------

VSHADOW.EXE 3.0 - Volume Shadow Copy sample client.
Copyright (C) 2005 Microsoft Corporation. All rights reserved.

(Option: Generate SETVAR script 'C:\Windows\temp\vss-setvar.cmd')
(Option: Execute binary/script after shadow creation 'C:\Windows\temp\vss.bat')
(Option: Create shadow copy set)
(Gathering writer metadata...)
(Waiting for the asynchronous operation to finish...)
Initialize writer metadata ...
Discover directly excluded components ...
- Excluding writer 'MSSearch Service Writer' since it has no selected components for restore.
- Excluding writer 'Shadow Copy Optimization Writer' since it has no selected components for restore.
- Excluding writer 'BITS Writer' since it has no selected components for restore.
Discover components that reside outside the shadow set ...
- Component '\BCD\BCD' from writer 'ASR Writer' is excluded from backup (it requires  in the shadow set)
Discover all excluded components ...
Discover excluded writers ...
- The writer 'ASR Writer' is now entirely excluded from the backup:
  (the top-level non-selectable component '\BCD\BCD' is an excluded component)
Discover explicitly included components ...
Verifying explicitly specified writers/components ...
Select explicitly included components ...
 * Writer 'Task Scheduler Writer':
   - Add component \TasksStore
 * Writer 'VSS Metadata Store Writer':
   - Add component \WriterMetadataStore
 * Writer 'Performance Counters Writer':
   - Add component \PerformanceCounters
 * Writer 'System Writer':
   - Add component \System Files
 * Writer 'Registry Writer':
   - Add component \Registry
 * Writer 'COM+ REGDB Writer':
   - Add component \COM+ REGDB
 * Writer 'WMI Writer':
   - Add component \WMI
Creating shadow set {208494ff-45c7-4082-86a3-750db3c29517} ...
- Adding volume \\?\Volume{bcbe9ee2-e6d1-11de-8e59-806e6f6e6963}\ [C:\] to the shadow set...
Preparing for backup ...
(Waiting for the asynchronous operation to finish...)
(Waiting for the asynchronous operation to finish...)
Creating the shadow (DoSnapshotSet) ...
(Waiting for the asynchronous operation to finish...)
(Waiting for the asynchronous operation to finish...)
Shadow copy set succesfully created.

List of created shadow copies:

Querying all shadow copies with the SnapshotSetID {208494ff-45c7-4082-86a3-750db3c29517} ...

* SNAPSHOT ID = {429519cb-419b-4788-8df0-f2b4b4e683ce} ...
   - Shadow copy Set: {208494ff-45c7-4082-86a3-750db3c29517}
   - Original count of shadow copies = 1
   - Original Volume name: \\?\Volume{bcbe9ee2-e6d1-11de-8e59-806e6f6e6963}\ [C:\]
   - Creation Time: 5/23/2012 9:10:27 PM
   - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy13
   - Originating machine: Dell-P370
   - Service machine: Dell-P370
   - Not Exposed
   - Provider id: {b5946137-7b9f-4925-af80-51abd60b20d5}
   - Attributes:  Auto_Release Differential

Generating the SETVAR script (C:\Windows\temp\vss-setvar.cmd) ...
- Executing command 'C:\Windows\temp\vss.bat' ...
-----------------------------------------------------
-----------------------------------------------------
- Mark all writers as succesfully backed up...
Completing the backup (BackupComplete) ...
(Waiting for the asynchronous operation to finish...)
(Waiting for the asynchronous operation to finish...)

Snapshot creation done.

--------------------------------------------------------------------------------
[5/23/2012 - 9:10:54 PM]
--------------------------------------------------------------------------------

C:\>
--------------------------------------------------------------------------------
[5/23/2012 - 9:10:57 PM]
--------------------------------------------------------------------------------
Closed. No longer reading pipes.
--------------------------------------------------------------------------------

The weird part is this works fine when it's run automatically at boot time.

[Shane]

How odd, why is it doing that?

The volume shadow copy reported back to my program with this

C:\>SET SHADOW_SET_ID={4badf327-19f7-4d78-9ed1-fe60194e7642}

C:\>SET SHADOW_ID_1={624b581a-5d69-4377-a6f8-0fca2ec61188}

C:\>SET SHADOW_DEVICE_1=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8

C:\>"C:\Program Files (x86)\Tweaking.com\Registry Backup\files\dosdev.exe" -a B: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8
 

Notice the HarddiskVolumeShadowCopy8

Yet down when it reports what it did you can see it is different

* SNAPSHOT ID = {429519cb-419b-4788-8df0-f2b4b4e683ce} ...
   - Shadow copy Set: {208494ff-45c7-4082-86a3-750db3c29517}
   - Original count of shadow copies = 1
   - Original Volume name: \\?\Volume{bcbe9ee2-e6d1-11de-8e59-806e6f6e6963}\ [C:\]
   - Creation Time: 5/23/2012 9:10:27 PM
   - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy13
   - Originating machine: Dell-P370
   - Service machine: Dell-P370
   - Not Exposed
   - Provider id: {b5946137-7b9f-4925-af80-51abd60b20d5}
   - Attributes:  Auto_Release Differential

And you see it should have been HarddiskVolumeShadowCopy13.



WAIT.... I just noticed something. The ID should be different each time. I just noticed that the ID in this batch SET SHADOW_SET_ID={4badf327-19f7-4d78-9ed1-fe60194e7642}

is the same as the old log you sent me.

The vss-setvar.cmd file in the windows dir isnt being over written.

Do me a fav and go to Windows\Temp and delete any vss bat file in there and try it again.

Shane

[Shane]

Felt I should pass this on as well, the bootable restore was simply one option. The program has a built in restore and I will also have other ways for users to do it.

I havent even written the help file yet lol

http://www.tweaking.com/forums/index.php?topic=275.msg1830#msg1830

Shane

[Tomas_Sweden]

I have compared your "Registry Backup" and "Mz Registry Backup" all the files that are saved are the same but one, do you know why?

In "Tweaking.com - Registry Backup"
"C:\Users\Default\NTUSER.DAT"
and in "Mz Registry Backkup"
"C:\Boot\BCD"
Tomas

[Shane]

Those are not the same reg files

That program and Erunt both look in the Registry under the hivelist key. This list all loaded reg files but only the loaded ones.

I dont do that, I have the program look at the profiles location for ntuser.dat So it grabs all profiles not just the ones loaded

And the one it is showing is the boot manager reg file. Which I don't have my program worry about as it sits on the unmapped system drive by Windows. But on yours you have it moved to the C:\ drive.

Shane

[Shane]

Oh and I am changing the program to make a dos_restore.bat to be stored with each backup.

If the person goes into the recovery console they just have to run that bat file. Nice and easy

Shane

[Shane]

The next version will have a restore batch file just like erunt does to run from the recovery console

This will be 1 of the 3 ways I will show people how they can restore the reg in different situations.

Shane

[Shane]

Ok new version is just about done.

Some key points that make it better than erunt

When you have to restore from the recovery console erunt makes a batch file that you run that has some simple copy commands. My reg backup now does this as well so you can restore just like erunt.

But on that I made an improvement. When restoring from the recovery console erunt only restores the system registry and none of the profiles. Mine replaces everything.

2nd improvement. In the Vista and Windows 7 repair options it maps the Windows drive as D: instead of C:. Because of this the restore from erunt will fail. I have made the batch file for these version detect what drive letter Windows is on and restore it properly. So my version support the repair options of the new versions of Windows.

Of course the program still has the restore option built into the program that you would run normally and even in safe mode. Again this can both backup and restore all profiles not just the loaded ones like erunt.

Lastly is the way the backups are stored. If needed if a recovery console or repair options are not available you will be able to do a extremely easy copy and paste from any other environment. Such as loading the drive in another system or loading another OS such as the ones that run off cds.

So my new program has the same 3 made restore options as erunt, but Improved them to be easier and work better with the new versions of windows.

And when it is out of beta I will have both guides and video showing how to do each one.

Shane

[Ztruker]

These are the logs from a good scheduled run at boot time. The vss* files in C:\Windows\temp were all dated today when the computer was booted.

[Shane]

Great! it is working.

Now lets see if it stays that way LOL

0.9.7 is out

And thanks again for working with me

Shane

[Ztruker]

BINGO!!!!! I deleted the vss* files in C:\Windows\temp and the manual backup worked correctly, so it looks like you are right and they are not being over written for some reason and are probably the ones created when by the scheduled backup at boot time.

Hmmm, just ran it again 3 minutes later and it ran okay again. Seems to only not work after the scheduled backup has occurred, which I think it setup to run under SYSTEM, not my login account.

I'll reboot in a little while then try the manual backup without deleting the vss* files in C:\Windows and see what happens.

[Ztruker]

Rebooted with 0.9.7 and there is a problem with the dos_restore.cmd file.

IF EXIST K:\WINDOWS\System32\Config\sam set WindowsDrive=K:
IF EXIST J:\WINDOWS\System32\Config\sam set WindowsDrive=J:
IF EXIST I:\WINDOWS\System32\Config\sam set WindowsDrive=I:
IF EXIST H:\WINDOWS\System32\Config\sam set WindowsDrive=H:
IF EXIST G:\WINDOWS\System32\Config\sam set WindowsDrive=G:
IF EXIST F:\WINDOWS\System32\Config\sam set WindowsDrive=F:
IF EXIST E:\WINDOWS\System32\Config\sam set WindowsDrive=E:
IF EXIST D:\WINDOWS\System32\Config\sam set WindowsDrive=D:
IF EXIST C:\WINDOWS\System32\Config\sam set WindowsDrive=C:

I have Win 7 on C: and Win 8 Customer Preview on I. I guess this will work as it will see the one on C: last and set the WindowsDrive variable correctly, but I think a better method would be for you to look at the HOMEDRIVE environment variable then set WindowsDrive to that value when building the batch file. Should always work.

Ran a manual backup and it worked. Checked C:\Windows\temp and not I have two sets of vss files:

C:\Windows\Temp>dir vss*
 Volume in drive C is D370_C
 Volume Serial Number is C89E-70E8

 Directory of C:\Windows\Temp

05/24/2012  08:51 PM               308 vss-setvar.cmd
05/24/2012  09:24 PM               308 vss-setvar553.bat
05/24/2012  08:50 PM               518 vss.bat
05/24/2012  09:23 PM               529 vss553.bat
05/24/2012  08:50 PM               290 vss_start.bat
05/24/2012  09:23 PM               296 vss_start553.bat

That works but will end up leaving more and more vss* files there over time. You need to figure out why you were not replacing the vss files before then go back to just the single instance of each.

Were you deleting them before writing new ones previously or just trying to write over them?

[Shane]

Does the HOMEDRIVE environment work in the windows vista and 7 repair environment?

And on the vss bat files. Here is the thing, I have the vss_start.exe set to when it closes it is deleting the files. So it shouldn't be building up. For some reason something is different in yours.

Can you do a check and post a screen shot of the security on the bat files? There has to be a reason for them not getting removed.

Shane

[Ztruker]

I don't know, but what I meant was when you create the dos_restore.cmd file, use the HOMEDRIVE variable then, or is the cmd file already built and not being generated on the computer when backup is run?

Next time I get a chance I'll start the Recovery Console and see what environment variables are set.

[Shane]

Yeah it is built after the backup runs.

Xp was a nightmare to do. VERY limited, I added some reg keys to allow the "set" command in the xp recovery console. I will have a how to on that when out of beta. So you can do
set allowallpaths = true

Without it you cant get to any other folders.

None of the normal commands work in the xp recovery. So it builds a VERY basic copy file just like erunt.

But when I got into vista and 7 they finally have all the commands and I was able to build a much better restore file.

I just built all that code today, so a good run through for any tweaks is always welcome.

Shane

[Ztruker]

Another possibility would be to add a line to backup_info.txt:

WindowsDrive=C:   (or whatever the boot drive actually is)

then you could read that from the dos_restore.cmd file but that's a lot more work. Easiest just to use the HOMEDRIVE variable when creating the cmd file.

[Shane]

Another possibility would be to add a line to backup_info.txt:

WindowsDrive=C:   (or whatever the boot drive actually is)

then you could read that from the dos_restore.cmd file but that's a lot more work. Easiest just to use the HOMEDRIVE variable when creating the cmd file.

See that's not the problem.

The problem is what drive letter did the repair environment give the windows drive?

In my test I found that it was giving the system reserved partition drive C: and the Windows partition drive D:

So the trick is to look for a file on each partition so it knows what drive letter to use.

That is also why I did it from higher to lower with C: being at the bottom. Better chance of it finding the right one on multiple installed systems.

I only had it go up to J: as just a base line, as I don't know how many are going to show up on someones system if they are multi boot.

I wonder what drive letter your Windows 8 will get when you go into the windows 7 recovery.

Let me know what each drive letter they get is

Shane

[Ztruker]

I booted the Recovery Console. My Win 7 boot drive was still C: even though I have a 100MB System Reserved partition. I know you can't depend on that though.

I guess a marker file on the partition is the best way to go unless each partition has a unique UUID or something that you can query in both environments.

The problem with a marker file is if there is more than one bootable Windows partition and Backup is used on each, then how do you tell which one to use?

Interesting problem. Could you key off the partition name? Each one has to be unique I think. For instance, mine are D370_C through D370_I.

[Shane]

Marker file could work. And it would be added to the list to check just in case the system got the marker file deleted.

Could have it create either a random marker file that the restore cmd looks for or a marker file based on computer name perhaps?

Have the marker file stored in the windows dir. If I did it with just a computer name, which is easier to keep track of, what are the odds that the dual boot systems will have the same name for each OS?

Shane

[Ztruker]

I think you can use the vol command:

>vol /?
Displays the disk volume label and s

VOL [drive:]

>vol c:
 Volume in drive C is D370_C
 Volume Serial Number is C89E-70E8
>vol d:
 Volume in drive D is D370_D
 Volume Serial Number is 9402-7174

It returns a unique VSN (Volume Serial Number) for each drive or partition. Now to figure out how to parse that info in the dos_restore.cmd file and I think it would be fail safe.

[Shane]

It wouldnt need to look for it in the recovery.

I would have the main program make a file in the windows folder. And when it is done witht he backup it writes the restore cmd which at that point I can tell it what file it needs to look for.

So all I need to do is come up with what to name the file.

Shane