Вопросы Теги

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

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

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

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

2
задан 31 October 2016 в 19:56
1 ответ

Совет Майкла Хэмптона уместен, и справочные страницы 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.

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

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

Теги

Похожие вопросы