Backup and running

Last modified by Mitchell on 2022/01/25 03:55

The past few weeks have been pretty hectic, so I haven't had as much time to work on things as I'd prefer.

An important part of having a production-grade system is, naturally, having backups. it's remarkably possible to put together a semi-decent system with a little bit of effort. Some requirements:

  • Cross-platform support
    • I have Linux and Windows systems with data I need to back up.
  • Secure
    • No single system should have the ability to read the backups of all other systems.
  • Redundant
    • As much as possible, the backup system should tolerate failure.
  • Free
    • Okay, so I'm cheap. But this is a purely personal setup, so I'd like to minimize my investment (especially since a lot of the available options easily run over several thousand dollars!).

The layered system I've put together looks like this:

  • Backup system: Greyhole
    • A Linux-based system that attempts to mimic Windows Home Server's Drive Extender capabilities. The advantage it provides is JBOD exported as a single logical volume, while not having to worry excessively about what happens when a single disk fails (you lose the contents of that disk, but the contents on other volumes remain intact). Honestly, it's a hack, but if it works....
  • As a basic level of access control, different Samba accounts for the various systems should restrict access for one system to another's backups.
  • Linux engine: tar through GnuPG
    • Piping tar through GnuPG allows for a simple system while keeping the encryption/decryption key on the client system.
    • Maintaining database consistency is incumbent on me.
  • Windows engine: Windows backup through TrueCrypt
    • Windows Server's built-in backup works well, in that it ensures that databases stay consistent (in particular those for Active Directory and Exchange). But it doesn't support encryption. Setting up a TrueCrypt volume for Windows to mount alleviates this issue, and allows for retaining the encryption/decryption key on the client system.
  • Secondary backup system: CrashPlan
    • Having "on-site" backups is great, but having "off-site" backups is also important. CrashPlan works well as a peer-to-peer backup system, allowing the backups to be duplicated elsewhere.

Putting together the Windows piece is actually a little bit more complex, due to the fact that although TrueCrypt declares itself as a local drive, it doesn't support all of the operations that Windows expects to be able to perform on a local drive, as a result failing with a not-so-helpful "Catastrophic failure" error message, with Event Viewer showing an error code of either 2147549183 or 8000FFFF (hex). There is a workaround described on Super User, but what's described doesn't lend itself well to automation. I've pulled together a batch script that handles everything reasonably well:

backup.bat
rem Cleanup from previous runs.
net share backup /delete
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /s /dy
net use z: /delete

rem Get variables to minimize customization.
for /f %%a in ('hostname') do set hostname=%%a
for /f %%a in ('whoami') do set whoami=%%a

rem Mount the network mount.
net use z: NETHOST\%hostname% "NETHOST_PW" /user:NETHOST_USER

rem Mount the TrueCrypt volume.
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /v z:\%hostname%.tc /ly /a /p "TRUECRYPT_PW"

rem Share the network drive.
net share backup=y: /grant:%whoami%,full

rem Run the backup.
wbadmin start backup -backupTarget:
%hostname%\backup -include:c: -systemState -allCritical -quiet

rem Sleep for 30 seconds to wait for the share to stop being used.
timeout 30

rem Remove the network drive.
net share backup /delete

rem Unmount the TrueCrypt volume.
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /s /dy

rem Cleanup this run.
net use z: /delete

Naturally, make the following substitutions:

  • NETHOST
    • The backup server that hosts the TrueCrypt volumes (accessed via SMB).
  • NETHOST_USER/NETHOST_PW
    • The username and password for the backup server.
  • TCPASSWORD
    • The password for the TrueCrypt volume.

A few assumptions made for general deployability:

  • This script uses drives Y: and Z:. Change as needed.
  • Each TrueCrypt volume goes to its own folder based upon the host's name (in case you want to have NETHOST_USER be per-host).
  • Each TrueCrypt volume is named after the host's name.
  • I chose not to rely on the administrative Y$ share, as it's not guaranteed to be available, and reliability >>> shorter code in this case.

Posted by Mitchell · Categories: · Permalink · Comments (0)