Комментарии 23
Вижу про ФС, про управление томами, снепшоты. А где, собственно, про бекапы, про восстановление? Вот это вот всё....!?
Евгений, здравствуйте!
В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.
Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
В этой статье мы сделали, скорее, обзор различных подходов к резервному копированию. Постарались осветить плюсы и минусы каждого из них.
Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
Простите, но снепшот ФС и его репликация — это только один подход к РК, просто вы делаете его разными средствами. При этом нет ничего про то — какие данные у вас на этих ФС, как приложение к этому бекапу относится, как и что вы из такого бекапа можете восстановить и как быстро. Это статья вообще не про бекап, а про снепшоты, которые мы можете куда то утащить с основного сервера и не более того.
Евгений, поскольку мы рассказываем про опыт Timeweb, то подразумевали, что на нашем хостинге хранятся сайты пользователей, базы данных.
Мы считаем, что тема про восстановление достойна отдельной статьи. В ней бы начали с выбора протокола сетевого доступа к файловым системам, далее рассказали про способ защиты пользовательских данных при подключении и копировании и закончили системой снятия дампов mysql.
Мы считаем, что тема про восстановление достойна отдельной статьи. В ней бы начали с выбора протокола сетевого доступа к файловым системам, далее рассказали про способ защиты пользовательских данных при подключении и копировании и закончили системой снятия дампов mysql.
А требования к оперативной памяти разных ФС сравнивали? Про ZFS говорят, что ей нужно много ОЗУ — у вас такое было?
И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 1Тб данных, сколько Тб дискового пространства вы резервируете на бекап-сервере?
И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 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. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…
И ZFS у вас на Linux?
Здравствуйте!
Вы правы, это основная схема работы системы резервного копирования. Поскольку статей на эту тему достаточно много, как и обзоров крутых инструментов для автоматизации типа ZREPL, мы решили осветить немного другую сторону вопроса.
Да, на Linux.
А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…
Вы правы, это основная схема работы системы резервного копирования. Поскольку статей на эту тему достаточно много, как и обзоров крутых инструментов для автоматизации типа ZREPL, мы решили осветить немного другую сторону вопроса.
И ZFS у вас на Linux?
Да, на Linux.
В «избыточность пространства» для rsync не совсем верно. Совсем не обязательно хранить на каждую точку копию всех данных. Можно хранить одну копию + изменённые файлы.
В случае ZFS немногим экономнее: одна копия + изменённые блоки. Хранить вообще только изменения не выйдет и тут.
К тому же, не всегда требуется копировать(да и считывать) всю файловую систему, часто достаточно работать только с данными какого-нибудь приложения, и тут 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 это вроде как достаточно быстро.
вот пример: сделал ddrescue для 1тб диска, сохранял образ сразу на fs которая поддерживает reflink — btrfs, дальше делаю cp --reflink=always и работаю с копией файла, если надо check disk и всё вот это.
мне в такой ситуации не нужен снапшот диска, но «снапшот» файла — то что доктор прописал.
и делается по времени на btrfs это вроде как достаточно быстро.
Держать три десятка снапшотов на тонком томе LVM, — это действительно не очень быстро. Я для решения этой проблемы придумал схему, при которой на рабочем массиве держится только один снапшот на каждый тонкий том, который служит для отслеживания изменений с последнего бэкапа. Вот на бэкап устройстве уже действительно много снимков.
Рабочие и резервные LVM группы отличаются и расположены на различных RAID группах. Если интересны подробности, у меня статья про «LVM и Матрешки» в профиле.
Рабочие и резервные LVM группы отличаются и расположены на различных RAID группах. Если интересны подробности, у меня статья про «LVM и Матрешки» в профиле.
Из статьи не понял что и куда копируется, где размещены клиентские данные и в каком виде и где у Вас хранятся бекапы.
Что именно у Вас копируется по SCP? Данные из конкретного снапшота, создаваемого на ноде виртуального хостинга? Клиентские приложеньки работают на ФС ZFS и там же создаются снапшоты?
Как работает восстановление клиентов в случае сбоя — берётся последний снапшот и наливается на новый/резервный сервер или есть какая-то другая логика?
Что именно у Вас копируется по SCP? Данные из конкретного снапшота, создаваемого на ноде виртуального хостинга? Клиентские приложеньки работают на ФС ZFS и там же создаются снапшоты?
Как работает восстановление клиентов в случае сбоя — берётся последний снапшот и наливается на новый/резервный сервер или есть какая-то другая логика?
Евгений, здравствуйте!
Попробуем ответить подробно на ваш комментарий.
Есть два вида серверов: клиентский и бэкапный. Файловая система, на которых находятся клиентские данные, — ZFS.
На клиентском сервере работают клиентские приложения. На бэкапном сервере хранятся бэкапы.
Снапшоты делаются на клиентском сервере и копируются на бэкапный сервер.
Схема бэкапа достаточно проста:
1. На клиентском сервере есть снапшот 1.
2. Перед копированием создается снапшот 2.
3. Снапшот 1 копируется / импортируется на бэкапный сервер. Для этого могут использоваться разные средства: ssh, scp, netcat и др. В нашем случае используется приложение, построенное на базе ssh.
4. По окончании успешного копирования снапшот 1 мержится / удаляется с основными данными, его место занимает снапшот 2.
5. При бэкапе переходим к пункту 1.
Восстановление отдельных файлов или директорий работает через копирование данных с сервера бэкапов из снапшота на клиентский сервер.
Восстановление целого сервера возможно из последнего снапшота, но по времени быстрее переставить диски в новую платформу.
Выход дисков из строя отслеживается. Все данные обязательно зеркалируются на разные диски.
Все ли понятно объясняли? На все ли вопросы ответили?
Попробуем ответить подробно на ваш комментарий.
Есть два вида серверов: клиентский и бэкапный. Файловая система, на которых находятся клиентские данные, — ZFS.
На клиентском сервере работают клиентские приложения. На бэкапном сервере хранятся бэкапы.
Снапшоты делаются на клиентском сервере и копируются на бэкапный сервер.
Схема бэкапа достаточно проста:
1. На клиентском сервере есть снапшот 1.
2. Перед копированием создается снапшот 2.
3. Снапшот 1 копируется / импортируется на бэкапный сервер. Для этого могут использоваться разные средства: ssh, scp, netcat и др. В нашем случае используется приложение, построенное на базе ssh.
4. По окончании успешного копирования снапшот 1 мержится / удаляется с основными данными, его место занимает снапшот 2.
5. При бэкапе переходим к пункту 1.
Восстановление отдельных файлов или директорий работает через копирование данных с сервера бэкапов из снапшота на клиентский сервер.
Восстановление целого сервера возможно из последнего снапшота, но по времени быстрее переставить диски в новую платформу.
Выход дисков из строя отслеживается. Все данные обязательно зеркалируются на разные диски.
Все ли понятно объясняли? На все ли вопросы ответили?
Почему Hetzner умеет делать бэкапы и снапшоты VPS без qemu-agent и прочего обвеса, а вы нет?
Вот бы ещё на таймвебе сайтики которые посещает только мониторинг агент периодически не уходили в даун, цены бы не было вашему zfs с бекапами.
restic хорош.
В разы быстрее rsync, шлет и хранит только изменения.
В разы быстрее rsync, шлет и хранит только изменения.
Срогласен+1
Хорош, но не в разы быстрее, конечно — это явное преувеличение. Я использую и то, и другое: разница в скорости есть, но не такая уж заметная даже.
Да и rsync тоже шлёт, и может хранить только изменённые файлы с помощью хардлинков.
К тому же, не так уж правильно сравнивать отдельно инструмент для синхронизации и более законченное решение именно для резервного копирования. Скорее тогда с rsnapshot надо сравнивать его и подобными вещами.
Да и rsync тоже шлёт, и может хранить только изменённые файлы с помощью хардлинков.
К тому же, не так уж правильно сравнивать отдельно инструмент для синхронизации и более законченное решение именно для резервного копирования. Скорее тогда с rsnapshot надо сравнивать его и подобными вещами.
Спасибо, полезно. Сейчас переходим пробуем ZFS
С btrfs видел еще такой метод бекапов/восстановления: делается снимок, который можно как передавать, так и принимать по сети: https://btrfs.wiki.kernel.org/index.php/Incremental_Backup#Incremental_Operation
На место pipeline идеально встает например ssh, или другие инструменты с обменом через pipeline - стеки можно собирать какие угодно, буквально на коленке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Таков путь! Эволюция бэкапов в Timeweb: от rsync до ZFS