Пятница, но серьёзное.
Всем насрать на бэкапы.
У меня есть заказчик, который вполне серьёзно считал RAID-массив за бэкап. Потом сервер залило водой из-за аварии ЖКХ.
В другом проекте бэкапы делал хостер. Крупный хостинг с хорошей репутацией, вы его наверняка знаете. Сервисы легли под DDoS-атакой вместе с доступом к бэкапам и были недоступны около недели.
Ещё история. Бэкапы были, делались автоматически, всё как будто хорошо. Пока в какой-то момент не понадобилось реально восстановиться. И тут выяснилось, что свежие копии битые и не ресторятся.
После нескольких таких случаев начинаешь иначе смотреть на фразу «у нас есть бэкапы».
Потому что RAID — это не бэкап.
Синхронизация тоже не бэкап, удалённый файл удалится везде.
Копия рядом с основной системой тоже так себе бэкап: в случае аварии вы потеряете доступ сразу ко всему.
И даже надпись "Backup completed successfully" означает только то, что какая-то программа считает, что она что-то куда-то скопировала.
Правильная формулировка вообще такая: пока вы не попробовали восстановиться из бэкапа, вы не можете утверждать, что они у вас вообще есть.
Но тестировать восстановление скучно. Хранить ещё одну копию геморно. Выносить её в другое место лень. А главное — прямо сейчас ведь всё работает, правда?
Поэтому всем насрать на бэкапы.
—
Вот вам задание на выходные:
Нет бэкапов вне контура? Зарегистрируйте S3, например тут (ссылка реферальная), и настройте бэкапы туда. Промпт для вашего агента оставлю в первом комментарии к этому посту.
Есть бэкапы? Проведите плановое восстановление, проверьте, что всё пройдёт штатно. Заодно потренируйтесь. Составьте документ, а ещё лучше — скрипт автоматического восстановления.
Вы уже ресторите бэкапы по расписанию?
Пятюню сюда ✋
Проанализируй этот проект и настрой внешние резервные копии в S3.
Сначала разберись, какие данные проекта действительно нужно резервировать: база данных, пользовательские файлы, загруженные документы, конфигурация и другие данные, без которых невозможно полностью восстановить сервис.
Бэкапы должны храниться вне текущего сервера и вне основной инфраструктуры проекта.
Для хранения будет использоваться S3 в SprintHost.
Если S3-хранилище ещё не создано, сначала сообщи мне, что именно нужно сделать в панели SprintHost.
Мне нужно получить от тебя короткую и понятную инструкцию:
- что именно создать: S3-хранилище / бакет;
- какое имя бакета можно использовать;
- нужно ли выбрать регион;
- где создать ключ доступа;
- какие данные после этого передать тебе.
Обычно для подключения тебе понадобятся:
- S3 endpoint;
- имя бакета;
- регион, если он используется;
- Access Key ID;
- Secret Access Key.
Если каких-то данных не хватает, не придумывай их. Скажи мне конкретно, что нужно найти или создать в панели SprintHost.
После получения доступа настрой резервное копирование.
Требования:
1. База данных должна резервироваться штатным способом для используемой СУБД: например, "pg_dump" для PostgreSQL или "mysqldump" для MySQL/MariaDB. Не копируй файлы работающей базы напрямую.
2. Добавь в резервную копию пользовательские файлы и другие изменяемые данные проекта.
3. Не включай то, что можно восстановить из репозитория, Docker-образов или зависимостей, если в этом нет необходимости.
4. Ключи S3 нельзя хранить в Git. Используй ".env", secrets или существующий в проекте механизм хранения секретов.
5. Настрой автоматический запуск минимум один раз в сутки.
6. Настрой хранение нескольких поколений резервных копий. Как минимум:
- ежедневные — 7 дней;
- недельные — 4 недели;
- месячные — 3 месяца.
Если удобнее реализовать retention средствами самого S3, используй lifecycle policy бакета.
7. Бэкап должен считаться успешным только в том случае, если все необходимые данные созданы и действительно загружены в S3.
8. Добавь логирование. Должно быть понятно:
- когда последний раз успешно выполнился бэкап;
- какой получился размер;
- какие данные были сохранены;
- была ли загрузка в S3 успешной.
9. После настройки обязательно проверь восстановление.
Не трогая production-данные, восстанови последний бэкап во временное окружение или отдельную директорию и проверь:
- что архивы читаются;
- что база восстанавливается;
- что пользовательские файлы присутствуют;
- что резервной копии действительно достаточно для восстановления проекта.
10. Если полноценную проверку восстановления нельзя выполнить автоматически, объясни почему и дай конкретную команду или последовательность действий для проверки.
В конце отчитайся:
- что именно резервируется;
- что не резервируется;
- как часто создаются копии;
- сколько они хранятся;
- где находятся настройки;
- как вручную запустить backup;
- как посмотреть состояние последнего backup;
- как выполнить restore;
- как проверить восстановление в тестовом окружении.
Не ограничивайся инструкцией или написанием "BACKUP.md".
Если у тебя есть доступ к проекту и серверу — настрой резервное копирование и проведи тестовое восстановление самостоятельно.
Если для продолжения мне сначала нужно что-то создать или получить в SprintHost — остановись и дай мне точную короткую инструкцию, что сделать в панели и какие значения потом прислать тебе.
Пятюни нет в наборе эмодзи😂
👋вот пятюня)
с учётом угроз датацентрам, надо ледяные копии где-то подальше хранить
есть "золотое правило бекапов" 3-2-1
минимум 3 бекапа
минимум 2 разных носителя (жесткий + облако)
1 копия обязательно "холодная" (дома в коробке с надписью яд, чтобы дети не взяли 😅)
Об этом и речь
Мой клиент забыл оплатить вдски. Последний бекап год назад.
Вспомнил через месяц
Медиа-комментарий — открыть в Telegram.
Самое приятное что 2 месяца назад он отказался от услуги регулярной ТП, и я с чистой совестью очистил диск от его бекапов.
Сумма за восстановление однозначно вышла выше 2 месяцев тп. :)
Но да, похоже что львиную долю восстановим ))