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

Резервное копирование большого количества разнородных web-проектов

Время на прочтение 12 мин
Количество просмотров 13K
Всего голосов 21: ↑21 и ↓0 +21
Комментарии 30

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

Неплохо, пошел пробовать)
возможно невнимательно читал Но зачем бэкапить веб сайты если они есть в системе контроля версий? Нужно ранить загруженные файлы и снимки баз данных.
Здравствуйте!
Я с Вами абсолютно согласен, что в случае использования на проекте системы контроля версий необходимость в бэкапе кода отпадает. Но дело в том, что на нашем обслуживании есть некоторое количество проектов, которые по каким-то причинам не используют VCS и работают с кодом исключительно по ftp/ssh.
Поэтому мы рассматриваем обобщённый вариант, который можно будет адаптировать под конкретный случай.

В списке рассмотренных решений не увидел, поэтому упомяну то что использу: restic, restic/rest-server и rclone.
Restic обеспечивает отличное хранение снапшотами и дедупликацию, удаление лишних снапшотов в соответствии с политикой хранения, проверку целостности данных. Плюс встроенное шифрование и эффективность, позволяющая полностью загрузить дисковую подсистему/сеть.
Rclone же позволяет restic-у бекапиться на облачные файловые хранилища.

Rclone мы успешно применяем в нашей работе для синхронизации копий в наше собственное облачное хранилище, а что касается restic — то ранее нам не приходилось с ним сталкиваться. Обязательно изучим его возможности и посмотрим какие идеи или наработки можно использовать для нашего инструмента.
Спасибо за информацию!
У вас небольшая путаница с терминологией. Холодный бэкап БД — это когда для бэкапа останавливают сервер БД и тупо копируют файлы данных. В вашем же случае и mysqldump, и XtraBackup — это горячий бэкап. Они отличаются по другому признаку. Первый делает логический бэкап (человекопонятный), просто набор SQL-запросов, который человек может легко исправить, если нужно. Вторая же тулза делает физический (бинарный) бэкап, т.е. по сути это ближе к холодному бэкапу, так как физически копируются файлы базы данных (но без остановки сервера), и человек его вручную не отредактирует.

Да и параметр mysql_xtradb как-то не очень подходит. Так как, есть такой движок таблиц с названием xtradb (в форке MySQL от Percona), и можно подумать, что это только для него. В то время, как в XtraBackup нет буквы «D».
Формально Вы правы, но в данном случае, употребляя термины «холодный» и «горячий» бэкапы БД, целью было подчеркнуть, что в первом случае (при использовании mysqldump) во время сбора дампа могут наблюдаться проблемы в работе проекта, связанные с блокировками, в то время как во втором случае (xtrabackup) вероятность этого события стремится к нулю, т.е. с точки зрения клиента это сопоставимо с остановкой/непрерывной работой СУБД.

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

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

Тем более mysqldump именно горячий бэкап, он работает исключительно при работающем сервере, так как, в процессе просто выполняются SQL-запросы. А тормоза с проектом, будут практически в любом случае при бэкапе, так как серверу нужно перелопатить большой объем данных, к тому же еще и сжать их, да и для таблиц MyISAM в любом случае блокировка делается.

Можно назвать logical и physical (или dump/sql и binary/raw). А то без заглядывания в доки никогда бы не догадался, что cold это создание SQL-дампа.
Ну и раз делаете свой репозиторий, возможно неплохо было бы включить в комплект mydumper, чтобы он шёл из коробки.
Согласен с Вами и чтобы у всех было единое представление о возможностях ПО, термины «горячий» и «холодный» бэкап в ближайшее время будут заменены на logical и physical. Что касается включения в комплект mydumper, то мы обязательно рассмотрим такой вариант.
Спасибо за предложение!
Скажите, а почему в списке open-source имеющихся систем нет BackupPC?
Статья не призвана сделать обзор всех имеющихся open-source систем резервного копирования и в ней представлено только то ПО, которые мы изучили в поисках лучшего решения для наших задач. BackupPC не был озвучен нами потому, что ранее мы не сталкивались с этим продуктом и не изучали его возможности.
При беглом ознакомлении с документацией уже можно сказать, что данное ПО нам бы не подошло хотя бы потому, что у него нет нативной поддержки бэкапов БД.
Я тут «имел удовольствие» бэкапить 1.5 тб фотографий в 3-х уровневой структуре с помощью Borg — из-за того, что он хранит бэкап в бинарных файлах единым массивом, листинг потом мог занимать часы, а восстановление сотни файлов пару дней — столько же, сколько сам бэкап изначально совершался. Хуже того, сама обратная связь на ошибки или отсутствие файлов была такой же медленной.
Я так понимаю, это проблема всех решений, кто хранит бэкап в виде снимков.
Как у вашей утилиты обстоят дела с таким кейсом? :)
Сильно сложно проверить существование и восстановить несколько файлов из инкрементального архива?
upd: и продолжается ли бэкап при обрыве связи, например, сессия ssh дропнулась, или бэкап просто заканчивается с ошибкой?

К сожалению, пока нам не удалось протестировать утилиту на таком объеме данных. Но поскольку как дискретные, так и инкрементные копии хранятся в формате tar, то каких-либо проблем с получением листинга и восстановлением конкретного файла из архива возникнуть не должно. Например, получить листинг файлов в архиве можно командой:


tar -tf <path_to_tarfile>

Извлечь конкретный файл из архива:


tar -xf <path_to_tarfile> [<file_1_in_archive> <file_2_in_archive> ..]
Ну то есть это пока никак не автоматизировано :)
Все-таки найти файл в нескольких инкрементальных архивах и распаковать его по сети не то же самое, что извлечь один файл из одного архива на локалхосте :)
upd: и продолжается ли бэкап при обрыве связи, например, сессия ssh дропнулась, или бэкап просто заканчивается с ошибкой?

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


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


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


Ну то есть это пока никак не автоматизировано :)

Да, пока процесс распаковки архива никак не автоматизирован. Этот функционал будет реализован в следующем релизе.

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

Это как раз сомнительно, так как tar файлы не содержат в себе листинга файлов, и чтобы получить листинг файлов нужно прочитать весь файл. В случае если файл где-то в удаленном хранилище, то его для простого листинга нужно весь скачать, и если речь хотя бы о архиве в сотни мегабайт, то процесс будет весьма не быстрым (не говоря о бэкапах в гигабайты).
Стоит заметить, что для того, чтобы получить листинг файлов архива, расположенного на удаленном storage не обязательно его выкачивать. Например, можно смонтировать удаленное хранилище и работать с архивом, как с локальным файлом (хотя скорость работы будет конечно же медленнее, чем с файлом, реально расположенным локально). В будущем, вероятно, этот процесс будет оптимизирован.
Речь шла о TAR файле, что с ним не делай, быстро список содержимого не получишь. К примеру в ZIP, есть в конце файла каталог содержимого, который легко скачать, не качая весь файл.
Интересная утилита, но про настройку хранилища S3 ничего нет в документации.
В документации отмечено, что пользователю надо самостоятельно настраивать s3fs, напишите хотя бы вкратце что и как. Особенно интересно как подключиться не к AWS серверам S3, а к сторонним.
Разберёмся конечно, но как-то «волшебство» утилиты начинает биться об реальность :)

И я так понимаю, что нельзя настроить внешний SMTP аккаунт для отправки E-mail оповещений?

И что за формат конфигурационных файлов? Это yml?
Интересная утилита, но про настройку хранилища S3 ничего нет в документации.
В документации отмечено, что пользователю надо самостоятельно настраивать s3fs, напишите хотя бы вкратце что и как. Особенно интересно как подключиться не к AWS серверам S3, а к сторонним.

Спасибо за ценное замечание, в ближайшее время дополним документацию по настройке s3. Что касается подключения к пользовательским серверам через s3 REST API интерфейс, то сама утилита s3fs поддерживает такую возможность, однако nxs-backup на текуший момент может работать только с AWS. Поскольку это, действительно, может оказаться полезной фичей — мы реализуем данный функционал в nxs-backup.


И я так понимаю, что нельзя настроить внешний SMTP аккаунт для отправки E-mail оповещений?

На текущий момент отправка почты осуществляется через системный sendmail, который уже можно настроить под свои нужды. В ближайших планах дать возможность рулить настройками почты через nxs-backup.


И что за формат конфигурационных файлов? Это yml?

Да, именно так.

Про сторонние S3 очень даже полезная фича в свете импортозамещения :)
А s3fs в docker ровно работает?
Сделал версию с дополнительными настройками для S3 и отправкой через сторонние SMTP сервера github.com/Sovetnikov/nxs-backup
А s3fs в docker ровно работает?

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




Сделал версию с дополнительными настройками для S3 и отправкой через сторонние SMTP сервера github.com/Sovetnikov/nxs-backup

Спасибо за Ваш вклад в развитие проекта!

s3fs в docker работает, проверил.
Только словил странную ошибку о том, что точка монтирования /mnt/s3 занята, когда два контейнера одновременно запустили бэкап при запуске… видимо это из-за того что /dev/fuse прокинут в контейнеры для корректной работы FUSE.
Про «по всем канонам CI/CD» — а автотестов то в репозитории нет, они где-то в другом месте находятся? Если их нет, то CI/CD становится опасной штукой, которая может распространять беду.

Сам процесс CI/CD описан в нашем Gitlab, что касается автотестов — то на текущий момент их, действительно, нет и ключевые моменты проверяются пока в ручном режиме. По мере развития проекта будут добавлены и автотесты.

Интересный проект.
diff-бэкапы добавить планируете?

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

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