|
|
Vzdálený přístup k datům Kaskády |
|
Technické podmínky provozu | Testovací databáze |
|
Informace obsažené ve firemní databázi jsou pro chod každé organizace životně důležité.
Při sebevětší péči o technický stav databázového serveru může dojít k havárii tohoto počítače, k destrukci dat na jeho pevných discích.
I při bezchybném provozu databázového serveru může nastat havarijní situace např. díky omylu administrátora při manipulaci s databází, při hrubém omylu uživatelů (mazání dat, která smazána být neměla), apod.
To vše a ještě řada dalších potenciálních problémů je důvodem pro velmi pečlivé zálohování databázového souboru, které je nezbytným prvkem při provozu informačního systému.
Dále je popsáno zálohování v režii Kaskády, které fakticky využívá zálohovací mechanismy 602SQL serveru k nimž přidává vlastní nadstavbovou funkcionalitu.
Běžným způsobem zálohování je zkopírování a komprese celého databázového souboru. Právě to zajišťuje kaskádní mechanismus zálohování.
Databázový soubor se jmenuje WB8.FIL a leží ve složce, která byla určena při instalaci databáze. Obvykle je to složka C:\Program Files\Software602\602SQL81.
Zálohování musí být prováděno dostatečně často - obvykle jedenkrát za den.
Zálohování by mělo probíhat v době nejmenšího provozu - obvykle v hlubokých nočních hodinách.
Zálohování v režii Kaskády proto probíhá jako součást nočního úklidu databáze.
Bezpečnost dat před jejich nenávratnou ztrátou roste s množstvím kopií dat, např. tři zálohy budou jistě bezpečnější než jedna. Zálohy z několika posledních po sobě jdoucích dní je užitečné zachovávat, s odstupem času stačí větší perioda.
Kaskádní mechanismus zálohování uchovává zálohy po určitou dobu, podle následujícího scénáře.
V rámci posledního týdne jsou uchovávány zálohy každého dne.
V rámci posledního měsíce je uchovávána jedna záloha z každého týdne.
V rámci posledního roku je uchovávána jedna záloha z každého měsíce.
Z každého roku by alespoň jedna záloha měla být uchována natrvalo.
V rámci schématu zálohování je také nutno zvážit, zda zálohy ponechat jako prosté kopie (přejmenovaného)
databázového souboru nebo zda výslednou zálohu zkomprimovat do formátu ZIP.
Komprimovaná záloha zabírá samozřejmě podstatně méně místa, vytvoření takové zálohy je však časově náročnější a
je potřeba s tímto faktem počítat. Zejména u velkých databází (desítky GB) se může jednat o desítky minut až
jednotky hodin, které jsou potřeba jak pro vytvoření zálohy tak pro její obnovení do provozuschopného stavu.
Zásadní věcí je to, aby zálohy dat byly logicky i fyzicky odděleny od původních dat.
Pokud budete zálohy ukládat na stejný pevný disk na kterém běží databáze, zabezpečíte se proti náhodným chybám typu "administrátor omylem smazal databázový soubor". Mnohem pravděpodobněji ale o data přijdete havárií disku, počítače nebo požárem v budově.
Z toho důvodu doporučujeme zálohu databázového souboru umístit minimálně na externí disk, nejlépe však na jiný počítač propojený s databázovým serverem dostatečně rychlou místní síť.
Ať už je cíl automatického zálohování kdekoliv, zásadní věcí je pravidelné odsouvání zálohy zcela mimo firemní prostředí.
Podrobnosti následují dále v této kapitole.
Konfigurace prostředí pro zálohování má tři části:
Zásadní rozdíl může být v tom, zda SQL server běží jako
Zásadní rozdíl může být v tom, zda cílem pro zálohování je
Vrcholový administrátor musí v Kaskádě nastavit parametry zálohování, odpovídající připravené situaci v operačním systému.
V zásadě existují 4 varianty běžícího SQL serveru, kombinované se třemi variantami cílového prostoru pro
zálohování.
V následující tabulce najdete informace o použitelných/nepoužitelných kombinacích včetně důležitých komentářů k
jednotlivým kombinacím.
| Cílem je | SQL server běží jako | ||||
| Služba běžící pod účtem |
Aplikace běžící jménem přihlášeného uživatele a v jeho session |
||||
| Local system | Local service | Běžný uživatel | |||
|
Složka sdílená v místní síti |
Auth |
LZE (hlavní doporučené řešení) Adresace musí být UNC Musí být zadané jméno / heslo |
Nelze |
LZE Adresace musí být UNC Musí být zadané jméno / heslo |
LZE (hlavní doporučené řešení) Adresace musí být UNC Musí být zadané jméno / heslo |
| Open |
LZE Adresace může být UNC i mapovaná jednotka Nesmí být zadané jméno / heslo |
Nelze |
Za určitých okolností lze ale není podporováno. |
LZE Adresace může být UNC i mapovaná jednotka Nesmí být zadané jméno / heslo |
|
|
Složka na lokálním disku |
LZE | LZE |
LZE Uživatel jehož jménem služba běží musí mít právo na zápis do složky s wb8.fil |
LZE Uživatel jehož jménem aplikace běží musí mít právo na zápis do složky s wb8.fil |
|
Zásadní rozdíl může být v tom, zda SQL server je provozován jako aplikace nebo služba.
Rozhodnutí o režimu provozu není pouze věcí zálohování, má to širší dopady (viz. Spuštění SQL serveru na databázovém serveru), zde se věnujeme rozlišení z pohledu zálohování.
SQL server v tomto případě běží jménem nějakého "běžného" uživatele a to toho, který SQL server spustil buďto přímo nebo nepřímo, třeba formou položky v sekci "Spustit po startu" během přihlášení do Windows.
Pro realizaci zálohování musí být zajištěno, že tento uživatel má právo pro zápis do složky s WB8.FIL i do složky pro cíl zálohování.
Záleží na tom, pod jakým účtem služba běží (určeno v konfiguraci služby OS).
Výchozí účet pro běh služby je Local System, což je systémový účet bez možnosti interaktivního přihlášení,
bližší popis možností následuje dále.
Tato varianta je výchozím stavem pro nainstalovanou službu.
V této situaci má služba právo na zápis do kterékoliv složky na lokálním disku.
Do složky sdílené v místní síti může přistupovat také, pokud je adresována formou UNC a v případě potřeby se řádně připojí s použitím jména a hesla (viz. složka s nutností autentizace).
Služba má právo na zápis do kterékoliv složky na lokálním disku.
Služba nemůže v žádném případě zapisovat do složky sdílené v místní síti.
Služba má práva daného uživatele, jehož jménem běží.
Běh služby pod takovýmto účtem má význam například z důvodu vyšší bezpečnosti, je však náročnější na konfiguraci.
Pokud chcete službu v tomto režimu provozovat, proveďte následující kroky:
Pro realizaci zálohování musí existovat diskový prostor, který
Pokud chcete zálohu databáze umístit do složky sdílené v místní síti
prostřednictvím Sdílení souborů (protokol SMB), je zásadní otázkou, jak je tento sdílený prostor nastaven z
hlediska autentizace.
Zda je volně dostupné (Open) pro jakéhokoliv uživatele v síti nebo zda je pro přístup nutná autentizace (Auth).
Následující odstavce popisují obě možné situace i situaci kdy cílem je složka na lokálním disku databázového serveru.
U této varianty je záloha fyzicky umístěna na jiném počítači, než je běžící databáze, což je dobře.
Autentizace (uživatel nebo program přistupující k ní musí zadat jméno a heslo pro možnost přístupu) zajišťuje ochranu před nežádoucím přístupem k zálohám, což je také dobře.
Autentizační data (login a heslo pro přístup ke sdílené složce v místní síti) zadejte v Kaskádě v menu na kartě v podkartě Zálohování.
Cestu k cílové složce pro zálohování musíte zadat ve formátu UNC - tedy například \\Server\Backup\Kaskada
Záloha je fyzicky umístěna na jiném počítači, než je běžící databáze, což je dobře.
Absence autentizace ale nezajišťuje ochranu před nežádoucím přístupem k zálohám, což je špatně, proto tato varianta není příliš doporučována.
Pokud se pro tuto variantu přesto rozhodnete, musí být složka sdílená v místní síti přístupná pro neznámé uživatele (Guest) a musí být zapisovatelná kýmkoliv.
Následující odstavce se netýkají Kaskády.
Je to pouze orientační pomůcka pro Vás, pokud budete konfigurovat zcela otevřenou sdílenou složku v
místní síti ve svém operačním systému:
Na složku, do které mají být umisťovány zálohy, klikněte pravým tlačítkem a vyberte Vlastnosti, karta Sdílení. Zde nastavte práva pro zápis skupině Everybody.
Příklad konfigurace sdílené složky v místní síti, konfigurační
soubor /etc/samba/smb.conf:
[database_backups]
writeable = yes
wide links = no
path = /var/lib/samba/database_backups
force directory mode = 777
force create mode = 777
create mode = 777
guest only = yes
public = yes
allow hosts = *** ip adresa databázového serveru ***
directory mode = 777
Záloha není fyzicky umístěna na jiném počítači než je běžící databáze, takže v případě technické havárie přijdete o běžící databázi i o zálohy.
Přípustným řešením může být použití externího disku připojeného přes rychlé rozhraní (např. USB 3.0, eSATA či FireWire), který např. každý týden měníte za druhý disk a cyklicky je střídáte. Druhý disk přitom odnášíte mimo firemní prostory do bezpečné úschovy.
V předchozím textu je vysvětleno, co je potřeba učinit pro zálohování databáze.
Ale cíl takového automatického zálohování musí být samozřejmě (z logiky věci) ve stejné síti, jako je původní
"živý" databázový soubor, který je zálohován.
Z toho plyne, že v případě opravdu velkých malérů jako je například požár budovy, vykradení firmy, vyděračský virus který zašifruje (a tedy znepřístupnění) veškerá data v počítačové síti, o zálohu přijdete a nezbyde vám nic. To je pak opravdu velká katastrofa. Není to fikce, víme o reálných případech kdy k tomu došlo. A ještě pár minut před tou událostí si dotyční vůbec nepřipouštěli, že by je něco takového mohlo potkat, stejně jako si to možná nepřipouštíte vy.
Prakticky jediným, ale přitom poměrně jednoduchým a naprosto spolehlivým řešením, je odnášet paměťové médium se zálohou mimo firmu a ukládat je někde na bezpečném místě.
Může to být například bankovní schránka, což je velmi bezpečné, ale není příliš praktické třeba každý týden do banky se zálohou chodit.
V praxi je dostatečným řešením umístění zálohy třeba doma u majitele firmy. Jde o to, aby to bylo v jiné budově, uloženo "v krabici zcela mimo firemní počítačové prostředí".
Řešení řešením může být například
Stačí jediný dostatečně velký externí disk, na který si třeba 1x týdně nakopírujete soubor poslední provedené zálohy databáze a disk odnesete.
Můžete také použít několik externích USB disků, z nichž jeden je vždy přímo cílem zálohování, ale třeba 1x za týden se disk odpojí, nahradí jiným, ten z poslední zálohu si odnesete mimo firmu.
Toto řešení velmi doporučujeme!
Cílem zálohování může být např. SynologyDiskstation se dvěma paralelními disky.
To samo o sobě zvyšuje bezpečnost zálohy (při poruše jednoho disku zůstávají kompletní data na druhém disku), ale hlavní výhodou je možnost za chodu jeden disk vyjmout a nahradit jiným.
Potom už stačí mít disky tři, dva ve stanici, třetí mimo firmu. Jedenkrát týdně (nebo častěji) stačí
přinést do firmy tento třetí disk,
ze stanice vyjmout jeden ze dvou běžících (na něm je poslední aktuální stav),
tento "ještě teplý disk" odnést
do stanice vložit disk se starším stavem (který byl dosud mimo firmu) a nechat jej sesynchronizovat s aktuálním stavem dat na stanici
Toto řešení není jen otázkou zálohy databáze, ale celého síťového úložiště, kde můžete mít většinu důležitých firemních dat.
Vrcholový administrátor Kaskády konfiguruje zálohování v Kaskádě prostřednictvím menu na kartě v
boxu Zálohování parametry zálohování.
Musí přitom:
V boxu Mechanismus zálohování zvolit "Zálohování v režii Kaskády" a určit datovou větev při jejímž nočním úklidu se bude záloha provádět ( technicky: @KASKADA / OdaBackupAppl = Schema_name ).
V boxu Periodicita zálohování určit zda Kaskáda bude provádět pouze denní zálohy, nebo i týdenní, nebo i měsíční ( technicky: @KASKADA / OdaBackupLevel ).
V boxu Cílové umístění zálohy, komprimace
V boxu Přihlašovací údaje pro zálohování do složky sdílené v místní síti zadat jméno a heslo uživatele na vzdáleném počítači, kde leží složka sdílená v místní síti, pokud přístup k této složce vyžaduje autentizaci ( technicky: @KASKADA / OdaBackupNetUsername a @KASKADA / OdaBackupNetPassword ).
Zálohování se provede v závěru tzv. nočního úklidu té datové větve, která je zvolena v boxu "Zálohovat při nočním úklidu datové větve" (technicky to znamená, že SQL procedura ODA_Backup spustí zálohování, pokud @KASKADA / OdaBackupAppl = Schema_name).
Kaskáda během nočního úklidu ověří, že je definovaná cesta pro cíl zálohování a pokud není, vytvoří alarm uživateli, určenému v globální
konfiguraci jako příjemce informací o chybách automatiky a ukončí zálohování bez provedení zálohy.
Uživatel, kterému byl adresován alarm, je o neúspěchu zálohování informován ihned při svém prvním přihlášení
do Kaskády zobrazením alarmu s příslušným popisem chyby.
Podle aktuálního datumu v okamžiku spuštění zálohy Kaskáda sestaví
Jméno cílového adresáře, přitom zohledňuje, zda "úroveň zálohování" je nastavena pouze na denní zálohy, nebo i týdenní a měsíční:
Poslední den v měsíci je provedena "měsíční záloha" do adresáře BackupDirectory\MesicNN
V neděli je provedena "týdenní záloha" do adresáře BackupDirectory\TydenNN a to tak, že NN := Integer
(Den / 7 )+1.
Hodnota funkce Day_of_Week = 0.
Ostatní dny je provedena záloha do adresáře BackupDirectory\DenN, kde N je pořadové číslo dne,
přitom
Hodnota funkce Day_of_Week je v rozmezí 1 (pondělí) až 6 (sobota).
Jméno cílového souboru, obsahuje m.j. datum a čas startu zálohování
Pokud je kopie zálohy prováděna do složky sdílené v místní síti a
adresované prostřednictvím UNC (cesta začíná "\\"), provede se připojení složky voláním
_sqp_connect_disk.
V případě neúspěchu akce končí a vytvoří se varovný alarm.
Klientům 602SQL serveru (uživatelům kteří mají v tom okamžiku spuštěnou Kaskádu) je v tom okamžiku odeslána informace o zahájení zálohování a spuštěná Kaskáda zajistí její zobrazení.
Provede se kopie databázového souboru voláním _sqp_backup.
V případě neúspěchu akce končí a vytvoří se varovný alarm.
Noční úklid je vzápětí ukončen, uživatelé mohou pracovat a nic je neblokuje.
V samostatném pracovním vláknu databázového serveru probíhají další činnosti nutné k dokončení zálohování.
Pokud
bude následovat komprese do jiné složky než kam byla provedena kopie databáze a pokud
cílem je složka sdílená v místní síti adresovaná prostřednictvím UNC,
provede se nyní připojení této složky voláním _sqp_connect_disk. V případě neúspěchu akce končí a vytvoří se varovný alarm.
Provede se komprese záložního souboru, pokud je tato volba v konfiguraci zaškrtnuta, realizuje se voláním _sqp_backup_zip.
Finálním krokem je redukce počtu záložních souborů v cílové složce na počet 1, realizuje se voláním _sqp_backup_reduce.
Nakonec je spuštěna SQL procedura ODA_Backup_Gen_info_result a v jejím rámci
je vytvořen alarm adresovaný uživateli, určenému v globální konfiguraci jako příjemce informací o chybách automatiky, zde je odpovídající informace o pozitivním nebo negativním výsledku zálohování.
v případě, že záloha NEbyla korektně vytvořena, provede se záznam pro odeslání varovného e-mailu na adresu technické podpory Kaskády - hotline@ekaskada.cz.
|
|
Vzdálený přístup k datům Kaskády |
|
Technické podmínky provozu | Testovací databáze |
|