Любая резервная копия работает — до того дня, когда она понадобится. Снапшот лежит на той же платформе, которая только что легла. Ночной tar-архив молча не срабатывает с марта, с тех пор как переполнился диск. Дамп базы данных оказался файловой копией, снятой посреди записи, и ни во что не восстанавливается. Резервная копия — единственная часть сервера, о которой нельзя судить по внешнему виду, — только по факту восстановления. Вот как построить такую, что переживёт отказ оборудования, ваши собственные руки и чужие руки на ваших учётных данных, не отдавая при этом читаемую копию машины тому, кто её хранит.
Четыре вещи уничтожают сервер, и каждая требует своего
Стройте резервное копирование вокруг сценария отказа, а не вокруг инструмента. Практически любая реальная потеря данных сводится к одному из четырёх сценариев, и каждый предъявляет свои требования к копии, которую вы храните. Схема, справляющаяся с одним из них, кажется полностью достаточной — пока не столкнётся с другим.
Отказ оборудования или хоста
Отказывает диск, узел или целый дата-центр. Спасает любая копия, хранящаяся где-то ещё. Это единственный сбой, с которым надёжно справляется снапшот на той же платформе, — именно поэтому так много людей считают, что снапшотов достаточно.
Собственные руки
Не тот флаг, скрипт миграции, случайно нацеленный на продакшен, очистка, удалившая больше, чем нужно. Повреждение мгновенно реплицируется на всё, что зеркалирует данные, поэтому спасает только история — версия до ошибки, а не свежая копия уже после неё.
Компрометация и программы-вымогатели
У атакующего с root ровно тот же доступ, что и у вашей задачи резервного копирования: те же учётные данные, та же точка назначения, то же расписание. Если сервер способен удалить собственные резервные копии, их удалят. Выживание зависит от того, доступна ли копия только для добавления — или вовсе недосягаема.
Потеря аккаунта, а не сервера
Просрочка оплаты, заблокированный аккаунт, блокировка по требованию не той юрисдикции. С оборудованием всё в порядке — вы просто не можете до него достучаться. Здесь поможет только копия у другого провайдера, оплаченная другим путём.
Прежде чем выбирать что-либо, запишите, от какого именно из этих четырёх сценариев вы на самом деле защищаетесь. Ночная копия во второй каталог на том же диске закрывает ровно один из них — самый маловероятный — при этом ощущаясь полноценной резервной копией. Большинство схем, отказывающих в продакшене, отказывают потому, что никто ни разу не назвал сценарий вслух.
Снапшоты — это не резервные копии
Эти слова используют как взаимозаменяемые, а описывают они разные объекты с разными областями отказа. От того, какой из них у вас на самом деле есть, зависит, есть ли у вас вообще хоть что-то.
Используйте снапшоты для того, в чём они действительно превосходны: пятисекундная отмена перед тем, как вы тронете ядро, загрузчик или схему базы данных. Сделайте снапшот, выполните рискованное действие, удалите его, когда всё получилось. Чего нельзя допускать никогда — чтобы фраза «есть снапшот» становилась причиной отсутствия резервной копии: снапшот разделяет судьбу платформы, на которой он хранится, а заблокированный аккаунт забирает и то, и другое разом.
3-2-1 и два числа, которые все отбрасывают
Старое правило живёт до сих пор, потому что описывает независимость, а не систему хранения файлов: три копии данных, на двух разных видах носителей, одна из них — где-то ещё. Два дополнения покрывают сбои, которые были редкостью, когда правило только придумали, а сегодня стали обыденностью.
- Три копии. Действующие данные плюс две резервные копии. Две копии означают, что вас отделяет от нуля одно неудачное восстановление.
- Два носителя или два провайдера. На арендованной инфраструктуре «носитель» на деле означает административную независимость — вторая копия в том же аккаунте, на той же платформе, оплаченная с того же баланса, это одна копия с лишними телодвижениями.
- Одна — удалённо. Другое здание, другая сеть, другая юрисдикция, если для вас это важно. /locations — практическое воплощение этого принципа: выберите регион, который откажет независимо от того, который вы защищаете.
- Одна — неизменяемая или офлайн. Копия, которую сам сервер удалить не может, потому что тот, кто владеет сервером, владеет и его учётными данными.
- Ноль непроверенных восстановлений. Резервная копия, которую вы ни разу не восстанавливали, — это лишь гипотеза. Значение имеет число выполненных восстановлений, а не число задач, отчитавшихся об успехе.
Резервируйте данные, остальное — пересобирайте
Первый инстинкт — снять образ всего подряд. Это дорого, медленно восстанавливается и добросовестно сохраняет скомпрометированный бинарник, сломанное состояние пакетов и конфигурационный дрейф, о происхождении которого вы уже не помните. На сервере есть три вида содержимого, и только один из них должен попадать в резервную копию.
- Включайте /etc, /home, /root, /srv, корневой каталог вашего сайта, каталог состояния вашего приложения, именованные тома контейнеров и каталог со свежими дампами баз данных.
- Включайте и сам рецепт развёртывания — compose-файлы, скрипты Ansible или shell, заметки, написанные в два часа ночи. Держите их и в системе контроля версий, но также положите копию в резервную копию, чтобы восстановление никогда не зависело от доступности второго сервиса.
- Исключайте /proc, /sys, /dev, /run и временные каталоги. Это интерфейсы ядра и рабочее пространство; их копирование тратит время впустую или вовсе подвешивает задачу.
- Исключайте кеши пакетов, каталоги сборки, деревья зависимостей и virtualenv — всё, что заново создаёт этап сборки. На типичном сервере приложений это большая часть диска.
- Исключайте живые файлы базы данных, если вы правильно снимаете её дамп. Резервирование обоих означает, что в три часа ночи кто-то восстановит именно большую и бесполезную копию.
- Не исключайте скрытые файлы. Половина всего важного на Linux-машине начинается с точки.
База данных не переживёт файловое копирование
Это самая частая причина неудачного восстановления. Работающая база данных держит состояние в памяти и пишет на диск не по порядку; копирование её файлов на ходу фиксирует рваное, наполовину записанное состояние, которое может восстановиться, может восстановиться незаметно повреждённым, а может не восстановиться вовсе. Снимите нормальный дамп, а затем резервируйте уже его.
- PostgreSQL: pg_dump для отдельной базы или pg_dumpall для всего кластера вместе с ролями. Там, где потеря дня недопустима, добавьте архивирование WAL, чтобы восстанавливаться на произвольный момент времени, а не только на прошлую ночь.
- MySQL или MariaDB: mysqldump с --single-transaction даёт консистентный снапшот на InnoDB, не блокируя запись. На MyISAM это не работает — ещё одна причина не использовать MyISAM. Для больших объёмов физический инструмент вроде mariabackup восстанавливает намного быстрее, чем проигрывание дампа.
- SQLite: никогда не копируйте файл напрямую. Используйте команду .backup или VACUUM INTO — они корректно берут блокировку. Копирование базы с активным журналом упреждающей записи — это игра в орла и решку, которую вы рано или поздно проиграете.
- Redis: запустите фоновое сохранение и резервируйте получившийся файл снапшота, либо работайте в режиме добавления в лог (append-only) и резервируйте сам лог. Копирование снапшота посреди записи даёт обрезанный файл, который при загрузке превращается в пустой набор данных.
- Контейнеры: том и есть данные. Остановите стек на те секунды, что займёт копия, либо запустите инструмент снятия дампа внутри контейнера — но не запаковывайте том работающей базы данных в tar и не называйте это резервной копией.
- У всего остального с постоянно работающим процессом — поисковых индексов, очередей сообщений, демонов-леджеров — есть своя команда консистентного экспорта. Найдите её сейчас, а не во время простоя.
Снапшоты файловой системы решают ту же задачу с другой стороны: LVM, ZFS и btrfs замораживают консистентное состояние тома за миллисекунды, и вы резервируете именно это замороженное состояние, пока база данных продолжает работать. Это правильный ответ для наборов данных, где снятие дампа занимает часы. Но это не повод пропускать дамп для базы на 200 MB — там дамп проще, переносим между версиями движка и читаем человеком, если что-то пошло не так.
Выбор инструмента
Четыре инструмента покрывают почти любой случай. Важнее всего то, где именно происходит шифрование. Если данные шифруются только при передаче, а затем — в состоянии покоя силами провайдера хранилища, значит, провайдер хранилища может их прочитать, и резервная копия незаметно стала самым слабым местом в системе, которую вы укрепили везде, кроме этого.
Что бы вы ни выбрали, парольная фраза или ключ должны существовать не только на самом резервируемом сервере. Именно в эту ловушку попадают даже осторожные люди: ключ репозитория лежит в /root и добросовестно резервируется внутри того самого репозитория, который он же и открывает. Распечатайте его или храните в менеджере паролей, который можно открыть с ещё живой машины. Репозиторий, который нечем расшифровать, неотличим от полного отсутствия резервной копии.
Где должна жить вторая копия
Точка назначения — это не только дисковое пространство, но и юрисдикция, и платёжные отношения. Четыре варианта, примерно в порядке того, насколько независимы они от сервера, который вы защищаете.
Второй сервер в другом регионе
Самый прямолинейный ответ: дешёвый инстанс в другой стране, доступный по SSH, на котором не работает ничего, кроме sshd и репозитория. Тариф /vps на 1 GB вмещает резервные копии небольшого парка серверов, а аккаунт можно ограничить единственной принудительной командой, чтобы украденный ключ не открывал shell.
Диск класса storage
Когда объём данных доходит до сотен гигабайт, ёмкость HDD на безлимитном канале стоит в пересчёте на терабайт намного дешевле NVMe, а записи резервных копий не нужна задержка уровня NVMe. /storage создан именно для этого: диск на терабайты под защитой RAID, полный root, без проверки содержимого.
S3-совместимое объектное хранилище
Удобно, тарифицируется за гигабайт и часто поддерживает object lock, дающий настоящую неизменяемость. Прежде чем на него полагаться, изучите тарифы на исходящий трафик — забирать терабайт обратно в аварийной ситуации не лучший момент, чтобы узнавать, сколько стоит извлечение.
Собственное оборудование
Внешний диск или домашняя машина, копия забирается, а не отправляется. Медленнее и вручную, зато единственная копия в этом списке, которую не тронет ни один провайдер, судебное решение или спор по оплате. Стоит держать для данных, которые вы правда не сможете воссоздать, даже если она отстаёт на неделю.
Приватность резервной копии должна соответствовать приватности сервера. Зашифровать диск через LUKS, а затем каждую ночь отправлять незашифрованные копии в бакет, зарегистрированный на вашу карту, — значит свести на нет всю затею: данные снова читаемы и подшиты под вашим именем. Если сервер стоило оплачивать анонимно, то и копия стоит того же — шифруйте на стороне клиента и покупайте точку назначения так же, как покупали источник.
Как это построить, шаг за шагом
- 1
Сначала определите два числа
Сколько данных вы готовы потерять — то есть интервал между запусками, — и сколько времени вы готовы простаивать. Всё остальное следует из этих двух ответов. Часовые резервные копии статического сайта — показуха; ночные копии базы данных с заказами — решение, которое стоит принять осознанно, а не унаследовать из первого попавшегося туториала.
- 2
Создайте точку назначения
Второй инстанс в другом регионе со своим SSH-ключом и отдельным непривилегированным пользователем, чей домашний каталог и есть репозиторий. Больше там ничего не работает. Ограничьте ключ принудительной командой, чтобы украденные учётные данные могли только добавлять резервные копии, но никогда не открывали shell.
- 3
Сгенерируйте ключ и храните его отдельно
Длинная случайная парольная фраза, записанная там, где она переживёт потерю сервера. Инициализируйте репозиторий, а затем докажите, что можете вывести список его содержимого с третьей машины, используя только то, что записали. Если не можете — исправьте это прежде, чем запишете хоть одну резервную копию.
- 4
Сначала снимите дампы баз данных
Короткий скрипт, который пишет консистентные дампы во временный каталог и завершается с ненулевым кодом, если хоть один из них не удался, — запускается до файлового резервного копирования, а не параллельно с ним. Задача, которая продолжается после неудавшегося дампа, — вот как люди получают тридцать дней файлов нулевого размера.
- 5
Резервируйте нужные пути
Направьте инструмент на список включённых путей, примените исключения и проверьте первый запуск на здравый смысл. Если свежий репозиторий для сервера на 40 GB получается на 300 MB, что-то молча пропускается; если он получается на 38 GB, ваши исключения не работают.
- 6
Поставьте по расписанию и сделайте сбой громким
Таймер systemd со случайной задержкой или cron, если так привычнее. Затем сделайте так, чтобы задача отчитывалась: heartbeat в систему мониторинга при успехе и оповещение, когда heartbeat перестаёт приходить. Тихий сбой — обычный режим отказа резервного копирования, потому что при его остановке видимо не ломается ничего — пока не сломается всё.
- 7
Задайте срок хранения и правда выполняйте очистку
Почасовые копии — сутки, ежедневные — две недели, еженедельные — пару месяцев, ежемесячные — год. Затем запустите очистку (prune) и убедитесь, что репозиторий перестал расти. Срок хранения, который настроен, но никогда не применяется на практике, заполняет точку назначения и утаскивает резервные копии за собой.
- 8
Восстановите что-нибудь уже сегодня
Не тестовое задание — настоящий файл, во временный каталог, открытый и проверенный. Затем поставьте в календарь дату для восстановления всей машины целиком. Первое полное восстановление всегда что-нибудь да вскроет: пропавший путь, право доступа, сертификат, пользователя базы данных, который существовал только на старой машине.
Отправляя резервную копию с сервера наружу (push), вы соглашаетесь с тем, что любой, у кого на нём есть root, может уничтожить все копии разом. Сделайте наоборот — пусть хост резервного копирования сам подключается, забирает данные (pull) и отключается, — и скомпрометированный сервер вообще не сможет дотянуться до репозитория, потому что у него просто нет для этого учётных данных. Pull сложнее настроить, но это самое крупное улучшение, которое способно сделать большинство существующих схем.
Срок хранения и почему дольше стоит дешевле, чем кажется
Срок хранения обычно задают исходя из того, что помещается на диск, а затем забывают о нём. Он заслуживает хотя бы одного осознанного решения, потому что именно от него зависит, какие ошибки вообще можно исправить. Семидневное окно поймает файл, удалённый во вторник. Но оно не поймает повреждение, начавшееся шесть недель назад и всплывшее, когда отчёт вышел неправильным, или злоумышленника, который месяц тихо просидел на машине, прежде чем начать действовать.
Дедупликация делает всё это намного дешевле, чем можно подумать по таблице: второй запуск на почти не изменившемся сервере сохраняет только изменения, поэтому год ежемесячных точек восстановления для машины на 40 GB обычно обходится в несколько гигабайт, а не в половину терабайта. Задайте политику исходя из того, от чего вам действительно нужно уметь восстанавливаться, а затем посмотрите на счёт. Обычно оказывается, что щедрый вариант вам вполне по карману.
Неизменяемость: то, что останавливает программы-вымогатели
Всё сказанное выше исходит из того, что противник — это энтропия. Но если противник — человек с root, обычная задача резервного копирования превращается в готовую инструкцию: учётные данные лежат на сервере, точка назначения — в конфиге, а репозиторий стирают ещё до того, как начинается шифрование. Четыре механизма разрывают эту цепочку, и достаточно любого одного из них, чтобы изменить исход.
- Репозитории только для добавления. Серверный режим append-only у Borg или REST-сервер restic в режиме append-only принимают новые данные и отказываются от удаления. Сервер может писать; удалять (prune) можете только вы, и только откуда-то ещё.
- Резервное копирование по модели pull. Соединение инициирует хост резервного копирования, и только у него есть учётные данные. У продакшен-сервера нет ни ключа, ни адреса точки назначения, ни вообще какого-либо пути к репозиторию.
- Object lock. S3-совместимое хранилище со сроком хранения, принудительно заданным на уровне бакета, где само хранилище отказывает в удалении независимо от того, что в остальном разрешают учётные данные.
- Отдельные учётные данные для каждого хоста. Одна скомпрометированная машина не должна раскрывать историю всех остальных. Разные ключи, разные пути, разные ограничения.
- Одна копия, по-настоящему находящаяся офлайн. Отключённый от сети диск невосприимчив к любой удалённой атаке, какая когда-либо была написана. Немодно — и непобедимо.
Тренировка восстановления
Восстановление — это процедура, а процедура, которую никто ни разу не выполнял, — вымысел. Проведите её один раз прямо сейчас и затем раз в полгода, и записывайте всё, что узнаёте, — в итоге эти заметки окажутся так же ценны, как и сами данные.
- 1
Разверните чистый инстанс
Та же версия операционной системы, больше ничего не установлено. Достаточно недолговечного VPS, а вся затея обойдётся дешевле обеда.
- 2
Восстанавливайте, используя только то, что записали
Адрес репозитория, парольную фразу, команды. Если вам понадобится что-то, что существует только на сервере, который вы понарошку считаете мёртвым, — вы только что нашли слабое место, и нашли его в день, когда это ничего не стоит.
- 3
Верните данные раньше, чем приложение
Загрузите дамп базы данных, разложите файлы по местам, затем поправьте владельца и права доступа. Владелец — это обычно и есть сюрприз: числовые ID пользователей со старой машины редко совпадают с новой.
- 4
Запустите сервис и правда им воспользуйтесь
Не команда статуса — войдите, откройте страницу, выполните запрос, отправьте сообщение. Сервис, который запустился, — это не то же самое, что сервис, который работает.
- 5
Засеките время и запишите число
Сколько заняло всё целиком? Это и есть ваше реальное время восстановления, и оно почти всегда в несколько раз больше оценки. Храните эти заметки рядом с парольной фразой и обновляйте и то, и другое при каждом изменении стека.
Сколько это стоит на самом деле
Резервное копирование — самая дешёвая страховка в инфраструктуре, и её регулярно пропускают именно из-за цены. Вот несколько конкретных цифр для небольшого сервера — при условии, что данные сжимаются и дедуплицируются так же, как обычные данные.
Сравните любую из этих сумм со стоимостью простоя, который она предотвращает. Смысл именно в том, чтобы назвать число, — как только сумма записана на бумаге, аргумент против резервного копирования перестаёт быть по-настоящему про деньги.
При чём здесь хостинг
У плана резервного копирования те же две зависимости, что и у сервера, который он защищает: независимое место, куда положить копию, и способ оплаты, который не создаёт новую запись о том, кто вы. Здесь обе они важны даже больше, чем на исходном сервере, потому что резервная копия — это полная копия всего, что защищал источник.
Каждый тариф /vps и /storage здесь разворачивается с предоплаченного крипто-баланса без KYC, в пятнадцати регионах, перечисленных на /locations, — так что вторая копия может оказаться в другой юрисдикции, чем первая, и нигде в цепочке не потребуется вторая проверка личности. Мгновенные снапшоты входят в каждый инстанс для пятисекундной отмены, безлимитный трафик означает, что ни первая загрузка, ни аварийное восстановление не станут тарифицируемым событием, а /storage добавляет диск на терабайты под защитой RAID от $8.99/mo без проверки содержимого. /pay-with перечисляет принимаемые монеты, /offshore-hosting разбирает, что юрисдикция реально меняет, а на /guides есть материалы-компаньоны о шифровании диска и о том, что хостинг может и не может видеть о машине.
Чек-лист
- Назовите сбой, от которого вы защищаетесь, прежде чем выбирать инструмент.
- Относитесь к снапшотам как к кнопке отмены, а не как к резервной копии.
- Резервируйте данные и конфигурацию; операционную систему пересобирайте из скрипта.
- Снимайте дамп каждой базы данных её собственной командой консистентного экспорта и резервируйте именно дамп.
- Шифруйте на стороне клиента, до того как что-либо покинет машину.
- Храните парольную фразу репозитория там, где она переживёт потерю сервера.
- Держите как минимум одну копию у другого провайдера, в другом регионе и с другим способом оплаты.
- Сделайте одну копию только для добавления, pull-based или офлайн, чтобы скомпрометированный root не мог её стереть.
- Настройте оповещение на отсутствие успешного запуска — сбои тихие, и именно тишина является симптомом.
- Восстановите файл сегодня и всю машину — дважды в год. Засеките время и запишите его.
Достаточно ли одних только снапшотов провайдера?
Нет, и это самый распространённый пробел в остальном аккуратных схемах. Снапшот живёт на той же платформе, что и том, который он копирует, поэтому он не переживёт сбой на уровне платформы, блокировку аккаунта или просрочку оплаты — как раз три сценария, где он нужен больше всего. Обычно он ещё и хранит только короткую историю, поэтому не восстановит файл, удалённый месяц назад, или повреждение, начавшееся шесть недель назад. Снапшоты превосходны как пятисекундная отмена перед рискованным изменением: держите их, пользуйтесь ими ежедневно и храните настоящую резервную копию где-то ещё.
restic или Borg — что выбрать?
restic — если точка назначения это объектное хранилище или обычный SSH-аккаунт, потому что на дальнем конце не нужно ничего устанавливать, а S3 он понимает нативно. Borg — если точка назначения это Linux-машина под вашим контролем и вам нужен его серверный режим только для добавления и чуть более плотное сжатие. Оба дедуплицируют, оба шифруют и аутентифицируют данные на стороне клиента, оба зрелые и широко используются, и любой из них — оправданный выбор. Неправильный ответ — потратить месяц на их сравнение, пока у сервера вообще нет резервной копии: выберите один сегодня же и передумайте позже, если это когда-нибудь будет иметь значение.
Как часто нужно резервировать VPS?
Интервал — это попросту максимальный объём работы, который вы готовы переделать заново. Для статического сайта честный ответ — раз в неделю. Для всего, во что пишут пользователи, ночное копирование — это минимум, а часовое обходится дёшево, как только за дело берётся дедупликация: второй за день запуск обычно сохраняет всего несколько мегабайт. Взвесьте ценность данных за один день против стоимости хранения двадцати четырёх точек восстановления вместо одной — и ответ обычно очевиден.
Резервировать весь диск или только свои данные?
Почти всегда — данные и конфигурацию. Полный образ диска восстанавливает машину именно такой, какой она была, включая тот самый взлом, от которого вы восстанавливаетесь, и состояние пакетов, в котором вы уже не разбираетесь, и создаётся и восстанавливается он медленнее. Файловая резервная копия /etc, данных приложения и дампов баз данных в паре со скриптом, пересобирающим операционную систему, восстанавливается быстрее и чище. Снимайте образ диска, когда нужно побитово точное сохранение для расследования или когда машина — чёрный ящик, собранный кем-то другим.
Провайдер говорит, что диски зашифрованы, — значит, и моя резервная копия зашифрована?
Ни в каком смысле, который был бы вам полезен. Шифрование на стороне провайдера защищает от ситуации, когда диск физически выносят из стойки; ключ хранится у провайдера, поэтому данные остаются читаемыми для самого провайдера и для всех, кто может его к этому принудить. Шифрование на стороне клиента — restic, Borg, crypt-слой rclone или зашифрованный архив — означает, что то, что приходит в точку назначения, бессмысленно без парольной фразы, которая никогда не покидала вашу машину. Для стека, критичного к приватности, это различие и есть вся суть, потому что резервная копия — это полная копия всего, что защищал сервер.
Как не дать программам-вымогателям зашифровать заодно и мои резервные копии?
Считайте, что всё, до чего может дотянуться сервер, способен уничтожить и атакующий с root, — учётные данные, точка назначения и расписание лежат прямо на нём. Разорвите эту досягаемость одним из трёх способов: репозиторием только для добавления, который принимает запись, но отказывает в удалении; моделью pull, где хост резервного копирования сам подключается внутрь, а сервер вообще не хранит учётных данных; либо объектным хранилищем с блокировкой, которую обеспечивает само хранилище. Затем добавьте длительный срок хранения, чтобы медленный и тихий взлом просто не успел выйти за пределы окна незамеченным, и держите одну копию офлайн — там, куда не дотянется ни одна удалённая атака.
