Наткнулся на статью про бэкапы, построенные как код. И понял: у многих сайтов всё ещё так, как в 2005 году — бэкапы на том же сервере, в папке с именем backup_final_FINAL_v3_new. Пока не сломалось — не думают. А потом — катастрофа. Я уже начал проверять это у своих клиентов. О чём речь и почему это важно для сайта Речь не о том, что бэкапы есть — а о том, что они работают. Статья про систему, которая поднимается за минуту через Terraform. Но за этим — глубокая мысль: бэкап — не «записали в папку», а отдельная инфраструктура, которая должна выжить, если умрёт сервер. Это не техническая мелочь — это вопрос выживания бизнеса. Если сайт не работает — выручка падает. А если данные потеряны — восстановить можно, но не за день. Я считаю, что у любого сайта, который делает деньги, бэкап — это не опция, а основа. И он должен быть не просто «есть», а проверен, изолирован и повторяем. Как это устроено — что тут вообще происходит В статье описано, как с помощью кода (Terraform) и открытого софта (Bareos) поднимается полноценная система резервного копирования. Не просто скрипт, а отдельный сервер, БД, хранилище в облаке, сеть, пароли — всё это описано в одном файле. Это не «вручную настроил», а «запустил и забыл». Важно: бэкапы не на том же сервере, не в папке, а в отдельном месте. И восстановить можно по сценарию — не «спроси у Серёги». Это не про сложность — про надёжность. У меня это вызывает одобрение: если система описана как код — значит, она воспроизводима. И не зависит от одного человека. Как понять, что это касается вашего сайта Я проверяю это первым делом, когда берусь за сайт. Нет ли в коде явных признаков: папка backup, файлы с именем backup_final, cron-задачи, которые не проверялись? Если сайт на Битриксе — смотрю версию PHP. Если ниже 8.1 — уже несёт риск. Если на WordPress — проверяю версию движка. Если устаревшая — ищем, не устарел ли и сам код. Если нет ни одного признака — может, бэкапы вообще не настроены. А если есть — где? На том же диске? В облаке? И кто помнит пароль? Я не спрашиваю у клиента — я проверяю. И если что-то не так — сразу в план. Что с этим делать Что я делаю в таких случаях? Сначала — резервная копия. Без неё ничего не делаем. Потом — проверяю, где сейчас лежат бэкапы. Если на том же сервере — начинаем переносить. Если в облаке — проверяем, хранятся ли они отдельно от основной инфраструктуры. Если нет — перекладываем. Потом — настраиваем автоматизацию. Не «сделать вручную», а «записать сценарий». И проверяем восстановление — не по документации, а на практике. Это занимает от нескольких часов до дня, в зависимости от объёма и сложности. Главное — не просто «есть бэкап», а «мы его восстановим, если нужно». И это — не аврал, а план. Что здесь даёт поддержка На постоянной поддержке мы закрываем эту задачу не «в один день», а в плановом окне. Слепое обновление — типовая причина падений. Мы не ставим обновления в ночь, не трогаем ничего без резервной копии. Всё — по сценарию. У нас есть система, которая описана как код, проверяется, воспроизводится. И если что-то пойдёт не так — мы знаем, как вернуться. Все наши разработчики имеют сертификаты PHP и MySQL — это не просто бумага, а гарантия, что мы знаем, как работают системы. И если у вас нет системы бэкапов — или она не проверена — мы поможем. Приглашаю на бесплатный аудит. Проверим, насколько ваш сайт готов к катастрофе.