FIBS (FIREBIRD-INTERBASE BACKUP SCHEDULER)

[stoar08]

Знам, че това не е продукт на Unrealsoft, но го намирам за крайно полезен (прави изключително малки архиви понеже ползва вградените функции във firebird, а и ги прави "в ефир" по същата причина). Намерих го докато търсех начин аз да си напиша "такова животно", но ...смятам че има достатъчно опции (например проверк и gzip компресия на базата, до 3 mirror-а за качване на готовия архив, изпълнение на bat-file след приключване на архива и т.н.).

http://www.talatdogan.com/fibs.htm

Надявам се и на вас да ви хареса, колкото на мен

ПС Програмката е OpenSource и май е писана на Delphi, а както не-веднъж съм казвал "Добрите копират, вликите - крадат"

[stoar08]

При база с размер 305 040 KB :

- за около 5 минути winrar постигна файл с големина 42 862 KB
- FIBS без GZip компресия,с проверка на базата, garbage collection, за половината време - 173 741 KB
- FIBS с GZip компресия, с проверка на базата, garbage collection, за малко над 4 минути - 30 571 KB

Опитите се правят на PentiumD 820 с 1 GB RAM, което не е велика машина (вече) , но очаквам на по-слаб сървър/архиватор да се получи и по-голяма разлика.

ПС Winrar няма да може да направи архива "в ефир" и да извърши проверка на базата и garbage collection ...а какво остава за архивиране, когато базата е на linux машина

[stoar08]

И понеже току що ме подсетиха, че все пак е хубаво да можем да разпънем архива - ето най-великия възможен инструмент за firebird бази данни (няма нечовешкото количество екстри на IBExpert, но е значително по-лесен за ползване).
http://intelrullz.data.bg/IBOConsole.rar

След като го стартирате цъквате с десен бутон върху върха на наличното дърво (пише "SERVERS") и давате register. Параметрите са както следва :
Local/Remote server (на тази машина ли е сървърът).
Server name : IP
Protocol : аз лично съм фен на TCP/IP и дори не съм пробвал други ...
Alias name : с какво име да ни излиза в списъка
Description : някакво описание, от което нищо не зависи, и което е трудно да се намери после:)
Username и Password не мисля да ги коментирам .
След като се разпъне дървото регистрирате база по същия начин както сървъра.
File е пълният път до базата, както го вижда сървъра (както и в Aton), или Alias-а, деклариран в Aliases.conf .
Цъквате десен бутон на базата, давате disconnect.
После десен утон на backup на съответното сървърно "клонче" от дървото !!! ->restore :
Alias : File
Filenames : Ако сте на сървъра ще ви излезе прозорец и ще можете да посочите файла от там. На единия ред пишете името на архива(теоритично може и повече, но не съм го пробвал а и не го мисля за нужно). Отново файла трябва да се намира физически на сървъра и се задава по начина, по който той го вижда.
Database :
Server : съвръра, върху който възстановяваме
Alias : Alias name на базата (както сме я регистрирали) по-горе
Опциите поне аз ги слагам както следва :
Page size : 4096 (default)
Overwrite : True (default)
Commit after each table : False (не съм остановил съществена разлика, но все пак като писането в диска е "на куп" май е маалко по-бързо)
Create shadow files : True (default)
Deactivate Indexes : False (default) (в противен случай не се гарантира верността на разпъването ...а и ще трябва Aton да ги активира, което си е излишен source за писане:) )
Validity Conditions : Resotre (default) (не съм сигурен това какво е, но Ignore е лошо нещо:) )
Use all space : False (default)
Verbose output : None (ако дадете screen/file ще получите няколко хиляди реда log, който освен ако няма някакъв проблем ...не е особено необходим).
Натискаме ОК , чакаме (около 2 минути за архива, над който правех теста), ползваме.

Препоръчвам обаче, където сървъра е под windows архиватора да стои на него ...може да копирате архива където искате, но е по-сигурно, че интернет няма да ви изиграе номер при самото архивиране (а ако се архивира от работна станция губите опцията за upload на архива). Разбира се, не пречи да има >1 архивиращи "кашони".

След малко ще опиша повечко и за fibs опциите (rad беше постигнал някакъв архив, но 1 от процесите беше "гръмнал" и при активирането на индексите ми дава грешка - затова е по-добре да не се прави при слаба връзка към сървъра с базата 8) ).

Надявам се да съм бил полезен - ако има въпроси ... uptime ми е повече от повечето компютри в офиса - обаждайте се по icq/mail/gsm .

[stoar08]

А ето какво може да се направи за FIBS-a :
Първо View Preferences :
GBAK директорията посочва местото на GBAK.EXE (което мисля е единственото изискване за нормална работа).
Log директорията си е лог директория ...
Настройките за мейл сървъра ги трия за да не спамя някой несъществуващ мейл сървър или пък да не се получат странни грешки при работа.
OK
File -> New Task
Task name - какво да ни се показва като име на задачата
database : ако е зададено "local connection" - нормален път до базата (при работа на сървъра). Иначе е във формат <ip>:fullpath (пак така, както я вижда сървъра).
Backup DIR е директория на локалния компютър.
Mirror 1/2/3 : Или директория от browse бутона или път от вида ftp://user:password@ftp.server.com/
User и Password са за базата данни.
Backup Time също ми изглежда достатъчно ясно.
Backup options :
По-важните чавки са
Do not perform garbage collection - Изключва проверка за "боклуци" в базата. Би ускорило, но при по-продължително ползване на базата би складирало ненужни неща.
Ignore checksum Error - игнорира грешки ...това не го обичам.
Only Backup Metadata - архивира САМО скелета на базата (без информация вътре).

Всички чавки в това заграждение ги оставям изключени.

Create GZip Backup - архивиране на получения GBK файл.
Comprresion level - "колкото повече, толкова повече".

Preserver Last * <>;
* - някакво число.
Backups - числото да означава брой архиви.
Hour`s backups - числото да означава архивите от последните * часа
Day`s backups - -||-||- * дни
Month`s backups - -||-||- * месеца
Delete All Out Of Criteria Backups - изтриване на всички архиви по-стари от посоченото по-горе.

Validate Database Before Backup - проверка на състоянието на базата преди архивиране. При по-сериозни бази е възможно да се усети леко забавяне в този момент.

Other Options :
Send Email Notification if Any Error Occurs - праща мейл на посочения адрес, ако се случи грешка.
External file to ... - изпълнение на файл след успешно архивиране.
Use the last ... - нямам идея къде се ползва параметъра
Show Window - Показва съобщение при успешно изпълнение.

Избираме вече направената задача от списъка (ако имаме други) и даваме file->activate.

И това е то ... надявам се на никой да не му се налага да стига до IBOConsole, но .... дори и ако ви трябва база е по-удобно да има отворена секция на сървъра за всички клиенти и при качване на втори архив (или по друг критерии) и да се поддържа по 1 актуална база на всички . Пък и дори и по usb - такава компресия трудно ще направите по друг начин .

[mIRCata]

Пробвай върху тестовата ти база следното:

Първо я направи с 8 или 16К размер на страница.

Backup с gbak, и после върху новия файл пусни един Winrar с най-добра компресия и кажи какви са резултатите.
След това разархивирай и отново с gbak възстанови базата като запазиш рамера на страниците 8 или 16 (каквото си избрал за тествне).
И кажи кое се е справило по-добре.

[stoar08]

Инструмента борави с GBAK => тестовете вече съм направил. Явно е, че WinRar се справя по-зле ( а и както споменах, не може да направи OnAir - Backup), но все пак ако някой ми даде 1 по-огромна база на Aton ще мога да кажа дали и с нея положението е същото.
Колкото до тестовия BackUP от Rad - разпъвам при 4096 размер на страница (винаги толкова големи ги правя ), но се получава грешка при единия Foreign Key, което предполагам идва от незавършения архив ...
До колкото виждам от някаква база на Aton, която имам - той ползва същия размер (освен ако не е сменен с по-новите версии)...

[mIRCata]

Знам, че работи с gbak. И естествено, че winrar върху нормнална база ще сработи по-зле(той работи с данните от целия файл и му прави архив, gbak изрязва голяма част от него и запазва само важните неща). Нормално е да не може да направи архив и върху отворен файл. Затова е и gbak-a.
Идеята е да се види коя компресия е по-добра върху backup файла. Тоя FIBS не вярвам да прави нещо по-различно. Просто е автоматизирал процеса - backup и след това архивиране на получения файл. Затова и предложих да направиш отделно с gbak един backup файл и минеш s winrar отгоре.

[mIRCata]

Рад ми прати една база в аргив .GZ. Предполагам е от тази програмка, за която става дума. Вътре има един .GBK файл от 54.1 МВ. Архива от Рад беше 7.00МВ. Архива който направих върху GBK файла с winrar даде 4.64 МВ.
Изводите си ги правете сами.
Сега ще пробвам да мина GBK файла през gzip нз линукс-а да видим какво ще се получи.

[stoar08]

Честно казано, повече ме интересува дали .GBK е работел ( дали по принцип има проблем или този при мен е бил дефектен )...
А и пак не разбирам, дори и да се печелят 2 % размер ( от общата база ), как с WinRar ще се прави автоматично архив с гарантирана цялост без да се спира работата с базата ...особено ако базата е на сървър под linux ( Просто не съм сигурен колко хора могат да работят с GBAK, а и аз не съм от тях ... ) .
Съвсем отделен е факта, че при цялата гама от екстри, които фигурират, тези 2 % се стопяват още по-бързо ...

Иначе си прав, че просто процеса е автоматизиран (просто всичко, без gbak, е вкарано като embeded ресурс, за да не се налага да се инсталират излишни програми).

Колкото до 2-та % - взех базата, за която съм писал тестове и пре-архивирах .FBK с RAR - разликата е 8 198 KB , което на база 305 040 KB е около 2.68 % ако някой смята, че 26.8MB на гигабайт си струват процедурата - да се чувства свободен да прави самата компресия с rar (подозирам, че .bat файловете, които FIBS може да стартира, са достатъчни за целта ).

[mIRCata]

Да но от гледна точка на двата вида компресия резултатите са почти 35% по-добра компресия и по-малко за изпращане насам натам. Едно е чакаш качване 50МВ поща друго е 70. Особено при много качествения интернет в Бг. А и не съм запознат дали тази прогрма цепи архива на томове, а голяма част от пощите имат ограничения за размера на прикачени файлове. Тук rar-a пак е от голяма полза.

[stoar08]

Да, когато се стигне до прехвърляне вероятно има смисъл, но в повечето случаи архивът ще си стои там и ще се радва на молитвите да не стигаме до него. А и предполагам, че функцииката за директен mirror ще работи ... въпреки въпросния интернет .
Може да е зададено например да има архив, който да започва към 00 - 01 през нощта и след това се дига на някакво ftp. По този начин стига да няма по-сериозен проблем, би трябвало все до 7-8 сутринта да се е качил където трябва.
Не пречи да се правят други архиви по-редовно (ако трябва на всеки 10 минути ), но мисля че идеята не е лошо да се обмисли в бъдеще (разбира се, трябва да се измисли и как точно ще се определя дали ново-каченият архив е цял и може да се изтрие предишният), поне за "по-сериозни" клиенти ...

[[SAT1977]]

Случайно попаднах тук. Ето Ви нещо което съм правил доста отдавна а скоро пренаправих. Ползвам си го от доста години, а и в офиса в Пазарджик колегите със него разпъват разни бази по клиентите ни. Това е деархиватор на Interbase / Firebird бази данни. работи с текущия вид инсталиран сървър и е елементарен за работа.

[stoar08]

http://stoar08.com/Insanity_2_0_9.7z

Понеже темата се разшава - това е предвидено основно за firebird, но е проектирано да е по-близо до arc, от колкото до FIBS.

Плюсове :
Директно дефрагментиране (backup/restore) и пращане по мейл с 1 операция
Опция за upload на архиви по ftp
Файлове с описание на архивите (за цялост)
"Nbackup" архиви
Ползва gbak/nbackup => съвместимо е с практически всяка версия на firebird (потенциално interbase)
Няма ограничение на броя бази за архивиране и броя архиви на база на ден
Всяка база е със самостоятелен лимит за място за архиви

Минуси :
7z библиотеката е тежка и при вечно включени компютри прави проблеми
Nbackup на ниво firebird има недоизкусорени проблеми
.net 2.0 sp2

ПС Ако започне да го ползва някой освен Слав - ще доизгладя и малкото налични "ръбчета". Планирам режим "самостоятелна работа" с вграден firebird, седмични графици, автоматично дефрагментиране и т.н., но все още не се ползва достатъчно за да го продължавам.

[morphieus]

Insanity 2.0.9 - защо го нямам до сега ?!?

Чудесен инструмент за информиране за грешки по време на архивиране. Няма нужда да се проверява периодично за това дали се правят архиви и те дали са цели. Отдалечен контрол на плана за архивиране.

P.S. Ако може и през отдалечено връзване към услугата да може и да и изпраща архивите без да се прекъсва работата в обекта...

[detelin]

Ами и аз го ползвам - не е само Слав, на 99% от обектите съм го сложил...