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

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

Время на прочтение 9 мин
Количество просмотров 27K
Всего голосов 30: ↑25 и ↓5 +20
Комментарии 46

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

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

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

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

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

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

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

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

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

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

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


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


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.
Ну в целом да — никто не будет возмещать вам потерянную прибыль и тд, но это не значит, что они не решают технические проблемы с бекапами, которые вы делаете с помощью их продуктов, или не консультируют по архитектуре и тд и тп

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

Для прикола сходил на сервер резервного копирования с 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
Что вы всем этим хотели показать?
Я уже больше 5 лет делаю дома бекапы при помощи Veeam. Как виртуальной инфраструктуры, так и файлового сервера. Ни раз уже восстанавливал данные и не испытывал проблем. Весной, например, сдох диск в файловом сервере, когда то развалился mdadm и тд, иногда ВМкам плохо становится. Так же восстанавливаю без проблем.
Или мы просто объёмами меряемся?
image

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

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


получилось так
> 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

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

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

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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

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


> 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, много приятнее работать

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

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
Так не используйте.

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

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

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

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

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий