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 zeigerpuppy on Friday July 11 2014, @07:59AM
Great to see you have some familiarity with Debian. I would recommend the following:
1) build two file servers, one on site and one off-site (Debian is fine) with RAID storage. RAID is not a backup but you want your backup on RAID! Make sure your servers have ECC RAM and a decent SAS controller (LSI 9207-8i for example are cheap and good) and at least 4 HDD drives (+ SSD optionally). These parts are not expensive now. You do not need a dedicated network connection between the servers unless you have more than about 5GB of data *changing per day.
2) I really like the combination of zfsonlinux with Debian http://zfsonlinux.org/debian.html [zfsonlinux.org] (use the unstable packages as they are plenty stable enough for such a purpose). ZFS makes sure that you don't suffer from "bit rot" but also makes replicating across an SSH connection easy (and incremental). The best thing is that snapshots are instantaneous and you get all sorts of other good features like easy NFS sharing and built in compression.
3) set up a nightly (or more frequent if needed) zfs snapshot and zfs send/receive (over SSH) to the offsite server. (if you go down this path, PM me and I am happy to share my backup scripts). Then you can rollback to any day (I keep one snapshot a month and the past 30 days).
ZFS has lowered my administrative load a great deal. Just a couple of gotchas, make sure that your ZFS version is the same or higher on your backup server (or else ZFS send/receive won't work), also make sure to have plenty of RAM - (at least 2GB per TB of data storage).
other less sophisticated (but still useful options) are rsnapshot and rdiff-backup (these are wrappers around rsync that do incremental backups that can be rolled back to particular dates). You still need two servers though, so just save yourself some time and spec them out for ZFS!
Also, the same thing can be achieved using FreeNAS or various BSD systems but if you're already familiar with Debian, stick with that (I also like that Debian can run a ZFS backed Xen hypervisor which you can't do on FreeBSD yet).
(Score: 2) by zeigerpuppy on Friday July 11 2014, @08:07AM
One more thing.... make sure to have a bash script that exports database tables on a regular basis (these are not properly backed up by just taking a file snapshot).
(Score: 1) by jbruchon on Monday July 14 2014, @01:14PM
SAS seems like a huge waste of money, especially for a very small business or home office. Why bother with SAS?
I'm just here to listen to the latest song about butts.