Резервное копирование сайта

Клиент: Интернет-магазин подарков на 1С-Битрикс.
Проблема: Магазин существовал 3 года, но резервные копии делались «на глазок» — иногда раз в месяц, иногда раз в полгода, хранились на том же хостинге. В один день системная ошибка привела к повреждению базы данных заказов. Последняя целая копия была двухмесячной давности. Было потеряно около 50 заказов и история клиентов за этот период.
Что сделано (поэтапно в рамках аудита и настройки):

1. Аудит текущей ситуации: Проанализировал структуру сайта (объём базы данных — 2 ГБ, файлов — 15 ГБ). Выяснил, что встроенные средства хостинга создают копии раз в неделю, но хранят только последние 2 версии.
2. Настройка автоматизации: Установил и настроил модуль резервного копирования для Битрикс. Создал расписание: ежедневное копирование базы данных и файлов (инкрементное) в 3:00 ночи.
3. Выбор удалённого хранилища: Настроил выгрузку архивов не на хостинг, а в облачное S3-хранилище (например, Yandex Cloud Object Storage). Это гарантирует сохранность копий даже при полной недоступности основного сервера.
4. Настройка уведомлений: Добавил отправку отчёта в Telegram после каждого создания бэкапа: успешно или нет, размер архива.
5. Результат: Теперь у клиента есть ежедневные автоматические копии за последние 30 дней, хранящиеся географически отдельно от сервера. Время восстановления в случае сбоя сократится с нескольких дней (поиск, попытки восстановить) до 1–2 часов.

Клиент: Сайт стоматологической клиники на WordPress.
Проблема: Сайт был взломан: злоумышленники внедрили вредоносный код, который перенаправлял посетителей на фишинговые страницы. Хостинг заблокировал аккаунт. Собственных резервных копий у клиента не было.
Что сделано (экстренное восстановление с использованием моего бэкапа):

1. Оценка ущерба: Сайт был недоступен уже сутки. Клиент терял пациентов, которые искали клинику в интернете.
2. Восстановление из моей копии: К счастью, клиент был на моём абонентском обслуживании, и я настроил ежедневные бэкапы на внешний сервер. Я взял последнюю чистую копию, сделанную за день до взлома.
3. Развёртывание на новом хостинге: Арендовал новый, временный хостинг, развернул на нём сайт из бэкапа. Временно переключил DNS-записи домена на новый хостинг, чтобы вернуть сайт в строй максимально быстро (заняло около 2 часов).
4. Анализ и устранение уязвимости: После восстановления проанализировал старый хостинг и код, нашёл дыру (устаревший плагин), через которую произошёл взлом. Обновил всё на новом сайте.
5. Результат: Сайт вернулся к работе через 4 часа после обращения. Клиент не потерял трафик и репутацию. Теперь он ещё тщательнее относится к регулярным обновлениям.

Клиент: Сервис по доставке еды на Django.
Контекст: Настроенное автоматическое резервное копирование работало несколько месяцев, но никто ни разу не проверял, можно ли из этих копий реально восстановиться. В рамках расширенного обслуживания я настоял на проведении тестового восстановления.
Что сделано (в рамках пункта «Тестовое восстановление»):

1. Подготовка тестовой среды: На отдельном виртуальном сервере развернул копию окружения, аналогичную боевому.
2. Процесс восстановления: Взял последний ежедневный бэкап и попытался восстановить из него сайт. Процесс не удался — архивы с файлами и базой данных оказались повреждены (ошибка при записи на внешний диск).
3. Диагностика и исправление: Выяснил, что проблема была в нестабильном подключении к облачному хранилищу в момент создания бэкапа. Перенастроил скрипт: теперь после создания архива он проверяет его целостность (контрольную сумму) и только потом удаляет старые версии. Настроил повторные попытки при сбое выгрузки.
4. Повторный тест: Провёл ещё одно тестовое восстановление — успешно.
5. Результат: Клиент избежал ситуации, когда в критический момент «спасательный круг» оказался бы дырявым. Теперь я ежеквартально провожу тестовое восстановление на отдельной среде и документирую процедуру.