Миф: синхронизация с облаком — это бэкап

MAATRIX

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

Что на самом деле делает синхронизация

Сервис синхронизации файлов — это репликация состояния в реальном времени. Клиент на вашем компьютере следит за папкой через системные события файловой системы (inotify в Linux, FSEvents в macOS, ReadDirectoryChangesW в Windows) и при любом изменении — создании, правке, переименовании, удалении — отправляет дельту на сервер провайдера. Сервер, в свою очередь, рассылает эту же дельту на все остальные устройства, подключённые к той же учётной записи. Задача инструмента одна: чтобы на всех концах в любой момент времени была одна и та же версия файла. Это инструмент доступности и совместной работы — открыть тот же документ с телефона, ноутбука и рабочего компьютера, не гоняя его вручную по флешкам и почте.

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

Три события, которые синхронизация обработает абсолютно одинаково:

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

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

Почему кажется, что это защищает от потери данных

Миф живуч по трём причинам, и все три основаны на реальном опыте, просто не с тем сценарием.

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

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

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

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

Что такое бэкап и чем он отличается по конструкции

Резервная копия — это снимок состояния данных на конкретный момент времени, который хранится отдельно от рабочей копии и не меняется автоматически вслед за ней. Три свойства обязательны одновременно, и если убрать хотя бы одно — это уже не бэкап, а что-то другое:

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

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

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

Таблица ниже — короткая сводка разницы:

Сценарий шифровальщика: почему синхронизация тут не просто бесполезна, а опасна

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

1. Шифровальщик получает исполнение на одном из устройств — через фишинговое письмо, уязвимость в RDP, скомпрометированный пароль или заражённый установщик.
2. Он начинает шифровать файлы на локальном диске, включая содержимое папки, за которой следит клиент синхронизации.
3. Клиент синхронизации видит изменение каждого файла (по сути — перезапись содержимого с новым расширением или без него) и честно, в течение секунд или минут, отправляет эти изменения на сервер провайдера.
4. Сервер провайдера рассылает эти же изменения на все остальные устройства с тем же аккаунтом — рабочий компьютер, ноутбук коллеги, планшет.
5. К тому моменту, когда шифровальщик обнаружен (а обнаруживают его обычно не в момент старта, а когда кто-то не может открыть файл), зашифрованными оказываются не только исходные файлы, но и все синхронизированные копии на всех устройствах и в самом облаке.

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

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

Как использовать синхронизацию и бэкап вместе

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

Практическая раскладка ролей:

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

# пример: снимок синхронизированной папки в отдельный архив с датой
tar -czf /backup/sync-$(date +%F).tar.gz -C /home/user/Sync .
# перенос архива на другой сервер по SSH, вне зоны доступа локального аккаунта
rsync -avz /backup/sync-$(date +%F).tar.gz backup-user@backup-host:/storage/sync/
# ротация: оставить только последние N дней
find /backup -name "sync-*.tar.gz" -mtime +30 -delete

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

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

Как выбрать инструмент под каждую задачу

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

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