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

А ты где храниш юзерские MailDir'ы ? У меня лимит 1G на юзера - я это в базу не хочу. А то что IMAP фолдеры держит на том же файл-сервере это даже правильно.

Про шутку - обновления в открытый файл до снапшота не долетят. Но путевые люди все одно tar для бакапа ФС не бзают :)

То: No-dashi - все так. Но скажи мне как проще? А попса победит.

> Но скажи мне как проще?

Проще - это под виндами в ацессе. Те, кто пришел к ораклу на юниксах, уже нуждаются не в "проще", а в "надежней и эффективней", и могут содержать нормального администратора.

2anonymous:

>А ты где храниш юзерские MailDir'ы ?

MailDir'ы для 150000 пользователей? в обыічной ФС? Тогда да, вам только снапшот ВСЕЙ ФС делать:)

>обновления в открытый файл до снапшота не долетят

Ещё раз поподробнее: чем в случае файлопомойки снапшот отдельного файла хуже снапшота всей ФС? По мне так снапшот ТОЛЬКО изменившегося за время между бекапами файлов на несколько порядков удобнее (так как на несколько порядков меньше ресурсов и времени ест при том же результате)

> очень даже интересно. предположим на разделе в 200 Гб у меня занято 180 Гб. я начинаю бэкапить, за время бэкапа пользователи успевают изменить 30Гб данных. 20 Гб из них - понятно - они на том же разделе временно будут сохраняться (типа как inode файла в линуксе не освобождается до тех пор пока есть хоть один процесс его использующий), а 10 Гб где будут храниться на время бэкапа ?

Это всё реализовано в LVM2 на RHEL4. (а также в evms.sourceforge.net)

Просто под этот снимок ты заранее выделяешь отдельный раздел. Если место на нём закончилось (как в твоей ситуации), значит кирдык снимку (как альтернатива возможно блокирование файловой системы, если очень хочется)

> однопроцессорная via epia

a tam i dvuhprocessornaya est' uzhe... Via EPIA DP... 2x Nehemiah, 2x 1GbE... vesh'. Dlia tunnel-servera, VPNskogo :-] na OpenBSD, vde /dev/crypto bystryj...

http://www.viaembedded.com/product/epia_dp_spec.jsp?motherboardId=321

> и какие задачи решают сервера с этими массивами?]

Lenin na nih *.avi hranit dlia domonet'a. Vinty - IDE. On rasskazyval eshe, shto SCSI fufel.

> предположим на разделе в 200 Гб у меня занято 180 Гб. я начинаю бэкапить, за время бэкапа пользователи успевают изменить 30Гб данных
- http://plan9.bell-labs.com/sys/doc/fossil.pdf
- http://cm.bell-labs.com/sys/doc/venti/venti.pdf
- http://cm.bell-labs.com/magic/man2html/4/fossil
- http://cm.bell-labs.com/magic/man2html/8/fossilcons
samo snapshotit, samo backup'it...

a eshe liuboj file arhiviruet do 45 bytes :-) ja ser'ezno, prikol takoj.

прочитай just for fun наконец и здохни чмо. тебе это уже года два говорят минимум.

в свое время ibm и ьелкосовт получили по башке за анонсы "суперкрутых вещей которые будут скоро-скоро"

Ага - они получили но все в шоколаде ... а мы вломили но бошка болит?

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

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

Да... Вот изврат... Посмотри, как сделаны нормальные снепшоты. Например в ufs.

Тем, кто кричит "snapshot'ы не нужны": вы хоть знаете, что это такое? Это снимок состояния fs на определенный момент, причем _непротиворечивого_ состояния. Тут абсолютно пофиг на открытые/закрытые файлы, главное, его можно смонтировать, и получить рабочую fs, которую даже проверять не надо. Можно продолжать работать, как если бы была перезагрузка в момент снимка на синхронной fs.

Чудику, который делает бекапы tar-ом файлов: это только на домашней файлопомойке прокатит, а вот в реальном мире необходимо еще устройства, пайпы, acl-и да расширенные метаданные сохранять. А кто-то еще и без точного сохранения номеров inode обойтись не может. Соответственно и используют dump. Инкрементальный, чтобы не дублировать уже забекапленое.

У тех, кто умеет snapshot, дампить можно и живую систему. Например, читать man dump на предмет ключа -L во FreeBSD. Делается снимок, dump работает с ним, а все остальные ничего и не заметят.

И, наконец, главное: со snapshot легко избежать простоя mission-critical задач, для которых важно обеспечить целостность данных. При бекапе таром или простым дампом необходимо или останавливать задачу на все время создания архива, или на такое же длительное время предотвратить запись данных. А создание снимка fs длится в худшем случае единицы секунд, после чего приложение может снова работать в полную силу. А если приложение сознательно поддерживает непротиворечивое состояние своих данных на файловой системе (не переписывает файлы бездумно "наживую"), то его даже беспокоить не надо, делай себе дамп снепшота.

Медленно и печально...
Нет, не в базе.

zulu@mail:~# pgrep exim | wc -l
742
zulu@mail:~# df -h /var/spool/cyrus | awk '{print $3}'
Used
201G

Тар, да? или в базу эти Maildir'ы?

zulu@www:~$ df -h /var/www | awk '{print $3}'
Used
47G

Юзеры на сайт знакомств аплоадят картинки и видео. Это таром бэкапить, да? Или в базе видео хранить? Кто из нас умом повредился?

Так чем отличается zfs от ext3 ?

> А создание снимка fs длится в худшем случае единицы секунд

Хватит уж гнать, а? Если я откатываю транзакцию с объемом изменений 150 мегабайт, и при этом приложение накатывает данные блоками по несколько десятков килобайт, и в середине процесса какой-нибудь умник "сделает snapshot", то никаким образом целостность данных не будет достигнута - хоть у тебя снапшот, хоть фигшот, хоть супер-пупер-шот: ты все равно получишь файл, в котором данные наполовину новые, наполовину старые.

Единственное, что снапшот позволяет сделать и чем эффективно отличается от tar/dump, так это тем, что с использованием снапшота ты получаешь бэкап полузаписанных файлов на конкретный момент времени, а при использовании tar/dump ты получишь те же полузаписанные файлы с разбросом времени изменения повсему временному интервалу, когда выполнялся бэкап.

С учетом того, что большинство бэкапов больших объемов таки инкрементальные, а специфические ситуации, когда нужно заморозить одномоментно все файлы достаточно редки (только всякие СУБД, но в них данные на ФС давно не хранятся, и у них есть свои системы бэкапирования, учитывающие описанные выше нюансы), в реальной жизни снапшот - это красиво расставленные "пальцЫ". Иногда он полезен, но называть его панацеей от всех бед и жизненно необходимой фичей я бы поостерегся.

>>>>> Хватит уж гнать, а? Если я откатываю транзакцию с объемом изменений 150 мегабайт, и при этом приложение накатывает данные блоками по несколько десятков килобайт, и в середине процесса какой-нибудь умник "сделает snapshot", то никаким образом целостность данных не будет достигнута - хоть у тебя снапшот, хоть фигшот, хоть супер-пупер-шот: ты все равно получишь файл, в котором данные наполовину новые, наполовину старые.

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

> Так чем отличается zfs от ext3 ?

zfs масштабируемая 128битная фс, может на лету менять размер блока

про снапшоты уже говорили

использование модели транзакций

ext3 всего этого не умеет, частично это умеет рейзер4, но он пока еще не в ядре

единственное куда годится ext3 это раздел /boot

> чем "dd if=/dev/device of=file" не снапшот?

Тем, что в результате dd утебя получится неконсистентная копия. И тем, что у тебя будет тратиться в два раза больше места.

> Единственное, что снапшот позволяет сделать и чем эффективно отличается от tar/dump, так это тем, что с использованием снапшота ты получаешь бэкап полузаписанных файлов на конкретный момент времени, а при использовании tar/dump ты получишь те же полузаписанные файлы с разбросом времени изменения повсему временному интервалу, когда выполнялся бэкап.

А подождать, пока файл не закроется или игнорировать открытые по таймауту?

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

ето как, без транзакций?

> а ты думешь рейдовые массивы на 250 с лишним гигов будут форматировать в ext3?

Запросто. Другое дело, если речь идет о терабайтах. ;)

> Прозрачное шифрование, HSM, QOS хотя бы в твоей VXFS есть?

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

> А у тебя каждую минуту снапшоты всей ФС делаются?:)

У меня есть клиент, у которого снапшоты делаются каждые 4 часа.

> это проблема приложения, а не ФС

А мне нафиг не сдалась ФС, мне нужны именно приложения! Или у вас на солярисе весь цикл жизни открытого файлового дескриптора, т.е. открытие-запись-закрытие стал уже атомарным? :-) Если да, то тогда снапшоты действительно рулят... Но почему-то так я в этом очень сомневаюсь.

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

Кстати, надо заметить, что снапшоты были еще в Solaris 8. man fssnap.

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

Весь вопрос - на какое время ты останавливаешь приложение. На 2 секунды, или на два часа.

> либо это приложение необходимо останавливать на указанное время.

Опять же, про Oracle Backup Mode я могу тебе рассказать по известным расценкам. ;)

> А подождать, пока файл не закроется

Гы... Типа мы не в курсе, что даже те же самые MS Word / Excel / PowerPoint в процессе работы удерживают файл открытым все время работы с документом? А работа с документом нередко длится и час, и два, и пять...

> или игнорировать открытые по таймауту?

И выкинуть нах из бэкапа все наиболее часто используемые документы? :-)

> Опять же, про Oracle Backup Mode

Началось... Ты же вроде бы так сильно на умного был похож, и вот теперь так глупо подставляться!

Ведь не хуже меня знаешь, что после alter tablespace ... begin backup датафайлы можно копировать даже простым cp, не связываясь ни с какими снапшотами.

> на какое время ты останавливаешь приложение. На 2 секунды, или на два часа

Нормальное приложение вообще не надо останавливать, оно и без всяких снэпшотов сбэкапится :-)

> Ведь не хуже меня знаешь, что после alter tablespace ... begin backup датафайлы можно копировать даже простым cp, не связываясь ни с какими снапшотами.

... и наблюдать при этом сосучую производительность на insert? Зачем, когда можно обойтись без этого, отдав эти вопросы дисковой системе.

Хотя, справедливости ради, снапшоты на FS тут не помогут - только на дисковых массивах и/или SAN.

В любом случае - очевидно, что снапшоты можно делать на разных уровнях:

... в приложении может быть соотвествующий режим;

... в файловой системе/драйвере - в OS в общем;

... в дисковом массиве/коммутаторе SAN и т.п.

Общее мое ощущение - чем ближе это к железу, тем меньше будет задержек. Поэтому снапшоты в OS будут быстрее, чем работа в backup mode, но, безусловно, медленнее, чем SnapView в CLARiiON или FlashCopy в FASt. ;)

Народ, че вы фигней страдаете? Зачем бэкапить оракл на уровне ФС, когда для этого есть средства самого оракла и еще куча стороннего софта? Этож глупо ИМХО.
Или я че не понимаю? %)

2baka-kun:

>вы хоть знаете, что это такое? Это снимок состояния fs на определенный момент, причем _непротиворечивого_ состояния.

Нахрен нужен "снимок ФС на определённый момент" на файлопомойке?! Почему для файлопомойки недостаточно снимка отделных файлов, причём не всех, а только изменившихся со времени прдидущего снимка?!

>Чудику, который делает бекапы tar-ом файлов: это только на домашней файлопомойке прокатит, а вот в реальном мире необходимо еще устройства, пайпы, acl-и да расширенные метаданные сохранять.

В РЕАЛЬНОМ мире (не дома) файлопомойки с "пайпами, acl-ами, устройствами", да ещё с необходимостью "непротиворечивого состояния" и чтоб ВСЕ бэкапились на определённый момент времени - где ты такое видел? ИМХО это только ленивый недоумок может использовать для бэкапа в таком случае снапшоты ФС...

а tar был приведён для частного случая, для которого его достаточно. Есть ещё cpio и другие средства ИНКРЕМЕНТАЛЬНОГО SMART бэкапа.

2Zulu:

>Тар, да? или в базу эти Maildir'ы?

Да, именно tar, или cpio или даже cp -a. Только сделать это с небольшой обвязкой, чтобы инкрментально бэкапились только изменённый файлы и чтобы было ожидание закрытия файлов, открытых на данный момент на запис (получение письма). И процесс бэкапа может быть не только дискретным, а бесконечным. Сможешь с помощьб ФС-снапшота обеспечить это (и чтоб "недополученных" писем в твоём бэкапе не было?:)

>Юзеры на сайт знакомств аплоадят картинки и видео. Это таром бэкапить, да?

Зачем тебе в бэкапе "недоаплоденные видеофильмы и картинки"??

2no-dashi:

>Единственное, что снапшот позволяет сделать и чем эффективно отличается от tar/dump, так это тем, что с использованием снапшота ты получаешь бэкап полузаписанных файлов на конкретный момент времени

О чём и речь. никто так ни привёл реальный пример такой необходимости: всё файлопомойки да MailDir'ы...:)

>> ... что с использованием снапшота ты получаешь бэкап полузаписанных файлов на конкретный момент времени
> О чём и речь. никто так ни привёл реальный пример такой необходимости: всё файлопомойки да MailDir'ы...:)

Элементарно. Валится в файл (открытый естественно) данные с какого-либо датчика. В файл, не в БД. В БД он попадает после послед. обработки.

Файл открытым может находиться долгое время, и эта фича снапфота ИМХО как-раз выручает.

2Korwin:

ок, пусть ваш файл - file.dat

параллельно запущенный

cat file.dat > /mnt/backup/file.dat

в этом случае не выручает?:)

> Зачем, когда можно обойтись без этого, отдав эти вопросы дисковой системе.

Гипотетическая ситуация:

1. ты сделал .. begin backup

2. активизировал снапшот

3. сделал end backup

4. начал бэкапиться со снапшота

И тут по некоторым причинам место под снапшот... Кончилось!

Дальше идут варианты развития событий - или у тебя встает база (неприятно, причем очень), или ты вбрасываешь измененные данные на реальный на реальный раздел, и получаешь инконсистентный бэкап. Упс?

> Гипотетическая ситуация:

гипотетическая ситуация - у ты пролил чай на материнку работающему серверу. Что станет с базой? ;)

К чему это я? К тому, что гипотетических ситуаций много, а тормоза, когда бекапится база весьма реальны.

2oxonian:

>гипотетическая ситуация - у ты пролил чай на материнку работающему серверу.

Ну так давайте реальные рабочие ситуации!:)

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

> гипотетическая ситуация - у ты пролил чай на материнку работающему серверу

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

> а тормоза, когда бекапится база весьма реальны.

Купи ленточник побыстрее, или бэкапь на раздел на носителе на другом контроллере. Да и вообще, о какой "производительности" может идти речь, если ты хранишь чанки на файловой системе (мы ведь раговариваем о снапшоте файловой системы, если ты не забыл)???

2no-dashi:

>сервера находятся в специальном помещении без чайников и без стационарных столов

Естественно, особенно если мы говорим о серъёзных серверах (Solaris на несереёзные врядли задействуешь, а разговор вроде был про Solaris?):)

> Купи ленточник побыстрее, или бэкапь на раздел на носителе на другом контроллере.

А причем тут ленточник? Работа с таблицей, находящейся в backup mode медленне, чем с той же таблицей в обычном режиме.

> Да и вообще, о какой "производительности" может идти речь, если ты хранишь чанки на файловой системе (мы ведь раговариваем о снапшоте файловой системы, если ты не забыл)???

Ну, по словам инжинеров Sun, сейчас уже нет особой разницы, где хранить базу.

Кроме того, снапшот может делаться на устройстве. Как именно это будет сделано в ZFS, которая якобы будет сочетать в себе FS и LVM, сказать пока нельзя.

> Как именно это будет сделано в ZFS, которая якобы будет сочетать в себе FS и LVM, сказать пока нельзя.

А в Linux уже можно. Берешь раздел LVM2, на него наливаешь XFS, начинаешь работать, затем делаешь заморозку XFS, средствами LVM строишь снапшот, размораживаешь XFS и продолжаешь работать.

Тебе это может не понравиться только одним - это под Linux и уже работает, а в Solaris это еще "будет", и не раньше, чем через год :-)

> Тебе это может не понравиться только одним - это под Linux и уже работает, а в Solaris это еще "будет", и не раньше, чем через год :-)

В Solaris, как я уже заметил, fssnap был еще в версии 8.

Почему мне может не понравиться, что что-то хорошее есть в Linux? Это замечательно. Заметь, я сказал только, что не знаю, как это будет сделано в ZFS.

Вот за что люблю ЛОР, так это за концентрацию профессионалов.

и подпись:
Линивый ламер с 150000 пользователей, знающий систему только по рекламным лозунгам, откуда и узнал про снапшоты.

PS. просто плАчу 8)))))))

>> А создание снимка fs длится в худшем случае единицы секунд

> Хватит уж гнать, а?

# df -i /mnt
Filesystem  1K-blocks     Used   Avail Capacity iused   ifree %iused  Mounted on
/dev/ad2s1f  51466566 43232452 4116790    91%  314065 6351149    5%   /mnt

# time mksnap_ffs /mnt snap1
0.000u 0.597s 0:18.61 2.0%      5+228k 1+4792io 0pf+0w

# ls -l snap1
-r--r-----  1 root  operator  54417426688 May 14 16:27 snap1

# df /mnt
Filesystem  1K-blocks     Used   Avail Capacity  Mounted on
/dev/ad2s1f  51466566 43263028 4086214    91%    /mnt

# time rm -f snap1
0.000u 0.103s 0:05.44 1.8%      20+224k 0+1622io 0pf+0w

Это IDE, на котором я параллельно создал загрузку двумя `tar c` и
двумя `tar x`. Поэтому, кстати, и удалялся снимок так долго -- почти
шесть секунд! На SCSI RAID (прокся с десятком тысяч клиентов)
заметить создание снимка надо еще успеть:

# dmesg
...
amr0: <LSILogic MegaRAID SCSI 320-2X> Firmware 413Y, BIOS H420, 128MB RAM
...
amrd1: <LSILogic MegaRAID logical drive> on amr0
amrd1: 69998MB (143355904 sectors) RAID 1 (optimal)
...

# time mksnap_ffs /cache snap1
0.000u 0.181s 0:01.40 8.6%      9+203k 88+6744io 1pf+0w
# time rm -f snap1
0.000u 0.012s 0:00.23 12.1%     15+165k 0+2188io 0pf+0w


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

Не совсем верно. Ты получаешь снимок _fs_ в непротиворечивом состоянии на момент времени. Содержимое файлов -- не дело fs.

> Если я откатываю транзакцию с объемом изменений 150 мегабайт, и
> при этом приложение накатывает данные блоками по несколько
> десятков килобайт, и в середине процесса какой-нибудь умник
> "сделает snapshot", то никаким образом целостность данных не будет
> достигнута - хоть у тебя снапшот, хоть фигшот, хоть
> супер-пупер-шот: ты все равно получишь файл, в котором данные
> наполовину новые, наполовину старые.

Перечитай, на что отвечаешь. ;) Snapshot не имеет никакого отношения
к целостности данных приложений, только FS. Данные приложений --
целиком их собственная забота, что при tar, что при dump, что при
snapshot. Специально для тебя повторю: snapshot позволяет
значительно (на порядки) сократить время простоя или ограничения
функциональности приложений. Вместо того, чтобы останавливать работу
на время копирования/архивирования файлов данных (или вместо того,
чтобы резко ограничивать производительность на примере того же
оракла), достаточно приостановить на время создания снимка fs. Потом
ты можешь спокойно дампить. Или просто подмонтировать снимок и
банально тарить файлы. Ответь сам, что быстрее: снимок (см. выше)
или копирование пусть даже полугигового файла?

> большинство бэкапов больших объемов таки инкрементальные

например dump

> а специфические ситуации, когда нужно заморозить одномоментно все
> файлы достаточно редки

путаешь причину со следствием, ну да это неважно.

> в реальной жизни снапшот - это красиво расставленные "пальцЫ".

В реальной жизни -- удобный инструмент. Не хочешь, не пользуйся.
Хочешь, получай преимущества.

> Нахрен нужен "снимок ФС на определённый момент" на файлопомойке?!

Реальный мир файлопомойками не начинается и ими не заканчивается. А ты просто так и не понял, что такое snapshot.

> Есть ещё cpio и другие средства ИНКРЕМЕНТАЛЬНОГО SMART бэкапа.

dump -- инкрементальный бекап.

2baka-kun:

>Реальный мир файлопомойками не начинается и ими не заканчивается.

Про снапшот ФС на файлопомойке не я придумал, а, кажется, Zulu.

Здесь так и не привели пример, когда без ФС-снапшота не обойтись - приведите хоть один. А то "есть крутые задачи... мир не заканчивается..." Ну так приведите пример такой задачи, где только снапшой ФС решает или решает (а не вроде будет решать с 2006 году) с меньшими затратами ресурсов без потери гибкости.

Пришло в голову, что надо уточнить: файл снепшота создается на той fs, которую "снимаем", т.е. `ls -l snap1` для /mnt читать как `ls -l /mnt/.snap/snap1`.

2Zulu:

>и подпись: Линивый ламер

Детсадовский приём ведения спора, когда понимаешь, что облажался - сказать "сам дурак!"?:) А ещё можно без слов сразу "в дыню"... "шоб знал!"?:)))

Стань в угол и не нарушай дисциплину в группе, Zulu:)