Приветствуем в блоге компании «Маклауд»!
Сегодня мы поговорим о том, о чём должен помнить каждый — про бэкапы.
Программисты уже давно стараются использовать серьёзные production-ready решения для сохранения личных данных. Требования к инструментам растут, и если когда-то было принято держать домашние файлы на NAS и перекачивать снапшоты сервера через Rsync, то сейчас на передовой гораздо более сложные и функциональные проекты. Один из них — возможно, самый перспективный и мощный — файловая система ZFS. Оставив конкурента (btrfs) далеко позади и отстояв право на опен-сорс, она активно применяется как в хайлоаде, так и в личных системах хранения. Далее мы разберём её основные аспекты и за несколько минут поднимем рабочую систему бэкапа на удалённой VPSке. Поехали!
Кратко о ZFS
В ZFS заложена одна простая идея: должна существовать единая файловая система, заточенная под идеальное локальное хранение данных. Без лишних слоёв над LVM, без жёсткой привязки к железу, с максимальным покрытием задач прямо из коробки. И список возможностей у неё впечатляющий, вот самые базовые:
- Copy-on-write: данные никогда не перезаписываются, все старые версии доступны напрямую с диска, без необходимости использовать write-ahead log (и как следствие, сверять журналы). ZFS работает на дереве хэшей (Merkle tree), гарантирующее консистентность в обмен на затратные вычисления всего дерева. Таким образом, система прежде всего нацелена на максимальную сохранность всех данных.
- Так как любое сохранение состояния выполняется через атомарные транзакции, доступны «мгновенные снапшоты», которые действительно можно снимать с почти неограниченной частотой благодаря фиксированной стоимости. Не нужно проверять изменения всех данных, достаточно оперировать хэшами, за валидацию которых отвечает корневой блок дерева.
- Программный RAID через mirror или raidz — аналог RAID 5/6/7 — конфигурируется через виртуальные устройства (vdev). Нет зависимости от конкретного железа (не придётся бояться write-hole), можно выбрать между надёжностью и производительностью на одном и том же наборе дисков. А ещё при избыточности ZFS автоматически выполняет self-healing при случайных ошибках.
- Потоковое сжатие (LZ4/gzip) работает из коробки, не накладывая заметной задержки при записи. При этом слегка возрастающий расход процессорного времени компенсируется меньшей нагрузкой на диск, что полезно и для отказоустойчивости, и для вариативности в выборе дисков.
- Категория «прочее»: дедупликация данных (отключаемая), независимые вложенные файловые системы со своими настройками, недостижимый лимит на размер файлов (ZFS 128-битная), и самое главное для нас: встроенный трансфер снапшотов через команды send/receive с триггерами before и after.
Здесь, здесь и здесь можно почитать подробнее про внутреннее устройство ZFS, её историю и нюансы администрирования.
Если сравнивать возможности Rsync и кастомных скриптов для синхронизации с ZFS, у них не будет ни шанса. Комбинируем плюсы выше: инкрементальные консистентные бэкапы + мгновенные снапшоты + программный RAID + отправка бэкапов из коробки = идеальный инструмент, объединяющий в себе мощный функционал и огромную производительность. Чтобы добиться подобного привычным инструментарием, понадобится оркестрировать кучу сервисов с многочисленными точками отказа.
Настраиваем бэкап за чашкой кофе
Разнообразие возможных хост-систем огромно — ZFS поддерживается на FreeBSD, Linux, Windows и MacOS, и разобрать все возможные сценарии в рамках одной статьи невозможно, поэтому рассмотрим самый расхожий вариант. Дано: локальная машина или сервер на Ubuntu/CentOS с данными (скажем, веб или база данных), которые необходимо сохранить на удалённый сервер (VPS на тех же системах), с версионированием и быстрым откатом.
Важный момент: за рокетсайнс под капотом ZFS расплачивается высокими требованиями к ресурсам при использовании raidz на обычных SSD (и при больших объёмах хранения, само собой). Поэтому для комфортной работы и на хост-машине, и на VPS потребуется как минимум двухъядерный процессор с 4гб памяти.
В последних версиях Ubuntu:
sudo apt install -y zfs
В версиях до 20.04:
sudo apt-get install zfsutils-linux
CentOS 8:
sudo dnf install https://zfsonlinux.org/epel/zfs-release.el8_3.noarch.rpm
gpg --import --import-options show-only /etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux
# в большинстве случаем также потребуется DKMS:
sudo dnf install epel-release
sudo dnf install kernel-devel zfs
Команда zfs без переданных аргументов откроет help:
missing command
usage: zfs command args ...
where 'command' is one of the following:
version
create [-p] [-o property=value] ... <filesystem>
create [-ps] [-b blocksize] [-o property=value] ... -V <size> <volume>
destroy [-fnpRrv] <filesystem|volume>
destroy [-dnpRrv] <filesystem|volume>@<snap>[%<snap>][,...]
destroy <filesystem|volume>#<bookmark>
snapshot [-r] [-o property=value] ... <filesystem|volume>@<snap> ...
rollback [-rRf] <snapshot>
clone [-p] [-o property=value] ... <snapshot> <filesystem|volume>
...
Создадим пулы на хосте и на сервере командой zpool:
zpool create rpool
zpool create hotspare mirror sda sdb
Создадим в пулах файловые системы:
zfs create rpool/send-remote
zfs create hotspare/receive-remote
Запишем тестовый файл и создадим снапшот:
touch /rpool/send-remote/tmp
zfs snapshot rpool/send-remote@test0
Как видно, сохранение не заняло и секунды.
Теперь реплицируем данные на сервер (предполагается, что авторизация в ssh по ключу настроена, о том как это сделать, можно прочитать здесь):
zfs send -R rpool/send-remote@test0 | ssh my-vps-host zfs receive -A hotspare/receive-remote
Теперь у нас есть реплика данных хоста. Обновим данные на хосте:
echo 123 > /rpool/send-remote/tmp
zfs snapshot rpool/send-remote@test1
Теперь нам не нужно делать модную реплику, достаточно инкрементальной записи:
zfs send -i rpool/send-remote@test1 | ssh my-vps-host zfs receive -A hotspare/receive-remote
Готово! Данные сохраняются на сервере, остаётся только настроить отправку по вашим триггерам (и/или регулярную синхронизацию). Для этого есть много готовых скриптов (пример), но лучше разобраться и написать свой, используя документацию
Заключение
Полностью разобраться в ZFS — огромный труд, освоив который, можно смело идти админить кровавый энтерпрайз. Но не всегда нужно идти на такие жертвы, достаточно изучить базовый функционал и написать пару скриптов, чтобы добиться результата, который потребовал бы куда более неудобного управления цепочкой более простых, но узкоспециализированных инструментов.
Маклауд размещает своё оборудование в надёжном дата-центре уровня TIER IV — DataPro. Мы предлагаем серверы для разных задач — в том числе, для хранения больших массивов данных, резервных копий. Зарегистрируйтесь по ссылке и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
RC_Cat
Вторая статья от хостера про бэкапы и zfs. Если все так хорошо, зачем хардварный raid тогда нужен? Или ресурсов на zfs требуется сильно много и это не всем подходит?
Kopilov
Хардварный raid нужен на случай поломки хардварного диска. В случае какого-нибудь софтового drop table или rm -rf /* без бэкапа он будет бесполезен, увы.
a1888877
Отвечу за автора статьи: zfs ортогональна аппаратному RAID.
У ZFS есть две киллер-фичи для резервного копирования:
1. Дешевые снимки состояния, с возможностью доступа во внутрь. Вы можете делать checkpoint-ы тысячами, без какого-либо влияния на производительность. Можете их сотнями одномоментно удалять, не заметно для текущих операций чтения/записи.Можете зайти в каталог .zfs/snapshots/имя-снимка и получить копию файловой системы этого снимка.
2. Возможность репликации снимков по сети.
Обычные RAID контроллеры, да и дисковые массивы начального-среднего ценового уровня такого не умеют. Поэтому, нет ничего зазорного в том, чтобы собрать RAID массив с помощью контроллера (ради скорости) и сделать на нём файловой системой ZFS (ради снимков и репликации), решая каждым элементом свою задачу. Естественно возможностей у ZFS сильно больше, но в контексте резервного копирования важны эти две.
katzen
Насколько я помню, с точки зрения создания снапшотов btrfs тоже быстрая и нетребовательная. Налепил себе миллион этих точек где хочешь и грохай какие вздумается. Или что-то стало хуже с тех времён, как я с btrfs съехал на ext4 и dattobd?
a1888877
Btrfs создавалась как альтернатива ZFS, поэтому, в целом, их принципы и функциональные возможности идентичны. Учитывая богатство этих возможностей, обычно, используют только одну из этих файловых систем. Из-за чего объективное сравнение опыта использования в идентичных условиях — редкость, а в таких статьях упор делается только на одну из них.
Если не секрет, поделитесь в комментарии или статье причинами подтолкнувшими к dattobd и опытом работы с ним?
katzen
Да какая статья, ну что вы :-) btrfs оказалась тяжеловатой, я прикинул список использованных фич за год или два и понял, что пора возвращаться на LVM2 и ext4. Перед перелезанием на ext4 поверх LVM2 пошерстил немного сеть на предмет снапшотов для ext4 — ну и нашёл dattobd. Опенсорсное, не расходует место на томе, а использует место на разделе файловой системы. Сказка просто! Мне нужна только одна точка в системе для создания бекапа, хотя dattobd позволяет, по-моему, делать снапшоты от снапшотов, а все остальные полезности типа CoW в бтрфс мне просто не нужны.
Вот и вся история. Работать — ну, не знаю, работает да и работает. Создал снапшот, примаунтил, рсинкнул нужное в хранилище — я использую хранилище на хардлинках, тупее просто уже некуда — всё, функции даттобд кончились.
akrupa
Я в итоге пришел к использованию LVM2 тонких томов и рукописным скриптам, которые позволяют извлекать разницу между двумя тонкими снапшотами из метаданных томов и реплицировать эту разницу на бэкап-устройство.
Использую для создания резервных копий (инкрементальных) образов виртуальных машин на тонких томах независимо от используемых там файловых систем/шифрования.
Статья в профиле есть соответствующая. Со скриптами.
alex_shpak
насчет миллиона снапшотов — есть мнение (2018 года), что их рекомендуется иметь «сильно меньше ста» ("single to low double-digits of snapshots per snapshotted subvolume"), если предполагается использование btrfs-команд типа balance и check: unix.stackexchange.com/a/422650
pansa
Есть. Для домашнего бэкапчика может и ладно, но нормальный пул категорически не рекомендуется ставить поверх железного рейда. В лучшей книге по zfs это просто обозначено в примерно такой фразе: "Never! Never install ZFS on hardware RAID!"
a1888877
Почему? Вы задумывались, что стоит за этой фразой?
ZFS не рекомендуют использовать поверх RAID, из-за того, что это нивелирует многочисленные технические ухищрения в ней, направленные на борьбу с ошибками, в том числе аппаратного характера. Из-за того, что выход из строя аппаратного контроллера, в некоторых, редких сценариях может разрушить массив. Из-за большей гибкости в управлении томами, которую может давать ZFS для сложных сценариев.
И всё это никак не соотносятся с другими функциями ZFS, вроде снимков состояния или сжатия.
При этом ZFS в режиме JBOD будет существенно медленней, чем обычный RAID контроллер, с батарейкой, Write-Back и осознанием рисков такого сценария. Или можно функциональностью ZFS дополнить дисковую полку, в которой в принципе нет режима JBOD — и это тоже будет быстрей, чем делать по отдельному LUN на каждый диск. Поэтому нет ничего зазорного, в том, что бы делать пул поверх RAID, если вы понимаете, что при этом теряете и что приобретаете, а не слепо следуете какой-либо книге.
pansa
Я задумывался, но вы же в своём комментарии написали просто "нет ничего зазорного". Зазорного нет только в очень ограниченном наборе кейсов и при полном понимании того, что делаешь. А кто-то может прочитать ваш коммент и решит, что нормально будет всегда. Я просто сталкивался с такими пулами, а потом народ хаит ZFS, что тормозит и тп.
a1888877
Да, наверное наверное и так можно воспринять мой комментарий. Но имелось в виду, что выбор включает в себя не только использование RAID или CoW файловой системой, но и возможность скомбинировать их для некоторых сценариев.
При этом, в целом, я в большей степени сторонник наличия резервного копирование данных. Т.е. в ситуациях серьезных сбоев (если это что-то больше горячей замены диска) вы не занимаетесь починкой массива, или файловой системы, а просто пересоздаёте их и развертываете одну из резервных копий. К сожалению, даже CoW ФС можно ввести в полностью не поддерживаемое состояние, когда извлечь с них данные оказывается крайне затруднительно.
Ну а насчёт тормозов и хая — он в значительной мере вызван тем, что функционал не подкреплен адекватными инструментами диагностики и простым описанием последствий для производительности. И пытаясь использовать сложную комбинацию разных функций (а сами ФС это скорей поощряют) можно иногда получить падение производительности в совершенно неожидаемых масштабах.
pansa
Поддерживаю! Разве что насчет инструментов и описания — в сети много инфы о zfs, и книжки есть, где всё написано. Но надо читать и вникать, имхо проблема больше в этом. И инструменты в zfs на порядок лучше поделок от megaraid и тп, которые явно писали наркоманы =)
pansa
Нет, киллер фич не две, а намного больше. В новых версиях, например, это возможность инкрементального бэкапа зашифрованного диска без необходимости переливать весь диск. Т.е бэкап сервер не имеет доступа к данным, но имеет возможность бэкапить только разницу!
А ещё ZFS не подвержен ошибкам write hole. А еще не придется бегать и искать точно такой же контроллер, чтобы получить доступ к данным, когда сгорит ваш. Еще гибко настраиваемая прозрачная компрессия из коробки, когда свои параметры сжатия можно применять чуть ли не к каждому диру. В общем… перечислять еще можно долго.
ЗЫ Еще сам не щупал, а только в анонсах читал про новый механизм для решения проблемы ребилдинга z2/z3, когда при замене сбойнутого диска не требуется перечитать пол массива. На больших пулах (а мы же тут не в бирюльки играем?) это просто бомбическая фича. D-RAID чтоли? Вот тут все дешманские (и не очень) железки будут просто курить в стороне. Может кто уже пробовал, будет очень интересно.
severgun
Всё так. Но всегда остается в тени тот факт, что за всё это вы платите доступным объемом, а следовательно долларом за гигабайт.
Плюс нет дефрагментации и через время выходом будет только ребилд.(насколько я помню)
pansa
Не понял, о чем речь про объем? У меня, например, обратная ситуация — LZ компрессия дает мне выигрыш 34% от объема пула, что при пуле 300Тб выливается в заметную экономию.
Дефрагментация там не нужна, в некотором смысле она заложена в принципы cow fs. Хотя в той же xfs тоже нет явной дефраг, и она великолепно живет у меня на десятках нагруженых серверов уже 10+ лет. Дефраг и тп это боль ntfs и другого старья, которое застряло в 90ых )
Кстати, компрессия, помимо объема, даёт прирост в скорости R/W и меньшей утилизации диска. Это неявный момент упускают, а он есть, засчёт того, что диску нужно читать/писать меньше данных с блинов. Конечно, за это платим CPU, но на современных процах нагрузка малозаметна, да и в большинстве случаев баттлнеком является io, а не cpu, поэтому не жалко.
vorphalack
хардварный рейд нужен для простреливания себе ноги в максимально неудачный момент и максимально неочевидным способом, всё. для чего-то другого последние лет 15-20 он в лучшем случае бесполезен.