dhicks: dont get me wrong, I love your model and it would certainly be one of the option I would consider, but it isnt something you can plough into without being confortable with the concept and the workings of it. rsync is capible of duplicating block devices now isnt it? I assume this is what you are talking about? Or are you referring to file level with LVM taking a snapshot, rsync mirroring it off, and then deleting the snapshot?
Either way its not masively complicated but IME it is way above alot of peoples heads and is certainly not something our LEA would be happy with for the reasons localzuk has mentioned.
Localzuk: you are certainly heading down the right path as far as your requirements. You do need to consider my point on how your fileserver will work. Does the Overland handle this well? Also how does the Overland handle HA? It seems that good HA is one of the big things you pay for with the expensive SANs. Dont just assume that you can buy a Overland and then the QNAP for a backup SAN as depending on the protocols used this may not be possible.
It rather depends on what kind of backups you want - what kind of service level / level of rubustness you would like to provide. For mirroring of file servers I'd use DRBD to replicate block devices over the network in real time - everything that gets written to one server's storage gets written to another's. If one server falls over the mirror can be up instantly, or maybe within a minute or two, depending on what hardware you're running on (I think you need identical processors to be able to do near-instant failover of VMs - probably easier to just boot a new instance of the file server VM on the mirror server). This, obviously, implies having a second chunk of storage sitting around not doing very much most of the time (other than using up power), which a lot of schools would probably see as overkill.
For versioning of files, I'd use rsync to sync two servers, then have a deduplicating script run on the backup server to replace duplicate files with hard links to a common file. Both rsync and such a deduplicating script would work fine on Windows. The files would be shared the same as on the original server, with the same users able to read files, but no-one able to write - this share could then be mounted as a Windows drive, and any time people needed to restore a file they could just go and copy-and-paste it over to their normal workspace. This implies having a chunk of storage available that's larger than the original - the larger, the further back you'll be able to keep versioning. rsync would probably run once a night - you could stop file-sharing services first (or shutdown the file server, snapshot, and reboot) to ensure all files were in a consistant state while rsync ran.
For backups of VM images, and anything else you wanted placed on removeable media and taken offsite or into a firesafe, I'd shutdown the server, snapshot, reboot and rsync (with --copy-devices) to the removeable media.
Are there no front ends available to make setting up DRBD mirrored easier? If not, that's a potential gap in the storage market there - systems that can do fully replicated storage, with excellent local disk performance for your VM images, but at less cost than a SAN. It just needs a nice management front end that gets the concept across clearly - most people do seem to be rather stuck on the idea that they must have a SAN.Either way its not masively complicated but IME it is way above alot of peoples heads
Last edited by dhicks; 20th February 2011 at 11:48 PM.
There are currently 1 users browsing this thread. (0 members and 1 guests)