Сайт собирался месяцами а исчезнуть может за секунду без единой копии

Среди владельцев сайтов живёт опасная иллюзия. Кажется, что раз сайт работает годами без сбоев, так будет всегда. Сервер тихо гудит, страницы открываются, и мысль о резервной копии откладывается на потом, которое не наступает. А потом случается то, что случается: сбой накопителя, ошибка при обновлении, взлом, неудачное движение мышью. И сайт, который собирали месяцами, исчезает за секунду, унося с собой содержимое, настройки и труд.

Резервная копия это не паранойя, а трезвый расчёт. Восстановить сайт из свежей копии дело часа, восстановить из ничего невозможно. При этом настройка автоматического копирования занимает один вечер, после чего работает сама, не требуя внимания. Разобравшись, что именно копировать, как это автоматизировать и куда складывать копии, владелец превращает потенциальную катастрофу в рядовую неприятность, устраняемую парой команд.

Что именно нужно копировать чтобы сайт можно было поднять заново

Прежде чем настраивать копирование, важно понять, из чего состоит сайт и что нужно сохранить. Распространённая ошибка новичков копировать что-то одно, забывая про остальное. Полноценное восстановление требует трёх составляющих, и пропуск любой делает копию неполной, а восстановление невозможным.

Первая составляющая это файлы сайта: страницы, оформление, загруженные изображения, скрипты. Они лежат в каталоге сайта на сервере и образуют его видимую часть. Вторая это база данных, где хранится изменяемое содержимое: тексты, настройки, учётные записи, комментарии. Файлы без базы дадут пустой каркас, база без файлов оформление без содержимого. Третья составляющая это конфигурационные файлы сервера, настройки веб-сервера и сопутствующих служб, без которых поднятые файлы и база не заработают как надо.

Подходы к объёму копирования различаются по задаче. Можно копировать только данные: базы, файлы пользователей, конфигурации, журналы. А можно снимать полный образ системы целиком со всей операционной средой. Для большинства сайтов достаточно копирования данных, оно компактнее и быстрее восстанавливается. Полный образ берут, когда важно поднять сервер один в один со всеми тонкими настройками, не повторяя их вручную.

Понимание трёх составляющих задаёт структуру хранения копий. Разумно завести отдельные места под разные части: папку для копий файлов сайта, папку для копий базы данных, папку для конфигураций. Такая инфраструктура избавляет от путаницы, и при восстановлении сразу понятно, что где лежит и за какую дату. Порядок в копиях так же важен, как и само их наличие.

Создание копии базы данных штатной утилитой выгрузки

База данных требует особого подхода к копированию. Нельзя просто скопировать её файлы на ходу, пока она работает, копия выйдет битой. Для корректного снятия используют штатную утилиту выгрузки, которая аккуратно извлекает всё содержимое базы в один текстовый файл, пригодный для восстановления. Каждая система управления базами несёт такую утилиту в своём составе.

Базовая команда выгрузки базы данных в файл выглядит так:

mysqldump -u root -p mydb > /backup/mydb_$(date +%F).sql

Здесь утилита подключается к базе под указанным пользователем с запросом пароля, выгружает базу с заданным именем и направляет результат в файл. Вставка текущей даты в имя файла делает каждую копию уникальной и подписанной днём создания, так что в папке копий легко найти нужную дату. Без даты в имени каждая новая копия затирала бы предыдущую, оставляя лишь последнюю.

Важная тонкость касается направления вывода. Утилита по умолчанию выводит всё в стандартный поток, поэтому результат обязательно перенаправляют в файл оператором перенаправления. Без этого содержимое базы хлынет на экран вместо сохранения. Указывают и полный путь к файлу от корня, иначе утилита не поймёт, куда писать. Эти мелочи отличают рабочую команду от той, что сыплет данные в консоль без толку.

Для экономии места выгрузку сразу сжимают, пропуская через архиватор. Сжатая копия базы занимает в разы меньше, что особенно ценно при ежедневном копировании, когда файлы накапливаются. Сжатие на лету объединяет выгрузку и упаковку в одну операцию, и на диск ложится уже компактный архив с датой в имени. При восстановлении его так же на лету распаковывают и загружают обратно в базу.

Архивирование файлов сайта в подписанный датой архив

Файлы сайта копируют иначе, упаковывая каталог в сжатый архив. Утилита архивирования собирает всё дерево файлов сайта в один компактный файл, удобный для хранения и переноса. Это сохраняет и сами файлы, и их структуру, права доступа, вложенность папок, чтобы при восстановлении всё легло на свои места.

Команда упаковки файлов сайта в датированный архив выглядит так:

tar -czf /backup/site_$(date +%F).tar.gz /var/www/site

Ключи здесь задают создание сжатого архива с указанным именем из каталога сайта. Как и с базой, в имя архива вставляют дату создания, чтобы копии за разные дни не затирали друг друга и легко различались. Понятное имя с датой позволяет потом с ходу понять, что это за копия и когда она снята, без гадания и распаковки.

Осмысленные имена копий это не мелочь, а удобство восстановления. Когда в папке лежат десятки архивов, подписанных датами, найти нужную копию дело секунды. Безымянные или одинаково названные файлы превращают восстановление в раскопки. Привычка подписывать каждую копию датой и понятным префиксом окупается в тот напряжённый момент, когда сайт лежит и нужно быстро поднять его из верной копии.

Файлы сайта и базу копируют в паре, ведь они дополняют друг друга. Копия файлов за один день и базы за другой при восстановлении дадут рассогласование: оформление одной версии, содержимое другой. Поэтому копирование обеих составляющих запускают вместе, единым заходом, чтобы они отражали одно и то же состояние сайта на один момент времени. Согласованность копий так же важна, как их свежесть.

Автоматический запуск копирования по расписанию через планировщик

Ручное копирование обречено на провал, о нём забывают в самый нужный момент. Надёжность даёт только автоматика, запускающая копирование сама по расписанию. За это отвечает системный планировщик задач, который выполняет заданные команды в назначенное время без участия человека. Настроив его однажды, владелец получает копии, появляющиеся сами каждую ночь.

Задание планировщику на ежедневный запуск сценария копирования в три часа ночи выглядит так:

0 3 * * * /home/admin/backup.sh

Эта строка в расписании планировщика означает запуск указанного сценария каждый день в три часа ночи. Ночное время выбирают не случайно: нагрузка на сервер минимальна, посетителей мало, и копирование не мешает работе сайта. Сам сценарий собирает в себе все команды копирования: выгрузку базы, архивирование файлов, при необходимости отправку копий в другое место.

Сценарий копирования это обычный текстовый файл с набором команд, которому дают право на выполнение. В него складывают всю логику: создание папки за текущую дату, выгрузку базы, упаковку файлов, чистку старых копий. Планировщик лишь запускает этот сценарий по расписанию, а вся работа описана внутри. Такое разделение удобно: логику правят в сценарии, расписание в планировщике, и одно не мешает другому.

Полезно, чтобы сценарий оставлял запись о своей работе в журнале. Строчка с отметкой об успешном завершении и датой, дописываемая в журнал после каждого прогона, даёт владельцу уверенность, что копирование идёт. Заглянув в журнал, он видит историю запусков и сразу замечает, если копирование вдруг перестало отрабатывать. Без такой отметки сбой автоматики обнаруживается лишь в момент, когда копия понадобилась, а её нет.

Хранение копий вдали от сервера и чистка устаревших архивов

Копия, лежащая на том же сервере, что и сайт, защищает лишь наполовину. При сбое накопителя или потере сервера исчезнут и сайт, и копии разом. Поэтому свежие копии отправляют в другое место, на отдельный сервер или в облачное хранилище. Утилита синхронизации файлов умеет переносить копии на удалённый сервер по сети, и эту отправку встраивают в тот же сценарий копирования.

Перенос копий на удалённое хранилище с зеркальным обновлением держит вдали свежий слепок сайта. Если основной сервер постигнет беда, копии останутся целыми в безопасном месте, и сайт поднимется из них на новом сервере. Правило хранения копий отдельно от оригинала это основа надёжности: данные в одном месте это данные под угрозой, данные в двух разнесённых местах это данные в безопасности.

Без чистки копии накапливаются и однажды забивают весь диск. Поэтому в сценарий добавляют автоматическое удаление устаревших копий, оставляющее лишь свежие за разумный срок. Команда поиска и удаления копий старше заданного числа дней убирает всё лишнее, освобождая место. Срок хранения выбирают по своим нуждам: недели глубины обычно хватает, чтобы откатиться к рабочему состоянию, если проблему заметили не сразу.

Глубина хранения это компромисс между надёжностью и местом. Слишком короткая история не даст откатиться далеко, если беда обнаружилась с запозданием. Слишком длинная съедает место под архивы. Разумная середина хранит ежедневные копии за последнюю неделю или две, а изредка снятые копии за более давние сроки откладывает отдельно. Продуманная политика хранения держит и свежесть, и глубину, не разоряя диск.

Как выбрать частоту копирования под характер конкретного сайта

Не каждому сайту нужна одинаковая частота копий, и слепое ежедневное копирование иногда избыточно, а иногда недостаточно. Разумную частоту выбирают по тому, как часто меняется содержимое. Сайт, который обновляется ежедневно, с новыми записями, заказами, комментариями, требует ежедневных копий, чтобы потеря отката составила максимум один день работы. Статичный сайт-визитка, который месяцами не меняется, обходится копированием раз в неделю или после каждого изменения.

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

Содержимое тоже копируют с разной частотой по его природе. Базу данных активного сайта, меняющуюся постоянно, снимают чаще, файлы оформления, которые правят редко, реже. Такое раздельное расписание экономит ресурсы, сосредотачивая частое копирование на быстро меняющейся части. Гибкая стратегия, учитывающая характер сайта и его составляющих, разумнее тупого единого расписания для всего подряд.

Отдельная мысль касается копирования перед рискованными операциями. Любое обновление системы управления сайтом, крупное изменение настроек, установка нового модуля несут риск всё сломать. Привычка снимать свежую копию прямо перед таким вмешательством это дешёвая страховка: если что-то пойдёт не так, откат к только что снятой копии вернёт сайт в рабочее состояние за минуты. Внеплановая копия перед риском часто выручает там, где регулярного расписания не хватило бы.

Проверка копий восстановлением без которой они остаются иллюзией защиты

Самая коварная ошибка это слепая вера в копии, которые никогда не проверяли. Копирование идёт, файлы копятся, владелец спокоен. А в час беды выясняется, что копии битые, неполные или вовсе пустые из-за давней ошибки в сценарии. Незримый сбой копирования обнаруживается в самый неподходящий момент, когда восстанавливать уже не из чего.

Защита от этого одна: периодическая проверка копий восстановлением. Время от времени берут свежую копию и разворачивают её на тестовой площадке, убеждаясь, что сайт поднимается и работает. Восстановление базы из выгрузки, распаковка файлов из архива, запуск сайта на проверочном сервере показывают, что копии живые и полные. Только проверенная восстановлением копия даёт настоящую уверенность, всё прочее лишь надежда.

Процедуру восстановления стоит отработать заранее, в спокойной обстановке, а не впервые осваивать в панике при упавшем сайте. Знание точных шагов, создание базы, загрузка в неё выгрузки, распаковка файлов на место, восстановление настроек, превращает аварийное восстановление из мучения в спокойную последовательность действий. Отрепетированное восстановление занимает час, неотрепетированное растягивается на нервный день с непредсказуемым итогом.

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