Pull to refresh

Comments 10

Введение так себе, давайте сразу 1-ю часть
Кричащий заголовок есть — соответствующего (или хотя бы интересного) содержаний нет
Я бы сказал что BTRFS тоже есть встроенные средства для резервного копирования (send/receive).
Причем там очень правильный подход к инкрементальным снимкам — инкремент средствами самой ФС, а не сторонними утилитами. Кому как не самой файловой системе знать, что там в ней изменилось с последнего бекапа.
Насколько (без)опасно её использовать не на десктопах? А почему редхат её выпиливает из своих дистрибов, если она такая хорошая?
Очень интересует как решается вопрос компрометации резервируемого хоста. В случае запуска указанных программ на источнике ( машине данные которой требуется зарезервировать ) требуется что-бы они имели доступ к машине на которой будут размещаться резервные копии. ( если я правильно помню, то rsnapshot, rdiff, borgbackup требуют наличия ssh ключа, duplicati duplicity restic требуют указания учетных данных для доступа к внешним хранилищам ). Если мы предполагаем что злоумышленник получил доступ на наше оборудование, то он также сможет получить доступ к нашим резервным копиям хранящимся в удаленном месте.
Мы используем borgbackup и «решили» эту проблему используя опцию append-only и ограничив доступ через authorized_keys, это работает, но тоже есть свои особенности.
В этом плане мне больше нравится идея bareos ( бывшая bacula ), где на резервируемый хост ставится агент к которому мы обращаемся.
Добрый день!

Да, все правильно, append-only хранилище в принципе решает вопрос, еще лучше будет такой процесс, при котором сервер для резервного копирования сам ходит по серверам, и «забирает» резервные копии.
В идеальном случае работает принцип «разделяй и властвуй», то есть к примеру сервисы работают где-то в виртуальной машине или контейнере, а уже ВМ\контейнер резервируются средствами хост-сервера.
Only those users with full accounts are able to leave comments. Log in, please.