Комментарии 30
Я с Вами абсолютно согласен, что в случае использования на проекте системы контроля версий необходимость в бэкапе кода отпадает. Но дело в том, что на нашем обслуживании есть некоторое количество проектов, которые по каким-то причинам не используют VCS и работают с кодом исключительно по ftp/ssh.
Поэтому мы рассматриваем обобщённый вариант, который можно будет адаптировать под конкретный случай.
В списке рассмотренных решений не увидел, поэтому упомяну то что использу: restic, restic/rest-server и rclone.
Restic обеспечивает отличное хранение снапшотами и дедупликацию, удаление лишних снапшотов в соответствии с политикой хранения, проверку целостности данных. Плюс встроенное шифрование и эффективность, позволяющая полностью загрузить дисковую подсистему/сеть.
Rclone же позволяет restic-у бекапиться на облачные файловые хранилища.
Спасибо за информацию!
Да и параметр mysql_xtradb как-то не очень подходит. Так как, есть такой движок таблиц с названием xtradb (в форке MySQL от Percona), и можно подумать, что это только для него. В то время, как в XtraBackup нет буквы «D».
Что касается замечания относительно типа mysql_xtradb — я с Вами соглашусь, в ближайшее время внесем необходимые изменения в наименование типа.
Спасибо за ценные замечания!
Тем более mysqldump именно горячий бэкап, он работает исключительно при работающем сервере, так как, в процессе просто выполняются SQL-запросы. А тормоза с проектом, будут практически в любом случае при бэкапе, так как серверу нужно перелопатить большой объем данных, к тому же еще и сжать их, да и для таблиц MyISAM в любом случае блокировка делается.
Можно назвать logical и physical (или dump/sql и binary/raw). А то без заглядывания в доки никогда бы не догадался, что cold это создание SQL-дампа.
Ну и раз делаете свой репозиторий, возможно неплохо было бы включить в комплект mydumper, чтобы он шёл из коробки.
При беглом ознакомлении с документацией уже можно сказать, что данное ПО нам бы не подошло хотя бы потому, что у него нет нативной поддержки бэкапов БД.
Я так понимаю, это проблема всех решений, кто хранит бэкап в виде снимков.
Как у вашей утилиты обстоят дела с таким кейсом? :)
Сильно сложно проверить существование и восстановить несколько файлов из инкрементального архива?
К сожалению, пока нам не удалось протестировать утилиту на таком объеме данных. Но поскольку как дискретные, так и инкрементные копии хранятся в формате 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 файлы не содержат в себе листинга файлов, и чтобы получить листинг файлов нужно прочитать весь файл. В случае если файл где-то в удаленном хранилище, то его для простого листинга нужно весь скачать, и если речь хотя бы о архиве в сотни мегабайт, то процесс будет весьма не быстрым (не говоря о бэкапах в гигабайты).
В документации отмечено, что пользователю надо самостоятельно настраивать 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?
Да, именно так.
А s3fs в docker ровно работает?
А s3fs в docker ровно работает?
Если честно, то нами не тестировалась работа s3fs внутри docker-контейнера, однако возникновения каких-либо проблем при этом не предполагаем. Если же Вы столкнетесь с какими-либо сложностями — сообщите нам и мы постараемся решить проблему.
Сделал версию с дополнительными настройками для S3 и отправкой через сторонние SMTP сервера github.com/Sovetnikov/nxs-backup
Спасибо за Ваш вклад в развитие проекта!
diff-бэкапы добавить планируете?
Резервное копирование большого количества разнородных web-проектов