«Я думала, что резервное копирование — это “на всякий случай”, пока не удалила базу по ошибке: рассказываю, как бэкапы на Timeweb спасли проект за 15 минут»

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

В тот день я хотела почистить базу от старых черновиков и комментариев со спамом. Открыла phpMyAdmin, быстро пробежалась глазами по таблицам, нажала «Удалить» там, где показалось «лишним», и… поняла, что удалила не ту таблицу. Сначала подумала: «Сейчас отменю», но в MySQL нет кнопки «Отменить». Паника накатила мгновенно: сайт перестал открываться, вместо статей — ошибка подключения к базе данных. До дедлайна по новой статье оставалось два часа, а у меня на экране — полный крах.

Я сразу вспомнила, что хостинг (Timeweb) делает автоматические бэкапы. Но до этого момента я ни разу их не открывала и не проверяла. В голове крутилось: «А вдруг они не работают? Вдруг там нет базы? Вдруг восстановление займёт полдня?»

Чего я боялась в ту минуту

Список страхов был короткий, но очень конкретный:

Потерять все статьи. Их было около 80 — и каждая писалась неделями: поиск информации, интервью, редактура.
Потерять подписчиков. Форма подписки собирала email‑адреса, и эта база была ценнее любого текста.
Опоздать с публикацией. Клиент ждал новую статью, и если я не выложу её вовремя, это скажется на партнёрских выплатах.
Не разобраться с восстановлением. Боялась, что придётся писать в поддержку, ждать ответа, объяснять, что натворила, и всё это время сайт будет лежать.
Что восстановление сломает текущие правки. Если я успела что‑то поменять в файлах за последние часы, вдруг это перезапишется старой версией.

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

Где искать бэкапы и как выбрать нужную версию

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

Дальше я выбрала этот бэкап и нажала «Восстановить». Появилось окно с выбором: восстановить только базу данных или базу вместе с файлами. Я выбрала только базу — потому что за день успела поменять пару файлов темы, и не хотела их откатывать.

Процесс пошёл: полоска загрузки, таймер, статус «Восстановление…». Через 3 минуты пришло уведомление: «Восстановление завершено».

Что происходит при восстановлении: важные нюансы

Здесь я хочу честно рассказать, что важно понимать заранее, чтобы не наделать новых ошибок:

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

Проверка после восстановления

Как только восстановление закончилось, я сразу начала проверять самое важное:

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

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

Что реально помогло на Timeweb

Оглядываясь назад, я вижу, что именно эти вещи сделали восстановление быстрым и безопасным:

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

Практические советы, чтобы не оказаться в такой ситуации

Если вы тоже ведёте сайт и хотите спать спокойно, вот что стоит сделать прямо сегодня:

Проверьте, включены ли автоматические бэкапы. В панели хостинга это видно сразу. Если нет — включите.
Сделайте ручной бэкап перед крупными изменениями. Перед обновлением плагинов, сменой темы, правкой базы — нажмите «Создать бэкап» вручную. Это пара кликов, которые могут сэкономить часы работы.
Разберитесь, как восстанавливать. Не ждите ошибки: зайдите в раздел «Бэкапы», посмотрите, где кнопки, что можно выбрать (файлы/база), сколько времени обычно занимает восстановление.
Храните архив локально. Раз в месяц скачивайте свежий бэкап на свой диск или в облако. Это страховка на случай, если с панелью хостинга что‑то случится.
Ведите журнал изменений. Записывайте, когда обновляли плагины, меняли настройки, чистили базу. Так проще понять, какой бэкап нужен: «до обновления» или «после».
Тестируйте восстановление. На тестовом сайте или на копии попробуйте восстановить базу из бэкапа. Это лучший способ убедиться, что всё работает.
Объясните клиенту или команде, как это работает. Если над сайтом работает несколько человек, все должны знать, где искать бэкапы и что делать при ошибке.

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

Добавить комментарий