-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Bennett wrote:
>> Each night, we run a script which does the following (on the backuppc
>> server, the live server is only accessed by backuppc - rsyncd for backups):
>> 1) Make sure the windows 'cdrive' is not mounted
>> 2) restore the partimage file to the partition
>> 3) mount the partition in linux
>> 4) backuppc restore the most recent backup to the cdrive using
>> BackupPC_tarCreate .... | tar -xf -
>> 5) umount the 'cdrive'
>> 6) Check the 'ddrive' is not mounted
>> 7) mkntfs the 'ddrive' partition
>> 8) mount 'ddrive'
>> 9) backuppc restore the most recent backup to the ddrive using
>> BackupPC_tarCreate .... | tar -xf -
>> 10) umount the ddrive
>>
>> In our testing so far, everything seems to work perfectly, except we
>> need to "re-activate" MS Windows within 3 days of booting the machine.
>> Generally we just do our testing without re-activating windows, and also
>> we don't want to re-activate too many times or it may not work when we
>> need it to.
> 
> That's great to know that _something_ works.  I'm actually surprised
> ACL's were not the biggest of your problems.  As Les suggested, and
> you've confirmed, this looks like a good grounding to connect the
> dots.
> 
> Does your cdrive backup exclude any particular files (other than
> 'normal' excludes like pagefile.sys etc)?

I don't exclude *any* files at all. The only errors I see from the
backup are (about 70 per night):
Remote[1]: rsync: send_files failed to open "System Volume
Information/{d8d52fa7-cfa7-11de-bd0f-000fb5d47709}{3808876b-c176-4e48-b7ae-04046e6cc752}"
(in ddrive): Device or resource busy (16)

As mentioned though, I *AM* using the VSS version of rsyncd:
Remote[2]: Using VSS volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy97

> I'm wondering if the reason your method works with a file level
> restore over a fully functioning mininmal install, is some kind of
> dependancy on block-level location for some important data?  And if
> that is the case, no amount of fiddling out-of-band will work unless
> you preserve block location for whatever those important files are..
> 
> e.g. why doesn't a new NTFS file system, file restore, fixboot/fixmbr
> "just work"?  What else is missing?

Yep, which is what I initially tried with no success... I suspect
something very early in the boot process is causing the problem. One
thing I thought of/considered is what would happen if we used grub as
the boot loader.... Never tried it though, as this network/setup is
about 1.5 hours away, so I never go on site...

>> Please see the script attached, and let me know if you have any
>> suggestions for improvement.
> 
> I'll have a play and see if I can replicate your results, as well as
> try and tie in permissions.  I suspect Jeff will be similarly
> interested in having a look at this.

Sounds good, I'd be happier to have someone else able to replicate my
work, and if you sort out the permissions part it would also be nice to
incorporate that also.

Regards,
Adam

- --
Adam Goryachev
Website Managers
www.websitemanagers.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksMvxMACgkQGyoxogrTyiWoSgCfSvj5Napl7unuB53WaANXakyB
N/EAnjqfVnn7qTboAAn7B7FFmfWzTe6b
=8OI/
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/