Резервная копия должна лежать в хранилище, которое не участвует в синхронизации, и создаваться по расписанию в режиме, где удаление в источнике не удаляет файл в копии. Проще всего взять отдельный внешний диск или отдельный аккаунт облака, настроить задание копирования и проверить его тестовым файлом: создали, скопировали, удалили в источнике — файл в копии остался. Дальше расскажу, как это устроить и какие настройки ломают всю схему.
Чем резервное копирование отличается от синхронизации и почему их нельзя смешивать
Синхронизация выравнивает текущее состояние двух мест. Вы удалили отчёт на ноутбуке — клиент синхронизации через несколько секунд удаляет его в облаке и на телефоне. Это удобно для доступа к свежим файлам с разных устройств, но как защита от ошибки не работает: ошибка мгновенно размножается по всем копиям.
Резервная копия фиксирует состояние на момент времени и хранится отдельно. Удалили файл в источнике — в снимке он остался, потому что задание копирования не обязано повторять удаления. Опасны три сценария: случайное удаление, ошибочная правка и шифровальщик. При синхронизации все три портят данные везде сразу. При бэкапе вы откатываетесь к вчерашнему или недельному снимку.
Отсюда правило 3-2-1: три копии данных, на двух разных носителях, одна из них вне основного места. Синхронизация закрывает удобство доступа, бэкап — восстановление. Это разные задачи, и держать их в одной папке нельзя.
Как спроектировать раздельные контуры: хранилища, расписание и права доступа
Разведите два контура по трём признакам: место, учётная запись и время. Синхронизация пусть работает в реальном времени между устройствами и облаком. Бэкап пишет в другое место: внешний диск, сетевое хранилище (NAS — устройство в вашей сети с собственными дисками) или объектное хранилище вроде S3-совместимого сервиса. Второй контур не должен быть подписан на папку синхронизации.
Учётные записи тоже разные. Если бэкап-хранилище доступно из источника только на запись, шифровальщик не сможет удалить старые снимки. У многих провайдеров для этого есть object lock — режим, при котором объект нельзя удалить или изменить до истечения заданного срока. Уточните в документации провайдера, как включить версионирование бакета и блокировку объектов: названия настроек у сервисов отличаются.
Расписание выбирайте по цене потери. Ежедневный ночной запуск в 22:00 даёт потерю максимум за сутки. Retention-политика (сколько версий хранить) задаётся отдельно: например, 7 дневных, 4 недельных и 6 месячных снимков. Так вы не платите за бесконечную историю, но можете откатиться на месяц назад.
| Признак | Синхронизация | Резервная копия |
|---|---|---|
| Что делает с удалением | Повторяет на всех устройствах | Оставляет файл в снимке |
| Когда работает | Сразу после изменения | По расписанию |
| Где лежит | Облако и устройства | Отдельный диск, NAS или отдельный аккаунт |
| Что восстанавливает | Текущее состояние | Состояние на момент снимка |
Пошаговая настройка на примере: Syncthing для синхронизации и restic + rclone для бэкапа
Ниже рабочая связка для ноутбука: Syncthing синхронизирует папку между устройствами, restic делает зашифрованные снимки в отдельное хранилище, rclone помогает работать с облачными бэкендами. Синтаксис команд сверяйте с официальной документацией restic и rclone на дату настройки: флаги обновляются.
- Настройте Syncthing между устройствами и убедитесь, что папка действительно синхронизируется. Проверка: измените файл на одном устройстве и увидите изменение на другом.
- Создайте отдельное хранилище для бэкапа и отдельные credentials. Для S3-совместимого сервиса это ключ и секрет с правами только на нужный бакет. Не используйте ключ от синхронизации.
- Инициализируйте репозиторий restic командой restic init. Пароль репозитория храните в менеджере секретов, а не в текстовом файле рядом с бэкапом: без пароля снимки не восстановить, а утечка пароля обесценивает шифрование.
- Создайте задание с командой restic backup для папки «Документы», с исключениями для кэша и временных файлов. Запуск — по cron, systemd timer или планировщику Windows, ежедневно в 22:00. Проверка шага: после первого запуска команда restic snapshots показывает снимок.
- Задайте retention командой restic forget —keep-daily 7 —keep-weekly 4 —keep-monthly 6 и затем restic prune. Проверка: старые снимки исчезают по политике, свежие остаются.
- Запустите restic check и тестовое восстановление в отдельную папку. Проверка: файлы открываются, размеры совпадают с исходными.
Пример с числами. Папка «Документы» занимает 40 ГБ. При хранении нескольких версий изменённых файлов ориентируйтесь на объём больше исходного: для 3 версий это порядка 120 ГБ и выше. Внешний диск на 1 ТБ закрывает такую задачу с запасом, но следите за свободным местом: при заполнении диска задание начнёт падать.
Проверка восстановления и контроль целостности бэкапов
Бэкап, который ни разу не восстанавливали, — это надежда, а не копия. Заведите регламент: раз в месяц восстанавливайте пару файлов в отдельную директорию и открывайте их. Раз в квартал проверяйте целостность репозитория командой restic check и просматривайте список снимков.
Настройте уведомления о результате задания. Проще всего, чтобы планировщик при ошибке отправлял письмо или сообщение в мессенджер. Если задание молча падает три недели, вы узнаете об этом только в момент аварии. Ведите короткий журнал: дата проверки, что восстанавливали, результат. Ответственного за проверку назначьте заранее, иначе она не случится.
Типичные ошибки и риски при совмещении бэкапа и синхронизации
Самая частая ошибка — положить бэкап внутрь папки, которую синхронизирует клиент. Копия мгновенно перезаписывается, а при удалении источника исчезает вместе с ним. Вторая — один аккаунт и один ключ для синхронизации и бэкапа: скомпрометированный ключ открывает доступ ко всему.
Третья ошибка — отсутствие retention: хранится единственная версия, и ошибочная правка трёхдневной давности уже не откатывается. Четвёртая — бэкап без шифрования и без проверки восстановления. Пятая — считать синхронизацию защитой от сбоя диска: при отказе накопителя синхронизированная копия в облаке останется, но историю изменений вы не вернёте.
- Бэкап лежит в той же папке, что и синхронизация, — копия бесполезна.
- Один ключ доступа на синхронизацию и бэкап — риск для обоих контуров.
- Нет политики хранения версий — нечего восстанавливать.
- Нет тестового восстановления — целостность не подтверждена.
- Нет уведомлений об ошибках — сбой задания остаётся незамеченным.
Чек-лист внедрения и что сверить с первоисточниками
Пройдите по пунктам и отметьте каждый проверяемым результатом. Если пункт нельзя проверить, схема ещё не готова.
- Бэкап-хранилище физически или логически отделено от синхронизации.
- Для бэкапа отдельные credentials, по возможности только на запись.
- Задание выполняется по расписанию, результат виден в журнале.
- Retention задан, старые снимки удаляются по политике.
- Тестовое восстановление проведено, файлы открываются.
- Уведомления об ошибках настроены.
Сверьте с документацией restic синтаксис команд backup, forget, prune и check, с документацией Syncthing — поведение версионирования файлов при удалении, с документацией провайдера хранилища — object lock, версионирование бакета и лимиты. Названия режимов и флагов у программ отличаются, поэтому не переносите команды из статьи вслепую.
Можно ли просто включить версионирование в облаке синхронизации?
Это лучше, чем ничего, но не заменяет отдельный бэкап. Версии в облаке синхронизации обычно привязаны к тому же аккаунту и той же папке: при компрометации аккаунта или ошибке в настройках они тоже пострадают. Держите независимую копию в другом месте.
Нужен ли отдельный диск, если есть облако?
Не обязательно. Подойдёт отдельный аккаунт облака, не подключённый к папке синхронизации, или объектное хранилище. Главное — другое место, другие credentials и режим, при котором удаление в источнике не удаляет снимок.
Как часто проверять восстановление?
Раз в месяц восстанавливайте несколько файлов в отдельную папку, раз в квартал проверяйте целостность репозитория. Частоту можно менять, но проверка должна быть регулярной и с записью результата.
Что делать, если бэкап уже лежит внутри синхронизируемой папки?
Перенесите его в отдельное хранилище и пересоздайте задание. Старую копию не удаляйте до первого успешного восстановления из нового места: пока новая схема не проверена, вы остаётесь без рабочей копии.