Как стать автором
Обновить

Комментарии 23

Вижу про ФС, про управление томами, снепшоты. А где, собственно, про бекапы, про восстановление? Вот это вот всё....!?
Евгений, здравствуйте!

В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.

Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
Простите, но снепшот ФС и его репликация — это только один подход к РК, просто вы делаете его разными средствами. При этом нет ничего про то — какие данные у вас на этих ФС, как приложение к этому бекапу относится, как и что вы из такого бекапа можете восстановить и как быстро. Это статья вообще не про бекап, а про снепшоты, которые мы можете куда то утащить с основного сервера и не более того.
Евгений, поскольку мы рассказываем про опыт Timeweb, то подразумевали, что на нашем хостинге хранятся сайты пользователей, базы данных.

Мы считаем, что тема про восстановление достойна отдельной статьи. В ней бы начали с выбора протокола сетевого доступа к файловым системам, далее рассказали про способ защиты пользовательских данных при подключении и копировании и закончили системой снятия дампов mysql.
А требования к оперативной памяти разных ФС сравнивали? Про ZFS говорят, что ей нужно много ОЗУ — у вас такое было?

И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 1Тб данных, сколько Тб дискового пространства вы резервируете на бекап-сервере?
А требования к оперативной памяти разных ФС сравнивали? Про ZFS говорят, что ей нужно много ОЗУ — у вас такое было?

Размер потребляемой ОЗУ на ARK кэш задается в параметрах модуля zfs_arc_max. В нашем случае он вычислялся эмпирически, чтобы не мешать работе основных сервисов, но при этом давать файловую производительность.

И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 1Тб данных, сколько Тб дискового пространства вы резервируете на бекап-сервере?

Тут все очень индивидуально, так как размер снапшота в ZFS зависит от размера добавленных данных. У нас это 1 к 2 для хранения сроком в 30 дней. То есть на 1 терабайт данных приходится 2 терабайта на бэкап-сервере.
А резервные копии через scp!111… 0_o

А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…

И ZFS у вас на Linux?
Здравствуйте!
А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…

Вы правы, это основная схема работы системы резервного копирования. Поскольку статей на эту тему достаточно много, как и обзоров крутых инструментов для автоматизации типа ZREPL, мы решили осветить немного другую сторону вопроса.

И ZFS у вас на Linux?

Да, на Linux.
В «избыточность пространства» для rsync не совсем верно. Совсем не обязательно хранить на каждую точку копию всех данных. Можно хранить одну копию + изменённые файлы.
В случае ZFS немногим экономнее: одна копия + изменённые блоки. Хранить вообще только изменения не выйдет и тут.

К тому же, не всегда требуется копировать(да и считывать) всю файловую систему, часто достаточно работать только с данными какого-нибудь приложения, и тут rsync может быть уже намного выгоднее, и по скорости, и по объёму.

Довольно много работаю и с rsynс и с zfs. Если коротко, то rsync имеет пожалуй только 1 профит, что он более переносимый. Но если у вас *nix, то проблем нет. Впрочем, через сетевые диски все прелести zfs доступны и для win.
У zfs много плюшек, перечислять нет смысла, даже на хабре не одна статья была. В мире бесплатных инструментов я не знаю альтернатив. А за большие деньги — Netapp, и Co, там тоже всё есть, но это совсем другой уровень....

У XFS с новыми ядрами доступна еще такая штука, как reflink-и. Позволяют быстро создавать копии директорий/файлов, без копирования блоков данных. Новые блоки выделяются только при изменении. Т.е некий такой симбиоз хардлинков и снапшотов, если можно так сказать.
Около года пользую этот механизм на одном из бэкап серверов и что-то всё больше склоняюсь таки к zfs. В реальности reflink-копирование выполняется далеко не мгновенно, иногда минуты (на нескольких сотнях гб данных). Плюс невозможность оценить реально доступное свободное место, из-за чего вроде бы 85% заполнения, а уже иногда (!) начинаются ошибки no free space on device :(


Но для не очень крупных бэкапов/горячих копий может для кого-то будет интересной альтернативой.

reflink — отличная штука, но нужна реально не часто.
вот пример: сделал ddrescue для 1тб диска, сохранял образ сразу на fs которая поддерживает reflink — btrfs, дальше делаю cp --reflink=always и работаю с копией файла, если надо check disk и всё вот это.
мне в такой ситуации не нужен снапшот диска, но «снапшот» файла — то что доктор прописал.
и делается по времени на btrfs это вроде как достаточно быстро.

Да, небольшие файлы быстро, а вот 400гигов бд копируются минуту. Иногда. В общем, штука специфичная, да.
Btrfs не готов применять в проде. :)

Держать три десятка снапшотов на тонком томе LVM, — это действительно не очень быстро. Я для решения этой проблемы придумал схему, при которой на рабочем массиве держится только один снапшот на каждый тонкий том, который служит для отслеживания изменений с последнего бэкапа. Вот на бэкап устройстве уже действительно много снимков.
Рабочие и резервные LVM группы отличаются и расположены на различных RAID группах. Если интересны подробности, у меня статья про «LVM и Матрешки» в профиле.

Из статьи не понял что и куда копируется, где размещены клиентские данные и в каком виде и где у Вас хранятся бекапы.

Что именно у Вас копируется по SCP? Данные из конкретного снапшота, создаваемого на ноде виртуального хостинга? Клиентские приложеньки работают на ФС ZFS и там же создаются снапшоты?

Как работает восстановление клиентов в случае сбоя — берётся последний снапшот и наливается на новый/резервный сервер или есть какая-то другая логика?
Евгений, здравствуйте!

Попробуем ответить подробно на ваш комментарий.

Есть два вида серверов: клиентский и бэкапный. Файловая система, на которых находятся клиентские данные, — ZFS.

На клиентском сервере работают клиентские приложения. На бэкапном сервере хранятся бэкапы.

Снапшоты делаются на клиентском сервере и копируются на бэкапный сервер.

Схема бэкапа достаточно проста:

1. На клиентском сервере есть снапшот 1.
2. Перед копированием создается снапшот 2.
3. Снапшот 1 копируется / импортируется на бэкапный сервер. Для этого могут использоваться разные средства: ssh, scp, netcat и др. В нашем случае используется приложение, построенное на базе ssh.
4. По окончании успешного копирования снапшот 1 мержится / удаляется с основными данными, его место занимает снапшот 2.
5. При бэкапе переходим к пункту 1.

Восстановление отдельных файлов или директорий работает через копирование данных с сервера бэкапов из снапшота на клиентский сервер.
Восстановление целого сервера возможно из последнего снапшота, но по времени быстрее переставить диски в новую платформу.

Выход дисков из строя отслеживается. Все данные обязательно зеркалируются на разные диски.

Все ли понятно объясняли? На все ли вопросы ответили?

Почему Hetzner умеет делать бэкапы и снапшоты VPS без qemu-agent и прочего обвеса, а вы нет?

Вот бы ещё на таймвебе сайтики которые посещает только мониторинг агент периодически не уходили в даун, цены бы не было вашему zfs с бекапами.

restic хорош.
В разы быстрее rsync, шлет и хранит только изменения.
Срогласен+1
Хорош, но не в разы быстрее, конечно — это явное преувеличение. Я использую и то, и другое: разница в скорости есть, но не такая уж заметная даже.
Да и rsync тоже шлёт, и может хранить только изменённые файлы с помощью хардлинков.

К тому же, не так уж правильно сравнивать отдельно инструмент для синхронизации и более законченное решение именно для резервного копирования. Скорее тогда с rsnapshot надо сравнивать его и подобными вещами.
Спасибо, полезно. Сейчас переходим пробуем ZFS

С btrfs видел еще такой метод бекапов/восстановления: делается снимок, который можно как передавать, так и принимать по сети: https://btrfs.wiki.kernel.org/index.php/Incremental_Backup#Incremental_Operation

На место pipeline идеально встает например ssh, или другие инструменты с обменом через pipeline - стеки можно собирать какие угодно, буквально на коленке.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий