Persistent backups for bare metal recovery Edit

[Micky]

I have a feature request.

Since shadow copies listed by vssadmin are accessible as block devices at \\.\HardiskVolumeShadowCopy# (w32 device name space) so it'll be really cool to have some something like dd loosely integrated into shadowspan for complete volume backups.

There are few variants of dd.exe out there.

Why? Because Windows OS is prone to crashes than its counterparts and baremetal recovery would make sense.

Thanks.

[Craig Andera]

Interesting. Is there something about the drive letter mounting that
prevents you from doing this now? That is, can you run something like

shadowspawn C:\ Q:\ dd whatever

?

Scenarios like this are sort of the reason I created shadowspawn from
hobocopy, although I haven't tried anything at the block level.

> --
> You received this message because you are subscribed to the Google Groups
> "ShadowSpawn Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to shadowspawn-to...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Micky]

I tried and it works very well.
I used the dd.exe from FAU package written by George Garner from
http://gmgsystemsinc.com/fau/

Ironically, I found dd very efficient on system resources with good
read/write speeds (uses very little memory with <2% of cpu) unlike the
stock Windows Backup, which not only is highly unreliable but also
hogs up the system resources and restoring bare metal backups created
with Windows Backup tool breaks all hell loose!

After running 'shadowspawn C: Q: ping -t 1.1.1.' command in a separate
window, I used 'vssadmin list shadow' and got the path for latest
shadow volume, which looked something like this:
Shadow Copy Voulme: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy103

Then I ran dd.exe with below syntax and dumped the image off to a
network share Y:
dd if=\\.\HarddiskVolumeShadowCopy103 of=Y:/server.img --localwrt

Restoring is easy. Reinstall the OS, boot through one of many live
rescue CDs out there, and run dd to restore C: drive.
Of course, even more easier, when your OS is virtual on a hypervisor
with LVM based storage, like myself!

I think integrating dd (or some sort of block level copy or at least
some way to get latest shadow volume path, time wait etc) with
shadowspawn would make it a killer spawning tool allowing bare metal
backups as well.

[Micky]

On Tue, May 28, 2013 at 7:03 AM, Craig Andera <can...@wangdera.com> wrote:

> Interesting. Is there something about the drive letter mounting that
> prevents you from doing this now? That is, can you run something like
> shadowspawn C:\ Q:\ dd whatever

Sorry forgot to answer your question.
Yes. The dd utilities take input as block device. And the device name
space for the last shadow volume cannot be known until the shadowspawn
creates one. And it has to be taken from 'vssadmin list shadows'. So,
an option that allows automatic usage of w32 name space of the shadow
volume (as a parameter) would be great.

> Scenarios like this are sort of the reason I created shadowspawn from
> hobocopy, although I haven't tried anything at the block level.

The reason why I love shadowspwan. It is really helpful in writing scripts :)

[Micky]

I was able to access volume shadow copies in Cygwin under
/proc/sys/Device/ and successfully scripted it out.
But still a built-in option to access vss device name paths would be great.

(May be, also, add it to README as other possible uses)

[Micky]

Discard that.
Seems like accessing block devices in Cygwin is not a good idea. As of
the latest stable version, Cygwin doesn't introduce the shadow vloumes
as real block devices. So dumping the aforementioned path goes into an
endless loop.
So, an option in shadowspawn will greatly help.

Sorry for the confusion!!

Thanks.

[Craig Andera]

Two things:

First, it almost seems to be like what would be better would be a
program that, when given a drive letter, would return the block device
it mounts. Then you have two tools rather than one more complicated
one. Obviously, gluing them together would be up to the caller.

Second, shadowspawn and hobocopy are no longer on my "I want to be
spending time on these" list. Even stuff like trying to figure out
where to put the downloads (github no longer has a download service)
is sort of a pain, and quite honestly I use Windows less and less
these days, with a target of "not at all" in the not-too-distant
future. So while I think your suggestion is cool, I'm not really in a
place where I'm inclined to spend time implementing it. Would you be
interested in taking over the project? I'd be happy to put redirects
or whatever in place.