SoylentNews is people
SoylentNews
This is probably one of those topics that gets regurgitated periodically, but it's always good to get some fresh answers.
The small consultancy business I work for wants to set up a new file server with remote backup. In the past we have used a Windows XP file server and plugged in a couple of external USB drives when space runs out. Backups were performed nightly to a USB drive and taken offsite to a trusted employees home.
They are looking to Linux for a new file server (I think more because they found out how much a new Windows file server would be).
I'm not a server guy but I have set up a simple Debian-based web server at work for a specific intranet application, but when I was asked about ideas for the new system the best I could come up with was maybe ssh+rsync (which I have only recently started using myself so I'm no expert by any means). Using Amazon's cloud service has been suggested, as well as the remote being a dedicated machine at a trusted employee's home (probably with a new dedicated line in) or with our local ISP (if they can offer such a service). A new dedicated line out of the office has also been suggested, I think mainly because daily file changes can potentially be quite large (3D CAD models etc). A possible advantage of the remote being nearby is that the initial backup could be using a portable hard drive instead of having to uploading terabytes of data (I guess there is always courier services though).
Anyway, just thought I'd chuck it out there. A lot of you guys probably already set up and/or look after remote backup systems. Even if anyone just has some ideas regarding potential traps/pitfalls would be handy. The company is fairly small (about 20-odd employees) so I don't think they need anything overly elaborate, but all feedback is appreciated.
(Score: 2) by egcagrac0 on Friday July 11 2014, @03:59PM
RPO, RTO is a good start. It's OK to have several different tiers of RPO/RTO, for different targets.
What do you want to recover from? What do you not want to recover from? This is an eye-opener - at some level of catastrophe, the business owners are going to say "You know what, screw it. Give up, collect the insurance, move on." When that level event happens, you don't need a full recovery - you need enough recovery so that the insurance claim can get filed.
Business continuity planning sucks. Particularly with small business owners who often don't understand what they want (everything, duh!) vs what they need vs what they are willing to pay for.
It gets more complicated if you have to mix desktops into the recovery plan, but in a lot of cases in the past, the people I've worked with don't want EVERYTHING backed up, they just want their documents folder (excluding music/movies). A lot of times, they're even willing to get back most of it, instead of insisting on everything, so long as they know that they're trading security vs convenience and which side they're balancing on.
Defining the targets, RPO, RTO, and scenarios to recover (and not recover) from informs the selection of a solution, including whether or not offsite is necessary (or desirable).
... and don't put the primary or backup servers in the same room as the water main, just in case.
(Score: 2) by egcagrac0 on Friday July 11 2014, @04:20PM
And then, once that's done, see if your ISP offers colocation - that's probably a better landing spot for the remote contingency plan than someone's home closet.
VPN is probably a more cost effective solution than a dedicated circuit.
When you're designing the storage solution, remember that the primary storage server (fileserver) needs to be fast and reliable, but the backup server just needs to be reliable (speed is a secondary concern - informed by RTO).
Set up some sort of monitoring. You want to discover before it's "too late" that the backups aren't working. Or that the RAID on the remote storage is degraded. Or that the RAID on the primary storage is degraded. Or that the chassis intrusion has gone off in your supposedly locked rack. Or that the remote system has gone offline because some bonehead kicked a power cord. I, for one, find notify-on-success to be an unhelpful monitoring system (it all just becomes background noise to me), whereas notify-on-failure is a somewhat harder problem to solve.
(Score: 0) by Anonymous Coward on Saturday July 12 2014, @12:02PM
I am impressed by your confident, rigorous use of arcane, domain-specific acronyms and want to subscribe to your newsletter.