Сам процесс CI/CD описан в нашем Gitlab, что касается автотестов — то на текущий момент их, действительно, нет и ключевые моменты проверяются пока в ручном режиме. По мере развития проекта будут добавлены и автотесты.
Если честно, то нами не тестировалась работа s3fs внутри docker-контейнера, однако возникновения каких-либо проблем при этом не предполагаем. Если же Вы столкнетесь с какими-либо сложностями — сообщите нам и мы постараемся решить проблему.
Сделал версию с дополнительными настройками для S3 и отправкой через сторонние SMTP сервера github.com/Sovetnikov/nxs-backup
Стоит заметить, что для того, чтобы получить листинг файлов архива, расположенного на удаленном storage не обязательно его выкачивать. Например, можно смонтировать удаленное хранилище и работать с архивом, как с локальным файлом (хотя скорость работы будет конечно же медленнее, чем с файлом, реально расположенным локально). В будущем, вероятно, этот процесс будет оптимизирован.
Интересная утилита, но про настройку хранилища S3 ничего нет в документации.
В документации отмечено, что пользователю надо самостоятельно настраивать s3fs, напишите хотя бы вкратце что и как. Особенно интересно как подключиться не к AWS серверам S3, а к сторонним.
Спасибо за ценное замечание, в ближайшее время дополним документацию по настройке s3. Что касается подключения к пользовательским серверам через s3 REST API интерфейс, то сама утилита s3fs поддерживает такую возможность, однако nxs-backup на текуший момент может работать только с AWS. Поскольку это, действительно, может оказаться полезной фичей — мы реализуем данный функционал в nxs-backup.
И я так понимаю, что нельзя настроить внешний SMTP аккаунт для отправки E-mail оповещений?
На текущий момент отправка почты осуществляется через системный sendmail, который уже можно настроить под свои нужды. В ближайших планах дать возможность рулить настройками почты через nxs-backup.
upd: и продолжается ли бэкап при обрыве связи, например, сессия ssh дропнулась, или бэкап просто заканчивается с ошибкой?
Если Вас имеете в виду, что будет в случае, если во время работы утилиты оборвется связь с удаленным storage, в который должен быть загружен файл, то стоит пояснить следующее — за исключением инкрементных копий файлов бэкап всегда сначала собирается локально во временной директории. Затем, архив поочередно копируется на все удаленные storage, после чего локально перемещается в постоянное место дислокации или удаляется (в зависимости от того, используется ли локальный storage).
Поэтому, если по какой-либо причине во время копирования файла на удаленный storage с ним была потеряна связь, то утилита должна сообщить о проблемах (сделать соответствующую пометку в лог-файле) и приступить к работе со следующим хранилищем, в том числе и локальным.
При ответе на Ваш вопрос мы обнаружили баг в коде, при котором утилита аварийно завершает свою работу, в случае обрыва связи во время передачи файла на какое-либо удаленное хранилище. В ближайшее время этот баг будет устранен, спасибо за интересный вопрос!
Ну то есть это пока никак не автоматизировано :)
Да, пока процесс распаковки архива никак не автоматизирован. Этот функционал будет реализован в следующем релизе.
К сожалению, пока нам не удалось протестировать утилиту на таком объеме данных. Но поскольку как дискретные, так и инкрементные копии хранятся в формате tar, то каких-либо проблем с получением листинга и восстановлением конкретного файла из архива возникнуть не должно. Например, получить листинг файлов в архиве можно командой:
tar -tf <path_to_tarfile>
Извлечь конкретный файл из архива:
tar -xf <path_to_tarfile> [<file_1_in_archive> <file_2_in_archive> ..]
Согласен с Вами и чтобы у всех было единое представление о возможностях ПО, термины «горячий» и «холодный» бэкап в ближайшее время будут заменены на logical и physical. Что касается включения в комплект mydumper, то мы обязательно рассмотрим такой вариант.
Спасибо за предложение!
Статья не призвана сделать обзор всех имеющихся open-source систем резервного копирования и в ней представлено только то ПО, которые мы изучили в поисках лучшего решения для наших задач. BackupPC не был озвучен нами потому, что ранее мы не сталкивались с этим продуктом и не изучали его возможности.
При беглом ознакомлении с документацией уже можно сказать, что данное ПО нам бы не подошло хотя бы потому, что у него нет нативной поддержки бэкапов БД.
Формально Вы правы, но в данном случае, употребляя термины «холодный» и «горячий» бэкапы БД, целью было подчеркнуть, что в первом случае (при использовании mysqldump) во время сбора дампа могут наблюдаться проблемы в работе проекта, связанные с блокировками, в то время как во втором случае (xtrabackup) вероятность этого события стремится к нулю, т.е. с точки зрения клиента это сопоставимо с остановкой/непрерывной работой СУБД.
Что касается замечания относительно типа mysql_xtradb — я с Вами соглашусь, в ближайшее время внесем необходимые изменения в наименование типа.
Rclone мы успешно применяем в нашей работе для синхронизации копий в наше собственное облачное хранилище, а что касается restic — то ранее нам не приходилось с ним сталкиваться. Обязательно изучим его возможности и посмотрим какие идеи или наработки можно использовать для нашего инструмента.
Спасибо за информацию!
Здравствуйте!
Я с Вами абсолютно согласен, что в случае использования на проекте системы контроля версий необходимость в бэкапе кода отпадает. Но дело в том, что на нашем обслуживании есть некоторое количество проектов, которые по каким-то причинам не используют VCS и работают с кодом исключительно по ftp/ssh.
Поэтому мы рассматриваем обобщённый вариант, который можно будет адаптировать под конкретный случай.
Добавление поддержки diff-бэкапов в наши ближайшие планы не входит, однако не исключено, что со временем мы займемся реализацией данного функционала.
Сам процесс CI/CD описан в нашем Gitlab, что касается автотестов — то на текущий момент их, действительно, нет и ключевые моменты проверяются пока в ручном режиме. По мере развития проекта будут добавлены и автотесты.
Если честно, то нами не тестировалась работа s3fs внутри docker-контейнера, однако возникновения каких-либо проблем при этом не предполагаем. Если же Вы столкнетесь с какими-либо сложностями — сообщите нам и мы постараемся решить проблему.
Спасибо за Ваш вклад в развитие проекта!
Спасибо за ценное замечание, в ближайшее время дополним документацию по настройке s3. Что касается подключения к пользовательским серверам через s3 REST API интерфейс, то сама утилита s3fs поддерживает такую возможность, однако nxs-backup на текуший момент может работать только с AWS. Поскольку это, действительно, может оказаться полезной фичей — мы реализуем данный функционал в nxs-backup.
На текущий момент отправка почты осуществляется через системный sendmail, который уже можно настроить под свои нужды. В ближайших планах дать возможность рулить настройками почты через nxs-backup.
Да, именно так.
Если Вас имеете в виду, что будет в случае, если во время работы утилиты оборвется связь с удаленным storage, в который должен быть загружен файл, то стоит пояснить следующее — за исключением инкрементных копий файлов бэкап всегда сначала собирается локально во временной директории. Затем, архив поочередно копируется на все удаленные storage, после чего локально перемещается в постоянное место дислокации или удаляется (в зависимости от того, используется ли локальный storage).
Поэтому, если по какой-либо причине во время копирования файла на удаленный storage с ним была потеряна связь, то утилита должна сообщить о проблемах (сделать соответствующую пометку в лог-файле) и приступить к работе со следующим хранилищем, в том числе и локальным.
При ответе на Ваш вопрос мы обнаружили баг в коде, при котором утилита аварийно завершает свою работу, в случае обрыва связи во время передачи файла на какое-либо удаленное хранилище. В ближайшее время этот баг будет устранен, спасибо за интересный вопрос!
Да, пока процесс распаковки архива никак не автоматизирован. Этот функционал будет реализован в следующем релизе.
К сожалению, пока нам не удалось протестировать утилиту на таком объеме данных. Но поскольку как дискретные, так и инкрементные копии хранятся в формате tar, то каких-либо проблем с получением листинга и восстановлением конкретного файла из архива возникнуть не должно. Например, получить листинг файлов в архиве можно командой:
Извлечь конкретный файл из архива:
Спасибо за предложение!
При беглом ознакомлении с документацией уже можно сказать, что данное ПО нам бы не подошло хотя бы потому, что у него нет нативной поддержки бэкапов БД.
Что касается замечания относительно типа mysql_xtradb — я с Вами соглашусь, в ближайшее время внесем необходимые изменения в наименование типа.
Спасибо за ценные замечания!
Спасибо за информацию!
Я с Вами абсолютно согласен, что в случае использования на проекте системы контроля версий необходимость в бэкапе кода отпадает. Но дело в том, что на нашем обслуживании есть некоторое количество проектов, которые по каким-то причинам не используют VCS и работают с кодом исключительно по ftp/ssh.
Поэтому мы рассматриваем обобщённый вариант, который можно будет адаптировать под конкретный случай.