Skip Ribbon Commands
Skip to main content

Cory's Blog

:

Quick Launch

Stenoweb Home Page > Cory's Blog > Posts > Dual Backup
December 14
Dual Backup

Years ago, I had become enamored with Acronis Backup and Recovery. I used it for a very long time, some of my desktop computers still use Acronis True Image Home, and to this day I would still probably run it if I could afford a copy. Instead, I've started to look toward other possibilities, especially those from Veeam. Last week, I alluded to Veeam Endpoint Backup Free, which I used with great success when TECT was a physical machine. As a virtual machine, I am now using Veeam Backup & Recovery Free Edition to make a weekly backup of TECT.

The complication with the way that I'd like to move forward with the TECT hardware, there will be two things that need to be backed up. The first is TECT itself, its operating system, configuration, management tools, and the base on which everything else runs. The second will be the Hyper-V virtual machines. As far as I presently know, Veeam Endpoint Backup will not back up Hyper-V machines.

Veeam Endpoint has a few other gotchas, such as the fact that it does not encrypt backups (while Veeam Backup and Recovery Free does). The biggest problem I can find with Veeam Backup and Recovery Free is that it doesn't do scheduling. Neither product is very specific about what it will do in the situation it runs out of space on the disk you're using, or more specifically, whether removable volumes (such as RDX cartridges) are supported for backup spanning.

The problem here is the same as it has ever been: TECT is a very big data-set and to back up everything at once involves a backup file that's bigger than most external hard disks. Right now, with most of my biggest datasets offloaded elsewhere, I can fit the whole backup onto a single 4TB disk, but that won't last for long as I start splitting things out, spinning up test machines, and putting some data back where it really belongs: on the server.

There are (as always) other questions, such as whether backups should be stored on very large external disks (or this one), in another server on the network, or on removable media such as tape. Years ago, I looked favorably upon tape, simply because most tape-focused backup software (such as Acronis Backup) automatically spans media, the same way that Acronis True Image Home can be used to back up a large system onto optical media.

The biggest problem with removable media as the primary backup destination is that it's often not big enough (LTO 7, said to store 15TB of compressed data) or if it's currently big enough, it won't be for long. Automation hardware for both tape and removable disk systems is costly. The cost of an inexpensive RDX system is high enough that it almost makes more sense to build a file server, and then manually replicate files to single RDX cartridges. Veeam appears to support tape an RDX cartridge in a disk-to-disk-to-x fashion. The details of how that's implemented might make it more or less practical, though.

I'll continue looking into it. One of the hardest things is that backup software and hardware are often sold disparately, so if you have an idea of what hardware solution will work best for your environment, you need to work from there and find software that works with the hardware you get. On the other hand, if you have software you want to use, you must find hardware that works with it.

Backup appliances are a thing that exists, although they tend to be very costly (usually). I tend to think that it's unnecessary to go that far for my specific needs.

I have some time to decide on an exact solution before moving forward. Because "TECT" is stable on finnmark, I can simply keep running that while doing some testing on TECT. I'd like to see whether I can find something easy to license that can back up everything in one go. If not, I'd like to play around with different ways to set up the TECT hardware and the virtual machines. Simply running two different backups, one for Windows and one for its client Hyper-V VMs may not be that bad.

Comments

There are no comments for this post.