В настоящее время у меня есть два сервера, у которых одинаковое оборудование, диски и т. Д.
Один сервер (server1) будет «основным» сервером. По сути, это сервер с raidz2, на котором есть общие ресурсы SMB, к которым подключаются люди.
Другой сервер (server2) настроен так же, как server1 (raidz2), но предназначен только для резервного копирования server1. Он предназначен для резервного копирования на случай потери server1 из-за сбоя диска, пожара, повреждения водой и т. Д.
Я пытаюсь найти лучший способ сделать резервную копию на server2.
Сначала я подумал что-то вроде rsync. Это тривиально настроить в cron, и я могу запускать его раз в неделю.
В качестве альтернативы я думал о чем-то с zfs send / recv. Я понимаю, что ZFS может делать «снимки», поэтому я подумал, что было бы здорово, если бы я мог создавать снимки / инкрементные резервные копии, не теряя много места. Я чувствую, что это может быть труднее реализовать / подвержено ошибкам.
Как я уже говорил, оба сервера настроены одинаково с точки зрения оборудования и схемы raidz2. Что бы вы все порекомендовали в моей нынешней ситуации?
ZFS очень устойчива. Самый простой пример доставки файловой системы:
# zfs snapshot tank/test@tuesday
# zfs send tank/test@tuesday | ssh user@server.example.com "zfs receive pool/test"
Обратите внимание на снимок перед отправкой (и отправкой снимка).
Вы можете обернуть это в сценарий для удаления локального снимка после того, как вы отправили его на удаленный компьютер, или сохранить его, если у вас есть дисковое пространство для этого. Сохраните предыдущие снимки на резервном сервере.
Источник и настоятельно рекомендуется прочитать: https://pthree.org/2012/12/20/zfs-administration-part-xiii-sending-and-receiving-filesystems/
Я бы использовал инкрементную отправку / получение ZFS. Он должен быть более эффективным, чем rsync поскольку ZFS знает, что было изменено с момента создания предыдущего снимка, без необходимости изучения всей файловой системы.
Предполагая, что вы хотите полностью создать резервную копию файловой системы namen datapool/fs.
Сначала вы создаете пул для хранения резервной копии на целевом сервере и рекурсивный снимок в исходном пуле:
dest # zpool create datapool ...
source # zfs snapshot -r datapool/fs@snap1
затем вы отправляете все данные в качестве первоначальной резервной копии:
source # zfs send -R datapool/fs@snap1 | ssh dest zfs receive datapool/fs
На следующей неделе (или в любой другой период, который вам нравится) вы создаете второй снимок в исходном пуле и постепенно отправляете его в пункт назначения. В этот раз ZFS достаточно умен, чтобы отправлять только то, что изменилось за неделю (удаленные, созданные и измененные файлы). Когда файл изменяется, он не отправляется целиком, а только измененные блоки передаются и обновляются.
source # zfs snapshot -r datapool/fs@snap2
source # zfs send -ri snap1 datapool/fs@snap2 |
ssh dest zfs receive -F datapool/fs
Повторите операцию с увеличением номеров моментальных снимков каждый раз при резервном копировании.
Удалите неиспользуемые старые снимки на любом из серверов, когда они вам больше не нужны.
Если у вас есть ограничения полосы пропускания, вы можете сжимать / распаковывать данные на лету, например, вставив gzip/zip команды в конвейере или включив сжатие ssh.
source # zfs send -ri snap1 datapool/fs@snap2 | gzip |
ssh dest "gunzip | zfs receive -F datapool/fs"
Вы также можете использовать mbuffer получить более стабильное использование полосы пропускания, как описано в этом страница:
dest # mbuffer -s 128k -m 1G -I 9090 | zfs receive datapool/fs
source # zfs send -i snap2 datapool/fs@snap3 |
mbuffer -s 128k -m 1G -O w.x.y.z:9090
Обратите внимание zfs -r флаг недоступен в реализациях ZFS, отличных от Solaris, см. http://lists.freebsd.org/pipermail/freebsd-fs/2012-September/015074.html . В таком случае не используйте -F флаг на цели, но вместо этого явно откатывает наборы данных. Если в источнике были созданы новые наборы данных, сначала отправьте их независимо, прежде чем выполнять моментальный снимок + добавочную отправку / получение.
Конечно, если у вас есть только одна файловая система для резервного копирования без базовой иерархии наборов данных или если вы хотите выполнять независимое резервное копирование, инкрементное резервное копирование проще в реализации и должно работать одинаково независимо от реализации ZFS:
T0:
zfs snapshot datapool/fs@snap1
zfs send datapool/fs@snap1 | ssh dest zfs receive datapool/fs
Т1:
zfs snapshot datapool/fs@snap2
zfs send -i snap1 datapool/fs@snap2 |
ssh dest zfs receive -F datapool/fs
У меня были проблемы с использованием zfs send / receive для отправки 1 ТБ на удаленный компьютер. Я решил разбить единственную файловую систему размером 1 ТБ, чтобы она содержала несколько дочерних элементов. Теперь после сбоя сети в худшем случае нужно обидеться только на ребенка. Я использую свой сценарий, чтобы заботиться о рекурсивных отправках и синхронизировать пульт: https://github.com/dareni/shellscripts/blob/master/zfsDup.sh
Надеюсь, этот сценарий может быть кому-нибудь полезен.
Пример вывода:
# zfsDup.sh shelltests
Test: array_add()
Test: array_clear()
Test: array_iterator()
Test: nameValidation()
Test: isValidSnapshot()
Test: getSnapshotFilesystems()
Test: getSnapshotData()
Test: getRemoteDestination()
Test: printElapsed()
Test: convertToBytes()
Shell tests completed, check the output for errors.
# zfsDup.sh zfstests
Start zfs tests.
Test: new parent file system.
Test: new child file system.
Test: simulate a failed send of the child filesystem.
Test: duplicate and check the child@2 snapshot is resent.
Test: snapshot existing files with updated child data.
Test: simulate a fail send os child@3
Test: snapshot test1.
Test: snapshot test2.
Test: snapshot test3.
Snapshot tests completed ok.
Test: remote host free space.
Test: new remote FS with no quota.
Test: incremental remote FS update with no quota.
Cleaning up zroot/tmp/zfsDupTest/dest zroot/tmp/zfsDupTest/source
Test execution time: 89secs
ZFS tests completed, check the output for errors.
# zfs list -t all -r ztest
NAME USED AVAIL REFER MOUNTPOINT
ztest 344K 448M 19K /ztest
ztest@1 9K - 19K -
ztest@6 9K - 19K -
ztest/backup 112K 448M 19K /ztest/backup
ztest/backup@1 9K - 19K -
ztest/backup@2 0 - 19K -
ztest/backup@3 0 - 19K -
ztest/backup@4 9K - 19K -
ztest/backup@5 0 - 19K -
ztest/backup@6 0 - 19K -
ztest/backup/data 57.5K 448M 20.5K /ztest/backup/data
ztest/backup/data@1 0 - 19.5K -
ztest/backup/data@2 0 - 19.5K -
ztest/backup/data@3 9K - 19.5K -
ztest/backup/data@4 9K - 19.5K -
ztest/backup/data@5 0 - 20.5K -
ztest/backup/data@6 0 - 20.5K -
# zfs list -t all -r zroot/tmp
NAME USED AVAIL REFER MOUNTPOINT
zroot/tmp 38K 443M 19K /tmp
zroot/tmp/zfsDupTest 19K 443M 19K /tmp/zfsDupTest
# zfsDup.sh ztest zroot/tmp root@localhost
================================================================================
Starting duplication 20151001 16:10:56 ...
ztest@6...new...19K...0hr.0min.1sec
ztest/backup@6...new...19K...0hr.0min.1sec
ztest/backup/data@6...new...20.5K...0hr.0min.0sec
Duplication complete 20151001 16:11:04.
================================================================================
# zfsDup.sh ztest zroot/tmp root@localhost
================================================================================
Starting duplication 20151001 16:11:25 ...
ztest@6...up to date
ztest/backup@6...up to date
ztest/backup/data@6...up to date
Duplication complete 20151001 16:11:29.
================================================================================
# zfs snapshot -r ztest@7
# zfsDup.sh ztest zroot/tmp root@localhost
================================================================================
Starting duplication 20151001 16:12:25 ...
ztest@7...incremental...9K...0hr.0min.1sec
ztest/backup@7...incremental...9K...0hr.0min.1sec
ztest/backup/data@7...incremental...10K...0hr.0min.0sec
Duplication complete 20151001 16:12:33.
================================================================================
# zfs list -t all -r zroot/tmp
NAME USED AVAIL REFER MOUNTPOINT
zroot/tmp 124K 442M 19K /tmp
zroot/tmp/zfsDupTest 19K 442M 19K /tmp/zfsDupTest
zroot/tmp/ztest 86K 442M 19K /tmp/ztest
zroot/tmp/ztest@6 9K - 19K -
zroot/tmp/ztest@7 0 - 19K -
zroot/tmp/ztest/backup 58K 442M 19K /tmp/ztest/backup
zroot/tmp/ztest/backup@6 9K - 19K -
zroot/tmp/ztest/backup@7 0 - 19K -
zroot/tmp/ztest/backup/data 30K 442M 20K /tmp/ztest/backup/data
zroot/tmp/ztest/backup/data@6 10K - 20K -
zroot/tmp/ztest/backup/data@7 0 - 20K -
Вы также можете передать отправку / получение, например, bzip2 и rsync это. Так как это сообщение в блоге примечания, ведомое устройство должно иметь "только чтение".
Есть хороший инструмент для управления материалами отправки / получения и интеграции индикатора выполнения.
он находится в дереве портов freebsd в sysutils / zxfer или на github
Вы также можете использовать такой инструмент, как sysutils / zfstools или sysutils / zfsnap, чтобы автоматизировать создание моментальных снимков, которые будут синхронизироваться с удаленным компьютером через zxfer.
Дополнительную документацию по процессу отправки / получения zfs можно найти в официальном Справочник FreeBSD