Мониторинг и управление вашей системой резервного копирования

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

Резервный набор может состоять из нескольких наборов файлов. Набор файлов — это набор файлов резервных копий, находящихся в одном и том же исходном каталоге набора резервных копий.

Следующая конфигурация YAML показывает пример наборов резервных копий и наборов файлов:

Первый набор резервных копий находится в /volume1/backupftp/mikrotik_backup и содержит два набора файлов. В основном вы будете настраивать его таким образом, когда у вас есть файлы нескольких серверов в одном каталоге. Есть другое решение, которое группирует по имени сервера (или любому идентификатору), как вы увидите в третьем примере.

У набора файлов есть name , которое является просто логическим именем для GUI и filterPattern . Этот шаблон будет фильтровать все файлы, которые соответствуют пути набора резервных копий, независимо от того, насколько глубоко дерево каталогов.

Политика удаления и политика согласованности будут применяться к файлам, упорядоченным по дате изменения (на диске), в порядке убывания.

Второй набор резервных копий предназначен для обмена резервными копиями. Обратите внимание, как мы используем groupByPattern в этом примере. Это группирует все отфильтрованные имена файлов (из filterPattern ) по groupByPattern . В этом случае groupByPattern также является шаблоном даты, который указывается в groupByPatternHasDatePattern .

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

Третий набор резервных копий для резервных копий Proxmox содержит файлы, хранящиеся в каталоге «dump», и смешивает два типа резервных копий. Резервные копии QEMU и LXC разделены на два набора файлов и сгруппированы по идентификатору виртуальной машины (VMID), указанному (\d+) . Поскольку groupByPattern является десятичным значением, а не датой, политики удаления и согласования будут применяться к сопоставленным файлам, упорядоченным по дате изменения (на диске), в порядке убывания.

Обратите внимание, что мы не всегда указываем deletePolicy или consistencyPolicy , потому что мы используем разумные значения по умолчанию для обеих политик. Оба они будут выполняться для каждого резервного набора и каждого набора файлов в нем.

У deletePolicy есть два параметра конфигурации:

• deleteEmptyDirectories : по умолчанию отключено, этот параметр полезен, если у вас есть groupByPattern который является значением даты. При превышении политики хранения все файлы в каталоге будут удалены, и у вас останется пустой каталог «date». В этом случае вы можете указать deleteEmptyDirectories . Каталог будет очищен только в том случае, если он действительно был пустым (на случай, если некоторые другие файлы журнала задерживаются).
• deleteNumberOfBackupsLargerThan : по умолчанию значение равно 30. В случае ежедневного резервного копирования это аналогично 30 дням. Если у вас есть еженедельные резервные копии, это будет означать политику хранения в течение 30 недель. Вы можете изменить это значение по своему усмотрению, независимо от количества дней. Он показывает, сколько наборов файлов необходимо сохранить на диске.

consistencyPolicy имеет три ручки настройки:

• numberOfBackupsRequired : по умолчанию значение 7. Несмотря на то, что мы сохраняем 30 наборов файлов в deletePolicy , нам требуется только 7 наборов файлов для обеспечения согласованности. В случае ежедневных резервных копий это означает, что нам нужно как минимум 7-дневное резервное копирование для согласованности набора файлов.
• minimumFileSizeRequired : по умолчанию значение 1. Это означает, что каждый файл в наборе файлов должен быть не менее 1 байта или больше. Это гарантирует, что в файле есть хоть что- то. Вы можете установить его больше или установить 0, чтобы отключить проверку.
• numberOfDaysOfBackupsRequired : по умолчанию значение 7. Это проверяет, что последний файл в наборе файлов (упорядоченный по дате или времени изменения в порядке убывания), как минимум, более поздний, чем 7 дней назад.

Объединение всех настроек гарантирует, что:

1. Наборы файлов содержат файлы, которые являются достаточно новыми.
2. По крайней мере, что-то написано в файлах набора файлов.
3. У нас есть набор файлов, которые охватывают определенный период, и этот период не превышает политику удаления.

Если какая-либо из проверок не пройдена, набор файлов завершится неудачей. В случае сбоя набора файлов сбой резервного набора и, как следствие, глобальное состояние также не удастся.

Реализация политики согласованности и политики удаления расширяет один и тот же абстрактный класс AbstractFileVisitor , который, в свою очередь, расширяет SimpleFileVisitor<Path> . Этот FileVisitor будет зацикливать все подкаталоги в URI резервного набора, дважды, сначала выполняя политику удаления, а затем выполняя политику согласованности.

Затем AbstractFileVisitor отфильтрует все файлы во всех подкаталогах, соответствующих фильтрам, и поместит их в структуры карты.

Для завершения процесса структуры карты зацикливаются, а файлы удаляются и проверяются в соответствии с правилами политики.

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

улучшения

Улучшения всегда можно сделать, вот список вещей в нашей голове:

• Добавьте контрольные суммы MD5 к источнику до того, как резервная копия выйдет из строя. Проверьте контрольные суммы MD5 в нашем приложении, чтобы убедиться в том, что резервное копирование постоянно.
• Разобрать архивы (.zip, .tar, .gz) в памяти в нашем приложении, просмотреть записи файлов и посмотреть, достигнем ли мы конца архива; это должно исключить повреждение .zip файлов.
• Анализируйте резервные копии почтовых ящиков и просматривайте записи, чтобы убедиться, что архив не поврежден.
• Отправить резервные копии базы данных в инфраструктуру, которая проверяет, можно ли восстановить базу данных.
• Добавьте возможность удаленной проверки резервных копий (например, войдите через SSH на удаленный сервер и проверьте, есть ли резервные копии, которые также доступны и согласованы), что полезно для некоторых сценариев резервного копирования за пределами площадки.
• Добавьте возможность проверять резервные копии через API (например, для статуса резервных копий AWS или резервных копий Proxmox, которые размещены в сторонней системе).