Резервное копирование и восстановление

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

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

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

Почему backup важнее сервиса

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

Данные — это:

документы;
фотографии;
архивы;
базы данных;
конфигурации;
заметки;
ключи доступа;
история событий;
настройки пользователей;
файлы сервисов;
compose-файлы и переменные окружения.

Приложение можно скачать заново. Данные — нет.

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

Backup и RAID — это не одно и то же

Название FASTRAID может ассоциироваться с RAID, поэтому важно сразу разделить понятия.

RAID помогает пережить отказ одного или нескольких дисков, если массив настроен правильно. Он повышает доступность хранилища, но не является полноценной резервной копией.

Backup защищает от других ситуаций:

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

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

Простая формула:

Технология	От чего помогает	Чего не заменяет
RAID	отказ диска	резервную копию
Backup	потеря или порча данных	отказоустойчивое хранилище
Snapshot	быстрый откат состояния	полноценное внешнее хранение
Документация	восстановление порядка	сами данные

Надёжная инфраструктура может использовать всё это вместе, но не должна путать их между собой.

Что нужно резервировать

Резервировать нужно не только пользовательские файлы. Часто для восстановления сервиса важны несколько частей.

Что сохранять	Почему это важно
Пользовательские данные	основная ценность сервиса
Конфигурации	позволяют восстановить настройки
Базы данных	часто содержат структуру, пользователей и историю
Compose-файлы	позволяют заново поднять контейнеры
Переменные окружения	хранят параметры подключения и секреты
Reverse proxy конфиги	восстанавливают маршруты и HTTPS
DNS-описание	помогает понять внешний путь к сервису
Скрипты обслуживания	экономят время при восстановлении
Документацию	объясняет, как всё было устроено
Список зависимостей	показывает, от чего зависит сервис

Плохой backup сохраняет только часть данных. Хороший backup позволяет восстановить сервис целиком.

Типы резервных копий

Есть разные типы резервного копирования. Не всегда нужно использовать всё сразу, но важно понимать разницу.

Полная копия сохраняет всё выбранное содержимое. Она проще для понимания, но может занимать много места.

Инкрементальная копия сохраняет только изменения после предыдущей копии. Она экономит место, но восстановление может быть сложнее.

Snapshot фиксирует состояние файловой системы или тома в конкретный момент. Это удобно для быстрого отката, но snapshot не всегда защищает от потери самого хранилища.

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

Архив проекта сохраняет файлы, скрипты, compose-конфигурации и документацию. Это особенно важно для self-hosted сервисов.

Где хранить резервные копии

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

Лучше разделять уровни хранения.

Минимальная логика:

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

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

Главное — не хранить единственную резервную копию там же, где лежат оригинальные данные.

Как часто делать backup

Частота резервного копирования зависит от ценности данных и скорости их изменения.

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

Нужно ответить на два вопроса.

Первый: сколько данных допустимо потерять?
Второй: сколько времени допустимо потратить на восстановление?

Например:

Тип данных	Возможная частота
Документы и рабочие файлы	ежедневно
Фотографии и архивы	по расписанию или после загрузки
Конфигурации сервисов	перед каждым изменением и регулярно
Базы данных	регулярно, с учётом активности
Статический сайт	после важных изменений и через git
Тестовые сервисы	по необходимости

Чем важнее данные, тем чаще их нужно сохранять.

Восстановление важнее копирования

Многие настраивают backup и считают задачу завершённой. Но настоящий вопрос звучит иначе: можно ли из этой копии восстановиться?

Backup без проверки восстановления — это надежда, а не гарантия.

Проверять нужно:

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

Хорошая практика — периодически делать тестовое восстановление в отдельной среде. Даже простая проверка “смогу ли я найти нужные данные и понять порядок действий” уже полезна.

План восстановления

Для каждого важного сервиса нужен короткий план восстановления.

В нём должно быть понятно:

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

План не должен быть красивым документом ради документа. Он должен быть практичным и понятным в момент аварии.

Резервные копии перед изменениями

Перед важными изменениями backup особенно важен.

К таким изменениям относятся:

обновление сервиса;
изменение структуры каталогов;
перенос данных;
изменение reverse proxy;
изменение базы данных;
обновление операционной системы;
изменение прав доступа;
крупные правки конфигурации;
миграция на другой узел.

Перед такими действиями нужно иметь свежую точку возврата. Это снижает риск: если изменение пошло не так, можно вернуться назад.

Backup для домашнего облака

Домашнее облако — один из самых важных кандидатов на резервное копирование.

Для него нужно сохранять:

пользовательские файлы;
базу данных;
конфигурацию сервиса;
настройки пользователей;
сведения о внешнем доступе;
параметры reverse proxy;
важные фоновые задания;
документацию по восстановлению.

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

Backup для сайта и документации

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

Для сайта FASTRAID LAB важны:

исходные файлы проекта;
статьи;
конфигурация Astro;
конфигурация Starlight;
стили;
изображения и логотипы;
Caddyfile;
git-история;
заметки по развёртыванию.

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

Git здесь работает как важная часть защиты: он сохраняет историю изменений и позволяет откатиться к прошлому состоянию.

Мониторинг backup

Резервное копирование нужно мониторить так же, как обычный сервис.

Важно знать:

выполнилась ли последняя задача;
когда была последняя успешная копия;
сколько места осталось в backup-хранилище;
не стала ли копия подозрительно маленькой;
не появились ли ошибки доступа;
не слишком ли старые последние данные;
можно ли прочитать архив.

Особенно опасна ситуация, когда backup сломался давно, но никто этого не заметил. Поэтому уведомления о проблемах резервного копирования должны быть отдельным важным уровнем мониторинга.

Частые ошибки

В резервном копировании часто повторяются одни и те же ошибки.

Первая ошибка — считать RAID резервной копией.

Вторая ошибка — хранить backup на том же диске.

Третья ошибка — сохранять только файлы, забывая базу данных и конфигурацию.

Четвёртая ошибка — не проверять восстановление.

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

Шестая ошибка — не делать копию перед обновлениями.

Седьмая ошибка — не мониторить успешность backup-задач.

Восьмая ошибка — хранить все копии постоянно доступными на запись.

Главная проблема не в том, что backup не настроен. Главная проблема в том, что владелец узнаёт о нерабочем backup только в момент аварии.

Простая схема мышления

Для каждого важного сервиса полезно задать несколько вопросов.

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

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

Итог

Резервное копирование — это не отдельная папка с архивами, а часть архитектуры.

RAID повышает доступность, но не заменяет backup.
Backup защищает данные, но должен быть проверяемым.
Snapshot помогает откатиться, но не всегда заменяет внешнюю копию.
Документация помогает восстановить порядок действий.
Мониторинг показывает, что копии действительно создаются.
Тестовое восстановление подтверждает, что backup работает.

Главная цель — не просто сохранить файлы, а иметь реальный путь восстановления.

Хорошая инфраструктура должна быть не только работающей, но и восстанавливаемой.