Резервное копирование сайта: выбирайте зависимости, а не все архивы подряд

В папке лежит полная резервная копия и несколько последующих файлов. Администратор выбирает нужную дату и собирается распаковать всё подряд в один каталог. Но названия и порядок файлов ещё не объясняют, от какой основы зависит выбранное состояние. Для настройки резервного копирования важно проверить не только создание архива, но и воспроизводимый путь восстановления конкретной версии.

Три типа копий задают разные зависимости

В документации Acronis полная версия содержит данные на момент копирования, инкрементная опирается на предыдущую копию, а дифференциальная — на соответствующую полную. Для восстановления нужны именно зависимости выбранной версии. Эти определения помогают поставить вопрос к системе, но не означают, что любой продукт использует одинаковый формат и допускает любую смесь методов.

full

Полное логическое состояние в учебном примере. Восстановление начинается с него.

diff

В нашем JSON это набор итоговых отличий от явно указанной full-основы.

inc

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

Ниже используется собственный формат обучения, а не файлы Acronis, PostgreSQL или другой программы. У каждой версии есть ID и тип; у неполной — base. Данные представлены именами условных файлов и текстовыми метками v1, v2. Эти метки не являются контрольными суммами.

Пример с возвращением к исходному значению

В D2 два файла снова соответствуют F, поэтому в нашей модели итоговых отличий они не перечислены. Если сначала применить D1, а поверх него только изменения D2, останутся лишние эффекты D1: index.html будет иметь v2, а prices.json исчезнет. Правильное состояние D2 строится от F, а не от D1.

Это контрпример для заданного учебного представления, а не утверждение, что все настоящие дифференциальные архивы кодируют возврат к исходному состоянию одинаково. Реальная система может хранить дополнительные метаданные, блоки и историю изменений. Её формат нельзя заменять описанным JSON.

Почему I3 не требует D1

Выбранный I3 указывает на D2. D2 указывает на F. Поэтому путь восстановления здесь состоит из трёх версий. D1 находится в том же наборе примеров, но не является зависимостью выбранного результата. Наличие рядом другой копии само по себе не делает её этапом этой цепочки.

Как читать входные данные инструмента

Полная версия содержит files — список пар «логическое имя, метка». Неполная версия содержит changes с такими же парами; null вместо метки означает удаление записи. Массивы пар позволяют обнаружить повтор одного имени в пределах версии. Пустая дельта допустима и не меняет состояние.

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

Что остаётся вне такого примера

Текстовая метка может совпасть даже у повреждённого настоящего файла: здесь вообще нет его содержимого. Форма не открывает архивы, не читает диск, не проверяет права, ссылки, владельцев, размер, подпись или согласованность базы данных. Итоговый список не является восстановленной рабочей папкой сайта.

Документация PostgreSQL по pg_combinebackup отдельно различает проверку допустимой цепочки и проверку целостности отдельных копий. Это важное разделение для приёмки услуги: знание зависимостей не заменяет проверку самих данных и пробный запуск. Учебная форма не реализует pg_combinebackup и не восстанавливает PostgreSQL.

Можно ли удалить старую копию после появления новой

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

Что включить в заказ на настройку резервирования

1. Зафиксировать состав данных сайта и способ согласованного копирования базы.
2. Описать сохранение зависимостей для нужных точек восстановления.
3. Согласовать отдельную проверку целостности и доступности хранилища.
4. Проверить восстановление выбранной точки в изолированном тестовом окружении.
5. Сохранить протокол, длительность и ограничения выполненного испытания.

В форме допускаются до двадцати версий, по сто записей в каждой и до пятисот логических файлов в результате. Упрощённые имена и метки нужны только для разбора алгоритма. Для объяснения зависимости достаточно технических обозначений.

При заказе администрирования и резервного копирования у Левицкий Концепт передайте требования к восстановлению, а не только расписание создания архивов. Полезный результат — подтверждённый тест нужного процесса с сохранёнными зависимостями и проверками. Эта модель помогает подготовить такой тест, но сама его не выполняет.