company_banner

Резервное копирование, часть 6: Сравнение средств резервного копирования


    В данной статье будет проведено сравнение средств резервного копирования, но сначала стоит узнать, как они быстро и хорошо справляются с восстановлением данных из резервных копий.
    Для простоты сравнения будет рассматриваться восстановление из полной резервной копии, тем более что данный режим работы поддерживают все кандидаты. Для простоты цифры взяты уже усредненными (среднее арифметическое из нескольких запусков). Результаты будут сведены в таблицу, в которой также будет информация и о возможностях: наличие веб-интерфейса, простота в настройке и работе, способность к автоматизации, наличие различных дополнительных возможностей (к примеру, проверка целостности данных) и т.п. Графики будут показывать загрузку сервера, где данные и будут применяться (не сервера для хранения резервных копий).

    Восстановление данных


    В качестве опорной точки будут использоваться rsync и tar, поскольку именно на них обычно основаны простейшие скрипты для снятия резервных копий.

    Rsync справился с тестовым набором данных за 4 минуты и 28 секунд, показав

    такую нагрузку


    Процесс восстановления уперся в ограничение дисковой подсистемы сервера хранения резервных копий (пилообразные графики). Также четко видно загрузку одного ядра без особых проблем (низкий iowait и softirq — нет проблем с диском и сетью соответственно). Поскольку две другие программы, а именно rdiff-backup и rsnapshot, основаны на rsync, а также предлагают в качестве средства восстановления обычный rsync, — у них будет примерно такой же профиль нагрузки и время восстановления резервной копии.

    Tar справился чуть быстрее, за

    2 минуты и 43 секунды:


    Полная загрузка системы была выше в среднем на 20% из-за возросшего softirq — возросли накладные расходы при работе сетевой подсистемы.

    Если архив дополнительно сжать, то время восстановления возрастает до 3 минут 19 секунд с
    такой нагрузкой на основном сервере (распаковка на стороне основного сервера):


    Процесс распаковки занимает оба процессорных ядра, поскольку работает два процесса. В целом — ожидаемый результат. Также сравнимый результат (3 минуты и 20 секунд) получился при запуске gzip на стороне сервера с резервными копиями, профиль нагрузки на основном сервере был весьма похожим на запуск tar без компрессора gzip (см. предыдущий график).

    В rdiff-backup можно синхронизировать последнюю сделанную резервную копию с помощью обычного rsync (результаты будут аналогичными), но более старые резервные копии все равно надо восстанавливать с помощью программы rdiff-backup, которая справилась с восстановлением за 17 минут и 17 секунд, показав

    такую нагрузку:


    Возможно так и было задумано, во всяком случае для ограничения скорости авторы предлагают такое решение. Сам процесс восстановление резервной копии занимает чуть меньше половины одного ядра, с пропорционально сравнимой производительностью (т.е. в 2-5 раз медленнее) по диску и сети с rsync.

    Rsnapshot для восстановления предлагает использовать обычный rsync, поэтому его результаты будут аналогичными. В целом, так оно и получилось.

    Burp с задачей восстановления резервной копии справился за 7 минут и 2 секунды с
    такой нагрузкой:


    Отработал достаточно быстро, и, по крайней мере, гораздо удобнее чистого rsync: не надо помнить какие-либо флаги, простой и интуитивный cli-интерфейс, встроенная поддержка нескольких копий, — правда раза в два медленнее. Если данные надо восстанавливать из последней сделанной резервной копии — можно воспользоваться rsync, с небольшими оговорками.

    Примерно такую же скорость и нагрузку показала программа BackupPC при включении режима передачи rsync, развернув резервную копию за

    7 минут и 42 секунды:


    А вот в режиме передачи данных с tar BackupPC справился медленнее: за 12 минут и 15 секунд, нагрузка по процессору при этом была в целом ниже

    в полтора раза:


    Duplicity без шифрования показал чуть лучшие результаты, справившись с восстановлением резервной копии за 10 минут и 58 секунд. Если активировать шифрование с помощью gpg — время восстановления возрастает до 15 минут и 3 секунд. Также при создании репозитория для хранения копий можно указать размер архива, который будет использован при разбиении потока входящих данных. В целом, на обычных жестких дисках, так же в связи с однопоточным режимом работы, особой разницы нет. Она, возможно, появится при разных размерах блоков, когда используются гибридные хранилища. Нагрузка на основном сервере при восстановлении была такой:

    без шифрования


    с шифрованием


    Duplicati показал сравнимую скорость восстановления, справившись за 13 минут и 45 секунд. Еще порядка 5 минут заняла проверка корректности восстановленных данных (суммарно около 19 минут). Нагрузка при этом была

    достаточно высокой:


    Когда шифрование aes активировалось внутренними средствами, время восстановления составило 21 минуту 40 секунд, причем загрузка по процессору была максимальной (оба ядра!) во время восстановления; при проверке данных был активен только один поток, занимающий одно процессорное ядро. Проверка данных после восстановления заняла те же 5 минут (суммарно почти 27 минут).

    Результат


    Чуть быстрее duplicati управился с восстановлением при использовании для шифрования внешней программы gpg, но в целом отличия от предыдущего режима — минимальны. Время работы составило 16 минут 30 секунд, с проверкой данных в 6 минут. Нагрузка была

    такой:


    AMANDA, использующая tar, справилась за 2 минуты 49 секунд, что, в принципе, весьма близко к обычному tar. Нагрузка на систему в принципе

    такая же:


    При восстановлении резервной копии средствами zbackup получились следующие результаты:

    шифрование, сжатие lzma


    Время работы 11 минут и 8 секунд

    шифрование aes, сжатие lzma


    Время работы 14 минут

    шифрование aes, сжатие lzo


    Время работы 6 минут, 19 секунд

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

    BorgBackup в режиме без шифрования справился чуть медленнее tar, за 2 минуты 45 секунд, однако, в отличие от того же tar, появилась возможность дедупликации репозитория. Нагрузка при этом получилась

    следующей:


    Если активировать шифрование на основе blake, то скорость восстановления резервной копии чуть замедляется. Время восстановления в этом режиме 3 минуты 19 секунд, а нагрузка вышла

    такая:


    Шифрование aes работает чуть медленнее, время восстановления 3 минуты 23 секунды, нагрузка особо

    не поменялась:


    Поскольку Borg может работать в многопоточном режиме — загрузка процессора максимальна, при этом при активации дополнительных функций просто растет время работы. По всей видимости, стоит исследовать многопоточность работы аналогично zbackup.

    Restic справился с восстановлением чуть помедленнее, время работы составило 4 минуты 28 секунд. Нагрузка при этом выглядела

    так:


    По всей видимости процесс восстановления работает в несколько потоков, но эффективность не такая высокая, как у BorgBackup, но сравнимо по времени с обычным rsync.

    С помощью UrBackup получилось восстановить данные за 8 минут и 19 секунд, нагрузка при этом была

    такой:


    Все так же видно не сильно высокую нагрузку, даже ниже, чем у tar. Местами всплески, но не более загрузки одного ядра.

    Выбор и обоснование критериев для сравнения


    Как было сказано в одной из предыдущих статей, система резервного копирования должна соответствовать следующим критериям:

    • Простота в работе
    • Универсальность
    • Стабильность
    • Быстрота

    Стоит рассмотреть каждый пункт отдельно более детально.

    Простота работы


    Лучше всего, когда есть одна кнопка «Сделать все хорошо», но если вернуться к реальным программам — удобнее всего будет некоторый привычный и стандартный принцип работы.
    Большинству пользователей, вероятнее всего, будет лучше, если не надо запоминать кучу ключей для cli, настраивать кучу разных, зачастую малопонятных опций через web или tui, настраивать оповещения о неудачной работе. Сюда же относится возможность легко «вписать» решение для резервного копирования в существующую инфраструктуру, а также автоматизация процесса резервного копирования. Тут же возможность установки пакетным менеджером, или в одну–две команды вида «скачать и распаковать». curl ссылка | sudo bash — сложный метод, поскольку надо проверить, что прилетает по ссылке.

    К примеру, из рассмотренных кандидатов простым решением является burp, rdiff-backup и restic, имеющие мнемонически запоминаемые ключи для разных режимов работы. Чуть более сложным — borg и duplicity. Самым сложным была AMANDA. Остальные по простоте использования где-то посередине. В любом случае, если надо больше 30 секунд на чтение руководства пользователя, или надо сходить в Google или другой поисковик, а также пролистать длинную простыню help — решение сложное, так или иначе.

    Часть рассмотренных кандидатов умеют автоматически отправить сообщение по e-mail\jabber, другие же полагаются на настроенные оповещения в системе. При этом чаще всего сложные решения имеют не совсем очевидные настройки оповещений. В любом случае, если программа снятия резервной копии выдаст ненулевой код возврата, который будет правильно понят системным сервисом периодических задач (улетит сообщение системному администратору или сразу в мониторинг) — ситуация простая. А вот если система резервного копирования, работающая не на сервере резервных копий, не может без настройки, очевидным способом сказать о проблеме — сложность уже избыточная. В любом случае выдача предупреждений и других сообщений только в веб-интерфейс и\или в журнал — плохая практика, поскольку чаще всего они будут проигнорированы.

    Что же касается автоматизации — простая программа умеет читать переменные окружения, задающие ее режим работы, либо имеет развитый cli, способный полностью дублировать поведение при работе через веб-интерфейс, к примеру. Сюда же относится возможность поточной работы, наличие возможностей для расширения и т.п.

    Универсальность


    Частично перекликается с предыдущим подразделом в части автоматизации, не должно быть особой проблемой «вписать» процесс резервного копирования в существующую инфраструктуру.
    Стоит отметить, что использование нестандартных портов (ну кроме веб-интерфейса) для работы, реализация шифрования нестандартным способом, обмен данными нестандартным протоколом — признаки неуниверсального решения. По большей части все кандидаты так или иначе их имеют по очевидной причине: простота и универсальность обычно не совместимы. В качестве исключения — burp, есть и другие.

    В качестве признака — возможность работы используя обычный ssh.

    Скорость работы


    Самый противоречивый и спорный пункт. С одной стороны — запустили процесс, он отработал максимально быстро и не мешает основным задачам. С другой — всплеск трафика и нагрузки на процессор на время резервного копирования. Еще стоит отметить, что самые быстрые программы для снятия копий обычно самые бедные по функциям, важным для пользователей. Опять же: если для того, чтобы достать один несчастный текстовый файлик размером несколько десятков байт с паролем, а из-за него стоит весь сервис (да-да, я понимаю, что тут процесс резервного копирования чаще всего не виновен), и надо перечитать последовательно все файлы в репозитории или развернуть целый архив — система резервного копирования ни разу не быстрая. Еще один пункт, который часто становится камнем преткновения — скорость разворачивания резервной копии из архива. Тут явное преимущество у тех, кто может просто скопировать или переместить файлы в нужное место без особых манипуляций (rsync к примеру), но чаще всего проблему надо решать организационным способом, эмпирическим путем: измерять время восстановления резервной копии и открыто об этом сообщать пользователям.

    Стабильность


    Следует понимать так: с одной стороны, должна быть возможность развернуть обратно резервную копию по-любому, с другой — устойчивость к различным проблемам: обрыв сети, отказ диска, удаление части репозитория.

    Сравнение средств резервного копирования


    Время создания копии Время восстановления копии Простая установка Простая настройка Простое использование Простая автоматизация Нужен ли клиент\сервер? Проверка целостности репозитория Разностные копии Работа через pipe Универсальность Самостоятельность Прозрачность репозитория Шифрование Сжатие Дедупликация Web-интерфейс Заливка в облако Поддержка Windows Балл
    Rsync 4m15s 4m28s да нет нет нет да нет нет да нет да да нет нет нет нет нет да 6
    Tar pure 3m12s 2m43s да нет нет нет нет нет да да нет да нет нет нет нет нет нет да 8,5
    gzip 9m37s 3m19s да
    Rdiff-backup 16m26s 17m17s да да да да да нет да нет да нет да нет да да да нет да 11
    Rsnapshot 4m19s 4m28s да да да да нет нет да нет да нет да нет нет да да нет да 12,5
    Burp 11m9s 7m2s да нет да да да да да нет да да нет нет да нет да нет да 10,5
    Duplicity no encryption 16m48s 10m58s да да нет да нет да да нет нет да нет да да нет да нет да 11
    gpg 17m27s 15m3s
    Duplicati no encryption 20m28s 13m45s нет да нет нет нет да да нет нет да нет да да да да да да 11
    aes 29m41s 21m40s
    gpg 26m19s 16m30s
    Zbackup no encryption 40m3s 11m8s да да нет нет нет да да да нет да нет да да да нет нет нет 10
    aes 42m0s 14m1s
    aes+lzo 18m9s 6m19s
    BorgBackup no encryption 4m7s 2m45s да да да да да да да да да да нет да да да да нет да 16
    aes 4m58s 3m23s
    blake2 4m39s 3m19s
    Restic 5m38s 4m28s да да да да нет да да да да да нет да нет да нет да да 15,5
    UrBackup 8m21s 8m19s да да да нет да нет да нет да да нет да да да да нет да 12
    Amanda 9m3s 2m49s да нет нет да да да да нет да да да да да нет да да да 13
    BackupPC rsync 12m22s 7m42s да нет да да да да да нет да нет нет да да нет да нет да 10,5
    tar 12m34s 12m15s

    Легенда таблицы:

    • Зеленый, время работы меньше пяти минут, или ответ «Да» (кроме столбца «Нужен клиент\сервер?»), 1 балл
    • Желтый, время работы пять-десять минут, 0.5 балла
    • Красный, время работы больше десяти минут, или ответ «Нет» (кроме столбца «Нужен клиент\сервер?»), 0 баллов

    Согласно вышеприведенной таблице наиболее простым, быстрым, а вместе с тем удобным и мощным инструментом для резервного копирования является BorgBackup. Второе место занял Restic, остальные рассмотренные кандидаты разместились примерно одинаково с разбросом в один-два балла в конце.

    Благодарю всех, кто дочитали цикл до конца, предлагаю обсудить варианты, предложить свои, если есть. По мере обсуждения таблица может быть дополнена.

    Результатом цикла станет заключительная статья, в которой будет попытка вывести идеальное, быстрое и управляемое средство для резервного копирования, позволяющее в кратчайшие сроки развернуть обратно копию и вместе с тем — иметь удобство и простоту в настройке и сопровождении.

    Анонс


    Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
    Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования
    Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
    Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
    Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
    Резервное копирование: часть по просьбам читателей: обзор AMANDA, UrBackup, BackupPC
    Резервное копирование, часть 6: Сравнение средств резервного копирования
    Резервное копирование, часть 7: Выводы
    Southbridge
    721,13
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией

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

      –1
      Обещали сравнение средств резервного копирования, а получился обзор архиваторов.
        0
        Если Вы дадите четкое определение понятия «архиватор», то можно будет подискутировать.
        А то у меня в голове rsync с zip как-то рядом не сильно уживаются.
          0
          Ну, как минимум, в 2019 году, ИМХО, неплохо бы изучить работу с облачными файловыми хранилищами.
          А то сравнивать с tar который для хранения на плёнках создавался и не имеет даже контрольной суммы для файлов (т.е. по сути вообще не гарантирует достоверного восстановления), как-то не сильно актуально. Восстановление всего бэкапа это хорошо, а удобство и скорость восстановления отдельного файла или каталога (особенно когда хранилище в каком-нибудь dropbox или backblaze)? Или, например, возможность восстановления версии файла на определенное время.

          Долго рассматривал разные варианты. В лидерах тоже оказались Borg и Restic. Но в итоге остановился на Restic, так как из коробки поддерживает Backblaze B2. Хотя конечно расстраивает отсутствие сжатия.
            0
            Спрашивали — отвечаем (tm).
            Облака — это всё прелестно, но если сервер в ЛВС навернулся (совсем-совсем) и новый надо восстановить за час-два, то здесь облака курят.
            Потому что надо восстановить пару сотен гигабайт, а канал в интернеты — обычных для небольшого офиса 10 мегабит.
            Среди меня пока в лидерах rsync с его потрясающей опцией --link-local, что ужасно экономит место для бэкапа, время архивирования и время восстановления.
              0
              А если у Вас серверная сгорела, то что толку от ваших пару сотен гигабайт на соседней полке? Никто же не запрещает держать одновременно несколько копий, локальную и удаленную (даже на нескольких облаках). Просто если удаленную нужно будет настраивать с большими танцами с бубном, то на неё большинство забьёт.

              Да и в этой теме в первую очередь обсуждался бэкап web-сервера (набор тестовых данных Wordpress с MySQL). А для всяких офисов могут быть другие инструменты более актуальны.
              0
              … неплохо бы изучить работу с облачными файловыми хранилищами.

              Облако — это чей-то компьютер. Перед тем, как думать о безопасности своих данных, произнесите себе это раза три.
                0
                Не ну если у Вас личный датацентр, а лучше парочка в разных городах/станах (или Вы бэкапы на соседней полке храните). Тогда да. А так AES спасёт паранойю отца русской демократии.
                  0
                  Дело не в ключах шифрования, а в иллюзии надёжности.
          0
          А можно показатель пальцем — кто реально использует эти вещи в продуктиве, ну хотя бы с сотней небольших VM?
            0

            У нас в компании применяется rdiff-backup, BorgBackup предлагают в Hetzner, zbackup я внедрял примерно пять лет назад на предыдущем месте работы. Знаю еще одного хостера, где применяют zbackup, но там уже перекатываются на restic по результатам этого цикла.

              0
              А можно прям списком? Просто хотелось бы знать — кто юзает опенсорсные решения в энтерпрайзе, без саппорта и гарантий.
                0

                К сожалению более подробного списка я предоставить не могу — не задавался вопросом. Ну а по поводу гарантий и суппорта в энтерпрайзе обычно я видел примерно такую ситуацию (раздел 12.)

                  0
                  Ну вы поработайте с нормальными продуктами СРК и увидите, какой там уровень поддержки.
                    0

                    Список пожалуйста, а еще уточните, как гарантии и суппорт спасут меня от потери данных при любом влиянии человеческого фактора (простейший пример: утерян ключ шифрования, его копии — тоже).

                      0
                      Commvault, Veeam, etc.
                      Что бы исключить влияние человеческого фактора — нужно делать несколько копий данных вот тут почитайте. Но дело в том, что чаще, проблемы с бекапами бывают именно на уровне ПО, нежели человеческого фактора (ну если у вас сотрудники квалифицированы и вы их не гнобите постоянно) :)
                        0

                        Читал, решение весьма простое: сбросим проблему из технической плоскости в организационную, проще говоря — повесим личную ответственность. При таком подходе, мне кажется, нету разницы, какое ПО использовать, с поддержкой и гарантиями за сантиметры денег, или проверенное и обкатанное миллионами с открытым исходным кодом.


                        Также я не хочу быть занудой по поводу нормальных продуктов, но все же:


                        commvault

                        цитата


                        NEITHER COMMVAULT, NOR ANY OF ITS LICENSORS, WILL, UNDER ANY CIRCUMSTANCES, BE LIABLE TO YOU OR ANY OTHER PARTY, FOR COSTS OF PROCUREMENT OF SUBSTITUTE PRODUCTS OR SERVICES, LOST PROFITS, LOSS OF INFORMATION OR DATA OR ANY OTHER SPECIAL, INCIDENTAL, PUNITIVE, INDIRECT OR CONSEQUENTIAL DAMAGES WHATSOEVER OR FOR DEATH, PERSONAL INJURY OR DAMAGE TO PHYSICAL PROPERTY OR ENVIRONMENTAL DAMAGES, REGARDLESS OF THE FORM OF ACTION, EVEN IF COMMVAULT HAS BEEN NOTIFIED OF THE POSSIBILITY OF SUCH DAMAGES AND NOTWITHSTANDING ANY FAILURE OF AN ESSENTIAL PURPOSE OF THIS LIMITED WARRANTY.

                        veeam

                        цитата


                        In no event will Veeam, its affiliates, resellers, or distributors or suppliers be liable for any indirect, special, incidental or consequential damages arising out of the use of or inability to use the Software, including, without limitation, damages for lost profits, loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses, even if advised of the possibility thereof.
                          0
                          Ну в целом да — никто не будет возмещать вам потерянную прибыль и тд, но это не значит, что они не решают технические проблемы с бекапами, которые вы делаете с помощью их продуктов, или не консультируют по архитектуре и тд и тп
                            0

                            Не хочу быть К.О., но все же в случаях с коммерческим ПО чаще всего разговоры по архитектуре, решение проблем и т.п. начинается только после того, как моя учетная запись в местной системе тех. поддержки переходит в статус "я заплатил". Иначе — цитируют документацию раз в трое суток согласно публичной оферте. Не буду показывать пальцем кто так делает, но все же.
                            С открытым и\или свободным ПО другая крайность: надо что-то — сделай сам, patches welcome! Но если использовать достаточно стабильное ПО (= обкатанное многими людьми до меня, карта с расположением граблей и мин уже заботливо помечена флажками разного цвета) — проблем обычно не бывает, документации достаточно, чтобы пользоваться сэкономленными средствами и радоваться.

                          0

                          Для прикола сходил на сервер резервного копирования с zbackup, на котором ежедневно делаются личные резервные копии моего домашнего каталога размером примерно 0.7-7гб (в разное время разные рабочие наборы файлов) вот уже несколько лет, пережив обновление Debian с шестой до десятой версии, а также zbackup с 1.2 (собирал сам из исходников) до 1.4 (любезно опакетили в восьмой версии Debian примерно с 1.3 — обновлялся через dist-upgrade):


                          посмотреть, что же там у него
                          > du -hs zbackup/
                          27G zbackup/
                          > find zbackup/backups/ -type f | wc -l
                          1630
                            0
                            Что вы всем этим хотели показать?
                            Я уже больше 5 лет делаю дома бекапы при помощи Veeam. Как виртуальной инфраструктуры, так и файлового сервера. Ни раз уже восстанавливал данные и не испытывал проблем. Весной, например, сдох диск в файловом сервере, когда то развалился mdadm и тд, иногда ВМкам плохо становится. Так же восстанавливаю без проблем.
                            Или мы просто объёмами меряемся?
                            image
                              0

                              Вы бесплатной версией пользуетесь, или оплатили за поддержку и гарантии?

                                0
                                NFR лицензия, т.к. для различных тестов и т.д. мне нужно чуть больше возможностей, чем есть в Community версии.
                            0

                            Попробовал восстановить:


                            получилось так
                            > zbackup restore /home/zbackup/backups/XXXXXXX --password-file XXXXXX > /home/restore.tar
                            Loading index...
                            Loading index file 31a5e956b96dcbc0138d9f3bcda8163c05b61cf9d15670de...
                            ..... почикал, 545 строчек с разными именами....
                            Loading index file d3918bf0140275d761ae6e4a1d7eef52831d0ae909db9668...
                            Index loaded.
                            Using up to 40 MB of RAM as cache
                            > echo $?
                            0
                            > ls -lah /home/*.tar
                            -rw-r--r-- 1 root root 4,6G окт  9 19:16 /home/restore.tar
                +2

                А Bacula не участвовала в тестах?

                  0

                  Участвовала, сложная в настройке, если кратко.

                    0
                    Да там вроде только сервер, клиент, правила бэкапов настроить, нет?
                      0

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

                  0
                  Для меня бы чуть ли не самыми важными критериями были бы:
                  • поддержка ленточных библиотек, маркировка картриджей, и поддержка резервных копий, хранящихся в другой локации (короче, чтобы можно было часть лент в хранилище увозить)
                  • поддержка консистентного резервного копирования баз данных разными способами
                  • компрессия/дедупликация, в том числе внутри архивов разных форматов, между данными разных серверов/рабочих станций
                    0

                    Мне кажется, что главным критерием должна быть возможность "заморозить" данные на все время пока выполняется бэкап, что бы получить консистентную копию данных в нем. А все остальное вторично и третично. Если у вас при условном двухчасовом бэкапе данные продолжают меняться, то что получится на выходе и можно ли будет с этого восстановиться?
                    Все что описано в этой серии статей годиться похоже разве что для пофайлового копирования домашней шары в некий архив.

                      0

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

                        0
                        В этой статье конкретно как раз описываются системы, которые используют (могут использовать) снапшоты.
                          0

                          Это вы сейчас про rsync и tar? Или про Rsnapshot, который базируется на rsync? Потому что у него в названии есть "snapshot" и пофайловое копирование его разработчики назвали снэпшотами?

                            0

                            Смотря как поставить процесс, можно и с rsync сделать снимки состояния файловой системы.

                              0

                              Посредством самого rsync сильно вряд ли.

                                0

                                Ну как посмотреть:


                                > export LV=store-snap-`date +%s`; export MP=`mktemp -d`;
                                > lvcreate -s -n $LV -L1G  /dev/volume/store
                                > mount $LV $MP; cd $MP
                                > rsync -av * .[^*]* backup@remote.server.com:/store
                                > umount $MP
                                > lvremove $LV

                                но лучше взять тот же burp, много приятнее работать

                                  0

                                  Ну собственно так и посмотреть. Я рад за вас, что вы освоили bash. Но rsync по прежнему всего лишь средство пофайловой синхронизации двух директорий. А в вашем случае еще и файлы и директории, уже отсутствующие в исходнике, останутся на remote server. И придется в итоге с переполнением тома на удаленной стороне разбираться.

                              0
                              Про urbackup, в частности. Ваш юмор по поводу названий утилит можете опустить, поскольку гадание об уровне осведомлённости собеседника заканчивается тогда, когда вы не прочитали статью.
                                0

                                Ок, юмор о названиях опустили. И чем же так уникален по вашему urbackup? Расскажите. Все тем же пофайловым инкрементальным копированием?
                                Меня не напрягает, помимо прочтения статьи, зайти на официальный сайт утилиты и почитать, что пишут про нее разработчики. И как то там не густо с возможностями, за исключением все того же пофайлового копирования. Что в принципе годиться наверно для домашнего использования, но вот в продуктив в нормальной организации такое не поставишь по вполне объективным причинам.

                                  0
                                  Вы спросили, чем отличаются программы, описанные в статье, от голой утилиты, в частности бекапа снапшотов. Я ответил. При чём тут какая-то выдуманная вами уникальность? Где я говорил об уникальности?
                                    0

                                    Ok, где именно я спросил про отличия? Как по мне, описанные программы скорее имеют общее сходство. К сожалению, ни одну из них нельзя использовать в продуктиве.

                                      0
                                      К сожалению, ни одну из них нельзя использовать в продуктиве.

                                      Так не используйте. Разве опыт использования другими от этого изменится?
                                        –1
                                        Так не используйте.

                                        Не беспокойтесь, КЭП, уже сделано!

                        0
                        такой красивый график из графаны?
                          0

                          netdata, но склеивались потом вручную

                          0
                          В списке статей в конце забыли добавить ссылку на: «Резервное копирование, часть по просьбам читателей: Обзор UrBackup, BackupPC, AMANDA»
                          habr.com/ru/company/southbridge/blog/468963
                            0

                            Поправил, спасибо!

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое