From: Jeffrey J. K. <bac...@ko...> - 2011-05-17 17:05:31
|
lmi...@mi... wrote at about 16:23:53 +0200 on Tuesday, May 17, 2011: > Hello backuppc-users, > > I would like to backup all the machines of my company (12 laptops, > Windows/Mac/Linux) in a centralized way on a NAS device. > I like a lot BackupPC and if possible I would like to use it to run the > backups. > > Now comes the choice of the NAS... What NAS device would you recommend with > a good ratio "performance / easy to install BackupPC on it" ? > > The ideal situation would be a NAS with BackupPC pre-installed - or a NAS > with some available BackupPC packages ready to deploy. > I looked at Synology / QNap / WD Sharespace but in each case the install of > BackupPC seems tedious, and I'm not sure of the performances I will get on > such devices... > For 12 laptops (which is all things considered a small setup), you could probably get by with either of the following approaches. I actually am implementing both now in my SOHO setup (the first is my primary setup, the second is my backup backup setup) 1. [Easiest] Run Backuppc on a normal (even low end) x86 PC and mount the NAS as a storage drive. I do this using NFS (but others have suggested using iSCSI or "SATA over Internet"). This requires next to no special configuration if your NAS supports (or can be made to support) NFS or other similar technologies. 2. [Harder] Run BackupPC native on the NAS. I have done this on arm-based NAS's (including a DNS-323) by installing debian and then running backuppc on debian. The only potentially difficult part here is installing debian (or other multi-purpose linux distro) if it is not already native on the device. Some NAS's may already have a working linux install. (Other people have installed BackupPC on the DNS-323 directly but I shied away from that since the native OS implementation on the DNS-323 is limited and old). Note that there are a couple of subtle bugs in the ARM-based implementation of the perl md5sum and rsync libraries that cause inconsistencies between arm and x86 pools -- this doesn't cause any real problems if you always keep your pool on an arm-based system. If you want to know how to fix those bugs I have posted solutions on the mailing list (search the archives). If you run BackupPC on a normal PC and mount the NAS then your rate limiting step is likely to be network bandwidth assuming that your PC is reasonably powered. However, since most NAS's can support gigE this shouldn't be a limitation if you have a gigE connection between your PC-based BackupPC server and the NAS. Note, I get by sharing the same 100MHz Ethernet connection as all my pc's using a low end switch & router. If you run BackupPC natively on a SOHO NAS, then your rate limiting step is likely to be CPU power and to a lesser extent RAM since many of the low end devices run on 1.2 GHz ARM-based CPU with 512MB DRAM. However, I have successfully run BackupPC on the DNS-323 which has a lowly *500MHz* ARM cpu with a measly *64K* of DRAM. The limitation. The limitation will be apparent with compression, ssh, and the rsync algorithm. With a small number of laptops (you mention just 12) and assuming that you don't have a huge number of files changing every day, you should be able to get by even with compression turned on as long as you have a long enough backup window. Also, if backups are taking too long you could change the backup interval so that backups occur only every other day or so. The bottom line is that BackupPC is not particularly resource intensive and will work with very minimalist systems. In most normal situations, the rate limiting step is disk speed anyway which has nothing to do with NAS vs. PC. |