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

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

Не совсем понял, какой смысл при наличии снапшотов в BTRFS притягивать LVM, бэкапы которого не отличаются надежностью и дают отличный способ отстрелить себе ноги.

Кстати, BTRFS хоть раз Вас подвела? Не страшно ли ей данные доверять?

Также вопрос по поводу «В качестве хранилища может выступать папка подключенная по NFS или sshfs» — а не нарушаете ли Вы этим основной принцип бэкапа — что бэкап НЕ должен быть доступен для удаления/правки с машины, с которой он выполнился?
Btrfs по заверению разработчиков и отзывам пользователей не совсем стабильна, поэтому полагаться только на снапшоты считаю не слишком разумным. У меня сбоев пока не было. Доверять данные страшновато, поэтому настроил бэкап. :)
По поводу LVM- сначала планировал хранить образы на Btrfs, но в процессе экспатации выяснилась неприятная особенность. KVM плохо совместим с Btrfs, IO ужасный. В интернете пишут, что это особенность внутренней структуры Btrfs. Поэтому используется LVM.
А может просто не использовать btrfs в пользу ext4, например? :) Ведь довольно легко можно подождать еще лет 7-12, когда btrfs-таки допилят до стейбла.
Основной причиной использования Btrfs была ее отличная работа с raid10, работает быстрее mdadm. Ну и плюшки в виде снапшотов, да и посмотреть хотелось, что за зверь.
не нарушаете ли Вы этим основной принцип бэкапа — что бэкап НЕ должен быть доступен для удаления/правки с машины, с которой он выполнился?

Примонтировать по NFS можно например NAS, который не может сам забрать бэкапы. Если есть другая линукс машина, то безусловно лучше забирать бэкапы бэкап-сервером. Но если есть сервер резервного копирования лучше использовать спец продукты (таже bacula).
Если забирать бэкапы бэкап сервером придется выдавать рута от всех машин бэкапу и компрометация бэкапа приведет к небольшой ядерной войне, ибо она будет иметь доступ везде. Да, Bacula вариант, но оно настолько монструозно, что временами становится страшно.
Не обязательно рута, можно делать бекап по крону, а бэкап сервер только забирает файл любым удобным способом.
> Кстати, BTRFS хоть раз Вас подвела? Не страшно ли ей данные доверять?

Использую btrfs на домашнем сервере около 2х лет. Технологии можно сказать на острие атаки — Linux Arch, multi-deviсe btrfs (5 дисков разных эпох и размеров — от 500G до 4T), raid1, snapshots. Все работает как надо. Серьёзных проблем с btrfs не было. Для снапшотов использую тулзу snapper.

Самые важные данные конечно же копирую на дополнительный диск, который хранится на работе.
Под Линукс есть еще ZFS.
И в качестве менеджера бэкапов-снапшотов zfSnap.
Так не проще?
> ### Delete Old Backups ###
find $dpath -maxdepth 1 -type d -mtime +$dayexp -exec rm -rf {} \;

Да, спасибо, ваша конструкция выглядит лучше и читается легче.
> можно считать не дни с 1970 года, а часы (костыль, будет еще непонятней за какую дату бэкап).

Сохранять дату кол-вом дней тоже не самый читабельный вариант ;)
Мне кажется, если бекапы делаются не чаще раза в минуту, то достаточно универсальным и читабельным вариантом именования будет
$ date +'%Y%m%d-%H%M'
т.е.
$ FILENAME=backup-`date +'%Y%m%d-%H%M'`.bak
$ echo $FILENAME
backup-20140210-1630.bak
Да, так тоже можно, но нужна будет функция, парсящая дату и вычисляющая сколько прошло дней. Сложнее, а выгода не большая при несложной иерархии архива.
Ну сейчас в приведённых скриптах я не вижу использования данных из имени файла для вычиления сколько дней прошло. find сам вычисляет сколько прошло часов/минут/секунд. А чтобы не зависеть от времени, затраченного на создание/изменение файла, после окончания создания бекапа можно через touch устанавливать ему access/modif -time по его имени. Только тогда копировать/переносить файлы бекапов нужно будет утилитой, сохраняющей эти данные (например rsync), либо добавлять touch по окончании переноса, но это может быть единый механизм, ничего нового придумывать не придётся.

Да и перевести из читабельного варианта дату в timestamp для каких-либо вычислений не сложно. Но опять же, чтобы не делать лишних телодвижений, можно в имени файла хранить и «читабельную» дату и дату в том формате, который упростит эти самые вычисления.

Да и вообще зачем чего-то вычислять в данной ситуации для оперирования файлами? Вывести листинг диры с сортировкой по имени/времени, отрезать нужное кол-во «строк» при помощи head или tail — вот и готов список из определённого кол-ва самых свежих файлов, либо наоборот список из остальных менее свежих файлов.



У каждого свой подход. Но как по мне, то строковый формат даты гораздо удобнее. Если программно он не используется, то здесь даже вопроса не стоит как именовать привязанные к датам файлы. Если же нужно как-то работать с файлами программно, то лучше уж дописать пару строчек в скрипт, но избавить себя от необходимости вычисления даты по хитрому имени в случае просмотра списка файлов-бекапов. Конечно же, это только моё личное мнение :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории