Синхронизация разнесла удаление файлов на все устройства сразу

MAATRIX

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

Как синхронизация технически принимает решения

Синхронизация — будь то Dropbox, Google Drive, OneDrive, Nextcloud или Syncthing — решает одну конкретную задачу: следить, чтобы содержимое папки на всех подключённых устройствах совпадало с содержимым на сервере (или между устройствами напрямую, как в Syncthing) максимально быстро. Клиент отслеживает изменения через события файловой системы или периодическое сканирование, вычисляет, что поменялось, и отправляет изменение остальным участникам синхронизации.

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

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

Реальные сценарии: как одна ошибка становится общей за секунды

Вот конкретные ситуации, где синхронизация распространяет проблему, а не защищает от неё:

• Случайное удаление папки. Вы чистите диск на ноутбуке, по ошибке удаляете не архив, а рабочую папку проекта. Клиент синхронизации фиксирует удаление и в течение секунд применяет его на десктопе, втором ноутбуке и в мобильном приложении — если вы не успели среагировать до окончания синхронизации, файлов больше нет нигде из «нескольких мест».
• Перезапись файла старой версией. Открыли на телефоне устаревшую локальную копию таблицы (например, синхронизация была на паузе несколько дней), внесли правку и сохранили — устройство отправляет эту версию как «новую», и она вытесняет актуальную версию, которая была на десктопе.
• Шифровальщик или порча файла приложением. Вредоносная программа или упавшее с ошибкой приложение переписывают содержимое файлов на диске. С точки зрения клиента синхронизации это обычное изменение файла, оно репликируется на все подключённые устройства и в облако так же исправно, как легитимная правка. Через несколько минут работы шифровальщика зашифрованными оказываются копии на всех устройствах разом.
• Массовое перемещение или переименование. Скрипт или менеджер файлов переименовывает сотни файлов не так, как задумывалось (например, теряется расширение или меняется кодировка имён) — синхронизация честно применит это переименование везде, и найти файлы по старым именам станет невозможно ни на одном устройстве.
• Конфликт версий при одновременном редактировании. Отдельная, более мягкая, но частая проблема: два устройства правят один файл офлайн, при следующей синхронизации появляется файл вида отчёт (conflicted copy user2 2026-08-27).xlsx, и непонятно, какая версия правильная — обе синхронизировались исправно, но по отдельности.

Разбор похожей механики, только применительно к RAID-массивам, есть в статье «Миф: RAID — это уже резервная копия» — там показано, как синхронная репликация на уровне блоков диска точно так же честно тиражирует порчу данных, только на уровне дисков одного сервера, а не на уровне файлов между устройствами. Логика та же: чем быстрее и надёжнее механизм копирует изменения, тем быстрее и надёжнее он копирует ошибку.

Почему «у меня же несколько копий» — это не защита

Здесь стоит проговорить прямо ключевую мысль всей статьи: синхронизация — это не бэкап. Она отлично решает задачу «иметь актуальную копию файлов на всех моих устройствах прямо сейчас» — вы открываете ноутбук, а там уже лежит файл, который полчаса назад правили на телефоне. Это удобно и по-настоящему полезно. Но у этой задачи и задачи «защититься от ошибки» разные требования, и одно устройство для решения обеих не годится.

Бэкап по определению — это копия данных, отделённая от оригинала во времени: снимок состояния на конкретный момент, который не переписывается автоматически новыми изменениями. Синхронизация — это принципиально противоположный механизм: она сознательно и активно устраняет любое расхождение между копиями, стремясь к состоянию «везде одно и то же, всегда». Наличие трёх, четырёх, пяти синхронизированных копий файла не даёт того, что даёт одна-единственная резервная копия недельной давности — возможности вернуться в момент, когда ошибки ещё не было.

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

Что синхронизация решает хорошо, а что нет

Чтобы не скатываться в «синхронизация — это плохо», стоит честно развести задачи по ролям.

Из таблицы видно: у синхронизации и у версионирования/бэкапа пересекается только один пункт — офлайн-доступность на конкретном устройстве, да и то частично. Во всём остальном это дополняющие друг друга, а не взаимозаменяемые инструменты.

Синхронизация — не версионирование: в чём разница на практике

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

• Dropbox хранит историю версий файлов и «корзину» удалённых файлов, но глубина по умолчанию ограничена 30 днями на большинстве тарифов (на расширенных планах больше — но всё равно конечное окно, а не бессрочный архив).
• Google Drive хранит до 100 версий файла или 30 дней (смотря что наступит раньше) для большинства типов файлов, а удалённые файлы 30 дней лежат в корзине, прежде чем удалиться безвозвратно.
• Nextcloud имеет приложение версионирования файлов с настраиваемой политикой хранения, но по умолчанию агрессивно чистит старые версии при нехватке места в квоте пользователя — практика синхронизации не гарантирует, что нужная версия доживёт до момента, когда она понадобится.
• Syncthing по умолчанию версионирование не хранит вообще — файл при изменении или удалении просто заменяется/исчезает, если явно не включить один из режимов версионирования (Simple, Staggered, Trash Can) в настройках папки:

# Пример конфигурации версионирования папки в Syncthing (config.xml)
<folder id="documents" path="/home/user/Documents">
    <versioning type="staggered">
        <param key="cleanoutDays" val="365"/>
        <param key="maxAge" val="31536000"/>
        <param key="versionsPath" val="/home/user/.sync-versions"/>
    </versioning>
</folder>

Настройка синхронизации на своём сервере вместо облачных сервисов разобрана в статье «Как установить и настроить Syncthing на VPS» — важный нюанс: даже с включённым staggered-версионированием история хранится на том же диске, что и сама синхронизируемая папка. Это лучше, чем ничего, но не заменяет разнесённую в пространстве резервную копию — при отказе или краже этого конкретного сервера пропадёт и рабочая копия, и вся история версий одновременно.

Практический вывод из всего раздела: встроенная история версий у сервисов синхронизации — это полезный, но урезанный по глубине и ненадёжный как единственная линия защиты механизм. Он спасает, если ошибку заметили быстро и в пределах окна хранения, и бессилен, если ошибка вскрылась позже или само хранилище истории пострадало вместе с оригиналом.

Как построить защиту на практике

Правильная схема — не отказ от синхронизации (она удобна и решает свою задачу), а добавление рядом отдельного, независимого слоя резервного копирования с точками восстановления в прошлое.

1. Держите синхронизацию для удобства, бэкап — для защиты. Это две разные системы с разными целями, и обе нужны одновременно, а не одна вместо другой.

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

3. Используйте инструмент с честным версионированием, а не просто «копия». Restic и borgbackup делают инкрементальные снимки, где каждая точка восстановления хранится независимо и не удаляется автоматически при следующем бэкапе:

# инициализация репозитория и первый снимок
restic -r sftp:backup-user@backup-vps:/repo init
restic -r sftp:backup-user@backup-vps:/repo backup /home/user/Documents /home/user/Projects

# список точек восстановления
restic -r sftp:backup-user@backup-vps:/repo snapshots

# восстановление конкретного снимка (по ID из списка выше), а не последнего
restic -r sftp:backup-user@backup-vps:/repo restore a1b2c3d4 --target /restore

Разница между restic и borgbackup разобрана отдельно в статье «Restic или BorgBackup: что выгоднее и когда» — для типовой задачи «бэкап рабочих файлов и документов с нескольких устройств» подойдёт любой из двух, разница скорее в удобстве конкретных сценариев восстановления и уже накопленном опыте с инструментом.

4. Настройте автоматический график и ретеншен, а не разовый ручной запуск. Ежедневный снимок через cron или systemd-таймер, с хранением ежедневных копий за 2-4 недели и нескольких более редких точек за пару месяцев — так, чтобы окно обнаружения проблемы почти наверняка попадало в границы хранения:

# /etc/cron.d/backup-documents — ежедневный бэкап в 3:00
0 3 * * * user restic -r sftp:backup-user@backup-vps:/repo backup /home/user/Documents --tag daily

# еженедельная очистка старых снимков по политике хранения
0 4 * * 0 user restic -r sftp:backup-user@backup-vps:/repo forget --keep-daily 14 --keep-weekly 8 --keep-monthly 3 --prune

5. Держите в голове правило 3-2-1 — три копии данных, два разных типа хранения, одна копия физически в другом месте. Подробный и недорогой вариант его реализации на практике разобран в статье «Правило 3-2-1 для бэкапов дёшево». Синхронизация в этой схеме честно закрывает только удобство доступа, а не роль второй или третьей копии в смысле правила.

6. Периодически проверяйте, что восстановление реально работает. Точка восстановления, которую ни разу не пробовали развернуть, — это гипотеза о защите, а не сама защита. Раз в квартал стоит выполнить тестовое восстановление на отдельную папку и убедиться, что файлы читаются и не повреждены.

Частые вопросы