Как стать автором
Обновить

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

Время на прочтение 7 мин
Количество просмотров 6.9K
Всего голосов 15: ↑8 и ↓7 +1
Комментарии 7

Комментарии 7

К вопросу о разных методах резервного копирования
image
Вот честно — ни черта не понял.
Обычно когда пишут сайт на django, то предполагается динамический контент. Который меняется в зависимости от того, какой пользователь зашел (админка? блог? ...), либо просто сам по себе (например, можно придумать сайт, который выдает каждый раз случайное изречение на своей главной странице).
В статье не описано, но данный механизм бекапа для таких сайтов не работает от слова совсем.

НО! Если сайт статический, то можно пойти обратным путем. Взять любой (!) генератор статических сайтов вроде Jekyll, Hugo, Middleman, Harp, Hexo, или Brunch (и сотни их) и положить сам сайт в репозиторий. Тогда репозиторий будет автоматически и бекапом, и единым источником правды (т.е. содержит ЦЕЛЕВОЕ состояние системы). Вот.
Дело в том, что у меня несколько сайтов на django.
Я пользуюсь виртуальным выделенным сервером за 90 рублей в месяц. За эти деньги дают ОС Linux с root-доступом, 10 гигабайт дискового пространства и 256 мегабайт памяти.
При использовании этого тарифа хостер подчёркивает полный отказ от ответственности в случае потери данных.
Сайты работают с помощью django/uwsgi/nginx, сам контент меняется редко. Поскольку памяти очень мало, то удаётся запускать uwsgi с его worker-ами только для одного сайта, в то время как другие могут храниться в виде статических страниц и выдаваться только сервером nginx.

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

Это некая промежуточная стадия: если хотим, то запускаем полноценный динамический сайт, а если хотим — легко его архивируем, убиваем соответствующие процессы (освобождаем память) и выдаём страницы с помощью nginx (который один на весь сервер).
Смотрите.
Вариант бекапа #2. Нам же по сути нужно только хранить код + содержимое БД, если она используется.
Код сайта — прекрасно хранится в репозитории. Если туда же в репозиторий положить инструкции по разворачиванию кода (описание софта на VDS, конфигурации, процесс деплоя и т.д.) — мы получаем IaC (Infrastructure-as-Code), т.е. всегда можно восстановиться на конкретную версию сайта.
Базы данных — если она небольшая — можно дампить mysql и точно так же класть в репозиторий, если она нужна. Тот же GitLab спокойно тянет репозитории до 2ГиБ.

Да, код, содержимое БД и медиафайлы.
С кодом вопросов нет, для него отдельный репозиторий.
Под кодом я имею в виду прежде всего сам код сайта на django (возможно, с парой вспомогательных вещей вроде requirements.txt). Однако я бы не хотел туда же отправлять код для разворачивания на сервере, т.к. он а) платформозависимый б) если сайтов несколько, то он может быть дублирован (в любом случае в отдельном репозитории должен быть код для разворачивания nginix на сервере и установки других системных пакетов — возможно, там же стоит хранить код для разворачивания отдельных сайтов).
Насчёт хранения БД в репозитории — я не могу сейчас ответить точно; есть мнение, что git хранит изменённые куски больших файлов (а .sql может восприниматься как бинарный файл). С другой стороны, насколько мне известно, git лучше всего подходит именно для текстовых файлов. Хранение именно кода или текста в репозитории мне кажется более "чистым" и "правильным" (тем более не хочется хранить каждую версию БД в отдельном файле, если можно хранить только изменения). В целом я не утверждаю что мой метод подходит для всех — вероятно, есть разные вкусовые предпочтения.
В предложенном методе плюсом является также то, что он подходит и для архивирования медиафайлов (картинки обычно не изменяются, хотя их тоже можно хранить в БД — но тогда и размер её будет существенно больше, чем у только текстовой).

Насчет дампа базы — я говорил именно о текстовом формате, а не бинарном.
Картинки и прочие медиаматериалы, если они часто меняются — да, только хранить отдельно (Amazon S3? или можно еще в Git LFS)

Комментарий Ивана Бегтина из OpenDataRussiaChat
https://t.me/opendatarussiachat:
ynikitenko это полезно, спасибо, но когда страниц много у этого есть существенные ограничения. Есть похожий способ через сохранение файла в WARC файл интернет архива. wget и его более продвинутый аналог wpull умеют в него сохранять. После чего есть инструменты отображения страниц из сайта по аналогии с интернет архивом. Например, pywb. Если не сохранять в warc файл то при использовании wget'а и воспроизведении сайта через веб-сервер часто ломаются ссылки с кириллицей и ссылки которые отдают файлы с серверной логикой и через Content-disposition

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории