Резервная копия сайта обычно воспринимается как простая страховка. Что-то сломалось, открываем бэкап и возвращаем все как было. Проблема в том, что наличие файла с резервной копией еще не означает, что он действительно спасет сайт.
Один из самых неприятных сценариев выглядит так: владелец исправно делает бэкапы, хранит их на сервере в отдельной папке и уверен, что подготовился к аварии. Затем VPS становится недоступен, диск повреждается, аккаунт блокируется или злоумышленник получает административный доступ. Вместе с рабочим сайтом исчезает и каталог с резервными копиями.
Формально бэкапы существовали. Практической пользы от них не осталось.
Поэтому при резервном копировании важно думать не только о том, как создать архив WordPress, базы данных или файлов проекта. Не менее важен второй вопрос — где этот архив будет находиться после создания.
Хорошее хранилище резервных копий должно пережить ту аварию, от которой мы пытаемся защититься.
Копия на том же сервере полезна но ее недостаточно
Хранить несколько локальных копий на VPS удобно. Они находятся рядом с сайтом, быстро создаются и так же быстро восстанавливаются.
Например, перед обновлением CMS можно сделать архив файлов и дамп базы. Если новый плагин сломает сайт через пять минут, локальная копия позволит вернуть рабочее состояние без долгой загрузки данных из внешнего хранилища.
Такой бэкап отлично защищает от ошибки приложения или неудачного обновления.
Но он почти не помогает при потере всего сервера.
Если удалена виртуальная машина, повреждено хранилище, потерян доступ к аккаунту или атакующий получил достаточно прав, чтобы удалить данные, резервная папка может исчезнуть вместе с основным сайтом.
Поэтому локальную копию лучше считать быстрым первым уровнем восстановления, а не единственным бэкапом.
Отдельный диск внутри VPS тоже не всегда решает проблему
На сервере можно подключить дополнительный виртуальный диск и хранить архивы на нем. Это уже лучше, чем складывать рабочие данные и резервные копии в один каталог.
При ошибке файловой системы или случайном удалении части рабочих данных отдельный том действительно может помочь.
Но нужно понимать, насколько независимо устроено такое хранилище у конкретного провайдера.
Если виртуальная машина и дополнительный диск относятся к одному аккаунту, одному дата-центру и управляются через одну панель, часть рисков остается общей. Компрометация учетной записи способна дать доступ сразу ко всему. Ошибка пользователя в панели тоже может затронуть несколько ресурсов.
Поэтому «другой диск» и «другая независимая копия» не всегда одно и то же.
Резервная копия должна находиться за пределами рабочего сервера
Самое простое правило хорошего резервирования — хотя бы одна актуальная копия должна храниться отдельно от инфраструктуры, на которой работает сайт.
Рабочий VPS находится у одного провайдера — бэкап можно отправлять в объектное хранилище, на другой сервер или в другое независимое хранилище.
Тогда авария основной машины не уничтожает последний способ восстановления.
Для особенно важных проектов полезно разделять риски еще сильнее. Например, рабочий сервер находится у одного поставщика, а внешние резервные копии — у другого.
Это не обязательная схема для каждого маленького блога, но принцип понятен: чем важнее данные, тем меньше у основной системы и последней резервной копии должно быть общих точек отказа.
Объектное хранилище хорошо подходит для бэкапов
Один из удобных вариантов — объектное хранилище с S3-совместимым API.
Для сайта оно интересно тем, что существует отдельно от файловой системы VPS. Сервер создает резервную копию и отправляет ее в удаленный bucket. После этого архив не зависит от рабочего диска виртуальной машины.
Так можно хранить ежедневные дампы базы, архивы файлов, конфигурации и другие данные.
Автоматизацию удобно строить так, чтобы старые версии удалялись по заданной политике, а несколько последних копий всегда оставались доступными.
При выборе объектного хранилища важно смотреть не только на возможность загрузить файл. Нужны понятные права доступа, надежная авторизация, возможность ограничить ключи, история или версионирование объектов при необходимости и предсказуемый процесс восстановления.
Бэкап не должен становиться публичным файлом только потому, что так оказалось проще настроить bucket.
Другой VPS может стать простым резервным сервером
Необязательно использовать именно S3.
Для нескольких сайтов можно завести отдельный сервер, задача которого — принимать резервные копии. Рабочие VPS передают туда архивы по защищенному соединению, а резервная машина хранит историю за нужный период.
Такой вариант дает много контроля. Можно самостоятельно определить структуру каталогов, расписание, шифрование и правила удаления старых копий.
Но вместе с контролем появляется обслуживание еще одного сервера.
Его тоже нужно обновлять, защищать, контролировать свободное место и мониторить. Если резервный VPS месяцами остается без внимания, он сам превращается в потенциальную проблему.
Кроме того, резервный сервер желательно не размещать на том же физическом узле или в той же единственной точке отказа, что и рабочая машина. Иначе независимость получается только на бумаге.
Хранить бэкапы у того же хостера можно
Иногда встречается слишком категоричный совет: резервная копия обязательно должна находиться у совершенно другой компании.
Для многих сайтов это необязательно.
Если провайдер предлагает отдельную систему резервного хранения, физически и логически отделенную от рабочего VPS, такой вариант может быть вполне разумным. Он удобен, быстро настраивается и нередко интегрирован с панелью.
Но нужно выяснить, что именно означает слово «резервное».
Находятся ли копии на другом хранилище? Сохранятся ли они после удаления VPS? Можно ли восстановить данные, если сама виртуальная машина больше не существует? Сколько версий хранится? Что произойдет при удалении услуги или аккаунта?
Ответы важнее названия функции в панели.
Снапшот VPS не стоит считать единственной резервной копией
Снапшоты чрезвычайно удобны перед опасными изменениями.
Нужно обновить систему, изменить конфигурацию сервера или выполнить крупную миграцию — создается снимок состояния, после чего можно экспериментировать спокойнее.
Если что-то пошло не так, виртуальную машину возвращают к предыдущему состоянию.
Но снапшот и независимый бэкап решают немного разные задачи.
Снимок часто тесно связан с инфраструктурой конкретного провайдера. Он может находиться в той же облачной системе, иметь собственный срок хранения и исчезнуть при определенных действиях с ресурсом.
Кроме того, снапшот всей машины не всегда удобен, когда нужно восстановить один файл или конкретную базу.
Поэтому снапшот хорошо дополняет резервное копирование, но для важных данных лучше не делать его единственной линией защиты.
Копия базы данных иногда важнее архива всего сервера
Не все данные сайта меняются одинаково часто.
Файлы ядра CMS можно скачать заново. Тему и собственный код желательно хранить в репозитории. Часть изображений меняется редко.
А база интернет-магазина может изменяться каждую минуту. В ней появляются заказы, пользователи, статусы, комментарии и другие данные, которые невозможно восстановить простой переустановкой программы.
Поэтому расписание резервного копирования лучше выбирать не по размеру сайта, а по допустимой потере данных.
Если бизнес готов в худшем случае потерять изменения за сутки, ежедневного дампа может быть достаточно. Если потеря нескольких часов заказов неприемлема, база требует более частого резервирования или другой архитектуры защиты.
Один огромный архив раз в неделю здесь может оказаться хуже небольших регулярных копий наиболее ценных данных.
Частота бэкапа зависит от того сколько вы готовы потерять
Универсального расписания нет.
Статический сайт, который обновляется раз в месяц, бессмысленно полностью архивировать каждые десять минут. Интернет-магазину с постоянными заказами одной еженедельной копии явно мало.
Полезно задать простой вопрос: если сервер исчезнет прямо сейчас, к какому состоянию сайта мы должны суметь вернуться?
Ответ фактически определяет допустимую потерю данных.
Для информационного проекта это может быть день. Для активного сервиса — часы или значительно меньший интервал.
При этом более частые копии требуют больше места, сетевого трафика и аккуратной автоматизации. Поэтому частота должна соответствовать ценности изменений.
Хранить только последнюю копию опасно
Представим, что сайт был заражен несколько дней назад, но проблему заметили только сегодня.
Если система каждую ночь создает новый бэкап и немедленно удаляет предыдущий, последняя копия уже может содержать вредоносные изменения.
Похожая ситуация возникает при незаметном повреждении базы или ошибке приложения. Проблема постепенно попадает во все новые резервные версии.
Поэтому полезна история.
Например, можно хранить несколько ежедневных копий, более редкие недельные и отдельные долгосрочные версии. Конкретная схема зависит от проекта, но смысл один — возможность вернуться не только «на вчера», но и дальше в прошлое.
Это называется политикой хранения или retention. Она помогает одновременно не копить бесконечные архивы и не оставаться с одной единственной версией.
Правило 3-2-1 остается хорошей отправной точкой
Классический подход к резервному копированию часто описывают правилом 3-2-1.
Идея проста: иметь несколько экземпляров данных, хранить их не одним способом и держать хотя бы одну копию отдельно от основной инфраструктуры.
Для сайта это не обязательно нужно реализовывать буквально с дорогой корпоративной системой.
Например, рабочие данные находятся на VPS. Провайдер делает собственные снимки. Дополнительно сайт отправляет независимые резервные копии в удаленное объектное хранилище.
Уже такая схема значительно устойчивее единственного архива рядом с сайтом.
Чем критичнее проект, тем серьезнее можно разделять учетные записи, провайдеров, регионы и способы хранения.
Локальная копия на компьютере тоже имеет смысл
Для небольшого сайта периодически скачивать резервную копию на собственный компьютер вполне разумно.
Это еще один независимый экземпляр данных, который не исчезнет одновременно с хостингом.
Но ручное скачивание плохо подходит как единственный способ резервирования. Человек забывает. Компьютер выключен. Владелец уехал. Несколько недель никто не обновляет локальный архив.
Кроме того, ноутбук тоже может сломаться, потеряться или заразиться вредоносным ПО.
Поэтому локальная копия хороша как дополнительный уровень, а основное регулярное резервирование лучше автоматизировать.
Облачный диск удобен для небольших проектов но требует осторожности
Некоторые системы резервного копирования умеют отправлять архивы в обычные пользовательские облачные диски.
Для небольшого WordPress это может быть очень удобным решением. Не нужно поднимать отдельный сервер, а файлы находятся вне хостинга.
Однако пользовательский облачный диск и специализированное резервное хранилище создавались для немного разных задач.
Нужно учитывать ограничения API, объем пространства, правила хранения, безопасность учетной записи и поведение при массовом удалении файлов.
Если аккаунт облачного диска одновременно используется для личных документов и резервных копий нескольких рабочих сайтов, доступы лучше организовать особенно аккуратно.
FTP и SFTP хранилище все еще могут выполнять свою задачу
Для отправки резервных копий не обязательно использовать современный объектный API.
Отдельное файловое хранилище с SFTP может быть простым и понятным решением. Сервер по расписанию создает архив и передает его на удаленную машину.
Здесь особенно важно различать FTP и защищенные способы передачи данных.
Если резервные копии содержат базу, конфигурацию и другие чувствительные данные, передавать учетные данные и содержимое по незащищенному соединению не стоит.
SFTP работает через SSH и обычно является более подходящим вариантом для такой задачи.
Но протокол передачи — только часть системы. Само удаленное хранилище все равно нужно защищать и контролировать.
Бэкап может содержать самые ценные секреты сайта
Резервный архив часто опаснее обычной публичной директории сайта.
В нем может находиться полный дамп базы с пользователями и заказами, конфигурационные файлы, ключи API, данные подключения к базе и другая информация, которую посетитель никогда не должен видеть.
Поэтому резервные копии нельзя складывать в публично доступную папку веб-сервера без защиты.
Если архив загружается в объектное хранилище, bucket не должен случайно стать общедоступным.
Если данные чувствительные, стоит рассмотреть шифрование резервных копий. При этом ключ шифрования нельзя хранить единственным экземпляром внутри того же архива, который без него невозможно открыть.
Безопасность бэкапа является частью безопасности самого сайта.
Доступ на запись и удаление лучше ограничивать
Есть еще один неприятный сценарий. Рабочий сервер взломан, а в его конфигурации хранится ключ, который дает полный административный доступ к резервному хранилищу.
Атакующий удаляет не только сайт, но и все его бэкапы.
Поэтому права учетной записи, используемой для автоматической отправки копий, полезно ограничивать настолько, насколько позволяет выбранная система.
В некоторых хранилищах можно использовать версионирование, блокировку объектов или политики, затрудняющие немедленное удаление уже созданных резервных копий.
Для обычного небольшого сайта настолько строгая схема может быть избыточной. Но для коммерческого проекта идея важна: доступ рабочего сервера к бэкапам не обязан автоматически означать возможность бесследно уничтожить всю историю.
Автоматизация важнее идеального расписания на бумаге
Можно придумать прекрасную схему резервирования и выполнять ее вручную каждую пятницу.
Первые несколько недель все будет хорошо. Затем появится срочная работа, отпуск или обычная забывчивость.
Поэтому регулярные копии лучше создавать автоматически.
На VPS это может быть системное расписание, скрипт резервного копирования, функция панели управления или отдельное специализированное решение.
Автоматизация должна охватывать весь цикл: создание копии, отправку во внешнее хранилище, удаление старых версий по понятным правилам и уведомление об ошибках.
Последний пункт особенно важен. Автоматический бэкап, который полгода молча не выполняется из-за закончившегося места, хуже ручного только тем, что создает ложное чувство безопасности.
Следите за свободным местом в резервном хранилище
Бэкапы имеют неприятное свойство расти незаметно.
Сегодня сайт занимает несколько гигабайт. Через год медиатека становится больше, база разрастается, а система продолжает хранить десятки полных копий.
В какой-то момент место заканчивается.
Если система резервирования настроена плохо, новые архивы просто перестают создаваться. Владелец узнает об этом только тогда, когда потребуется восстановление.
Поэтому мониторить нужно не только рабочий сервер, но и хранилище резервных копий.
Политика удаления старых версий помогает контролировать объем, но должна учитывать требования проекта к глубине истории.
Резервная копия без проверки восстановления остается предположением
Самая недооцененная часть резервного копирования — восстановление.
Архив может создаваться каждый день и при этом быть бесполезным. В нем нет части файлов. Дамп базы поврежден. Скрипт год назад изменил путь и с тех пор архивирует пустую директорию. Пароль шифрования потерян.
Узнать об этом во время аварии слишком поздно.
Поэтому резервные копии нужно периодически проверять.
Для сайта можно развернуть тестовое окружение, восстановить туда файлы и базу и убедиться, что проект действительно запускается.
Необязательно делать это после каждого ночного бэкапа. Но регулярная проверка восстановления превращает резервную копию из надежды в проверенный инструмент.
WordPress требует копировать и файлы и базу данных
У WordPress содержимое распределено между файловой системой и базой.
В базе находятся записи, страницы, настройки, пользователи и множество данных плагинов. В каталоге uploads лежат изображения и другие загруженные файлы. Плагины и темы тоже находятся на диске.
Если сохранить только базу, после аварии могут исчезнуть изображения. Если копировать только файлы, не получится вернуть актуальные записи и настройки.
Поэтому полноценное восстановление обычно требует обеих частей.
Для других CMS и приложений структура отличается, но принцип тот же: нужно заранее определить все данные, без которых проект невозможно восстановить.
Для интернет-магазина особенно важна согласованность данных
Чем активнее сайт меняется, тем сложнее получить хорошую копию.
Представим магазин, в котором во время создания большого файлового архива продолжают поступать заказы и изменяться база.
Если разные части резервной копии относятся к разным моментам времени, восстановленное состояние может оказаться несогласованным.
Для небольших проектов проблема решается относительно просто подходящими инструментами резервирования базы и приложения. Для крупных систем появляются специализированные механизмы, репликация и другие способы обеспечить целостность.
Главное — не считать обычное копирование каталога работающего приложения универсальным способом защиты любой системы.
Не храните единственный бэкап только в панели хостинга
Встроенное резервное копирование провайдера удобно и отказываться от него без причины не нужно.
Но если это единственная копия, пользователь полностью зависит от одной учетной записи и одной инфраструктуры.
Возникает проблема с доступом к аккаунту — одновременно становится недоступен и сайт, и механизм его восстановления.
Для важного проекта полезно иметь хотя бы одну копию, которую можно получить независимо от панели рабочего хостинга.
Тогда даже серьезная проблема с основной площадкой не лишает владельца исходных данных для переезда.
Какую схему выбрать для обычного сайта
Не каждому проекту нужна сложная корпоративная система резервирования.
Для небольшого сайта практичная схема может быть довольно простой: хостинг делает свои автоматические копии, а дополнительно сайт регулярно отправляет файлы и базу во внешнее хранилище.
Периодически можно сохранять еще одну копию локально.
Для VPS полезно иметь быстрые локальные или провайдерские снимки перед крупными изменениями и независимые бэкапы за пределами рабочей машины.
Для магазина или другого проекта с ценными постоянно меняющимися данными расписание и глубину хранения нужно делать строже.
То есть сложность резервирования должна расти вместе с последствиями потери данных.
Перед выбором хостинга стоит проверить как устроены его бэкапы
Резервное копирование является такой же характеристикой хостинга, как процессор, диск или панель управления.
Перед покупкой полезно выяснить, делает ли провайдер копии автоматически, как часто они создаются, сколько версий хранится и где физически находится резервное хранилище.
Не менее важен процесс восстановления. Можно ли вернуть отдельный сайт самостоятельно? Доступно ли восстановление базы? Что происходит после удаления VPS? Можно ли скачать копию наружу?
Хорошо, если встроенная система провайдера решает большую часть повседневных задач.
Но даже тогда для действительно важных данных разумно оставить независимый канал резервирования, которым управляете вы.
Главное чтобы авария не уничтожила оригинал и копию одновременно
Идеального места для бэкапа не существует.
Локальный архив быстро восстанавливается, но зависит от сервера. Снапшот удобен для отката виртуальной машины, но связан с инфраструктурой провайдера. Объектное хранилище хорошо отделяет копии от VPS, но требует правильной настройки доступа. Отдельный резервный сервер дает контроль, но его тоже приходится обслуживать.
Поэтому надежность появляется не от выбора одного модного способа хранения, а от сочетания нескольких независимых уровней.
Для большинства сайтов ключевой шаг очень простой: перестать хранить единственную резервную копию рядом с оригиналом.
Пусть на рабочем сервере остается быстрый локальный бэкап. Пусть провайдер делает свои снимки. Но хотя бы одна актуальная версия файлов и базы должна находиться там, где она переживет потерю основного VPS или аккаунта.
И обязательно попробуйте однажды восстановить из нее сайт до того, как это потребуется по-настоящему.
Хороший бэкап — не тот, который каждый вечер появляется в списке файлов. Хороший бэкап — тот, из которого сайт действительно можно вернуть после аварии.
