[kwlug-disc] Open source backup tools

[B.S.]

----- Original Message -----

> From: Paul Nijjar <paul_nijjar at yahoo.ca>
> To: kwlug-disc at kwlug.org
> Sent: Friday, December 4, 2015 1:12 PM
> Subject: [kwlug-disc] Open source backup tools
> 
> I am heartily sick of Symantec/Veritas Backup Exec. I am looking
> shifty-eyed at Bacula/Barios and Amanda. There might be other backup
> solutions as well.
> 
> Unfortunately, my backup programs need to deal with proprietary
> software: 
> - Microsoft Exchange 2010!
> - Windows file shares!
> - Windows domain controllers!
> - Hyper-V virtual machines!
> 
> Bacula/Barios looks like it does not understand the concept of a
> registry, which sounds suspicious to me.
> 
> Obviously, the ability to support VSS is important. But there seem to
> be other intricacies to backing up these things that the software
> would need to handle as well.
> 
> I am backing up to big hard drives, not to tapes. 
> 
> So my questions: 
> 
> - Has anybody successfully used open-source backup tools to back up
>   horrible proprietary Windows stuff?
> - What works and what doesn't?


Can you clarify:

> - Microsoft Exchange 2010!


I expect only MS solutions are going to understand Exchange - are you willing to shut down exchange to back it up? Are you willing to move off Exchange to the Linux equivalent (which would let you use corresponding backup programs)?


> Unfortunately, my backup programs need to deal with ...


Are you talking bare metal restore?


> - Hyper-V virtual machines!


Are you willing to take them down in order to back them up? Else, snapshots / tools internal to the virtualizer being used? Assuming those tools are insufficient - migrating off Hyper-V to a bare metal solution like Xen or KVM? How much grief are you willing to go through at restore time? i.e. When I looked at this for vbox, for example, there was no way to do a live backup, even with fs snapshots/replication - e.g. snapshots don't take memory state, so attempting to boot a snapshot taken live risks bad things. e.g. Restore a SQL snapshot with a half-written transaction log and you will likely be unhappy. Less of an issue for a standalone (DC?) or file sharing server, I suspect - If turning a server off and on doesn't lead to too much issue most of the time, you're probably ok.

There is a not unreasonable argument to be made these days that all machines should be virtual.


> Obviously, the ability to support VSS is important.

- if VSS is being used, registries should come along for the ride. Ultimately they are just .dat files - the problem is usually that they are held open at all times. VSS works around that (for registries). [But you can still get half written preferences, for example, changes grouped instead of being atomic.]


Is clustering an option that substantially eliminates your need for backups? There are a couple of key backup concepts, RTO and RPO. Failover/Clusters may make a once per week backup acceptable.


Does it have to be centralized? (vs logs feeding to a central place for daily success confirmation?)
i.e. Central store restorable to alternate machines, vs having to go over to that particular repo to initiate a restore?


For me, replication has long been a better strategy than 'backup'. A BMR option for os only (ntbackup/mondoarchive), then replication (robocopy/rsync) for the rest. Replication to 2 cascading repositories provides for immediate restoration of oopses for 2 or 3 days. If you can implement a similar solution for SQL (and thus Exchange), you could then backup the non-live backup - which may expand your range of candidate options.


Are you looking for BMR on laptops and workstations too?
[Else, you have a clearly documented policy that if it didn't get saved on a server, you're SOL? And, broken machines will be replaced with standard images - personal settings will not be preserved?]