В принципе, оно работает:
[root@orca ilyxa]# uname -a && pacman -Q zfs-dkms-git spl-dkms-git
Linux orca 4.4.3-1-ARCH #1 SMP PREEMPT Fri Feb 26 15:09:29 CET 2016 x86_64 GNU/Linux
zfs-dkms-git 0.6.5_r172_g048bb5b-1
spl-dkms-git 0.6.5_r45_g18d2f56-1
При сборке *dkms* есть досадные косячки (собственно, не заработал dkms – пришлось чуточку пригладить напильником). В остальном – ОК.
Продолжаем ранее начатый монолог про простоту ZFS и функционал, который может доставить некоторые проблемы в реальной эксплуатации, короче, очередной занудный пост о пользе снэпшотов и вреде от упрощения администрирования. Правильно делать вот так, мы же сделаем все неправильно! 🙂
…или занудный пост о пользе снэпшотов и вреде от упрощения администрирования…
Дано: Solaris 11, iSCSI target (которые новые уже, с sbd* и it*), том ZFS (создан давно, работает), роздан по iSCSI на Win 2003 (далее в примере – рабочая солярка 11.2 с последними патчами, без данных CU, для быстрой оценки перспектив восстановления, в процессе были получены совсем любопытные результаты).
root@snooky:~# zfs get volsize storarray/test_vol
NAME PROPERTY VALUE SOURCE
storarray/test_vol volsize 512M local
Надо увеличить размер тома. Совсем просто:
root@snooky:~# zfs set volsize=1024K storarray/test_vol
root@snooky:~# zfs get volsize storarray/test_vol
NAME PROPERTY VALUE SOURCE
storarray/test_vol volsize 1M local
Вместо 1024M поставили 1024K.
Тома с данными больше нет.
Возврат значений, прочие игрища ни к чему не приведут – том – потерян, данные подлежат восстановлению с бэкапа.
Есть, правда, один нюанс – мгновенные снимки перед началом проведения любой операции. Работают безотказно, проверено, но, увы, не всегда они есть…
Далее простыня с игрушками, картина с IT + win + NTFS еще более удручающая и намного менее наглядная:
Для начала остановиться и дать команду:
При инсталляции Ops Center возникли довольно жесткие требования к системе, в которую желаем ставиться – в частности по требуемому месту на диске. Ну у нас же Solaris – нам даже не нужно перезагружаться 🙂
Доступна в Solaris 11! Раньше – только в 7000-ой серии.
В продолжении вот этого поста.
Известно, что Veritas NetBackup умеет бэкапить (и восстанавливать) именованные каналы (named pipes, пайп(ы) дальше по тексту). Этим и воспользуемся.
“Горячее” резервное копирование Oracle с использованием мгновенных снимков ZFS и процедура восстановления
Кхм – по-русски не звучит, потому плюнул – написал in english. Вот возникла задачка, вот и сделал для себя шпаргалку, чтобы кругами не “нарезать” по сайтам – я все-таки далек изрядно от Oracle DBA’s – специфика у меня другая, но вот приходиться и подумать иногда на отстраненные темы…
Рекомендовано к прочтению: Backup and Recovery@orafaq.com, масса полезной документации лежит здесь. Ну и Google никто не отменял.
Итак: есть Oracle 10gR2 + Solaris 10 x86_64. Есть БД. Некая. Которая лежит на ZFS – плюсы и минусы такого размещения я не обсуждаю, по крайней мере – здесь. Есть метод фактически прошлого века – Oracle User-Managed Hot Backups. Настоящие джежаи меня заклюют, но я не вижу способа использования RMAN в сочетании с ZFS Snapshot в рамках одной машины (вижу, но об этом – другой раз 😉 ). Надо: сделать копию БД, которая была бы пригодна к однозначному восстановлению.
Далее – много букофф…
В конце октября в Opensolaris была интегрированна интересная возможность – откат группы транзакций из коммандной строки. Почитать можно здесь. Полезно в случае проблем возникновения проблем с оборудованием – “битыми” RAID-контроллерами, например – короче, всякий раз, когда ZFS сталкивается с невозможностью проконтроллировать корректную запись блоков данных на диски. В результате – мы не можем импортировать свой пул, а рекоммендация в такой ситуации была одна – восстановление с бэкапа после приведения в порядок “железа” (ну или вдумчивый – очень вдумчивый!!! – анализ происходящего). Степень “полезности” этой функции я бы поставил чуть ли не выше наличия, например, дедупликации.