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