Windows system backup/restore methodology

[Spadajspadaj]

Hi there.

I've been pondering the windows quirks and challenges related to this
particular system. For many years I used the approach of "do a Windows
Backup job and let bareos pick the results". That worked... reasonably
well although windows backup image was always backed up as full which
was not very space-effective. But it worked until one day my windows
(probably after a migration from bare-metal to a virtual machine; but
that was undebuggable - no logs, no nothing) simply decided that windows
backup won't run. Just like that. Also as far as I remember, windows
backup is obsolete and deprecated and the "recommended" way of handling
backup with windows is "back up your data; preferably on onedrive and
for disaster recovery just reinstall from scratch". There's also this
silly thing called "file history".

Anyway, while backing up my documents is easy and I've been backing it
up with bareos for many years now, the most frustrating thing in case of
disaster is the necessity of complete system reinstall along with all
the software reinstall and reconfiguration. Of course with unices it's
relatively easy to handle since you can back up package lists and easily
reinstall the packages from the source and the configuration and state
of the system-wide stuff as well as user-level configuration is
relatively easy to restore (even if it boils down to "restore whole
system to another drive, boot with just shell running and move over
whole /etc, /var and so on - I can do that easily and get a working
system from scratch in two hours).

But with windows while apparently you can back up all files from the
running system (including registry), you can't restore the system onto a
running machine since a lot of files will be locked for writing and you
can't boot up a system with "just shell running" - windows has so many
strange services running underneath that it's impossible. I already
found some mentions of attempts of using WinPE and bareos-fd to do a
bare-metal restore (mind you, my problem is not a bare-metal restore as
such; I don't mind installing a fresh system and then do a restore over
it; it just seems impossible in this case so it might indeed boil down
to bare-metal restore).

For now, since I needed to install windows from scratch anyway (and
restoring about half of the previously installed software took me
several days) I tried to do an ugly hack - Install windows on a small
c:\ disk, then boot with rescue console, move all the essential
directories that are not c:\windows onto another disks and leave
junction points pointing to them instead. This way I'd have a small
system disk which I can do a LVM snapshot of and can back it up on the
hypervisor's side and the "work disk" which I can normally back up
file-wise. The idea was neat but it seems that for windows it's not a
seamless replacement and some programs notice difference.

I'm also trying to do a windows install and point %PROGRAMFILES%,
%PROGRAMDATA% and such to another disk right from the start (which is an
even uglier hack, I admit) but I can't get it to work yet. The only
upside to this story is that I'm learning about windows installation
process (which is nowadays a bit more organized that used to be, I admit).

Of course I could have a huge windows device and back it up as a block
device but that's extremely ineffective and I cannot reasonably easily
extract files from within such backup, so that's a bad idea.

Any other hints? The point is to be able to restore system _with
configuration_ if something happens. And not use ridiculously big
amounts of space.

MK

[Frank Kohler]

Not sure I have all details. If your win deployment is as .vhd why not
checkpoint/snapshot and backup?

--

[Spadajspadaj]

Ahhh. No.

As you might have noticed (true, I didn't write it explicitly) - I
mentioned LVM snapshots - it's a windows machine on linux hypervisor.

MK

[Seth Galitzer]

The thing about Windows is it is A) fragile, and b) uses (largely) a
monolithic binary configuration database (registry). Both of these mean
you can't treat it like you would a Linux host, for example. In
enterprise shops, configuration of Windows machines is done with a
combination of Group Policy Objects (GPOs) stored in the AD, and
external application deployment and configuration, with something like
SCCM (we use PDQ).

If a system breaks, you install the OS (or clone from a known good
source), and redeploy configuration and apps. The installation or
cloning can be automated as well, where a tech just needs to initialize
it, in person or remotely using various tools, and then can walk away.
Nobody wants to sit around watching the OS install on a dozen or 100
desktops at refresh time. Centralized configuration means a more
homogeneous desktop deployment where you always know what to expect when
you sit down at a machine to work on it.

Even if you are using snapshots of VMs, you need to make sure the
snapshots are healthy. If you have an "old" machine that you keep taking
snapshots of, due to system fragility, that snapshot becomes less and
less reliable. You could end up with a garbage-in-garbage-out scenario.
If you are using a VDI solution, you have more options, as it separates
the system layer from the user layer.

As for user files, in the department I manage (Computer Science at a
state university), our users are long-conditioned to save files on the
file server and not the desktop. We don't backup desktop files, but we
do backup the file server (using bareos, of course). I have a few
colleagues elsewhere on campus that do backup files from desktops for
users, but I don't and I make sure my users know that.

That's what works for me, and what I preach to future IT professionals
that come through our department. And I'm always on the lookout to do
all of this better and more efficiently.

Cheers!

Seth

On 12/17/23 10:12, Spadajspadaj wrote:

>
> Any other hints? The point is to be able to restore system _with
> configuration_ if something happens. And not use ridiculously big
> amounts of space.
>
> MK
>

--
Seth Galitzer

The beatings will continue until morale has improved.