Как стать автором
Обновить
114
0

Пользователь

Отправить сообщение
Спасибо большое, что поймали. Моя личная редакторская перекомпенсация: уже после вычитки правишь одно и плодишь другое.
Добрый день! Спасибо за предложение, а можно основные тезисы статьей оформить – чтобы всем были доступны, не только участникам группы?
Добрый день! Не то чтобы Bacula плохая, просто настроек столько, что результаты могут сильно отличаться.
Добрый день! Оба нынешних кандидата применяются чаще, чем остальные, к тому же они более «всеядные», поэтому их интересно сравнивать с предыдущими кандидатами. Ну а описание оборудования и его метрики есть в второй статье, к тому же выбран файловый режим работы (методика есть тоже в второй статье), поскольку поблочный режим не всегда удобно применять (не часто изменяемые файлы).
Добрый день! Включим, спасибо!
Добрый день! Тех.поддержка Veeam так и сказала, что «файловый может быть медленным, используйте поблочный режим работы».
Добрый день! Тесты уже сделаны, будет обзор в следующей статье, получилось чуть быстрее, чем Вacula.
Спасибо и Вам! Учтем :) Экспериментируем, так сказать.
Да, Вы правы, локальный каталог и удаленный репо через ssh.
Добрый день! Процесс резервного копирования — часть общего процесса, поэтому настоящие джедаи, для особенно критических с точки зрения доступности сервисов, делают PITR и соблюдают правило 3-2-1. Но эта задача весьма уверенно переходит в разряд с SLA, и если клиента предупредили, что раскатка с резервной копии будет сутки, и клиент согласился — все в порядке.
Добрый день! Сжатие возможно и не актуально на нашем наборе данных (уже пожатые изображения и видео), а вот дедупликация реально решает. И еще — у Borg тоже есть куча бэкэндов, не такая большая, как у restic, но покрывает 90% существующих облаков. Ну, и zbackup можно скрестить с rclone и получить свой кастомный продукт :) Первый проход будет долгим, а дальше все будет достаточно быстро.
Добрый день! Ссылочки добавили, спасибо!

Veeam будет в следующей статье, плюс идет оценка влияния процесса резервного копирования _без_ создания snapshot т.к. данные не изменяются в процессе резервного копирования для простоты и наглядности.
Добрый день! Главный принцип — установка из репозитория, так что подключаем EPEL и ставим через yum install… А если по каким-то причинам нету желания использовать версию из репозитория — наиболее крутые решения собирают свои бинарники статически.
Добрый день! В предыдущей статье он упоминался, но из-за того, что текущая методика тестирования не покрывает и 10% его возможностей — его обзор может быть будет в 6-й части цикла.
Добрый день! Сервер резервного копирования обычно обслуживает несколько клиентов, так что особой разницы может и не быть, добавим график с pigz в ближайшее время.
Что касается тестового набора — давайте подождем ситуацию с borgbackup сотоварищи :)
В шестой части увидим и его тоже :)
Добрый день! Возможно, в 6-й части рассмотрим.
Добрый день!

Да, все правильно, append-only хранилище в принципе решает вопрос, еще лучше будет такой процесс, при котором сервер для резервного копирования сам ходит по серверам, и «забирает» резервные копии.
В идеальном случае работает принцип «разделяй и властвуй», то есть к примеру сервисы работают где-то в виртуальной машине или контейнере, а уже ВМ\контейнер резервируются средствами хост-сервера.
1

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность