Технологии ZFS и Janus появятся в Solaris 10 только в 2006 году.

> приведите хоть один.

Еще раз перечитай со слов "snapshot позволяет значительно (на порядки) сократить время простоя...". И попытайся понять.

> а не вроде будет решать с 2006 году

Снепшоты существуют уже давно.

2baka-kun:

>Еще раз перечитай со слов "snapshot позволяет значительно (на порядки) сократить время простоя..."

Перечитал. Ещё раз перечитайте "ГДЕ ПРИМЕР", когда "snapshot позволяет значительно (на порядки) сократить время простоя..."?

> Содержимое файлов -- не дело fs.

А в бэкапе наиболее важно как раз СОДЕРЖИМОЕ файлов, не так ли? Соответственно, все данные сложной структутры должны бэкапиться собственными средствами.

Бэкапы же файлопомоек проще делать tar'ом, не получая вообще никакого падения производительности, не считая ресурсов, потребляемых самим tar'ом - тем более что tar может использоваться чуть ли не любым образом.

Впрочем, одно применение снапшоту таки есть - на нем можно безбоязненно пускать debugfs! :-)

>> Просто под этот снимок ты заранее выделяешь отдельный раздел.

> О! Это что, копируются на отдельный раздел все данные? Или только метаданные? А на момент создания снимка замораживается fs? Как долго 
будут копироваться метаданные 1Тб fs? А каким образом fs узнает, что 
занятые на момент снимка иноды трогать нельзя, если перенесли только 
метаданные?

Нет не копируются. Пока chunk LVM не изменён, то при обращении к 
снапшоту происходит чтение данных с реального раздела. Если с момента 
снимка производится запись, то она производится в новый chunk, а 
старый передаётся разделу, выделенному для снимка. Собственно для 
этого и место выделяться должно. Чтобы с одной стороны на снимок не 
тратилось свободное место на реальном разделе, а с другой стороны 
можно было посмотреть сколько места уже использовалось на хранение 
изменённых разделов.

Пример:
lvcreate -s -L500M --name test-snap /dev/system/test 

lvdisplay /dev/system/test-snap

--- Logical volume ---
LV Name                /dev/system/test-snap
VG Name                system
LV Write Access        read only
LV snapshot status     active destination for /dev/system/test
LV Status              available
LV #                   4
# open                 1
LV Size                40 GB
Current LE             2560
Allocated LE           2560
snapshot chunk size    64 KB
Allocated to snapshot  0.01% [64 KB/1020 MB]
Allocated to COW-table 4 MB
Allocation             next free
Read ahead sectors     1024
Block device           58:3

По строке Allocated to snapshot я всегда могу знать сколько ещё места осталось на разделе со снимком и при необходимости могу его увеличить

В ufs лучше?

>HSM в продуктах Veritas есть уже, наверное, лет 10.

Я очень рад. В любом случае утверждать, что для Linux нет аналогов(а в списке "возможностей ZFS" я вообще ничего серьезного не увидел), было исключительно наивно.

Тебе было повторено несколькими людьми несколько доводов, и в ответ услышано "в детский сад"? Ну так иди сам туда. Личность, неспособная к осмыслению услышанных доводов, мне не интересна.
Засим разговор считаю законченным, а сам я буду пользоваться снапшотами на LVM там, где посчитаю нужным. И кто не дурак и понимает, тот их тоже где надо применит.

> А в бэкапе наиболее важно как раз СОДЕРЖИМОЕ файлов, не так ли? Соответственно, все данные сложной структутры должны бэкапиться собственными средствами.

Ты положительно не читаешь оппонента перед ответом. Выхватил фразу и побежал "опровергать" ;) Давай попробует нумеровать утверждения, и ожидать от тебя ответа на каждый пункт.

1. Цитирую себя: "При бекапе таром или простым дампом необходимо или останавливать задачу на все время создания архива, или на такое же длительное время предотвратить запись данных". Согласен?

2. Гипотетическая ситуация: некое приложение ворочает массив данных, скажем, в 10Гб, настало время делать бекап. У тебя в контексте беседы есть два выбора:

а) остановить приложение, скопировать данные в архив (не важно, cp|tar или еще что), возобновить работу; как вариант, сделать копию данных (cp или средствами приложения), возобновить работу, затем неспешно бекапить копию;

б) остановить, сделать снимок fs, запустить, бекапить данные со снимка.

Утверждение: "Вместо того, чтобы останавливать работу на время копирования/архивирования файлов данных (или вместо того, чтобы резко ограничивать производительность на примере того же оракла), достаточно приостановить на время создания снимка fs. Потом ты можешь спокойно дампить. Или просто подмонтировать снимок и банально тарить файлы". Так в каком случае меньше простой: (а) или (б)? Учти, что снимок создается считанные секунды. Менее двух секунд на SCSI RAID в моем случае.

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

> Если с момента снимка производится запись, то она производится в новый chunk, а старый передаётся разделу, выделенному для снимка.

Понятно. Т.е. создание снимка разом удорожает запись минимум в 2-3 раза. И так на каждый последовательный снимок. Ужжась! ;)

> В ufs лучше?

Документ уже слегка устарел, но: http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/m...

В ufs snapshot делается на самой fs. Создаваемый файл содержит список блоков (свободен/занят), и служит еще и для отслеживания изменений fs после снимка: "занят" меняется на "изменен". В результате, пока существует хоть один снимок, блоки данных реально не освобождаются. После удаления снимка "замороженные" им блоки возвращаются. Поэтому, кстати, "место под снепшот" закончиться не может, зато изменение любого (свободен/занят) блока уменьшает свободное место, и может "кончить" место на fs. ;)

Хотя, надо сказать, "кончилось место" -- отговорка. Это говорит только о том, что никто серьезно не подходил к анализу нагрузки сервера перед принятием решения о покупке. В нормальном сервере файловая система редко когда забита даже на две трети. Главная причина -- производительность.

>> Если с момента снимка производится запись, то она производится в новый chunk, а старый передаётся разделу, выделенному для снимка.

> Понятно. Т.е. создание снимка разом удорожает запись минимум в 2-3 раза. И так на каждый последовательный снимок. Ужжась! ;)

Куда? Было:
fs:0010 -> chunk0010
snap:0010 -> chunk0010
...
snapn:0010 -> chunk0010

стало
fs:0010 -> chunk0011
snap:0010 -> chunk0010
...

В норме по времени то же самое, так как размер блока IO равен размеру
chunk'а, а отображение блок->chunk выполняется в LVM всегда (за счёт
чего вообще динамичность разделов обеспечивается). А так в любом
случае ОДНА дисковая операция.

А вот в UFS судя по твоим словам на запись будет две операции дисковой записи:
1. собственно запись (причём также в новый блок)
2. в файле снимка замена одного бита.

> Поэтому, кстати, "место под снепшот" закончиться не может, зато
изменение любого (свободен/занят) блока уменьшает свободное место, и
может "кончить" место на fs. ;)

> Хотя, надо сказать, "кончилось место" -- отговорка. Это говорит
только о том, что никто серьезно не подходил к анализу нагрузки
сервера перед принятием решения о покупке. В нормальном сервере
файловая система редко когда забита даже на две трети. Главная причина
-- производительность.

Проблема будет, если снимков несколько и их не убиваешь сразу после
бэкапа (иногда удобно, чтобы делать восстановление только что
удаленных файлов, держать снимок всегда подключенным). Так вот, если
снимков хотя бы два, то на ufs рискуешь забить диск (или получить мало
свободного места, что тоже не очень хорошо). В LVM в худшем случае
отключится самый старый снимок.

> некое приложение ворочает массив данных, скажем, в 10Гб, настало время делать бекап

onbar, ontape, rman & etc. :-) Поверь, "проседание" там не такое тяжелое - там те же алгоритмы, что и в хваленой zfs: записали блок в журнал, пометили как измененный, когда заканчивается бэкап - журналы "вливаются" в реальные данные. Как видишь, отличие от снапшота соляриса только в последнем шаге, и вследствие этого тормоза там совсем не такие страшные, как рассказывают всякие, не будем в них показывать пальцем. Более того, если будут грабли с бэкапами от этих тулзов, ты позвонишь в поддержку, и тебе скажут что и как делать. В случае со снапшотами тебе скажут "сам дурак". Опять же - бэкапирование штатными средствами обеспечивает (при правильных настройках) в случае сбоя восстановление с точностью до последних нескольки минут - и никакое снапшотанье тебе такой точности не даст.

>Опять же - бэкапирование штатными средствами обеспечивает (при правильных настройках) в случае сбоя восстановление с точностью до последних нескольки минут - и никакое снапшотанье тебе такой точности не даст.

Опять же, инкрементальный бэкап можно поставить в бесконечный цикл на отделное устройство (примонтированное с -o sync, если это не лента) и забыть, вспомнив лишь когда (не дай Бог) случилось что с основным носителем или когда получишь сообщение по e-mail/SMS/IM, что место на backup-носителе заканчивается и его нужно сменить:)

> Опять же, инкрементальный бэкап можно поставить в бесконечный цикл

Инкрементальный бэкап десяти двухгигабайтных файлов, изменяющихся каждые десять минут??? О-о-о... Поручик был больщой затейник :-)

2no-dashi:

Сорри, прощёлкал, что именно о таких файлах идет речь:)

> onbar, ontape, rman & etc. :-)

А кто тебе сказал, что "некое приложение" -- это одна хорошо всем известная DBMS? ;)

> Поверь, "проседание" там не такое тяжелое

Я в курсе, какое у оракла "проседание", те, в которых ты не хочешь пальцем тыкать, думаю, тоже. Есть мнение, подтвержденное экспериментами и на солярке, и на фре, что ФС со снепшотом на ней менее сказывается на производительности, чем online backup. Причем _заметно_ менее.

> бэкапирование штатными средствами обеспечивает ... в случае сбоя восстановление с точностью до последних нескольки минут

От "мелких неприятностей" спасает дисковый массив. Backup нужен на случай крупных: видел, как горит в пожаре "Sun Fire" о 12 камнях? Я видел, незабываемо. ;)

PS. И я тебя _очень_ попрошу ответить на _каждый_ нумерованный пункт в прошлом моем посте.

> видел, как горит в пожаре "Sun Fire" о 12 камнях?

Ты что, тоже в джете работаешь? Или вы выкинули все бабки на 12-ти процессорные саны и солярисы с поддержкой снапшотов, так что денег на АСПТ не хватило? :-)

> Есть мнение, подтвержденное экспериментами и на солярке, и на фре

А еще есть мнение, подтвержденное тестами, что UFS и FFS на солярисе и фре, соответственно, сильно медленнее чем большинство других файловых систем. Поэтому вполне естественно, что проседание этого дела на солярисе и фре действительно может быть значимым :-)

To: no-dashi

1) Дык Orakel'у на любимых тобой rew-dev по барабану что там за FS у OS. А уж то что и сами такие девайсы обычно лежат где нить на EMC Clarion - ты тоже навеное слышал. А уж как здорово там снапшоты сделаны ... вобшем перечитай посты baka-kun'a :)

2) Есть в этом мире лавка занимается мониторингом рекламы на масс медия .... у них стоит чегото дремучее (COBOL ?) и база точти 800Gb. Нанято "миллион китайцев(С)" по всему миру которые эту БД интенсивно обновляют. Ессно 365/7/24 ... Предложи как это бакапить без снапшотов?

> такие девайсы обычно лежат где нить на EMC Clarion - ты тоже навеное слышал. А уж как здорово там снапшоты сделаны ...

Но ведь это не снапшоу файловых систем? Вот и приехали - базы данных все равно бэкапим без снапшотов уровня ФС. Вывод - для современных тяжелых СУБД снапшоты ФС не нужны, а для файлопомоек... Ну если вам ТАК хочется, то пожалуйста - дело хозяйское.

2 no-dashi:

ох и трудный ты :)
Ладно бохЪ с ним, но как насчет позшен нумбер 2 ???

2anonymous:

>Есть в этом мире лавка... ...у них стоит чегото дремучее (COBOL ?) и база точти 800Gb. ...Ессно 365/7/24 ... Предложи как это бакапить без снапшотов?

А как у них изначально бэкапилось? или они используют ФС-снапшоты со времён "чегото дремучего"?:) Т.е. ФС-снапшоты - для приделывания костылей к криво спроектированному софту?:)

Изначально им кроме NA никто не нужен бул :) Ну а теперь глобализация -> весь мир под колпаком. Размер базы вырос взрывообразно. Ну переташили мы их на могучий сунЪ - ожило, а бэкапить вот так стали.
Ну и плюс - имеем теперь "живые снимки" по которым новонаняые жабисты всякие кубы собирают для манагеров ...

PS: Про "кривой софт" ты как то ... по пионерски :) Или "переписать инибЁт!"(С)LOR???

2anonymous:

>Про "кривой софт" ты как то ... по пионерски :) Или "переписать инибЁт!"

А, ну если так, тогда да:) Хотя пример, наверное реальный, но вряд ли типичный:)

А на счёт переписать... Если это софтина в основном представляет собой базу важных данных, то может и о "переписать" стОит задумываться, но это вы уже детали знаете, так что вам виднее:)

Хорошо, если ФС-снапшот решает все проблемы с целостностьб базы - тогда для вас это выход. Уверены, что при восстановлении получите целостную непротиворечивую базу, с которой можно работать? или нужно и состояние клиентов на момент снапшота восстановить?

> Про "кривой софт" ты как то ... по пионерски :) Или "переписать инибЁт!"(С)LOR???

Ну так задумываться о переписывании пораньше надо было, когда "взрывообразность" только началась :-)

А то прямо как в анекдоте - "мы общитывали нашу бухгалтерию в двадцати филиалах на фоксовых програмках, и не видели смысла строить единую систему, и не модифицировали ничего пять лет, но в этом году от нас потребовали сводный баланс уже по пятидесяти филиалам, и сделать его нужно было за три дня, и мы все попали в психушку" :-)