Comments 5
Все бы хорошо, НО. У некоторых серверов(например FTP) есть свойство отдавать локальное время, которое может быть например UTC -8. Так что на time.After я бы не полагался в вопросах удаления устаревших файлов. Рискуете удалить лишнее. Кроме того время на удаленном сервере может просто "слететь"(часто бывает когда удаленный сервер под windows в виртуалке на KVM c неправильно созданным конфигом). Время так же может слететь и на машине проводящей архивацию. ИМХО наши друзья юниксоиды часто сталкивались с этим потому ротация архивов часто по номерам файлов. Еще можно записывать дату в имя файла. Но лучше бы в UTC, чтобы не иметь "граблей" с изменениями во временных зонах. А еще процесс архивации и отправки гигабайтов данных по времени может сильно затянуться, так что время создания файла на удаленном сервере будет иметь мало общего с временем создания бэкапа. Удаление бэкапов вещь ответственная.
Очень интересно насколько быстрее будет повторный запуск restic с измененными файлами чем в первый раз, все системы бекапов которые могут в дедупликацию и/или бекап только измененных данных, последующие запуски бекапов выполняется гораздо быстрее.
Еще бы сравнить сколько займет определенное количество бекапов места на диске.
То есть сравнивать запуская один раз не совсем корректно.
зы Еще бы версию restic указали какую тестировали
Тестировали restic версии 0.12.1.
По поводу повторного запуска и скорости его работы.
Всё зависит от количества изменённых фалов и объёма изменений, но в целом скорость уменьшается не глобально, как минимум потому, что требуется перебрать все файлы. Время в таблице приведено усреднённое после нескольких запусков, первый запуск выполнялся дольше.
По поводу объёма итоговых данных.
Если сравнивать инкрементный бэкап tar и слой/коммит созданный restic, то restic сильно проигрывает. В нашем случае после первого запуска бэкап tar получался порядка 250Мб, у рестик объём полученного каталога сотавил чуть больше 2Гб. Прирост инкремента будет зависеть от объёма данных.
Если рассматривать restic как инструмент используемый исключительно для копий файлов, то, безусловно он отлично справляется со своей задачей. Он реализует классный подход к хранению и, что действительно круто, даёт очень простой способ восстановить файловые данные на нужную дату вообще не напрягаясь.
В нашем случае есть определённые требования, под которые restic, к сожалению, не подходит. Это, в частности, создание копий БД. Отчасти это можно обойти, передавая поток данных в stdin, но это существенно осложняет процесс настройки регулярных бэкапов и, что важнее, восстановления из таких копий.
Резюмируя, сам по себе инструмент интересный и перспективный, но не в наших сценариях работы.
Добрый день. Отличный продукт, спасибо большое. Не нашёл куда можно писать для оперативного общения. В телеге канал как будто только по новостям.
Вопрос следующий: из документации не очень понял можно ли сделать централизованный сервер с холодным хранением, на который поставить всего один инстанс вашей чудесной тулзы и который будет ходить по нужным серверам/нодам/подам и оттуда тянуть себе бекапы?
У меня уже очень продолжительное время работает примерно таким образом сервер с rsnapshot под капотом (классная тулза, пользуюсь уже лет 10).
Суть такая:
Есть разведённые по времени кроны, которые дёргают сервера через rsnapshot. Первым шагом в конфиге rsnapshot прописывется кастомный удалённый скрипт, который делает дамп бд через xtrabackup/mariadb-backup/clickhouse-backup/elastic-backup... в локальную папку проекта. Далее rsnapshot инкрементально выкачивает весь проект.
С этим есть определённые сложности, но выгода, на мой взгляд, такова:
Не надо ходить по всем серверам и настраивать что-то везде
Можно сделать запуски конкурентными, и не допустить того, что все разом ломанутся писать в медленный hdd.
Из минусов могу подчеркнуть, что я так и не смог добиться нормального мониторинга всей этой общей массы бэкапов. Вероятнее всего из-за лени). Бывает, что отваливается что-то и об этом узнаешь не своевременно.
Король умер. Да здравствует Nxs-backup v3.0