Бэкапы, которые реально спасут, а не лежат мёртвым грузом

Часть 12 из 12 · Серия «Свой сервер с нуля»

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

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

Главный закон: бэкап — это не копия, а восстановление

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

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

Где бэкап лежать не должен

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

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

Что вообще бэкапить

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

Чёткое понимание, что именно незаменимо, заодно делает бэкапы легче и быстрее — вы не таскаете гигабайты того, что и так лежит в любом репозитории.

Одной копии мало: версии и время

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

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

Автоматизация — и почему её одной мало

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

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

Практика на VPS

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

Базу данных выгружают отдельно и по расписанию — mysqldump для MySQL и MariaDB, pg_dump для PostgreSQL. Это тот самый незаменимый кусок, который должен копироваться чаще всего.

А для главного — копии в другом месте — удобны инструменты вроде restic или borg. Они делают зашифрованные, сжатые и инкрементальные бэкапы (то есть докидывают только изменения, а не гоняют всё заново) и умеют отправлять их на отдельное хранилище или в объектное облако. Шифрование здесь не роскошь: копия, уехавшая на чужую площадку, должна быть закрыта, чтобы данные не утекли вместе с ней.

Чек-лист живого бэкапа

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

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

Серия «Свой сервер с нуля»

Полный цикл — от выбора хостинга до рабочего сайта с почтой, Docker и бэкапами. Вы читаете часть 12 из 12.

1. VDS, VPS, хостинг, облако — что это
2. Nginx vs Apache: холивар, который пора закрыть
3. Зачем арендовать сервер, если есть хостинг за 100 ₽
4. SSH для тех, кто боится чёрного экрана
5. Как не запороть сервер в первый день: топ ошибок
6. SSH-ключи за 10 минут: вход без пароля
7. Поднимаем свой сайт на VPS за вечер
8. Ставим WordPress на свой VPS
9. Свой почтовый сервер — героизм или мазохизм?
10. Docker на VPS: спасение или пушка по воробьям
11. Настраиваем домен и SSL, чтобы браузер не ругался
12. Бэкапы, которые реально спасут — вы здесь

← Предыдущая: Настраиваем домен и SSL, чтобы браузер не ругался