12 често срещани грешки при архивиране на бази данни
Бих искал да ви разкажа за тях, така че администраторите и разработчиците да могат да променят подходите си за управление на архиви и да предотвратят възможни проблеми.
Така че нека да започнем.
1. Изтриване на предишното копие на архива преди създаването на ново копие на архива
Най-често тази грешка се допуска от начинаещи, които не разбират, че основната цел на съществуването на резервно копие на база данни е да се осигури минимален престой на информационната система (важна част от която е базата данни), а не само създайте копие на базата данни.
В резултат от момента на изтриване на последния архив до създаването на нов, системата е в незащитено състояние, тъй като през този период базата данни няма резервни копия. Тъй като архивирането може да отнеме много време, това е идеалното време за действието на закона на Мърфи. Този подход работи особено добре във връзка с точка 7 (виж по-долу).
Препоръка: не изтривайте предишния архив, докато не бъде създаден нов! (и не правете ново архивиране на съществуващ файл)
2. Презаписване на съществуваща база данни при възстановяване от резервно копие
Тази грешка се допуска по-рядко, но резултатите могат да бъдат много по-тъжни. Ако архивът не е бил проверен и е бил повреден (виж точка 6), тогава в резултат на презаписването няма да имате нито предишно копие на базата данни, нито валиден архив.
Обикновено това безобразие се случва в петък вечер, по време на избягване, объркване и противоречиви инструкции от властите. Малко отрицателен късмет и тежък уикенд в сървърната стая са гарантирани.
Firebird има известна защита срещу тази грешка - създаването на ресторант от резервно копие с помощта на помощната програма gbak със стандартния ключ за създаване няма да работи, ако посоченото име на файл сочи към съществуваща база данни. За съжаление има и байпас на тази защита - превключвателят -rep, който ви позволява да презапишете съществуващ файл.
Препоръки: никога не презаписвайте файла на бойната база данни, без да получавате писмени инструкции от ръководството и, за предпочитане, без да получавате ново предложение за работа.
3. Използване на ресторант за архивиране в една стъпка, без създаване на междинен архивен файл
Стандартните I/O потоци ви позволяват да извършите интересен трик с много СУБД (включително Firebird): изпълнете поточно архивиране с незабавно възстановяване на базата данни от него. В резултат на това не се създава междинен архивен файл. Това е удобно за извършване на рутинна поддръжка и стартиране на тестово възстановяване (ако имате друг архив), но в никакъв случай не трябва да го използвате за автоматично архивиране!
Ако по време на такова архивиране на ресторант възникне сериозна повреда на диска, например, оригиналната база данни може да бъде повредена и новата все още няма да бъде създадена. Разбира се, ако клауза 1 е спазена и има копие на базата данни от предишен опит, тогава ще настъпи само загубата на данни, които са създадени или променени в базата данни от създаването на нейното копие.
Препоръки: не използвайте възстановяване на резервно копие в една стъпка в автоматичен режим, но в ръчен режим, винаги проверявайте за достатъчно свежо копие.
4. Съхраняване на резервно копие и база данни на едно и също физическо устройство
Тук мнозина могат да се смеят, че даваме някакъв съвет за децата - това е азбуката на системната администрация. Това е така, но във връзка с разпространението на виртуални среди, както базата данни, така и дискът могат да бъдат разположени в една и съща система за съхранение. И със сигурност ще се развали в най-неподходящия момент за бизнеса. Освен това все още има хора, които вярват, че ако използват RAID (1 или по-нова версия), нищо не може да се случи с техните данни. Все още има хора, които вярват в супер-надеждността на „марков“ хардуер, но това е частен случай.