Назад | Перейти на главную страницу

Быстрая синхронизация пулов zfs

Мой сервер сохраняет инкрементные резервные копии на томе zfs. Из-за того, что данные очень похожи, я могу значительно уменьшить рост - существует около 500 ГБ «новых данных» каждый день, но пул растет только примерно на 5-10 ГБ / день, остальное хранится при дедупликации / сжатии.

Я хочу скопировать резервную копию на зашифрованные USB-диски, которые по этой причине я также настроил как тома zfs. Когда я синхронизирую резервную копию с помощью rsync или zfs send / recieve, кажется, что все данные передаются снова (просто сохраняются как дедупликация на USB-накопителе). Из-за этого резервное копирование в настоящее время занимает более 24 часов, что делает невозможным ежедневное резервное копирование.

Есть ли способ сделать резервную копию быстрее?

Совет Майкла Хэмптона уместен, и справочные страницы Solaris неплохие, но новичку не так-то легко понять эту концепцию. Я выделю моменты, которые я испытал при написании сценариев.

По сути, вы сначала делаете снимок x и полный send/recv по-прежнему:

# Initial send, destroy all filesystems on the destination
# pool which are not present on the source pool.
zfs snapshot pool0@snap0
zfs send -R pool0@snap0 | zfs recv -Fdu pool1

После этого вы делаете снимок x+1 и отправляйте его постепенно. Вы можете удалить старые привязки в источнике, но вам нужно оставить включенными последние (самые свежие), чтобы можно было рассчитать различия. Если вы потеряете / уничтожите свой последний снимок в источнике, вам придется начать с полной начальной отправки!

# incremental send, destroy all filesystems on the destination
# pool which are not present on the source pool. Afterwards, old
# snapshots can be destroyed.
zfs snapshot pool0@snap1
zfs send -R -I pool0@snap0 pool0@snap1 | zfs recv -Fdu pool1
zfs destroy pool0@snap0

# Afterwards, repeat and replace snap1 with snap2 and snap0 with snap1 etc.

Несколько советов из моего собственного опыта:

  • Удаление последнего снимка означает, что вам нужно начать все сначала, поэтому будьте осторожны, сначала проверьте успешные возвращаемые значения в своем скрипте.
  • Вы можете пронумеровать снимки или использовать date - нумерация проще, но даты лучше, если вы смотрите журналы и / или часто делаете снимки.
  • Экспериментируя с вариантами и пробуя -nv для моделирования имейте в виду, что это работает для send, но не сработает с recv, потому что получать нечего. Это не очевидно ни из руководства, ни из сообщений об ошибках.
  • Снимки будут занимать место, пока они не будут уничтожены, и они «заблокируют» ваше удаленное пространство. Если вы часто делаете резервное копирование, это не проблема. Если вы редко используете более одного целевого диска / пула и / или резервную копию, вы можете столкнуться с ограничениями дискового пространства. В illumos / OpenZFS существует bookmarks функция, которая может быть способом обойти эту проблему. К сожалению, в настоящее время он поддерживает только одиночные снимки, а не рекурсивные, поэтому вам придется добавить рекурсивный код самостоятельно.
  • Если вы не хотите использовать / писать свои собственные, воспользуйтесь одним из многих на Github. думаю znapzend самый зрелый из них.