Добрый день! Оба нынешних кандидата применяются чаще, чем остальные, к тому же они более «всеядные», поэтому их интересно сравнивать с предыдущими кандидатами. Ну а описание оборудования и его метрики есть в второй статье, к тому же выбран файловый режим работы (методика есть тоже в второй статье), поскольку поблочный режим не всегда удобно применять (не часто изменяемые файлы).
Добрый день! Процесс резервного копирования — часть общего процесса, поэтому настоящие джедаи, для особенно критических с точки зрения доступности сервисов, делают PITR и соблюдают правило 3-2-1. Но эта задача весьма уверенно переходит в разряд с SLA, и если клиента предупредили, что раскатка с резервной копии будет сутки, и клиент согласился — все в порядке.
Добрый день! Сжатие возможно и не актуально на нашем наборе данных (уже пожатые изображения и видео), а вот дедупликация реально решает. И еще — у Borg тоже есть куча бэкэндов, не такая большая, как у restic, но покрывает 90% существующих облаков. Ну, и zbackup можно скрестить с rclone и получить свой кастомный продукт :) Первый проход будет долгим, а дальше все будет достаточно быстро.
Veeam будет в следующей статье, плюс идет оценка влияния процесса резервного копирования _без_ создания snapshot т.к. данные не изменяются в процессе резервного копирования для простоты и наглядности.
Добрый день! Главный принцип — установка из репозитория, так что подключаем EPEL и ставим через yum install… А если по каким-то причинам нету желания использовать версию из репозитория — наиболее крутые решения собирают свои бинарники статически.
Добрый день! В предыдущей статье он упоминался, но из-за того, что текущая методика тестирования не покрывает и 10% его возможностей — его обзор может быть будет в 6-й части цикла.
Добрый день! Сервер резервного копирования обычно обслуживает несколько клиентов, так что особой разницы может и не быть, добавим график с pigz в ближайшее время.
Да, все правильно, append-only хранилище в принципе решает вопрос, еще лучше будет такой процесс, при котором сервер для резервного копирования сам ходит по серверам, и «забирает» резервные копии.
В идеальном случае работает принцип «разделяй и властвуй», то есть к примеру сервисы работают где-то в виртуальной машине или контейнере, а уже ВМ\контейнер резервируются средствами хост-сервера.
Veeam будет в следующей статье, плюс идет оценка влияния процесса резервного копирования _без_ создания snapshot т.к. данные не изменяются в процессе резервного копирования для простоты и наглядности.
Да, все правильно, append-only хранилище в принципе решает вопрос, еще лучше будет такой процесс, при котором сервер для резервного копирования сам ходит по серверам, и «забирает» резервные копии.
В идеальном случае работает принцип «разделяй и властвуй», то есть к примеру сервисы работают где-то в виртуальной машине или контейнере, а уже ВМ\контейнер резервируются средствами хост-сервера.