Consider open source appliances for backup

“Backup used to be simple in SMB environments: You slapped on
your tape and autoloader, scheduled backup in the backup
application, and set it to run. Occasionally you would test to see
that it actually did run. Most of the time it worked; when it
didn’t you could troubleshoot the problem and make sure backup ran
that night. No harm, no foul.

“Those days are long gone. Backup remains a critical function
but several factors contribute to making a once-simple process
anything but.

“Manage complex backup procedures. Backup used to be tape. Now
it’s tape/VTL/SAN/NAS /DAS/cloud, etc. Your choices depend on what
you already own, what you’re familiar with, if the data is primary
or secondary, if the data is regulated and/or valuable, and how
much time you actually have to spend on all this. Multiple
applications require multiple backup procedures, which change
depending on server locations, application types, data sizes,
service level agreements (SLAs), and backup targets. There is
nothing wrong with having multiple procedures, but the complexity
makes it awkward to administer and verify.

“Grapple with restore. If you want to restore from backup
– which is the entire point – you must protect the
backup. The most basic procedure is to store inactive backup tapes
off-site, but this begs the question of quickly restoring priority
data. Storing lower priority data off-site is fine, but you should
keep critical data protected and close to hand for fast restores.
This requires maintaining secondary sites that enable
near-immediate restoration of critical data. However, this is an
expensive proposition.”

Complete Story