Backup - hardware implementation

mpoleski

Cadet
Joined
Jun 16, 2019
Messages
5
Backup is supposed to protect my data not only from hardware failures, but also software errors (rm -rf /too/much/) or even disasters (NAS hardware stolen). Here we simplify the problem by making compromise on freshness - let's say that restoring my data from 2 weeks old backup is good enough (if doesn't happen too often).

Implementation of backup using snapshots is probably not good enough - still can accidentally/purposely destroy my pool, or software bug can do this, or virus, ...

Building full separate NAS for this purpose is a quite expensive approach though. So I was thinking about intermediate solutions. If we ignore site disasters for the moment, here are the ideas:
  • Put more hard drives in the NAS. Additional hard drives will not participate in the ZFS pool, preferably would not even start on power on. These hard drives could be started programatically according to backup schedule only to update backups (two separate sets with round-robin?) and then switched off again. Having these hard drives switched off would protect them from unwanted wear, save electricity, protect from some classes of software issues (but in principle these could still be dd if=/dev/zero of=/dev/... or similar when e.g. rebuilding ZFS setup).
  • Have separate box(es). I was thinking about something cheap, just to assure there is enough capacity. Schedule, wake on LAN, automatic backup, shut down. Better isolation, but need more hardware. Also reliability would probably have to be lower (unless I basically want to duplicate my primary NAS). It would take more space and probably more electricity. It would also take more $$$ to build.

Solution of site disaster issue probably requires going for a separate server, probably in cloud, so I keep it separate for now.

What is your solution for backups? Any advices how to build decent solution without thrashing too much money?
 

John Doe

Guru
Joined
Aug 16, 2011
Messages
635
Top