Как бэкапить сайт с сервера

Делаем резервное копирование сайта с помощью git и Makefile

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

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

Автор пользуется стеком django/uwsgi/nginx, виртуальным выделенным сервером под управлением GNU/Linux, но содержание статьи почти не зависит от конкретных технологий.

Загружаем страницы

Сохранять страницы сайта мы будем с помощью стандартной программы wget. Мы будем сохранять каждый сайт в отдельную директорию (которая, возможно, не связана с доменным именем сайта).

Внутри каждой директории страницы будут сохраняться рекурсивно с помощью ключа wget -r (предполагается, что ко всем страницам можно перейти по ссылкам с главной). По умолчанию рекурсивное копирование идёт вплоть до 5-го уровня, но это можно изменить с помощью ключа -l.

Если мы храним медиа и статические файлы отдельно от текстовых страниц, то соответствующие директории игнорируются с помощью ключа -X.

Полная команда выглядит так:

-nH означает —no-host-directories. По умолчанию wget -r example.com поместит всё в директорию example.com/, а эта опция отменяет создание директории с именем хоста.

Опция —restrict-file-names указывает на экранирование символов в URL при создании локальных файлов. Значение nocontrol означает отключение экранирования и очень важно для сохранения страниц с кириллическими ссылками. Без неё страницы сохраняются в файлы с немного изменёнными именами, и не совсем понятно, как их выдавать серверу. К сожалению для пользователей Windows, —restrict-file-names=nocontrol у них не будет работать, это известная проблема.

Добавляем в git

Новый репозиторий создаётся с помощью команды git init. По умолчанию он создаётся внутри текущей директории в папке .git, однако мы хотим, чтобы серверу были доступны только файлы, которые соответствуют названиям открытых страниц сайта. Поэтому полная команда, создающая чистый (bare) репозиторий в папке ../.git-primer, выглядит так:

Чтобы далее пользоваться таким нестандартным репозиторием, нужно передавать git опции git-dir и work-tree:

Пишем Makefile

Начнём с объявления наших проектов:

В переменной SITES содержатся названия наших проектов. Целью по умолчанию является первая цель all, то есть для выполнения всех действий достаточно будет набрать одну команду make. Все цели в SITES являются фиктивными (PHONY): рецепт для каждой из них будет выполняться независимо от существования директории и времени её изменения.
Базовое введение в make можно прочитать, например, здесь, а основным руководством является info make (оригинал, перевод).

Правило для каждого из проектов выглядит так:

Данное правило по сути является одной командой shell.
$@ — автоматическая переменная, в которой содержится название текущей цели (например, primer).
Сначала мы проверяем, существует ли директория .git-primer. Если да, то переходим в директорию проекта, скачиваем страницы, добавляем их в git.
Если содержание страниц не изменилось, то git ничего не добавит, но в этом случае commit будет вызывать ошибку и остановку исполнения Makefile. Поэтому сначала мы вызываем git status с опцией —porcelain, которая предназначена для использования в скриптах. Если длина строки вывода git status —porcelain не нулевая, то мы можем делать commit (отсюда).

get-data, mgit и init-git — это заготовленные (canned) рецепты в Makefile. Например, mgit — это вызов git c указанием директории с файлами репозитория и рабочего каталога:

Canned recipes создаются, когда одна последовательность команд может использоваться в нескольких рецептах. Они могут состоять из нескольких строк, каждая из которых автоматически выделяется табуляцией в рецептах (более точно, символом .RECIPEPREFIX). В нашем примере отступ сделан лишь для удобства чтения Makefile.
Во время исполнения рецептов каждая строка заготовленных последовательностей интерпретируется как отдельная строка рецепта, то есть, в частности, в них можно использовать автоматические переменные для данной цели.

Полный Makefile выглядит так:

В четвёртом абзаце идут целе-зависимые (target-specific) переменные: для каждой цели можно установить собственное значение этой переменной. Эти значения передаются также в зависимости (prerequisites) каждой из целей и в используемые заготовленные рецепты, то есть мы можем быть уверены, что рецепт для каждого сайта будет выполнен с правильным именем сайта и его директории.
Для каждого проекта мы можем передать свои не архивируемые директории через переменную EXCLUDEDIRS или оставить её пустой. Аналогично можно менять имя сервера для архивирования с рабочего компьютера (SERVERHOST) и путь на сервере к директории с архивом сайтов (SERVERPATH). Для простоты, в этом примере все сайты находятся на одном сервере и архивируются в одной директории.
Поскольку каждая строка рецепта (в том числе заготовленного) выполняется в отдельной оболочке shell, то чтобы переход в директорию оставался в силе для следующих команд, мы пользуемся оператором «и» && и экранированием конца строки \ .

Далее идёт условная конструкция Makefile: с помощью команды shell hostname мы проверяем, запускается ли make на сервере или на локальном компьютере. Строки, не удовлетворяющие текущей ветви условной директивы, полностью игнорируются Makefile.

Локальный компьютер служит прежде всего для хранения данных, поэтому на него мы только копируем данные с сервера (git pull), а для удобства локальной работы с git (просмотра логов или версий файлов) мы пользуемся структурой репозитория по умолчанию (обычным репозиторием в папке .git).
В обоих случаях достаточно одной команды make. Для автоматического копирования можно использовать планировщик cron. Чтобы каждый раз не вводить пароль для доступа на сервер, генерируются ssh-ключи.

Для удобства работы на сервере можно из директории текущего сайта создать псевдоним (alias) git с заданной конфигурацией:

Переменная $ содержит название текущей директории без пути к ней и входит в стандарт POSIX, то есть может использоваться во всех поддерживающих POSIX оболочках.

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

После запуска make директория архивов выглядит так:

Файл конфигурации nginx для пример.рф может выглядеть так:

Первый location соответствует главной странице сайта, пример.рф. Она сохраняется wget как файл index.html. Если он не находится, выдаётся ошибка 404.

Для всех остальных URI проверяются файлы в директории primer с названием URI. Если они не найдены, то выдаётся 404.

В конце, чтобы избежать дублирования контента, мы явно запрещаем доступ по ссылке пример.рф/index.html (404). Чуть более подробно об этой конфигурации написано здесь.

Заключение

Резервное копирование сайтов можно делать с помощью стандартных инструментов wget, git, make. Можно копировать все страницы сайта или исключать медиа- и ряд других файлов настолько точно, насколько это позволяет wget. Аналогично, с помощью .gitignore, можно контролировать, какие статические страницы будут добавляться в репозиторий для резервного копирования, а какие нет. Makefile позволяет гибко управлять различными конфигурациями для различных проектов. Полный пример Makefile для клиента и для сервера выше при этом содержит лишь около 60 строк.

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

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

Сохранение версий содержимого сайта также может осуществляться через базу данных при изменении его страниц. Но для этого нужна поддержка версий моделями CMF, а также больший контроль за дампом базы данных (полностью копировать его после любого редактирования страниц). В предложенном методе в случае небольшого изменения содержимого в репозиторий будет добавлено только это изменение, и не требуется использование полной копии БД. Кроме того, сгенерированные статические страницы могут напрямую использоваться сервером или просматриваться в браузере (изменение дизайна или другого программного кода сайта при этом тоже будет копироваться).

Альтернативные программы для резервного копирования перечислены здесь. Для хранения и синхронизации медиафайлов стоит обратить внимание на git-annex. Отделение .git репозитория от рабочего дерева также успешно используется для управления конфигурационными файлами пользователя (dotfiles). Сегодня существуют серверы, которые напрямую поддерживают работу с git-репозиториями.

Как бэкапить сайт с сервера

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

Как восстановить из резервной копии свой ресурс? Рассмотрим три наиболее простых способа.

Иногда достаточно ее нажать и подождать, пока файлы полностью восстановятся. Затем удалить cookies сайта и попробовать на него зайти. Если кнопки восстановления нет, загружать резервную копию придется вручную. Для этого зайдите в файловый менеджер сайта и переименуйте папку с файлами. Выберите такое название, чтобы вы понимали — перед вами хранилище старых файлов. Например, old.

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

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

Резервные копии

Резервная копия — это копия всех сайтов, баз данных и почтовых ящиков пользователя. Резервные копии позволяют:

• восстановить информацию при проблемах в работе сайта;
• восстановить сайт при переносе с сервера на сервер ;
• сохранить данные при возможных перебоях в работе сервера, программных сбоях, проблемах с оборудованием и т.п.

Копия может храниться на сервере с ispmanager или во внешнем хранилище. В качестве внешнего хранилища вы можете использовать:

• Dropbox;
• Google Drive;
• Amazon S3;
• S3-совместимое хранилище;
• FTP-сервер;
• SFTP-сервер (с подключением по SSH).

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

Резервное копирование не выполняется для директорий и файлов, которые:

• находятся на примонтированных устройствах;
• являются символьными ссылками.

Для работы с резервными копиями перейдите в Резервные копии.

Настройка резервного копирования

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

Укажите Основные настройки.

Включите опцию Включить резервное копирование, чтобы резервное копирование выполнялось с указанными настройками.

Для того, чтобы включить/выключить резервное копирование для конкретного пользователя, нужно включить/выключить эту опцию в параметрах пользователя.

Укажите настройки выбранного типа хранилища:

• Путь до папки — директория на сервере, куда будут сохраняться копии.
  
• Код доступа — код доступа к Dropbox. Вы можете перейти по ссылке и авторизоваться в Dropbox. После этого поле будет заполнено автоматически.
  
• Путь до бэкапов — директория в Dropbox, куда будут сохраняться копии.
• Код доступа — код доступа к Google Drive. Вы можете перейти по ссылке и авторизоваться в Google Drive. После этого поле будет заполнено автоматически.
  
• Путь до бэкапов — директория в Google Drive, куда будут сохраняться копии.
• Идентификатор ключа — идентификатор ключа доступа.
• Секретный ключ — секретный ключ доступа.
• Корзина (bucket) — имя контейнера Amazon S3 для хранения резервных копий.
• Регион корзины — код региональной конечной точки Amazon Web Services .

Подробнее о настройках Amazon S3 см. в официальной документации.

• URL хранилища — URL для API-запросов к хранилищу.
• Идентификатор ключа — идентификатор ключа доступа.
• Секретный ключ — секретный ключ доступа.
• Корзина (bucket) — имя контейнера для хранения резервных копий.
• Метод адресации корзин:
  • поддомен — для доступа к корзине будет использоваться URL вида http[s]://bucket.host[:port][/path]. Например, https://bucket.example.com:5555/backup .
  • URL-путь — для доступа к корзине будет использоваться URL вида http[s]://host[:port][/path]/bucket/. Например, https://example.com:7777/backup/bucket .
  • Адрес сервера — доменное имя или IP-адрес сервера.
  • Порт FTP — порт подключения. Значение по умолчанию — 21.
  • Путь до бэкапов — директория на сервере, куда будут сохраняться копии.
  • Пользователь — имя пользователя FTP.
  • Пароль — пароль пользователя FTP.
  • Адрес сервера — доменное имя или IP-адрес сервера.
  • Порт SSH — порт подключения. Значение по умолчанию — 22.
  • Путь до бэкапов — директория на сервере, куда будут сохраняться копии.
  • Авторизация на сервере — тип авторизации: по паролю или ключу SSH. При авторизации по паролю ispmanager сгенерирует ключ, который будет использоваться для доступа к удаленному серверу.
  • Имя пользователя — имя пользователя SSH.
  • Пароль — пароль пользователя SSH.
  • Закрытый ключ — содержимое закрытого ключа SSH.

  Общий объём в байтах. Вы можете указать в этом поле единицу измерения. Например, 100MB.

  • При превышении заданной величины будут удаляться наиболее старые резервные копии;
  • Вы можете оставить это поле пустым, тогда резервные копии будут храниться, пока в хранилище не закончится место;
  • Вы можете ограничить общее количество резервных копий через параметр конфигурационного файла BackupCountLimit. Значение параметра по умолчанию — 14 (7 ежедневных и 7 еженедельных копий).

  В поле Исключить файлы укажите какие файлы не нужно включать в резервную копию. Каждое исключение нужно указывать с новой строки.

  • Пути к файлам задаются относительно домашнего каталога пользователя (по умолчанию это /var/www/username/). Например, data/.filemgr-tmp;
  • Вы можете использовать символ *, чтобы заменить любые символы в имени файла.
  1. Установите Время запуска резервного копирования по Времени сервера.
  2. Для шифрования архива задайте Пароль резервной копии.

  Чтобы изменить заданные настройки, перейдите в Резервные копии → кнопка Настройки.

  Создание резервной копии вручную

  Под учётной записью администратора

  Чтобы создать резервную копию вручную:

  1. Перейдите в Резервные копии → кнопка Создать копию .
  2. Выберите тип копии:
     • полная резервная копия, которая содержит настройки панели управления и всех пользователей;
     • резервная копия настроек панели управления;
     • резервная копия данных пользователей — выберите нужных пользователей для создания резервной копии.

  Ispmanager создаст резервную копию. Она будет добавлена в таблицу. Таблица содержит дату создания копии, размер архива и длительность резервного копирования.

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

  Пример: В 12:00 была создана резервная копия всех пользователей. В 12:01 в панель управления был добавлен пользователь John. В 12:05 администратор повторно создал резервную копию. В эту копию попадут только данные пользователя John.

  

  Под учётной записью пользователя

  Вы можете создать резервную копию из-под учётной записи пользователя. Для этого:

  1. Войдите под учётной записью пользователя: Пользователи → выберите пользователя → кнопка Войти под пользователем.
  2. Перейдите в Резервные копии → кнопка Новый.

  Ispmanager создаст резервную копию и скачает её на ваш компьютер в формате архива tar.gz.

  Таким способом вы можете создавать резервные копии не чаще, чем один раз в час. Если в течение часа после создания первой резервной копии повторно нажать кнопку Новый, ispmanager скачает тот же архив, что и в первый раз.

  Восстановление данных из резервной копии

  Восстановление пользователя и всех его данных

  Чтобы восстановить данные пользователя из резервной копии, перейдите в Резервные копии → выберите копию → кнопка Смотреть файлы → выберите пользователя → кнопка Восстановить → OK. Когда данные будут восстановлены, в интерфейсе ispmanager появится сообщение «Восстановление из резервной копии успешно завершено».

  Существующие файлы не перезаписываются. Перед восстановлением БД пользователей, удалите с сервера одноимённую БД. Если этого не сделать, то ispmanager дополнит существующую БД, а не восстановит её полностью из резервной копии.

  Восстановление удалённого пользователя

  Удалённого пользователя можно восстановить из резервной копии под другим именем. Для этого перейдите в Резервные копии → выберите копию → кнопка Смотреть файлы → выберите пользователя → кнопка Восстановить как → укажите Имя пользователя, которому будут восстановлены данные из резервной копии или Создайте с новым именем → Ok. В этом случае ispmanager не будет восстанавливать совпадающие сущности. Также пользователю будут не доступны резервные копии, созданные под старым именем.

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

  Например, пользователь был удалён 10 марта, а его резервные копии есть за январь и за февраль. После восстановления пользователя из резервной копии за 15 января, он не увидит резервные копии, сделанные позднее этой даты. То есть резервные копии с 15 января до 10 марта будут ему недоступны.

  Восстановление отдельных файлов

  Чтобы восстановить отдельные файлы из резервной копии пользователя:

  1. Войдите под учётной записью пользователя: Пользователи → выберите пользователя → кнопка Войти под пользователем.
  2. Откройте резервную копию пользователя: Резервные копии → выберите копию → кнопка Данные.
  3. Выберите тип данных.
  4. Выберите нужные файлы.
  5. Нажмите кнопку Восстановить для восстановления файлов из резервной копии.

  Когда данные будут восстановлены, в интерфейсе ispmanager появится сообщение «Восстановление из резервной копии успешно завершено».

  Полный бэкап сайта через SSH

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

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

  Создание копии базы данных

  Первым делом нужно подключиться к серверу. Доступ по протоколу SSH изначально выключен, Вы можете его включить в Панели Управления. Под OS Windows мы рекомендуем использовать программу Putty. Подробно о том, как ее настроить можно почитать здесь.

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

  Перейдем в mysqlBackup

  К сожалению, нельзя получить список всех баз на аккаунте, поэтому придется посмотреть их в Панели Управления (далее по тексту ПУ) аккаунтом в разделе «MySQL».

  

  Выполним бекап баз данных с помощью команды mysqldump. Синтаксис вызова следующий:

  После выполнения данной команды для всех БД, в директории mysqlBackup у нас будет лежать дамп всех баз mysql.

  Создание архива файлов сайта

  Теперь, имея полный бекап БД, нужно создать архив сайта. Наиболее распространенный формат это ZIP, так что и архив мы будем создавать в этом формате.

  Для создания архива необходимо перейти в корень аккаунта и выполнить команду:

  В корне Вашего аккаунта будет лежать файл siteBackup_<дата создания архива>.tar.gz, в котором будет содержаться архив всего содержимого Вашего аккаунта.

  Удачной работы! Если возникнут вопросы — напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка».