napp-it ZFS Storage, Руководство пользователя

Страница: 49 / 63

23.3 Disaster Protection
As long as your storage server is working or you can repair the system, you will need nothing but snaps to
regain any state of data, current or a previous version based on readonly snaps that you can create nearly
without limits, without a delay or a initial space consumption and that you can use for long term storage and
accessability. Monthly scrubs will check and repair any sort of bitrot to ensure long term data security.
What you must care about is a real disaster like fire, theft, sabotage, human errors, overvoltage or a massive
computer problem that results in a pool loss. To address such problems, you need backups that are not affectes
by any of the disaster reasons. Your backup system can also adress availability needs below realtime switchover
of storage or services that requires a hot failover system and the ZFS-1 plugin from high-availability.com as you
can access your data from a backupsystem at any time. With ZFS replication to can sync data between your
active storage and a backup system down to a few minutes even when the system is under heavy load.
Several Levels of disaster protection
Level 1: home use
Buy one or more disks depending to your security concerns like external USB disks or disks that you can insert
into your storage server with free disk bays. You can also connect USB disks to your laptop or desktop. You can
then access the backup there but without the snapshot security. Then use a sync tools, best is zfs send that
allows readonly snapshots on the backup disk. Other options are rsync or robocopy to sync folders from your
storage server to such a disk. Remove the disk (can be a mirror in case of ZFS) on a regular base and place it on
a safe place and insert the next disk to continue backups. Change this disk or disks with the former or next and
re-sync data on a daily, weekly or monthly base.
Level 2: SoHo use
Add another small ZFS storage server and place it on another physical location/ room. This can be a cheap HP
Microserver that gives you 4 disk bays where you can insert disks for a backup pool. Replicate data from your
primary storage on a hourly or daily base. Keep replication snaps there for previous versions. On problems you
can access or continue working on the backup system. From time to time, replace the backup pool with a
second one and keep the disks on a safe location outside.
Level 3: Professional use
Care additionally about two backups on different systems and different locations. As availability may be a
concern, use a second similar/ same system in a HA config or with async replication that you can run down
to some minutes delay. It would be perfect if it offers enough free disk bays to just move the disk from your
primary storage on hardware problems to continue work after a pool import with the original data state. Use
another backupsystem that allows to continue backup even when your first backup system is out of order or on
service. Care about a snapbased longterm backup history with replication snaps on your backup system. This
can be different from the snap retention polica on your primary system that you set with autosnap.
As an additional suggestion, use different disks on your backups systems to avoid problems like I had with
Seagate Constellations 3 TB. They work for more than a year without problems and nearly simultaniously they
fail one by another. Another suggestion is stay on a former OS release on your backup system. Bugs on a newer
OS will then not affect backups.
Level 4. Critical data
Backup and Async Replication are always needed to be protected against a disaster but they do not work
in realtime. If someting happens, your backup state is not really up to date. The delay to your former data state
can be minutes (replication) or a day (backup). An additional problem is the restore time of a backup or the
time for a service failover to a backup system. If you need your data and services to be available on a second
system with the same state without interuption, the current default commercial solution is a RSF-1 cluster
with two server accessing the same SAS disks via Multipath IO and a pool/service failover in case of problems.
Another solution is a napp-it ZFS Appliance Raid over the network. You need two ZFS server where each provide
an iSCSI target from a local datapool. An SCSI initiator (can be dedicated or provided by one of the server)
allows to build a pool with a Raid-1 over them. If server1 fails, you can enable the initiator on server2, import
the pool and your NFS and SMB services are up again with current data -even in an AD environment. Uf ser-
ver1 comes back, the data is resilvered over the network. An automatic failover is planned.