Комментарии 20
We need more CRB (cron-rsync-bash) backup scripts!
> На клиентах только стандартное и проверенное поколениями админов ПО.
Почему не та же Bacula, к примеру?
Конечно, есть у неё непрятные недостатки, но много и плюшек — дифферинциальные / инкрементальные бекапы по хэшу, гибкое расписание, SD-SD репликации, шифрование искоробки, более-менее вменяемые контейнеры, и т.д.
Почему не та же Bacula, к примеру?
Конечно, есть у неё непрятные недостатки, но много и плюшек — дифферинциальные / инкрементальные бекапы по хэшу, гибкое расписание, SD-SD репликации, шифрование искоробки, более-менее вменяемые контейнеры, и т.д.
Bacula отлично подходит, если не хотеть, чтобы файлы были «доступны без дополнительных инструментов и оболочек». Мне такого хотелось. Теперь в качестве софта для восстановления данных из бекапов можно использовать привычные grep, find или даже mc.
Благодаря ZFS появился еще один инструмент, способный стать альтернативой традиционным системам резервного копирования. Разумеется, подойдет он не всем. Как минимум, описанный в статье способ не годится в случаях, когда критичен объем передаваемого при бекапе трафика.
Благодаря ZFS появился еще один инструмент, способный стать альтернативой традиционным системам резервного копирования. Разумеется, подойдет он не всем. Как минимум, описанный в статье способ не годится в случаях, когда критичен объем передаваемого при бекапе трафика.
ZFS на mdraid… зачем?
И кстати zfs set compression=lz4 backup или gzip-9.
И кстати zfs set compression=lz4 backup или gzip-9.
Процитирую себя же: «поскольку на этой машине уже есть одно зеркало (для корневого раздела) и оно сделано штатным mdadm, то и для второго зеркала я предпочту использовать его же». Просто для единообразия.
Про lz4 почитал. Пишут, что он значительно лучше, чем используемый по умолчанию LZJB. Обязательно попробую.
Про lz4 почитал. Пишут, что он значительно лучше, чем используемый по умолчанию LZJB. Обязательно попробую.
В качестве бесплатной альтернативы относительно дорогим «энтерпрайз» продуктам для бэкапа вполне интерестное решение. Смущает только одно. Помимо процессов бэкапа и хранения резервных копий, есть еще процессы восстановления из этих бэкапов в случае сбоев. И тут скорость восстановления в пределах даже небольших организаций бывает критична. Простаивать сутки и более бизнес обычно не любит. Ну и кроме того сами сценарии восстановления продумывать и отрабатывать (тестировать) лучше заранее. Что бы понимать «куда бежать? и что делать?» в случае необходимости, а кроме того понимать сколько потребуется времени.
Спасибо за намёк. Вопрос восстановления из бекапа я совсем не рассмотрел. Добавил в статью отдельный пункт об этом.
а зачем эти всякие zfs и пр.?
чем не работает
basepath=/path/to/backup
today=`date +%Y%m%d`
yesterday=`date --date=«yesterday» +%Y%m%d`
monthago=`date --date=«30 day ago» +%Y%m%d`
todaydir=$basepath/$today
yesterdaydir=$basepath/$yesterday
monthagodir=$basepath/$monthago
mkdir -p $todaydir
cp -al $yesterdaydir $todaydir
rsync -a --delete /path/to/files/ $todaydir
rm -rf $monthagodir
а ещё вот это вот место /path/to/backup можно подключить через vfs_shadow2 к ресурсу самбы и народ будет видеть в проводнике винды прошлые версии файла. И ничего не надо там разворачивать для того чтобы что-то найти. И ZFS тут нигде не нужен.
чем не работает
basepath=/path/to/backup
today=`date +%Y%m%d`
yesterday=`date --date=«yesterday» +%Y%m%d`
monthago=`date --date=«30 day ago» +%Y%m%d`
todaydir=$basepath/$today
yesterdaydir=$basepath/$yesterday
monthagodir=$basepath/$monthago
mkdir -p $todaydir
cp -al $yesterdaydir $todaydir
rsync -a --delete /path/to/files/ $todaydir
rm -rf $monthagodir
а ещё вот это вот место /path/to/backup можно подключить через vfs_shadow2 к ресурсу самбы и народ будет видеть в проводнике винды прошлые версии файла. И ничего не надо там разворачивать для того чтобы что-то найти. И ZFS тут нигде не нужен.
Предположим вам надо бэкапить огромную кучу почти идентичных виртуалок, в вашем случае будет огромный оверхед по занимаемому месту, т.к. никакого намека на дедубликацию в этом скрипте нет, во вторых нет инкрементальных и дифф бэкапов, если вам надо бэкапить полтора хоста, то решение годное, если счет давно перевалил за сотню, то приходится искать альтернативы, чтоб не добавлять новую дисковую полку на каждый лишний день бэкапов.
А вы маны то читали по cp и rsync? cp -al создает жесткие ссылки на существующие файлы, сами файлы не копирует. директории создает новые, да, но это мизер. rsync в новую директорию копирует только модифицированные файлы. --delete удаляет жесткие ссылки если файлы были удалены. Где оверхед?
Покажу на примере:
Один из образов виртуальных машин занимает 74G. За день он меняется незначительно (предполагаю, что не более чем на 1G). Но меняется. Семь ежедневных копий этого файла займут 518G. А на хранилище с дедубликацией — всего 80G.
Один из образов виртуальных машин занимает 74G. За день он меняется незначительно (предполагаю, что не более чем на 1G). Но меняется. Семь ежедневных копий этого файла займут 518G. А на хранилище с дедубликацией — всего 80G.
Data deduplication требует конских объемов ОЗУ для своей работы. Это не на любом сервере уместно.
Для виртуалок это не работает, я потому и заострил внимание на виртуалках, ваше решение из мира одиночных серверов, там где облака и кластеры гипервизоров оно не применимо. Маны читал, не считайте заранее незнакомых вам людей идиотами даже не вникнув в суть, а вот вы маны по дедубликации в общем и работе системы ZFS в частности читали?
В ZFS тоже ничего не надо разворачивать, зашел в /.zfs/snapshots и все тут как тут.
Надо примонтировать? Клонируем и монтируем.
Надо примонтировать? Клонируем и монтируем.
Это не Вы рассказывали на одном из SPbLUG-ов о своем опыте использования ZFS под Linux где-то год-полтора назад? Кажется тогда речь шла о том, что был убит целый год, опробовано куча вариантов, но ни один так и не оказался годным для промышленного применения? Неужели он теперь нормально работает под Linux? И вообще — зачем он там нужен когда есть нативный btrfs? Хотете ZFS — используйте те ОС, где он работает нативно.
Нет, не я рассказывал.
Для моей задачи ZFS оказалась вполне годной. Даже на Linux.
Для моей задачи ZFS оказалась вполне годной. Даже на Linux.
Если в кратце, то человек там перепробовал все возможные способы использования ZFS под Linux. Пробовал даже такие шутки, как openindiana. Но были проблемы, в т.ч. серьезные.
А вообще при использовании ZFS нужно иметь в виду следующее:
Data deduplication требует примерно 5Gb RAM на каждый Тб данных. Память должна обязательно быть с ЕСС. ZFS должен иметь полный доступ к диску, т.е. диски должны быть подключены через HBA (это важно!), а не через RAID контроллер. Крайне желательно наличие UPS т.к. при потери питания весь пул может разрушится. Данные при этом восстановить будет невозможно. Так же надо понимать, что в случае kernel panic или подобной ситуации вы так же можете потерять все данные на ZFS. По этому разумно будет кроме ZFS не гонять ни каких служб на машине.
Самый простой способ получить все плюшки ZFS — это поставить FreeNAS или его аналог. Его настройка не сложнее настройки обыкновенного SOHO роутера вроде dlink. У меня под наблюдением есть сервак на FreeNAS где установлены 8 дисков по 4Тб, 32Гб ОЗУ, 4 сетевухи и Xeon не помню какой. Все это хозяйство работает файлсервером в обычном понимании этого слова, а так же хранит днные от кластера виртуализации. Отлично работает уже более полугода в такой связке.
Так же настоятельно рекомендую ознакомится вот с этой презентацией forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/
Там подробно разъясняют терминологию ZFS, как надо строить пулы и как не надо и почему.
А вообще при использовании ZFS нужно иметь в виду следующее:
Data deduplication требует примерно 5Gb RAM на каждый Тб данных. Память должна обязательно быть с ЕСС. ZFS должен иметь полный доступ к диску, т.е. диски должны быть подключены через HBA (это важно!), а не через RAID контроллер. Крайне желательно наличие UPS т.к. при потери питания весь пул может разрушится. Данные при этом восстановить будет невозможно. Так же надо понимать, что в случае kernel panic или подобной ситуации вы так же можете потерять все данные на ZFS. По этому разумно будет кроме ZFS не гонять ни каких служб на машине.
Самый простой способ получить все плюшки ZFS — это поставить FreeNAS или его аналог. Его настройка не сложнее настройки обыкновенного SOHO роутера вроде dlink. У меня под наблюдением есть сервак на FreeNAS где установлены 8 дисков по 4Тб, 32Гб ОЗУ, 4 сетевухи и Xeon не помню какой. Все это хозяйство работает файлсервером в обычном понимании этого слова, а так же хранит днные от кластера виртуализации. Отлично работает уже более полугода в такой связке.
Так же настоятельно рекомендую ознакомится вот с этой презентацией forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/
Там подробно разъясняют терминологию ZFS, как надо строить пулы и как не надо и почему.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация backup-сервера. Linux, ZFS и rsync