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