Инкрементное резервное копирование файлов
Друзья, привет. На сайте так много практического материала по резервному копированию, но вот как-то я упустил из виду теоретическую часть. В комментариях вы меня периодически спрашиваете по поводу методов резервного копирования - полного, инкрементного и дифференциального. В чём их разница, что лучше выбрать и т.п. В этой статье, собственно, и будем детально разбираться во всех этих вопросах.
Дифференциальное резервное копирование
При дифференциальном резервном копировании каждый файл, который был изменен с момента последнего полного резервного копирования, копируется всякий раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все, что вам необходимо — это последняя полная и последняя дифференциальная резервная копия. Популярность дифференциального резервного копирования растет, так как все копии файлов делаются в определенные моменты времени, что, например, очень важно при заражении вирусами.
Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.
В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.
Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то стоит удалять/исключать ненужные вам файлы. Например, это могут быть кеши CMS. В таких кешах обычно очень много маленьких файлов, потеря которых не скажется на корректной работе сервера.
Правила очистки
- Максимальный «возраст» цепочек бэкапов.
- Максимальное количество цепочек бэкапов.
- Максимальный общий размер бэкапа.
Безопасность
Необходимо обезопасить себя от ситуации когда хранилище или ваш сервер будут взломаны. Если взломан сервер, то лучше чтобы не было прав на удаление/изменение файлов в хранилище у пользователя, который записывает туда данные.
Если взломано хранилище, то права бекапного пользователя на сервере так же желательно ограничить по максимуму.
Если канал резервного копирования может быть прослушан, то нужны средства шифрования.
Инкрементальное резервное копирование
При инкрементальном резервном копировании копируются только файлы, которые были изменены со времени предыдущего бэкапа. Последующее инкрементальное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. В среднем инкрементальное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, плюс данные всех последующих инкрементальных резервных копирований. При этом в отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Инкрементальное копирование чаще всего производится с помощью утилиты rsync. С его помощью можно сэкономить место в хранилище, если количество изменений за день не очень велико. Если измененные файлы имеют большой размер, то они будут скопированы полностью без замены предыдущих версий.
- Составляется список файлов на резервируемом сервере и в хранилище, по каждому файлу считываются метаданные (права, время изменения и т.д) или контрольная сумма (при использовании ключа —checksum).
- Если метаданные файлов разнятся, то файл бьется на блоки и по каждому блоку считается контрольная сумма. Отличающиеся блоки закачиваются в хранилище.
- Если во время подсчета контрольных сумм или передачи файла в него было внесено изменение, его резервирование повторяется с начала.
- По умолчанию rsync передает данные через SSH, а значит каждый блок данных дополнительно шифруется. Rsync можно также запустить как демон и передавать данные без шифрования по его протоколу.
С более подробной информацией о работе rsync можно ознакомиться на официальном сайте.
Для каждого файла rsync выполняет очень большое количество операций. Если файлов на сервере много или если процессор сильно загружен, то скорость резервного копирования будет существенно снижена.
Из опыта можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200G данных на сервере. На самом деле всё, конечное же, зависит от количества inode. И в каждом случае эта величина может смещаться как в одну так и в другую сторону.
После определенной черты время выполнения резервного копирования будет очень долгим или попросту не будет отрабатывать за сутки.
Для того, чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию об изменившихся файлах, т.е. мы уже заранее будем иметь готовый их список для rsync. Следует, однако, учесть, что он дает дополнительную нагрузку на дисковую подсистему.
Полное резервное копирование
Полное копирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется по пятницам или в течение выходных, когда копирование большого объёма данных не влияет на работу организации. Последующие резервные копирования, выполняемые с понедельника по четверг до следующего полного копирования, могут быть дифференциальными или инкрементальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервное копирование следует проводить по крайней мере еженедельно.
В большинстве публикаций по соответствующей тематике рекомендуется полное резервное копирование выполнять один или два раза в неделю, а в остальное время время — использовать инкрементальное и дифференциальное. В таких советах есть свой резон. В большинстве случаев полного резервного копирования раз в неделю вполне достаточно. Выполнять его повторно имеет смысл в том случае, если у вас нет возможности на стороне хранилища актуализировать полный бекап и для обеспечения гарантии корректности резервной копии (это может понадобиться, например, в случаях, если вы по тем или иным причинам не доверяете имеющимся у вас скриптам или софту для резервного копирования.
- Полное резервное копирование на уровне файловой системы;
- Полное резервное копирование на уровне устройств.
Рассмотрим их характерные особенности на примере:
Резервировать мы будем только /home. Все остальное можно быстро восстановить вручную. Можно также развернуть сервер системой управления конфигурациями и подключить к нему наш /home.
Как насчет бэкапа в облачное хранилище?
Все, о чем мы до сих пор говорили, относится к бэкапам, которые вы храните у себя на внутреннем или внешнем жестком диске, на NAS-е, FTP-сервере и т.д. А как насчет бэкапа в облако? True Image сохраняет как файловые, так и дисковые бэкапы в Acronis Cloud по простой инкрементной схеме – один полный бэкап и цепочка инкрементных – и не позволяет ее менять. На резонный вопрос «почему» ответ прост – эта схема самая бережливая к дисковому пространству, а сохранность бэкапов в облаке гарантирует Acronis.
Правила очистки облачного бэкапа чуть проще, чем обычного.
Вы можете ограничить бэкап по «возрасту» и по количеству версий каждого из файлов, которые хранятся в облаке. Ограничивать бэкап по объему хранилища было бы не очень логично. Ведь в первую очередь Acronis Cloud используется именно для хранения бэкапов.
Казалось бы, тема избитая – про резервное копирование сказано и написано многое, поэтому нечего изобретать велосипед, просто бери и делай. Тем не менее, каждый раз, когда перед системным администратором web-проекта встает задача настроить бэкапы, для многих она повисает в воздухе большим вопросительным знаком. Как правильно собрать бэкап данных? Где хранить резервные копии? Как обеспечить необходимый уровень ретроспективы хранения копий? Как унифицировать процесс резервного копирования для целого зоопарка различного ПО?
Для себя мы впервые решали эту задачу в 2011. Тогда мы сели и написали свои скрипты резервного копирования. На протяжении многих лет мы пользовались только ими, и они успешно обеспечивали надежный процесс сбора и синхронизации бэкапов web-проектов наших клиентов. Бэкапы хранились в нашем либо каком-то другом внешнем хранилище, с возможностью тюнинга под конкретный проект.
Надо сказать, эти скрипты отработали своё по полной. Но чем дальше мы росли, тем больше у нас появлялось разношерстных проектов с разным ПО и внешними хранилищами, которые наши скрипты не поддерживали. Например, у нас не было поддержки Redis и “горячих” бэкапов MySQL и PostgreSQL, которые появились позже. Процесс бэкапов не мониторился, были только email-алерты.
Другой проблемой был процесс поддержки. За многие годы наши, некогда компактные, скрипты разрослись и превратились в огромного несуразного монстра. И когда мы собирались с силами и выпускали новую версию, отдельных усилий стоило выкатить обновление для той части клиентов, которые использовали предыдущую версию с какой-то кастомизацией.
В итоге в начале этого года мы приняли волевое решение: заменить наши старые скрипты бэкапов чем-то более современным. Поэтому сначала мы сели и выписали все хотелки к новому решению. Получилось примерно следующее:
- Бэкапить данные наиболее часто используемого в работе ПО:
- Файлы (дискретное и инкрементное копирование)
- MySQL (холодные/горячие бэкапы)
- PostgreSQL (холодные/горячие бэкапы)
- MongoDB
- Redis
- Local
- FTP
- SSH
- SMB
- NFS
- WebDAV
- S3
Мы посмотрели open-source решения, которые уже существуют:
- Bacula и её форки, например, Bareos
- Amanda
- Borg
- Duplicaty
- Duplicity
- Rsnapshot
- Rdiff-backup
Но у каждого из них были свои недостатки. Например, Bacula перегружена ненужными нам функциями, начальное конфигурирование — достаточно трудоемкое занятие из-за большого количества ручной работы (например, для написания/поиска скриптов бэкапов БД), а для восстановления копий необходимо задействовать специальные утилиты и т.д.
В конце концов мы пришли к двум важным выводам:
- Ни одно из существующих решений в полной мере нам не подходило;
- Похоже, у нас у самих было достаточно опыта и безумия, чтобы взяться за написание своего решения.
Так мы и сделали.
В качестве языка для реализации выбрали Python – он прост в написании и поддержке, гибок и удобен. Конфигурационные файлы было принято решение описывать в формате yaml.
Для удобства поддержки и добавления бэкапов нового ПО была выбрана модульная архитектура, где процесс сбора бэкапов каждого конкретного ПО (например, MySQL) описывается в отдельном модуле.
Дискретное резервное копирование
Для разных задач подойдут либо дискретные, либо инкрементные бэкапы, поэтому реализовали оба типа. Можно задавать, какой способ использовать на уровне отдельных файлов и каталогов.
Для дискретных копий (как файлов, так и БД) можно задавать ретроспективу в формате дни/недели/месяцы.
↑ Полное, инкрементное, дифференциальное – о методах резервного копирования
А разбираться в методах резервного копирования предлагаю на примере программы AOMEI Backupper. Итак, друзья, когда мы в программе AOMEI Backupper создаём резервную копию Windows, целого диска, отдельных разделов или отдельных папок с данными, в дальнейшем после создания резервной копии сможем использовать для неё некоторые программные возможности. В их числе – создание на базе заданных условий бэкапа новых копий с выбором механизма резервного копирования:
- Полная копия;
- Инкрементная копия;
- Дифференциальная копия.
Логирование
В любом процессе, а в бэкапах особенно, важно держать руку на пульсе и иметь возможность узнавать, если что-то пошло не так. Система ведёт лог своей работы и фиксирует результат каждого шага: запуск/остановка средств, начало/конец выполнения определенного задания, результат сбора копии во временном каталоге, результат копирования/перемещения копии из временного каталога в постоянное место дислокации, результат ротации бэкапов и т.д..
События делятся на 2 уровня:
- Info: информационный уровень – полёт проходит нормально, очередной этап завершился успешно, в логе делается соответствующая запись информационного характера
- Error: уровень ошибки – что-то пошло не так, очередной этап завершился аварийно, в логе делается соответствующая запись об ошибке
Схема организации хранения и восстановления из резервных копий
- Резервные копии нельзя хранить в одном месте с резервируемыми данными. Если вы храните резервную копию на одном дисковом массиве с вашими данными, то вы потеряете её в случае повреждения основного дискового массива.
- Зеркалирование (RAID1) нельзя сравнивать с резервным копированием. Рейд защищает вас только от аппаратной проблемы с одним из дисков (а рано или поздно такая проблема будет, т.к. дисковая подсистема почти всегда является узким местом на сервере). К тому же при использовании аппаратных рейдов есть риск поломки контроллера, т.е. необходимо хранить его запасную модель.
- Если вы храните резервные копии в рамках одной стойки в ДЦ или просто в рамках одного ДЦ, то в такой ситуации тоже имеются определенные риски (об этом можно прочитать, например, здесь.
- Если вы храните резервные копии в разных ДЦ, то резко возрастают затраты на сеть и скорость восстановления из удаленной копии.
Часто причиной восстановления данных служит повреждение файловой системы или дисков. Т.е. бекапы нужно хранить где-то на отдельном сервере-хранилище. В этом случае проблемой может стать «ширина» канала передачи данных. Если у вас выделенный сервер, то резервное копирование очень желательно выполнять по отдельному сетевому интерфейсу, а не на том же, что выполняет обмен данных с клиентами. Иначе запросы вашего клиента могут не «поместиться» в ограниченный канал связи. Или из-за трафика клиентов бекапы не будут сделаны в срок.
Далее нужно подумать о схеме и времени восстановления данных с точки зрения хранения бекапов. Может быть вас вполне устраивает, что бекап выполняется за 6 часов ночью на хранилище с ограниченной скоростью доступа, однако восстановление длиной в 6 часов вас вряд ли устроит. Значит доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро. Так, например, восстановление 1Тб данных с полосой в 1Гб/с займет почти 3 часа, и это если вы не «упретесь» в производительность дисковой подсистемы в хранилище и сервере. И не забудьте прибавить к этому время обнаружения проблемы, время на решение об откате, время проверки целостности восстановленных данных и объем последующего недовольства клиентов/коллег.
↑ Дифференциальное резервное копирование
Дифференциальное – это такое резервное копирование, при котором полная копия создаётся единожды в начале, а все последующие копии, создаваемые в рамках одной и той же задачи, содержат не все данные, а лишь произошедшие изменения с момента создания первичной полной копии. Ключевой момент здесь – с момента создания полной копии. Тогда как при инкрементом копировании вторая инкрементная копия цепочки являет собой разницу между ней и первой копией, при дифференциальном и первая, и вторая, и третья, и четвёртая, и все следующие дифференциальные копии будут зависимыми только от полной копии. Но никак не зависимыми друг от друга. Удаление или повреждение любой из дифференциальных копий не повлияет на другие копии – ни на те, что создавались до удалённой (повреждённой), ни на те, что после неё.
Необходимость дифференциальной копии каждый раз сравнивать себя с полной первичной копией, соответственно, влечёт за собой использование большего дискового пространства. На скриншоте ниже сиреневым маркером отмечен размер полной копии и жёлтым размеры дифференциальных бэкапов. Размер последних в районе 450 Мб свидетельствует о том, что между ними произошло немного изменений, тем не менее каждое такое изменение с момента создания полной копии зафиксировано в отдельном порядке. И в отдельном порядке поглощает место на диске.
↑ Инкрементное резервное копирование
Инкрементное – это такое резервное копирование, при котором полная копия создаётся единожды в начале, а все последующие копии, создаваемые в рамках одной и той же задачи, содержат не все данные, а лишь произошедшие изменения - какие файлы удалены, а какие добавлены. Первая инкрементная копия содержит разницу в данных между ней самой и полной копией. А вторая инкрементная копия содержит разницу между ней самой и первой инкрементной копией. Третья – между ней самой и второй. И так далее. Каждая новая инкрементная копия зависит от своей предшественницы и не может быть задействована для процесса восстановления без такой предшественницы. Ну и, конечно же, без полной первичной копии. Каждая из резервных копий задачи – хоть полная, хоть инкрементная - являет собой точку восстановления. И мы всегда сможем выбрать дату или время, на которое хотим откатить систему или данные.
Удаление инкрементной копии (или повреждение её вирусами) не будет иметь следствием неработоспособность предыдущих инкрементных копий и первичной полной. А вот последующих – будет. К точкам после удалённой инкрементной копии откатиться мы уже не сможем. В этом плане, конечно, метод инкрементного копирования уязвим, но его сильной стороной является обеспечение отката к разным точкам состояния при минимально занятом дисковом пространстве. Ведь при незначительных изменениях каждая новая копия будет весить пару Мб разницы между ней и предшественницей. Вот как, например, бэкап раздела на скриншоте ниже. Вес в 3,57 Гб, отмеченный сиреневым маркером – это вес полной первичной копии, а отмеченные жёлтым маркером 9,12 Мб и 20,01 Мб – это вес инкрементных копий.
Ещё один недостаток инкрементных копий – более долгий по времени процесс восстановления, чем из полных и дифференциальных бэкапов.
Параметры для запуска сбора бэкапов
В предыдущем примере мы подготовили конфигурационные файлы job для сбора бэкапов сразу всех элементов: файлов (дискретно и инкрементно), двух БД и их хранения на локальном и внешних (ftp, smb) хранилищах.
Осталось всё это дело запустить. Запуск производится командой:
При этом есть несколько зарезервированных имен job:
- files — выполнение в произвольном порядке всех job с типами desc_files, inc_files (то есть, по сути забэкапить только файлы)
- databases — выполнение в произвольном порядке всех job с типами mysql, mysql_xtradb, postgresql, postgresql_hot, mongodb, redis (то есть, забэкапить только БД)
- external — выполнение в произвольном порядке всех job с типом external (запуск только дополнительных пользовательских скриптов, подробнее об этом ниже)
- all — имитация поочередного запуска команды с job files, databases, external (значение по умолчанию)
Поскольку нам необходимо на выходе получить бэкапы данных как файлов, так и БД по состоянию на одно и тоже время (или с минимальной разницей), то рекомендуется осуществлять запуск nxs-backup с job all, что обеспечит последовательное выполнение описанных job (Bitrix-desc-files, Bitrix-inc_files, Bitrix-mysql).
То есть, важный момент – бэкапы будут собираться не параллельно, а последовательно, один за другим, с минимальной разницей во времени. Более того — само ПО при очередном запуске проверяет наличие уже запущенного процесса в системе и в случае его обнаружения автоматически завершит свою работу с соответствующей пометкой в журнале. Такой подход значительно снижает нагрузку на систему. Минус – бэкапы отдельных элементов собираются не одномоментно, а с некоторой разницей во времени. Но пока наша практика показывает, что это не критично.
Цепочки и схемы
Ну вот мы и подошли к самому интересному. Разумеется, вы уже догадались. Три метода резервного копирования дают нам массу всевозможных вариантов так называемых цепочек бэкапов. Цепочка – это один полный бэкап и все зависящие от него инкрементные и/или дифференциальные бэкапы. Схема же состоит из одной или нескольких цепочек, а также содержит правила удаления старых бэкапов.
Действительно, вариантов цепочек может быть великое множество. Но это в теории. На практике же в основу цепочки берется только один из методов: полный, инкрементный или дифференциальный.«Тут же все ясно как белый день! Всегда создавай полные бэкапы!» – скажете вы и будете правы. Но как всегда есть одно больше «но». Полные бэкапы – самые увесистые. Вам не жалко забить ваш 2 ТБ диск бэкапами? Тогда это самое лучшее решение. Но большинству хочется максимальной надежности и вариативности при минимальных потерях дискового пространства. Поэтому, как говорится, давайте разбираться. Вот со схем на основе полных бэкапов и начнем.
Схемы на основе полных бэкапов
- На создание каждого бэкапа уходит много времени.
- Значительная трата дискового пространства.
- Небольшое количество бэкапов, т.е. точек во времени, на которые можно «откатиться».
- Дублирование одной и той же информации в разных бэкапах.
Схемы на основе инкрементных бэкапов
При такой схеме создается один полный бэкап и цепочка зависимых от него инкрементных. Достоинства очевидны – бэкапы создаются быстро и весят мало, т.е. можно позволить себе насоздавать их гораздо больше, чем при схеме с полными бэкапами. Как итог, вы получаете максимальную вариативность при выборе точки восстановления. Но есть один серьезный недостаток – низкая надежность. При повреждении любого из бэкапов все последующие превращаются в мусор – восстановиться из них вы не сможете. Можно ли каким-то образом повысить надежность? Да, можно. Самый простой способ – создавать новый полный бэкап после нескольких инкрементных, скажем, после четырех или пяти. Таким образом, мы получаем схему с несколькими цепочками, и повреждение одной из цепочек не повлияет на другие.
Эта схема универсальная, ее можно использовать для защиты как дисков, так и файлов.Схемы на основе дифференциальных бэкапов
При такой схеме создается один полный бэкап и зависимые от него дифференциальные. Этот подход объединяет в себе достоинства двух предыдущих. Так как дифференциальные бэкапы меньше полных и больше инкрементных, вы получаете среднюю вариативность при выборе точки восстановления и довольно высокую надежность. Но без недостатков все равно не обойдешься. Чем дальше по времени отстоит дифференциальный бэкап от своего полного бэкапа, тем он «тяжелее», и даже может превысить размер полного бэкапа. Решение здесь то же, что и при инкрементном подходе, — разбавляйте ваши дифференциальные бэкапы полными. В зависимости от интенсивности изменения защищаемых данных новый полный бэкап рекомендуется создавать после двух-пяти дифференциальных.
Такой схемой можно защитить ваш системный раздел, если дисковое пространство не позволяет вам хранить несколько полных бэкапов.Заключение
У каждой системы резервного копирования свои минусы и свои плюсы. В этой статье мы постарались осветить часть нюансов при выборе системы резервного копирования. Надеемся, что они помогут нашим читателям.
- время резервного копирования в текущей стадии проекта;
- время резервного копирования в случае, если данных будет в разы больше;
- нагрузку на канал;
- нагрузку на дисковую подсистему на сервере и в хранилище;
- время восстановление всех данных;
- время восстановления пары файлов;
- необходимость в консистентности данных, особенно БД;
- расход памяти и наличие вызовов oom-killer;
В качестве решений по резервному копированию, можно использовать supload и наше облачное хранилище.
Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.Создание схемы начинается с понимания методов резервного копирования. Таких методов три: полное, инкрементное и дифференциальное резервное копирование (full, incremental, differential backup). Зачем они нужны и в чем разница? Смотрим.
Полное резервное копирование
Тут все очень просто. В файл бэкапа записываются все данные, которые были выбраны для резервного копирования.
На рисунке: все бэкапы — полные.
Такие бэкапы самые надежные, но и самые большие. При этом для восстановления потребуется только один файл.Инкрементное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — инкрементные бэкапы.
Инкрементные бэкапы гораздо меньше полных. Однако для восстановления потребуется предыдущий полный бэкап (на рисунке — 1.tib) и вся цепочка инкрементных бэкапов заканчивая тем бэкапом, из которого вы хотите восстановить данные.Дифференциальное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего полного резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — дифференциальные бэкапы.
Дифференциальные бэкапы меньше полных, но больше инкрементных. Для восстановления потребуется сам дифференциальный бэкап и предыдущий полный бэкап (на рисунке — 1.tib).Внешние модули
Как было сказано выше, благодаря модульной архитектуре, возможности системы можно расширять с помощью дополнительных пользовательских модулей, которые взаимодействуют с системой через специальный интерфейс. Цель – иметь в будущем возможность добавлять поддержку бэкапов нового ПО без необходимости переписывать nxs-backup.
Особое внимание необходимо уделить ключу dump_cmd, где в качестве значения указывается полная команда для запуска внешнего скрипта. При этом по завершению выполнения данной команды ожидается, что:
- Будет собран готовый архив данных ПО
- В stdout будут отправлены данные в формате json, вида:
- При этом ключи basename, extension, gzip необходимы исключительно для формирования конечного имени бэкапа.
Например, пусть у нас есть скрипт для создания snapshot etcd /etc/nxs-backup-ext/etcd.py:
Конфиг для запуска этого скрипта выглядит следующим образом:
При этом программа при запуске job etcd-external:
- Запустит на выполнение скрипт /etc/nxs-backup-ext/etcd.py без параметров
- После завершения работы скрипта проверит код завершения и наличие необходимых данных в stdout
- Если все проверки прошли успешно, дальше задействуется тот же механизм, что и при работе уже встроенных модулей, где в качестве tmp_path выступает значение ключа full_path. Если нет — завершит выполнение данного задания с соответствующей отметкой в журнале.
Процесс разработки и поддержки новой системы бэкапов реализован у нас по всем канонам CI/CD. Больше никаких обновлений и правок скриптов на боевых серверах. Все изменения проходят через наш центральный git-репозиторий в Gitlab, где в pipeline прописана сборка новых версий deb/rpm-пакетов, которые затем загружаются в наши deb/rpm репозитории. И уже после этого через менеджер пакетов доставляются на конечные сервера клиентов.
Мы сделали nxs-backup open-source проектом. Любой желающий может скачать и пользоваться им для организации процесса бекапа в своих проектах, а также дорабатывать под свои нужды, писать внешние модули.
Исходный код nxs-backup можно скачать с Github-репозитория по этой ссылке. Там же находится инструкция по установке и настройке.
Также мы подготовили Docker-образ и выложили его на DockerHub.
Если в процессе настройки или использования возникнут вопросы, напишите нам. Мы поможем разобраться и доработаем инструкцию.
Acronis True Image 2021 предлагает три метода резервного копирования. полное, инкрементное и дифференциальное.
Полное резервное копирование
Результат операции полного резервного копирования (называемый также полной версией резервной копии) содержит все данные, существовавшие на момент создания резервной копии.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию этого документа методом полного резервного копирования. Acronis True Image сохраняет весь документ при каждом выполнении резервного копирования.
1.tibx, 2.tibx, 3.tibx, 4.tibx — это файлы полных версий резервной копии.
Полная версия резервной копии образует основу для последующих инкрементных и дифференциальных резервных копий. и его можно также использовать для создания автономной резервной копии. Создание автономной полной резервной копии может быть оптимальным решением, если вы часто возвращаете систему в исходное состояние или не хотите управлять разными версиями резервных копий.
Восстановление: В приведенном выше примере, чтобы восстановить всю работу из файла 4.tibx, нужна только одна версия резервной копии — 4.tib.
Инкрементное резервное копирование
Результат операции инкрементного резервного копирования (называемый также инкрементной версией резервной копии) содержит только те файлы, которые изменились с момента ПОСЛЕДНЕЙ ОПЕРАЦИИ РЕЗЕРВНОГО КОПИРОВАНИЯ.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию методом инкрементного резервного копирования. Acronis True Image сохраняет новую страницу при каждом выполнении резервного копирования.
Примечание. Сначала всегда создается полная версия резервной копии.
- 1.tibx — это файл полной версии резервной копии.
- 2.tibx, 3.tibx, 4.tibx — это файлы инкрементных версий резервной копии.
Инкрементные резервные копии наиболее полезны, если нужно часто создавать версии резервных копий и иметь возможность вернуться к состоянию на определенный момент времени. Как правило, инкрементные версии резервной копии существенно меньше полных или дифференциальных. С другой стороны, инкрементные версии резервной копии требуют больше работы от программы при восстановлении.
Восстановление: В приведенном выше примере, чтобы восстановить всю работу из файла 4.tibx, нужны все версии резервной копии — 1.tibx, 2.tibx, 3.tibx и 4.tibx. При утере или повреждении инкрементной версии резервной копии все последующие инкрементные версии резервной копии оказываются бесполезными.
Дифференциальное резервное копирование
Результат операции дифференциального резервного копирования (называемый также дифференциальной версией резервной копии) содержит только те файлы, которые изменились с момента СОЗДАНИЯ ПОСЛЕДНЕЙ ПОЛНОЙ РЕЗЕРВНОЙ КОПИИ.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию методом дифференциального резервного копирования. Acronis True Image сохраняет весь документ, кроме первой страницы, хранящейся в версии полной резервной копии.
Примечание. Сначала всегда создается полная версия резервной копии.
- 1.tibx — это файл полной версии резервной копии.
- 2.tibx, 3.tibx, 4.tibx — это файлы дифференциальных версий резервной копии.
Дифференциальный метод является промежуточным между двумя предыдущими. При данном подходе требуется меньше времени и места для хранения по сравнению с полным резервным копированием, но больше по сравнению с инкрементным. Для восстановления данных из версии дифференциальной резервной копии Acronis True Image требуется только дифференциальная версия и последняя полная версия. Поэтому восстановление из дифференциальной версии будет проще и надежней, чем из инкрементной.
Восстановление: В приведенном выше примере, чтобы восстановить всю работу из файла 4.tibx, нужны две версии резервной копии — 1.tibx и 4.tibx.
Чтобы выбрать метод резервного копирования, необходимо задать пользовательскую схему резервного копирования. Дополнительные сведения см. в разделе Пользовательские схемы.
Инкрементная или дифференциальная резервная копия, созданная после дефрагментации диска, может иметь значительно больший размер, чем обычная. Это вызвано тем, что программа дефрагментации изменяет местоположение файлов на диске и эти изменения отражаются в резервной копии. Поэтому после дефрагментации диска рекомендуется заново создать полную резервную копию.
Changed Block Tracking (CBT)
Технология CBT ускоряет процесс резервного копирования при создании локальных инкрементных или дифференциальных версий резервных копий дисков. Изменения в содержимом диска непрерывно отслеживаются на уровне блоков. При запуске резервного копирования изменения могут быть сразу сохранены в резервной копии.
↑ Какой метод лучше выбрать
Какой из методов резервного копирования – полное, инкрементное или дифференциальное – выбрать для обычных домашних нужд? Полное – самое надёжное, но каждый раз создавать полную копию не всегда целесообразно. В стеснённых условиях дискового пространства ветвистой системы точек отката особо не настроишь. Инкрементное будет экономить место на диске, но если вирус повредит промежуточную копию или её, например, кто-то из близких случайно удалит, мы не сможем откатиться к свежим бэкапам. Оптимальный вариант – дифференциальное резервное копирование. Его можно как периодически выполнять вручную, так и настроить для автоматического запуска в планировщике программы-бэкапера.
Но есть же ещё нюанс, друзья. Некоторые продвинутые программы-бэкаперы могут предложить не только тот или иной метод создания бэкапа, но и его применение в тех или иных условиях. Например, у AOMEI Backupper есть 5 схем резервного копирования. Схемы можно включить сразу при создании первичного бэкапа.
При настройке схем нужно поставить галочку «Включить управление дисками». И в выпадающем списке ниже увидим пятёрку гибких решений от AOMEI Backupper.
• «Полная копия» - схема с применением метода полного резервного копирования, при котором по достижении назначенного количества копий старые будут автоматически удаляться;
• «Инкрементная копия» - схема с инкрементным бэкапом. По достижении назначенного числа копий цепь предыдущих копий – полной и зависимых инкрементных – удаляется, уступая место новым цепям;
• «Дифференциальная копия» - схема с созданием полных и дифференциальных копий. По достижении их граничного числа старые удаляются, и происходит всё это с учётом привязки дифференциальных копий к их полным;
• «Управление пространством» - схема с созданием полных и дифференциальных копий, заточенная под удаление старых копий при обнаружении недостатка места на диске;
• «Другие схемы резервирования» - схема с полным резервным копированием и возможностью выбора условий автоматического удаления старых копий.
В других программах-бэкаперах, соответственно, могут быть другие идеи от разработчиков. Здесь нужно уже разбираться с каждой такой программой в отдельности и подбирать условия создания бэкапа под свои нужды.
Подготовку нового сервера к работе следует начинать с настройки резервного копирования. Все, казалось бы, об этом знают — но порой даже опытные системные администраторы допускают непростительные ошибки. И дело здесь не только в том, что задачу настройки нового сервера нужно решать очень быстро, но еще и в том, что далеко не всегда бывает ясно, какой способ резервного копирования нужно использовать.
Конечно, идеальный способ, который бы всех устраивал, создать невозможно: везде есть свои плюсы и минусы. Но в то же время вполне реальным представляется подобрать способ, максимально подходящий под специфику конкретно проекта.
- Скорость (время) резервного копирования в хранилище;
- Скорость (время) восстановления из резервной копии;
- Сколько копий можно будет держать при ограниченном размере хранилища (сервере хранения бекапов);
- Объем рисков из-за неконсистентности резервных копий, неотлаженности метода выполнения бэкапов, полной или частичной потери бекапов;
- Накладные расходы: уровень нагрузки, создаваемой на сервер при выполнении копирования, уменьшение скорости отклика сервиса и т.п.
- Стоимость аренды всех использующихся сервисов.
В этой статье мы расскажем об основных способах резервного копирования серверов под управлением Linux-систем и о наиболее типичных проблемах, с которыми могут столкнуться новички в этой очень важной области системного администрирования.
Восстанавливаемся из инкрементных бэкапов
С восстановлением из дискретных бэкапов проблем нет – просто берём копию за нужную дату и разворачиваем обычным консольным tar. С инкрементными копиями немного сложнее. Чтобы восстановиться, например, на 24 июля 2018, нужно выполнить следующее:
- Развернуть годичный бэкап, пусть в нашем случае он отсчитывается от 1 января 2018 (на практике это может быть любая дата, в зависимости от того, когда было принято решение внедрить инкрементное резервное копирование)
- Накатить на него месячный бэкап за июль
- Накатить декадный бэкап за 21-ое июля
- Накатить дневной бэкап за 24 июля
При этом для выполнения 2-4 пунктов необходимо в команду tar добавить ключ -G, тем самым указав, что это инкрементный бэкап. Конечно, не самый быстрый процесс, но если учесть, что восстанавливаться из бэкапов приходиться не так уж часто и важна экономичность, такая схема получается вполне эффективной.
Полное резервное копирование на уровне устройств
-
mdraid и DRBD
Фактически настраивается RAID1 с диском/рейдом на сервере и сетевым диском, и время от времени (по частоте выполнения бекапов) дополнительный диск синхронизируется с основным диском/рейдом на сервере.Например, с одним MySQL это будет выглядеть так:
* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.Далее можно копировать снапшот в хранилище. Главное — следить за тем, чтобы во время копирования снапшот не самоуничтожился и не забывать, что при создании снапшота скорость записи упадет в разы.
Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.
Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.
Исключения
Часто нужно исключить из бэкапов отдельные файлы или каталоги, например, каталоги с кешем. Это можно сделать, указав соответствующие правила-исключения:
Планирование
Здесь все просто. Вы составляете расписание, а True Image обновляет для вас бэкапы точно в назначенное вами время и в соответствии с настроенной схемой. Чем чаще меняются данные, тем чаще рекомендуется их бэкапить. К примеру, системный раздел можно бэкапить раз в месяц, а вот файлы, с которыми вы работаете каждый день, и бэкапить рекомендуется каждый день или даже чаще.
Разумеется, когда вам срочно нужно создать бэкап, не обязательно ждать запланированного времени. Вы всегда можете запустить резервное копирование вручную.
Структура конфигурационных файлов
Структура конфигурационных файлов выглядит следующим образом:
Здесь /etc/nxs-backup/nxs-backup.conf – главный конфигурационный файл, в котором указываются глобальные настройки:
Массив заданий (jobs) содержит список задач (job), которые представляют собой описание того, что именно бэкапить, где хранить и в каком количестве. Как правило, они выносятся в отдельные файлы (один файл на один job), которые подключаются через include в главном конфигурационном файле.
Также позаботились о том, чтобы максимально оптимизировать процесс подготовки этих файлов и написали простенький генератор. Поэтому администратору не нужно тратить время на поиск шаблона конфига для какого-то сервиса, например, MySQL, а достаточно просто запустить команду:
На выходе генерируется файл /etc/nxs-backup/conf.d/mysql_local_scp.conf:
В котором остаётся только подставить несколько нужных значений.
Структура файлов типичного Битрикс-проекта примерно следующая:
Как правило, каталог upload весит много, и со временем только растёт, поэтому его бэкапим инкрементно. Все остальные каталоги — дискретно, за исключением каталогов с кешем и бэкапами, собираемых нативными средствами Bitrix. Пусть схема хранения бэкапов для этих двух площадок должна быть одинакова, при этом копии файлов нужно хранить как локально, так и на удаленном ftp-хранилище, а БД — только на удаленном smb-хранилище.
Итоговые конфигурационные файлы для такого сетапа будут иметь следующий вид:
bitrix-desc-files.conf (конфигурационный файл с описанием job для дискретного резервного копирования)
bitrix-inc-files.conf (конфигурационный файл с описанием job для инкрементного резервного копирования)
Ротация бэкапов
В наших старых скриптах ротация была реализована так, что старая копия удалялась только после того, как новая собиралась успешно. Это приводило к проблемам на проектах, где места под бэкапы в принципе выделено ровно под одну копию – свежая копия не могла там собраться по причине нехватки места.
В новой реализации мы решили поменять этот подход: сначала удалять старую и уже потом собирать новую копию. А процесс сбора бэкапов поставить на мониторинг, чтобы узнавать о возникновении каких-либо проблем.
При дискретном резервном копировании старой копией считается архив, который выходит за рамки заданной схемы хранения в формате дни/недели/месяцы. В случае инкрементного резервного копирования бэкапы по умолчанию хранятся год, а удаление старых копий происходит в начале каждого месяца, при этом старыми резервными копиями считаются архивы за тот же месяц прошлого года. Например, перед сбором месячного бэкапа 1 августа 2018 система проверит, есть ли бэкапы за август 2017, и если да, то удалит их. Это позволяет оптимально использовать дисковое пространство.
E-mail нотификации
По окончанию сбора резервной копии система может рассылать email-уведомления.
Поддерживаются 2 списка получателей:
- Администраторы – те, кто обслуживают сервер. Они получают только нотификации об ошибках, нотификации об успешных операциях им не интересны
- Бизнес-пользователи – в нашем случае это клиенты, которые иногда хотят получать уведомления, чтобы удостовериться, что с бэкапами у них всё хорошо. Или, наоборот, не очень. Они могут выбирать – получать полный лог либо только лог с ошибками.
Поддержка файлов, БД и удалённых хранилищ
На текущий момент реализована поддержка следующих типов бэкапов файлов, БД и удалённых хранилищ:
- MySQL (горячие/холодные бэкапы)
- PostgreSQL (горячие/холодные бэкапы)
- Redis
- MongoDB
- Дискретное копирование
- Инкрементное копирование
Полное резервное копирование на уровне файловой системы
Типичный представитель: dump.
Утилита создает «дамп» файловой системы. Можно создавать не только полную, но и инкрементальную резервную копию. dump работает с таблицей inode и «понимает» структуру файлов (так, разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», потому что ФС может изменяться во время создания дампа. Его надо создавать со снапшота (чуть позже мы обсудим особенности работы со снапшотами более подробно), отмонтированной или замороженной ФС.Такая схема так же зависит от количества файлов, и время её выполнения будет расти с ростом количества данных на диске. В то же время у dump скорость работы выше, чем у rsync.
В случае, если требуется возобновить не резервную копию целиком, а, например, только пару случайно испорченных файлов), извлечение таких файлов утилитой restore может занять слишком много времениИнкрементное резервное копирование
Инкрементные копии файлов делаются по следующей схеме:
В начале года собирается полный бэкап. Далее в начале каждого месяца – инкрементная месячная копия относительно годичной. Внутри месячных – инкрементные декадные относительно месячной. Внутри каждой декадной – инкрементные дневные относительно декадной.
Стоит оговориться, что пока наблюдаются некоторые проблемы при работе с директориями, которые содержат большое количество поддиректорий (десятки тысяч). В таких случаях сбор копий значительно замедляется и может протекать более суток. Мы активно занимаемся устранением этого недочета.
↑ Полное резервное копирование
Полное – это резервное копирование, при котором снимок операционной системы, диска, раздела или отдельных папок содержит все резервируемые данные. Такие снимки, создаваемые в рамках одной и той же задачи по бэкапу, независимы друг от друга, повреждение одного из них никак не повлияет на другие снимки. Это самый надёжный метод резервного копирования, но, вместе с тем, самый затратный по ресурсам дискового пространства. Например, образ рабочей Windows без особых каких-то громоздких программ и игр будет весить примерно 20 Гб. Если по мере создания новых бэкапов не избавляться от старых, диск-хранилище просто забьётся ими под завязку. Решить эту проблему призваны два других механизма резервного копирования.
Читайте также: