LINUX.ORG.RU

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


0

0

По заявлению Sun Microsystems технологии ZFS (Zettabyte File System) и Janus (Linux Application Environment) появятся в Solaris 10 не раньше 2006 года.

Для бета тестирования ZFS будет доступна в рамках программы Solaris Express в конце 2005 года.

Janus - возможность работы Linux приложений в среде Solaris 10. Окружение будет соответствовать спецификации Linux Standard Base. Разработчики гарантируют 100 процентную совместимость с Red Hat Enterprise Linux.

Достоинствами ZFS является:

* Контроль целостности данных путем хранения и сверки контрольных сумм
* Непревзойденная масштабируемость, является 128-битной файловой системой, динамически выбираемый размер блока
* Использование модели транзакций
* Возможность создания "снапшота" файловой системы
* Контроль целостности ФС через применение 64-битных контрольных сумм
* Легкость расширения ФС на новые диски (единый "storage pool") и динамическое распределение нагрузки, через интеллектуальное разнесение данных по дискам

взято c opennet.ru

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от baka-kun

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

anonymous
()
Ответ на: комментарий от no-dashi

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

ivlad ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

ivlad ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от ivlad

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от ivlad

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

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

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

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

ivlad ★★★★★
()
Ответ на: комментарий от no-dashi

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

Krause
()
Ответ на: комментарий от no-dashi

2no-dashi:

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

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

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

Korwin ★★★
()
Ответ на: комментарий от Korwin

2Korwin:

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

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от ivlad

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

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

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

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

3. сделал end backup

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

2oxonian:

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от ivlad

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

2no-dashi:

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

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

Led ★★★☆☆
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

ivlad ★★★★★
()
Ответ на: комментарий от Led

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

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

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

Zulu ★★☆☆
()
Ответ на: комментарий от no-dashi

>> А создание снимка 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

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

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

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

baka-kun ★★★★★
()
Ответ на: комментарий от Zulu

2Zulu:

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от baka-kun

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от Led

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

Zulu ★★☆☆
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

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

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

2no-dashi:

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

Led ★★★☆☆
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

To: no-dashi

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

2 no-dashi:

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

anonymous
()
Ответ на: комментарий от anonymous

2anonymous:

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

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

anonymous
()
Ответ на: комментарий от anonymous

2anonymous:

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

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от anonymous

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

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

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

no-dashi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.