В продолжении вот этого поста.
При восстановлении снимка на другой машине через ssh (rsh аналогично) нарвались на проблему с низкой пропускной способностью всего комплекта (zfs send, ssh, zfs receive). Быстрый анализ привел к этой дискуссии.
Проблема хорошо описана здесь – zfs receive имеет характер “пульсирующей” нагрузки (bursty) – приняли блок, чего-то делаем и перевариваем, zfs send в это время фактически простаивает (хотя – оба процесса могут давать пропускную способность много больше – просто у одного не забирают, а другой не принимает данные потоком, “забивая” сеть – получается ситуация, когда все компоненты могут существенно больше, чем есть на деле).
Решение – в том же блоге – описано довольно неплохо – надо буферировать приемо-передачу. Для этих целей создана утилита mbuffer. Небольшое клиент-серверное приложение, создающее буфер заданного объема с заданным размером блока внутри.
Успешно собирается (товарищ подтвердит) на Solaris 10, можно и пакеты поставить готовые.
Использование:
# принимаем поток
[root@server2]# mbuffer -s 128k -m 1G -I 9090 | zfs receive datapool/fs1
# отправляем поток
[root@server1]# zfs send datapool/fs1@pipesnap | mbuffer -s 128k -m 1G -O 10.0.0.1:9090
На мой вкус – чистый профит – выигрываем почти 10х приростом производительности!
К сожалению, эти механизмы как-то странно обходят собственно в Solaris 10/11 (по крайней мере – очевидного решения я не нашел).
PS: http://truewaytags.blogspot.com/2011/05/zfs.html – а вот и товарищ по несчастью 
Известно, что Veritas NetBackup умеет бэкапить (и восстанавливать) именованные каналы (named pipes, пайп(ы) дальше по тексту). Этим и воспользуемся.
Дано: файловая система ZFS, около 1 Тб в объеме, около 2-х миллионов файлов на ней, небольшого размера – 200-400 Кб. каждый. Для понимания – сделаем ls -la внутри этой директории, подождем. Много – и долго.
Надо: изготовить резервную копию этой ФС. Обычный бэкап работает очень медленно (tar, bpbackup) – около 12-18 часов на одну ФС, поток в 4-8 Мб/c – неприменимо, лента занята слишком долго одним заданием. Скорость модификации составляет около 800 Мб-1Гб/сутки по предварительной оценке (добавляются новые файлы). Что делает применение обычного файлового бэкапа вообще малореальным. Задачи восстановления единичного файла с ленты – не стоит. Предполагаем, что политики у нас уже настроены…
Делаем:
- создаем снимок ФС (по хорошему – надо перестраховаться и “притормозить” приложение, но – нам известен регламент записи заранее – и потому этого мы делать не будем, занимаясь изготовлением снимка в подходящий момент)
- создаем пайп
- запускаем процесс отправления снимка
- запускаем процесс бэкапа (в нашем случае NB bpbackup)
- ждем окончания процесса
- удаляем пайп
- удаляем снимок
zfs snapshot datapool/fs1@pipesnap
mkfifo /tmp/pipesnapGate
zfs send datapool/fs1@pipesnap > /tmp/pipesnapGate &
bpbackup <ключи NB> -w /tmp/pipesnapGate &
wait
rm /tmp/pipesnapGate
zfs destroy datapool/fs1@pipesnap
Скорость – 50-80 Мб/c – на порядок лучше, чем стандартными средствами. Очевидный минус – из архива проблематично достать единичный файл.
Как всегда – бэкап без восстановления – пустое место. Если надо – нарисую последовательность команд для восстановления. Она такая же простая. Вдумчивое “курение” документов позволит отказаться от запуска скрипта на стороне сервера.
Tags: Backup, bpbackup, NB, NBU, Oracle, Restore, send, snapshot, SUNW, Veritas, ZFS
Собрался отдходить ко сну, все было просто замечательно – почитывал книжечку на досуге, прямо-таки с удовольствием. И тут… горе. iPhone – завис. Намертво. Решил помочь – получил яблоко после включения. И все.
Вот сижу, качаю рестор, делаю кастом-прошивку. Блин. 2 часа ночи. Долбаный кирпич.
Пришлось даже нокию достать старую, чтобы хоть звонки не терять… Благо сегодня вечером сделал синхронизацию, не поленился дождаться окончания бекапа – так что надеюсь на лучший исход.
PS: решил нифига не ставить “левого” из Cydia, бо есть опасения, что причина где-то в “левых” приложениях.
PPS: вчера к 2:30 восстановление было успешно закончено. Чтд.
