Tytuł oryginału: Backup & Recovery Tłumaczenie: Piotr Pilch (wstęp, rozdz. 1 – 16), Marek Pętlicki (rozdz. 17 – 24) ISBN: 978-83-246-5971-5 © Helion S.A. 2008. Authorized translation of the English edition of Backup & Recovery © 2007 O’Reilly Media Inc. This translation is published and sold by permission of O’Reilly Media, Inc., the owner of all rights to publish and sell the same. Polish language edition published by Helion S.A. Copyright © 2008. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 032 231 22 19, 032 230 98 63 e-mail:
[email protected] WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie?odzyda_ebook Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/odzyda.zip Printed in Poland. • Poleć książkę na Facebook.com • Kup w wersji papierowej • Oceń książkę
• Księgarnia internetowa • Lubię to! » Nasza społeczność
Książka jest dedykowana tym dzielnym kobietom i mężczyznom, którzy poświęcili się w służbie ojczyźnie. „Nikt nie ma większej miłości od tej, gdy ktoś życie swoje oddaje za przyjaciół swoich”. — Ewangelia św. Jana 15:13
Spis treści Przedmowa . ...................................................................................................................11
I Wprowadzenie . ..................................................................................... 25 1. Filozofia archiwizacji . ...................................................................................................27 Rozbudowana archiwizacja przy niskim budżecie Dlaczego powinno się przeczytać tę książkę? Dlaczego należy archiwizować dane? Znalezienie optymalnej metody archiwizowania
27 28 32 34
2. Archiwizowanie wszystkich danych ...........................................................................39 Nie wolno pomijać tego rozdziału! Dlaczego archiwizuje się dane? Co należy archiwizować? Decydowanie o momencie przeprowadzania archiwizacji
39 41 42 50
II Narzędzia archiwizujące open source ...................................................79 3. Podstawowe narzędzia do archiwizacji i odtwarzania ............................................. 81 Przegląd Archiwizowanie i odtwarzanie danych za pomocą narzędzia ntbackup Zastosowanie narzędzia Przywracanie systemu Archiwizowanie za pomocą narzędzia dump Odtwarzanie danych za pomocą narzędzia restore Ograniczenia narzędzi dump i restore Funkcje godne sprawdzenia Archiwizowanie i odtwarzanie danych za pomocą narzędzia cpio
81 87 90 92 104 114 114 116
5
Archiwizowanie i odtwarzanie danych za pomocą narzędzia tar Archiwizowanie i odtwarzanie danych za pomocą narzędzia dd Zastosowanie narzędzia rsync Archiwizowanie i odtwarzanie danych przy użyciu narzędzia ditto Porównanie narzędzi: tar, cpio i dump Zastosowanie programu ssh lub rsh w roli kanału między systemami
127 133 137 140 144 146
4. Amanda ....................................................................................................................... 149 Podsumowanie ważnych funkcji Konfigurowanie narzędzia Amanda Odtwarzanie danych przy użyciu narzędzia Amanda Społeczność użytkowników i opcje wsparcia Przyszły rozwój
152 167 170 171 172
5. BackupPC ......................................................................................................................173 Funkcje systemu BackupPC Zasady działania systemu BackupPC Instrukcje instalacyjne Uruchamianie serwera BackupPC Konfigurowanie klienta Społeczność związana z systemem BackupPC Przyszłość systemu BackupPC
173 174 176 181 182 183 183
6. Bacula .......................................................................................................................... 185 Architektura oprogramowania Bacula Funkcje oprogramowania Bacula
185 189
III Komercyjne narzędzia archiwizujące ..................................................227 8. Komercyjne narzędzia archiwizujące ........................................................................229 Czego szukać? Pełna obsługa używanych platform Archiwizowanie niesformatowanych partycji
6
|
Sp s treśc
230 231 232
Archiwizowanie bardzo dużych systemów plików i plików Rygorystyczne wymagania Jednoczesne archiwizowanie wielu klientów przy użyciu jednego napędu Archiwizacja dysk-dysk-taśma Jednoczesne archiwizowanie danych jednego klienta na wielu napędach Dane wymagające specjalnego traktowania Funkcje zarządzania magazynem danych Zmniejszone obciążenie sieci Obsługa standardowego lub niestandardowego formatu archiwizacji Łatwość administrowania Bezpieczeństwo Łatwość odtwarzania Ochrona indeksu kopii zapasowych Niezawodność Automatyzacja Weryfikowanie woluminów Koszt Dostawca Końcowe wnioski
233 233 244 246 246 248 250 257 260 263 265 266 268 270 270 271 272 273 274
9. Urządzenia archiwizujące . .........................................................................................275 Czynniki decyzyjne
275
Zastosowanie sprzętu archiwizującego
284
Napędy taśmowe
287
IV Przywracanie komputera od podstaw . ...............................................321 10. Przywracanie od podstaw komputera z systemem Solaris . ....................................323 Zastosowanie narzędzia Flash Archive Przygotowanie do interaktywnego odtwarzania Przygotowanie nieinteraktywnego procesu odtwarzania Końcowe wnioski
323 327 332 339
11. Systemy Linux i Windows . ........................................................................................ 341 Działanie procedury Kroki w teorii Założenia Metoda pełnego obrazu i alternatywnego ładowania Metoda obrazu partycji i alternatywnego ładowania
342 347 352 353 355 Sp s treśc
|
7
Metoda trybu online Metoda systemu plików i alternatywnego ładowania Automatyzowanie przywracania komputera od podstaw za pomocą narzędzia G4L Rozwiązania komercyjne
357 360 363 365
12. Przywracanie od podstaw komputera z systemem HP-UX . ....................................367 Przywracanie systemu za pomocą narzędzia Ignite-UX Przykład wdrożenia Powielanie systemów Bezpieczeństwo Przywracanie danych komputera i powielanie dysków
367 374 379 385 386 387
13. Przywracanie od podstaw komputera z systemem AIX . .........................................389 Narzędzia mksysb i savevg firmy IBM Archiwizowanie przy użyciu narzędzia mksysb Konfigurowanie menedżera NIM
389 394 401
Zastosowanie narzędzia savevg
402 Weryfikowanie kopii zapasowej utworzonej za pomocą narzędzia mksysb lub savevg 403 Przywracanie systemu AIX za pomocą narzędzia mksysb 403 Powielanie systemów
V Archiwizowanie baz danych . ...............................................................415 15. Archiwizowanie baz danych . .................................................................................... 417 Czy to może być zrobione? Zamieszanie — tajemnice architektury baz danych Niech wszystko stanie się jasne — bazy danych objaśnione prostym językiem Na czym polega cały problem? Struktura bazy danych Omówienie modyfikowania stron Zgodność z modelem ACID Co może stać się z systemem RDBMS? Archiwizowanie systemu RDBMS Odtwarzanie systemu RDBMS Dokumentacja i testowanie Unikatowe wymagania baz danych
8
|
Sp s treśc
418 419 419 420 421 432 434 434 435 443 446 447
16. Archiwizowanie i odtwarzanie bazy danych Oracle .............................................. 449 Dwie metody archiwizowania Architektura bazy danych Oracle Tworzenie fizycznych kopii zapasowych bez użycia narzędzia rman Tworzenie fizycznych kopii zapasowych przy użyciu narzędzia rman Technologia Flashback Zarządzanie archiwalnymi dziennikami powtórzeń Przywracanie bazy danych Oracle Logiczne kopie zapasowe Powtórka
449 451 463 470 476 477 479 512 513
17. Wykonywanie i odtwarzanie kopii serwera Sybase ................................................ 515 Architektura baz Sybase Perspektywa zaawansowanego użytkownika Punkt widzenia administratora baz danych Zabezpieczanie bazy danych Automatyzacja kopii zapasowych z użyciem skryptów Wykonywanie fizycznych kopii zapasowych za pomocą programu Storage Manager Odtwarzanie danych baz Sybase Procedury dla serwera Sybase Procedura naprawcza dla baz Sybase
516 519 523 529 536 540 541 544 548
18. Wykonywanie i odtwarzanie kopii zapasowych baz IBM DB2 . ..............................557 Architektura DB2 Polecenia: backup, restore, rollforward i recover Odtwarzanie bazy danych
558 566 577
19. Microsoft SQL Server ..................................................................................................585 Ogólne informacje o Microsoft SQL Server Perspektywa zaawansowanego użytkownika Perspektywa administratora Kopie zapasowe Kopie na poziomie logicznym (tabel) Odtwarzanie i przywracanie
586 587 590 595 607 607
20. Exchange . ....................................................................................................................615 Architektura serwera Exchange Grupy składowania Wykonywanie kopii zapasowych Wykorzystanie programu ntbackup Odtwarzanie Odtwarzanie serwera Exchange
615 618 623 629 634 636 Sp s treśc
|
9
21. PostgreSQL . .................................................................................................................647 Architektura serwera PostgreSQL Kopie zapasowe i ich odtwarzanie Odtwarzanie danych w punkcie czasu Metodologie wykonywania i odtwarzania kopii zapasowych baz MySQL
647 651 655 665
VI Różności . ...............................................................................................675 23. VMware i inne ............................................................................................................ 677 Wykonywanie kopii zapasowych serwerów VMware Ulotne systemy plików Zasada działania programu dump Jak odczytać ten wolumin? Gigabit Ethernet Odzyskiwanie zawartości uszkodzonych dysków Wczoraj Zaufaj mi, jeśli chodzi o kopie zapasowe
677 681 686 694 703 704 704 705
24. Ochrona danych .......................................................................................................... 707 Biznesowe powody ochrony danych Techniczne uzasadnienie ochrony danych Kopie zapasowe a archiwa danych Co należy kopiować? Co należy archiwizować? Przykłady kopii zapasowych i archiwów Czy oprogramowanie open source nadaje się do poważnych zadań? Odtwarzanie danych po katastrofie Wszystko zaczyna się od biznesu Bezpieczeństwo składowania Podsumowanie
708 711 714 715 716 717 718 721 722 727 730
Skorowidz ....................................................................................................................731
10
|
Sp s treśc
Przedmowa
Mam nadzieję, że Czytelnik dowie się chociaż połowy tego, czego ja się dowiedziałem, pisząc tę książkę. Był to dość interesujący projekt, w ramach którego oryginalną książkę rozbudowaliśmy tak bardzo, że trzeba było zmienić jej tytuł. Siedem lat temu napisałem książkę Unix Backup and Recovery. Od tego czasu wiele się zmieniło, zarówno w branży, jak i w moim życiu. Największą zmianą w przemyśle komputerowym było rozpowszechnienie się w centrach danych komputerów z systemami Windows i Mac OS, a także serwerami Exchange i SQL Server (nigdy nie spotkałem się z serwerem Apple Xserve). Dla mnie największą zmianą było bliższe zainteresowanie się aplikacjami archiwizującymi i odtwarzającymi niezaliczanymi do „tradycyjnych”. Prawdą jest, że większość mojej kariery zawodowej spędziłem jako konsultant dla dużych firm, które wydawały na oprogramowanie i sprzęt archiwizujący ilość pieniędzy wystarczającą, żeby sfinansować niewielką armię. Cieszy mnie to, czym się zajmuję. Bardzo motywujące jest pokazanie firmie, jak może zaoszczędzić miliony dolarów rocznie, i jednocześnie sprawić, że procesy archiwizowania i odtwarzania danych będą szybsze i bardziej niezawodne (nawiasem mówiąc, jeśli Czytelnik potrzebuje pomocy w związku z używanym systemem archiwizującym, może wysłać wiadomość pod adres
[email protected] — właśnie w ten sposób zarabiam na życie). Sporo czasu zajęło mi też podróżowanie po świecie i rozmawianie z użytkownikami na temat radzenia sobie z archiwizowaniem i odtwarzaniem danych. Zawsze kierowano do mnie następujące pytania: • Dostałem ofertę z firmy XYZ na oprogramowanie archiwizujące. Firma chce za nie XXXX
złotych! Skąd mam niby zdobyć taką sumę pieniędzy?
• Nie mogłem sobie pozwolić na oprogramowanie archiwizujące firmy XYZ, dlatego nabyłem
aplikację firmy ABC, która nie spełnia oczekiwań. Czy może Pan polecić coś lepszego?
• Żadne z komercyjnych narzędzi nie potrafi zarchiwizować mojej bazy danych MySQL
lub PostgreSQL. Jak to można zrobić?
• W jaki sposób przeprowadzić proces przywracania od podstaw w przypadku systemu ope-
racyjnego ABC?
• Czy są dostępne jakieś narzędzia open source, które umożliwią wykonanie tego typu rzeczy?
W czasie, gdy właściwie przygotowywałem się do pisania swojej kolejnej książki, dotyczącej metod wybierania komercyjnych aplikacji archiwizujących, ich instalowania i zarządzania nimi, stwierdziłem, że ta książka musiała powstać jako pierwsza. Kierowana jest do osób, które uznały, że komercyjne produkty archiwizujące nie spełniają wszystkich ich wymagań. 11
Być może Czytelnik ma niewielki sklep, który może przeznaczyć 10 000 złotych na przyzwoite oprogramowanie archiwizujące. Być może Czytelnik już korzysta z komercyjnej aplikacji archiwizującej, lecz nie zamierza wydać tysięcy złotych na agenta tworzącego kopię zapasową baz danych DB2 lub nie może znaleźć kogoś, kto będzie archiwizować bazy danych MySQL lub PostgreSQL. Książka ma na celu zaoferować opcje — darmowe. Niemal wszystko, co omówiłem w książce, jest dołączone do systemu operacyjnego lub aplikacji bądź dostępne w ramach projektu open source (opisywane przeze mnie komercyjne produkty kosztują tylko 99 dolarów). Czytelnik może być zaskoczony tym, co może zrobić za darmo lub prawie darmo.
Chciałbym mieć taką książkę Chciałem napisać książkę, która zapewni, że nikt już nie będzie musiał zaczynać czegoś od początku. Wierzę, że właśnie to udało się osiągnąć mnie i moim współpracownikom. W książce przedstawiłem każde narzędzie archiwizujące, którym chciałbym dysponować, gdy wkraczałem w branżę archiwizacyjną. Ponadto zawarłem w niej wszystkie lekcje i sztuczki, których dotąd się nauczyłem. Książka wyjaśnia, jak archiwizować i odtwarzać dane, począwszy od zwykłych stacji roboczych z systemem Linux, Windows lub Mac OS, a skończywszy na złożonych bazach danych, takich jak DB2, Oracle i Sybase. Niezależnie od tego, czy dostępny budżet ledwie starcza na pokrycie kosztu nośnika archiwizacyjnego, czy pozwala na zakup silosu większego od mieszkania, w książce Czytelnik znajdzie coś dla siebie. Niezależnie od tego, czy zadaniem Czytelnika jest stwierdzenie, jak zarchiwizować dane bez użycia komercyjnych narzędzi w środowisku, z jakim miałem do czynienia, gdy zaczynałem karierę, czy wybranie jednego z ponad 50 komercyjnych produktów archiwizujących, książka podpowie, jak postępować. Mając to na uwadze, pozwolę sobie wspomnieć o kilku istotnych rzeczach związanych z książką.
Liczy się tylko odtwarzanie danych Mój przyjaciel Joe Fitzpatrick mówił mi coś takiego: „Nikogo nie obchodzi to, czy możesz zarchiwizować dane, lecz wyłącznie to, czy jesteś je w stanie odtworzyć”. Ile Czytelnik przeczytał rozdziałów na temat archiwizowania, w których mniej niż 10% miejsca poświęcono procesowi odtwarzania? Ta książka jest inna. Starałem się z całych sił, żeby zagadnienie odtwarzania danych zostało poruszone w równym stopniu.
Produkty zmieniają się Niektórzy mogą być zaskoczeni tym, że w części książki poświęconej komercyjnym aplikacjom archiwizującym nie podano żadnych ich nazw. Powodów jest kilka. Podstawowy jest taki, że produkty nieustannie się zmieniają. Byłoby niemożliwe aktualizowanie w książce informacji dotyczących ponad 50 produktów dostępnych dla samego systemu Unix. Książka zdezaktualizowałaby się już w momencie, w którym trafiłaby do księgarń. W książce objaśniono pojęcia związane z komercyjnymi aplikacjami archiwizującymi i odtwarzającymi dane. Dzięki temu Czytelnik może pojęcia te skonfrontować z deklaracjami składanymi obecnie przez producentów. Aktualne informacje na temat konkretnych produktów są dostępne pod adresem http://www.backupcentral.com.
12
|
Przedmowa
Archiwizowanie baz danych nie jest takie trudne Jeśli Czytelnik jest administratorem baz danych, może nie być zaznajomiony z poleceniami wymaganymi do zarchiwizowania bazy. Jeżeli jest się administratorem systemu, można nie mieć wiedzy na temat architektury platformy bazodanowej zarządzanej przez administratora baz danych. Obie kwestie zostaną szczegółowo omówione w książce. Prostym językiem objaśniam narzędzia archiwizujące, tak aby było to zrozumiałe dla administratora baz danych. Ponadto omawiam architekturę baz danych w taki sposób, żeby nie miał z nią problemów administrator systemu, nawet taki, który nigdy nie widział na oczy bazy danych.
Przywracanie komputera od podstaw nie jest takie trudne Wcześniej lub później zdarzy się, że po tym, gdy utraci się dysk z systemem operacyjnym ważnego komputera i stanie przed koniecznością odtwarzania, cały dzień będzie trzeba poświęcić na przywracanie komputera od podstaw. Standardowa metoda odtwarzania opisana w dokumentacji wielu produktów archiwizujących polega na zainstalowaniu systemu operacyjnego w minimalnej wersji i przywróceniu danych. Przywracanie komputera od podstaw w ten sposób jest najgorszym możliwym wariantem. Jednym z licznych problemów będzie to, że nadpisze się część plików systemowych, gdy system zostanie załadowany z tego samego dysku, na którym próbuje się odtworzyć dane. W książce szczegółowo omówiono najlepsze metody przywracania komputera od podstaw w przypadku takich systemów operacyjnych, jak AIX, Solaris, HP-UX, Windows, Linux i Mac OS.
Struktura książki Książkę podzielono na sześć części:
Część I W pierwszej części książki zamieszczono wystarczającą ilość informacji, żeby zachęcić Czytelnika do rozszerzania wiedzy na temat archiwizowania i odtwarzania danych. Rozdział 1. „Filozofia archiwizacji” W rozdziale zaprezentowałem swoją filozofię archiwizacji, w tym odpowiedź na pytanie, dlaczego powinno się tworzyć kopie zapasowe, a także wstępne informacje na temat metod archiwizowania. Rozdział 2. „Archiwizowanie wszystkich danych” W rozdziale drobiazgowo omówiono zasadnicze składniki dobrego systemu archiwizowania i odtwarzania danych.
Część II W tej części książki przedstawiono podstawowe dostępne narzędzia umożliwiające archiwizowanie komputera i kilka systemów archiwizujących open source ułatwiających zarządzanie kopiami zapasowymi.
Przedmowa
|
13
Rozdział 3. „Podstawowe narzędzia do archiwizacji i odtwarzania” W rozdziale zaprezentowano podstawowe narzędzia archiwizujące i odtwarzające, które Czytelnik prawdopodobnie znajdzie w takich systemach, jak Unix, Windows i Mac OS. Te narzędzia to m.in. dump, tar, cpio, dd, ditto, ntbackup i rsync. Rozdział 4. „Amanda” W rozdziale omówiono ciągle popularne oprogramowanie Amanda (Advanced Maryland Disk Archiver). Rozdział 5. „BackupPC” W rozdziale objaśniono system archiwizujący BackupPC bazujący wyłącznie na dyskach. Narzędzie to może archiwizować znacznie więcej niż tylko zawartość komputera PC. Rozdział 6. „Bacula” W rozdziale omówiono oprogramowanie Bacula, które nocą przenosi dane z centrum danych i korzysta z najważniejszych zasobów sprzętowych komputerów. Rozdział 7. „Narzędzia open source służące do niemal ciągłej ochrony danych” W rozdziale przedstawiono trzy produkty niemal ciągłej ochrony danych, czyli narzędzie rsync z migawkami, a także programy rsnapshot i rdiff-backup.
Część III Jeśli możliwości darmowych narzędzi nie są wystarczające lub po prostu chciałoby się skorzystać z nowych technologii archiwizowania i odtwarzania, trzeba będzie przyjrzeć się komercyjnemu produktowi. Aby móc ocenić pełny zakres opcji archiwizacji i odtwarzania, należy mieć również wiedzę na temat najnowszego sprzętu dostępnego na rynku. Rozdział 8. „Komercyjne narzędzia archiwizujące” Rozdział pełni rolę przewodnika po setkach funkcji dostępnych w ponad 50 komercyjnych produktach archiwizujących znajdujących się obecnie w sprzedaży. Dzięki temu rozdziałowi będzie można podjąć w pełni świadomą decyzję zakupu. Rozdział 9. „Urządzenia archiwizujące” W rozdziale objaśniono wiele różnego typu dostępnych obecnie urządzeń archiwizujących i podano kryteria ułatwiające zdecydowanie, który rodzaj napędu archiwizującego będzie najbardziej odpowiedni.
Część IV Odtwarzanie komputera od podstaw jest najszybszą metodą przywrócenia do życia komputera po wystąpieniu awarii, nawet wtedy, gdy napęd systemu operacyjnego został całkowicie zniszczony. Rozdział 10. „Przywracanie od podstaw komputera z systemem Solaris” W rozdziale omówiono produkt Flash Archive firmy Sun dołączony do systemu Solaris, będący odpowiednikiem narzędzia mksysb systemu AIX. Rozdział 11. „Systemy Linux i Windows” W rozdziale wyjaśniono kilka procedur i narzędzi, które mogą być zastosowane do przywracania od podstaw komputerów z systemami Linux i Windows. Omówiono też produkt open source o nazwie Ghost for Linux (G4L), który sporządza obrazy.
14
|
Przedmowa
Rozdział 12. „Przywracanie od podstaw komputera z systemem HP-UX” W rozdziale przedstawiono narzędzia make_net_recovery i make_tape_recovery, które obecnie są dołączane do systemu HP-UX, aby można było przywrócić od podstaw komputer z tym systemem. Rozdział 13. „Przywracanie od podstaw komputera z systemem AIX” W rozdziale omówiono narzędzie mksysb systemu AIX, które prawdopodobnie jest jednym z najstarszych i najlepiej znanych programów do przywracania komputera od podstaw. Rozdział 14. „Przywracanie od podstaw komputera z systemem Mac OS X” W rozdziale wyjaśniono, jak przeprowadzić proces przywracanie od podstaw komputera z systemem Mac OS X.
Część V W tej części książki prostym językiem objaśniono dziedzinę stawiającą kilka z największych wyzwań związanych z archiwizowaniem i odtwarzaniem, z którymi może mieć do czynienia administrator systemu lub bazy danych. Dziedziną tą jest archiwizowanie i odtwarzanie baz danych. Rozdział 15. „Archiwizowanie baz danych” W rozdziale omówiono architekturę baz danych, kojarząc każdy jej element z odpowiednim terminem stosowanym w przypadku takich baz, jak DB2, Exchange, Informix, MySQL, Oracle, PostgreSQL, SQL Server i Sybase. Rozdział okaże się przydatny dla kogoś, kto jest administratorem systemu i boi się baz danych lub uczy się obsługi nowej bazy. Rozdział 16. „Archiwizowanie i odtwarzanie bazy danych Oracle” W rozdziale wyjaśniono, jak wykonywać „gorące” kopie zapasowe bazy danych Oracle przy użyciu narzędzia rman lub przeprowadzać proces archiwizacji zarządzany przez użytkownika. Rozdział 17. „Archiwizowanie i odtwarzanie bazy danych Sybase” W rozdziale pokazano, jak za pomocą serwera archiwizującego tworzyć kopie zapasowe bazy danych Sybase ASE. Rozdział 18. „Archiwizowanie i odtwarzanie bazy danych IBM DB2” W rozdziale omówiono archiwizowanie i odtwarzanie baz danych DB2. Rozdział 19. „SQL Server” W rozdziale wyjaśniono, jak archiwizować i odtwarzać bazy danych SQL Server. Rozdział 20. „Exchange” W rozdziale pokazano, w jaki sposób archiwizować i odtwarzać bazy danych serwerów Exchange przy użyciu wbudowanego dodatku narzędzia ntbackup. Rozdział 21. „PostgreSQL” W rozdziale przedstawiono procesy archiwizowania i odtwarzania baz danych PostgreSQL. Rozdział 22. „MySQL” W rozdziale dokonano przeglądu różnych opcji archiwizacji i odtwarzania dostępnych dla serwera bazodanowego MySQL.
Przedmowa
|
15
Część VI Informacje zamieszczone w tej części książki w żadnej mierze nie są mało istotne. Po prostu nie mogły znaleźć się w innym miejscu! Rozdział 23. „Różności” W rozdziale omówiono oprogramowanie VMware, przedstawiono często poruszaną kwestię zrzutów aktywnych systemów plików, a nawet zamieszczono trochę poezji o archiwizowaniu danych. Rozdział 24. „Ochrona danych” Rozdział zmusza do poważnych przemyśleń. Czytelnik znajdzie w nim odpowiedź na pytanie, dlaczego kopie zapasowe nie rozwiązują wszystkich problemów. Czytelnik powinien też zastanowić się nad innymi obszarami podlegającymi ochronie danych, takimi jak tworzenie archiwów, przywracanie po awarii i zabezpieczanie magazynów danych.
Co nowego można znaleźć w książce? Aby poznać odpowiedź na to pytanie, należy przeczytać poprzedni podrozdział. W rzeczywistości w porównaniu z książką Unix Backup & Recovery nowy materiał to około 75% całości. Niektóre rozdziały oryginalnej książki zostały napisane całkowicie od nowa. Oto najważniejsze ze zmian: Nowe podejście Książka odzwierciedla moje nowe podejście do archiwizowania danych, które jest oparte na wykorzystaniu dysku (dotyczy to zwłaszcza mniejszych firm). Nowe polecenia archiwizujące W rozdziale poświęconym podstawowym narzędziom uwzględniono programy: ntbackup, ditto i rsync. Amanda Całkowicie uaktualniono rozdział opisujący oprogramowanie Amanda, aby uwzględnić w nim postępy dokonane w ostatnich siedmiu latach. Komercyjne narzędzia Zaktualizowano rozdział poświęcony komercyjnym narzędziom w celu uwzględnienia dokonań z dziedziny archiwizowania i odtwarzania danych z ostatnich siedmiu lat. System HP-UX Ponieważ zmieniły się narzędzia make_net_recovery i make_tape_recovery, tak też się stało z omawiającym je rozdziałem. Urządzenia archiwizujące Ależ przez siedem lat zmienił się sprzęt! Docelowe magazyny dyskowe, wirtualne biblioteki taśmowe i systemy z deduplikacją danych. Wszystko to zostało opisane. W książce jest 11 zupełnie nowych rozdziałów, które znacznie rozszerzają jej zakres. Oto zagadnienia przedstawione w tych rozdziałach: DB2 Metoda archiwizowania bazy danych DB2 przy użyciu jej wbudowanych funkcji. 16
|
Przedmowa
Exchange Metoda archiwizowania serwera Exchange za pomocą programu ntbackup. SQL Server Metoda tworzenia kopii zapasowej danych serwera SQL Server przy użyciu jego wbudowanych funkcji. MySQL Metoda archiwizowania i odtwarzania baz danych MySQL przy wykorzystaniu mechanizmów magazynowania: MyISAM, InnoDB i NDB. PostgreSQL Metoda archiwizowania i odtwarzania tej popularnej darmowej bazy danych przy użyciu narzędzia pg_dump lub pg_dumpall. BackupPC Objaśniono obsługę oprogramowania BackupPC, czyli kompletnego dyskowego systemu archiwizowania i odtwarzania wyposażonego w internetowy interfejs. Bacula Omówiono użytkowanie darmowego produktu archiwizującego Bacula, który nocą przenosi dane z centrum danych i korzysta z najważniejszych zasobów sprzętowych komputerów. Niemal ciągła ochrona danych Wyjaśniono, jak używać migawek i replikacji w celu archiwizacji danych. System Solaris Omówiono przywracanie od podstaw komputera za pomocą narzędzia Flash Archive. Przywracanie od podstaw komputera z systemami Linux i Windows Wyjaśniono, jak przy użyciu dysku Linux Live CD lub narzędzia Ghost for Linux przeprowadzić proces przywracania od podstaw komputera z systemami operacyjnymi Windows i Linux. System Mac OS X Przedstawiono użycie wbudowanej funkcji przywracania od podstaw komputera z systemem operacyjnym Mac OS X (nie jest to zbyt trudne).
Co zostało pominięte? Z różnych powodów w książce nie uwzględniono niektórych rozdziałów książki Unix Backup & Recovery. Wszystkie te rozdziały są obecnie dostępne pod adresem http://www.backupcentral.com. Oczywiście problemem jest to, że rozdziały te nie zostały uaktualnione. W związku z tym umieszczono je na stronie internetowej, aby każdy, kto chce, mógł pomóc w ich zaktualizowaniu. • „Tru64 Bare-Metal Recovery”, • „IRIX Bare-Metal Recovery”, • „Informix Backup and Recovery”, • „Clearcase Backup and Recovery”, • „High Availability”.
Przedmowa
|
17
Coś na temat witryny BackupCentral.com Całkowicie przebudowaliśmy witrynę znajdującą się pod adresem http://www.backupcentral.com, używając systemu zarządzania treścią, forów i technologii MediaWiki. Moim celem numer jeden jest sprawić, aby łatwiej było zapewnić na niej dynamiczną treść. Zależy mi również na zbudowaniu silnej społeczności związanej z dziedziną archiwizowania i odtwarzania danych. Nowa witryna Backup Central ma do zaoferowania kilka świetnych rzeczy: • Fora phpBB poświęcone różnym tematom związanym z archiwizowaniem. Jedno z forów
dotyczy tej książki. Zachęcam do przyłączenia się do dyskusji.
• Każde forum dysponuje listą wysyłkową umożliwiającą śledzenie dyskusji za pośrednic-
twem forum lub poczty elektronicznej. Wszelkie posty zamieszczone na forum są przekazywane do listy wysyłkowej. Wiadomości pocztowe wysłane na adres listy wysyłkowej spowodują, że na forum pojawią się posty lub odpowiedzi. • Wielokierunkowe połączenie między grupami dyskusyjnymi Usenet, listami wysyłkowymi
i forami phpBB związanymi z archiwizowaniem. Jedną z rzeczy, które uświadomiłem sobie w czasie pisania książki, było to, że Usenet nadal funkcjonuje i ma się dobrze. Zależy mi na przedstawieniu tego znakomitego, choć niedocenianego zasobu społeczności związanej z witryną Backup Central, a także na utworzeniu innego portalu wykorzystującego Usenet. Każda interesująca mnie grupa dyskusyjna Usenet ma listę wysyłkową i forum. Wszystkie wiadomości kierowane do grupy dyskusyjnej Usenet, listy wysyłkowej lub forum trafiają na odpowiednie forum, listę wysyłkową lub grupę dyskusyjną. • Strony Wiki bazują na tym samym oprogramowaniu MediaWiki, które obsługuje witrynę
Wikipedia. Jedną z rzeczy, które Czytelnik znajdzie w witrynie Backup Central, jest strona Wiki dla każdego rozdziału książki. Strony te posłużą do aktualizowania i rozszerzania zagadnień poruszanych w książce. Na takie rozwiązanie zdecydowałem się z dwóch powodów: • Z pisaniem specjalistycznych książek wiąże się następujący problem: ledwie książka trafi
do druku, pojawiają się w niej zmiany. W czasie gdy książka była przygotowywana do druku, serwer MySQL zaoferował kolejne trzy mechanizmy magazynowania danych, narzędzie QTParted miało zacząć obsługiwać system plików NTFS, a serwer dla systemu Windows oprogramowania Bacula miał stać się bardziej dostępny. Aby uwzględnić te zmiany, posłużymy się stronami Wiki.
• Ja i moi współpracownicy nie znamy wszystkich odpowiedzi. Dołożyliśmy wszelkich
starań, żeby zaoferować Czytelnikowi solidną książkę. Jednak nie mieliśmy do czynienia z wszystkim, z czym mógł mieć do czynienia Czytelnik. Bylibyśmy zadowoleni, gdyby Czytelnik pomógł nam rozwinąć tematy poruszone w książce, objaśnić sytuacje, w których określona procedura nie działa, lub przedstawić metody, przy użyciu których procedura powinna zostać zmodyfikowana (przykładowo mój przyjaciel próbował mi pomóc w zrozumieniu, jak sprawić, żeby program rsync lepiej radził sobie z milionami plików; ponieważ przeprowadzane przez niego testy nie zostały ukończone przed oddaniem książki do druku, poprosiłem Jasona o zawarcie wyników na stronie Wiki). Niech Czytelnik zajrzy na przebudowaną stronę internetową Backup Central i ocali świat lub przynajmniej jego dane. Do zobaczenia pod adresem http://www.backupcentral.com!
18
|
Przedmowa
Konwencje zastosowane w książce W książce użyto następujących konwencji typograficznych: Kursywa Przy użyciu tego stylu są wyróżnione nowe terminy, adresy URL, tytuły rozdziałów i książek, a także nazwy i rozszerzenia plików, katalogów, komputerów i programów. Tekst o stałej szerokości
Styl ten wyróżnia polecenia do wykonania, zmienne i opcje. Kursywa o stałej szerokości
Za pomocą tego stylu są wyróżniane łańcuchy zawarte w wierszach poleceń, w miejsce których należy wstawić rzeczywistą nazwę.
Pogrubiona kursywa o stałej szerokości
Tym stylem są wyróżnione łańcuchy znajdujące się w wierszach poleceń, w miejsce których należy wstawić rzeczywistą nazwę. Listing
Stylem tym są identyfikowane wyniki wygenerowane przez polecenia. Pogrubiony listing
Przy użyciu tego stylu wyróżnia się wykonywane polecenia.
Książka jest efektem pracy zespołowej To prawda. Choć na mojej tabliczce z nazwiskiem widnieje, że jestem specjalistą od archiwizowania i odtwarzania danych, nie oznacza to, że wiem wszystko na ten temat. W rzeczywistości nigdy nawet nie miałem do czynienia z częścią systemów operacyjnych lub baz danych omówionych w książce! Byłoby to oznaką lekceważenia Czytelnika, gdybym sam napisał rozdziały poświęcone produktom, których nie używałem. Jednak zależało mi na uwzględnieniu takich rozdziałów w książce. W związku z tym wynająłem zespół ekspertów, którzy napisali te rozdziały. W przybliżeniu 250 stron jest autorstwa innych osób. Współautorzy zostali przedstawieni na początku rozdziałów, w których tworzeniu brali udział.
Osoby, które brały udział w pisaniu książki Nie jest prosto napisać rozdział w cudzej książce. Nie tylko trzeba umieć pisać, trzeba także robić to zgodnie z założeniami autora całości. Ponadto terminy są krótkie i cały proces tworzenia to mieszanka pośpiechu i czekania. Nie byłbym w stanie napisać książki bez wsparcia innych osób. W związku z tym pozwolę sobie oficjalnie podziękować wszystkim moim współpracownikom. Amanda W tworzeniu tego rozdziału udział brali Dmitri Joukovski i Stefan G. Weichinger. Dziękuję za ukończenie tego rozdziału. BackupPC Współtwórcą tego rozdziału jest Don „Kaczka” Harper. Kwa!
Przedmowa
|
19
Bacula W pisaniu tego rozdziału brał udział Adam Thornton. Dzięki za uwzględnienie w książce narzędzia Bacula. Narzędzia open source służące do niemal ciągłej ochrony danych Współautorami tego rozdziału są: Michael Rubel, Ben Escoto i David Cantrell. Rozdział kilka razy się zmieniał. Doceniam Waszą cierpliwość, gdy ostateczny kształt rozdziału układał mi się w głowie. Przywracanie od podstaw komputera z systemem AIX W pisaniu rozdziału udział brał Mark Perino. Myślę, że jesteś najszybszym pisarzem w całym zespole. Przywracanie od podstaw komputera z systemem HP-UX W pracach nad rozdziałem udział brali Eric Stahl i Ron Goodwyn. Znakomita współpraca, chłopaki. Systemy Linux i Windows Współautorem tego rozdziału jest Reed Robins. Być może możemy to zrobić w ten sposób, w tamten sposób lub jeszcze inny! Czy wystarczająco zmieniłem zakres rozdziału? Dzięki. Przywracanie od podstaw komputera z systemem Mac OS X W pracach nad rozdziałem uczestniczył Leon Towns-von Stauber. Dziękuję, Leon. Bez wątpienia jestem zadowolony z tego, że Mario namówił mnie, żebym do Ciebie zadzwonił. Ten rozdział jest perfekcyjny. Przywracanie od podstaw komputera z systemem Solaris W pisaniu rozdziału udział brał Aaron Gersztoff. Aaron, uważaj, o co prosisz, dobrze? Archiwizowanie i odtwarzanie bazy danych IBM DB2 Współautorami tego rozdziału są: Jeff Richardson, Kulvir S. Bhogal i Kondal Yennaram. Wiele przeszliście i jestem za to niezmiernie wdzięczny. Exchange W pracach nad tym rozdziałem uczestniczył Scott Harris. Więcej rysunków! Mniej rysunków! Zrób to w ten sposób! Nie, zrób to w taki sposób! Czyż nie jest fajne pisanie dla mnie? SQL Server Współtwórcą tego rozdziału jest Scott Harris. Scooter, spójrz na to! Jesteś jedyną osobą, która była na tyle szalona, żeby napisać dla mnie dwa rozdziały. Dzięki. Archiwizowanie i odtwarzanie bazy danych Sybase W pisaniu rozdziału udział brał Edward Barlow, który zaktualizował rozdział oryginalnie stworzony przez Bryn Smith. Następny współpracownik, bez którego nie mógłbym się obejść. Dzięki. Oprogramowanie VMware i inne różności Współtwórcą tego rozdziału jest David Young. Kiedy wyprowadzisz się od swojej mamy? Bez pomocy tych osób książka zawierałaby znacznie mniej informacji niż teraz.
20
|
Przedmowa
Redaktorzy techniczni Następna grupa osób, której muszę podziękować, to techniczni recenzenci. Było ich wielu! Problem z pisaniem książki poruszającej tak wiele zagadnień polega na tym, że trzeba korzystać z usług specjalistów i technicznych recenzentów. Z tego powodu większość redaktorów technicznych sprawdzała tylko jeden lub dwa rozdziały. Nie mógłbym się bez nich obejść. Choć jestem pewien, że kilka osób pominąłem, dołożyłem wszelkich starań, żeby wymienić je wszystkie (w kolejności alfabetycznej według imienia). Adrin Kow Axel Schwenke Brian Peasland Christoph Haas Dana Diederich David Boyd Eric Stahl Greg Lehey James Bougor Jeff Frost Jeffrey P. Humes John Madden Lenz Grimmer Mark Dawson Matthew Huff Mohammed Mehdi Patrick Matthews Rob Worman Scott Boss Simon Riggs Tammy Bednar Vitalis Jerome
Andy Shellam Ben Garrett Charles Whealton Craig Barratt Daniel Callahan Edward Conba Finn Henningsen Ian Gorrie Jayesh Thakrar Jeff Harbert John Haight Kern Sibbald Marcel Lans Mark Perino Megan Restuccia Neal A. Lucier Paul Muggeridge Rodrigo Real Scott Harris Steve Hanson Todd Toles Wil Coulbourn
Anthony Johnson Brian Eliassen Chris Thomas D.A. Morgan Dave Mehler Eric Gilmore Frank Sweetser Ian Herd Jeff Badger Jeff Richardson John Hurley Kumar Sundaram Mark D. Powell Massimiliano Daneri Mike Harrold Norbert Munkel Ralph R. Hirtler Satyaprakash Pandey Shane Seymour Stewart Smith Víctor A. Rodríguez William Cole
Przerażające historie Osoby, które przyczyniły się do zamieszczenia w książce przerażających historii, sprawiły, że stała się bardziej interesująca. Jeśli nawet nie mogłem wykorzystać w książce historii jakiejś osoby, chcę jej podziękować za przesłanie. Brian O’Neill David Bregman Hywel Matthews Jason Frankovitz Jim Donnellan Karl Langdon Michael Rice Richard Ackerman William Birch
Brian Sakovitch David J. Young Jack Coats Jason Shupe John Merryman Kevin Suttle Michael Tobin Scott Boss William S. Duncanson
Chris Pritchard Harry Tirrell James Hunt Jim Damoulakis Jorgen Lie Mark Perino Natalie Meek Theo Van Dinter
Przedmowa
|
21
Specjalne podziękowania Było kilka osób, które okazały się niezmiernie pomocne w ten lub inny sposób podczas realizowania projektu. Chciałbym im szczególnie podziękować. Anthony Johnson Nie każdy prezes zarządu w ramach wolontariatu podjąłby się zrecenzowania rozdziału, który właściwie był poświęcony darmowej aplikacji konkurującej z produktem jego firmy. Mam nadzieję, że zarówno Ty, John, jak i Twoja firma macie się bardzo dobrze. Firma oferuje przyzwoite narzędzie służące do przywracania od podstaw komputerów z systemami Linux i AIX. Brian Peasland Skrytykowałeś kiepską jakość pierwszej roboczej wersji rozdziału poświęconego bazie danych Oracle — i słusznie. Nowa wersja rozdziału jest znacznie lepsza dzięki Twojej dokładnej i szczerej recenzji (sprawiłeś, kolego, że ponownie napisałem połowę rozdziału!). Deb Cameron Czyż nie jest fajne wydawanie książki mającej 18 autorów z trzech kontynentów, kilku stref czasowych i posługujących się różnymi językami, a także około 60 redaktorów technicznych? Zróbmy kiedyś coś takiego jeszcze raz! Joshua D. Drake Joshua, dziękuję, że poświęciłeś czas na te wszystkie rozmowy przez telefon, które miały pomóc mi zrozumieć serwer PostgreSQL. Następnym razem powinieneś być bardziej bezpośredni w wyrażaniu własnych opinii. Naprawdę nie wiadomo, jakie w danej chwili jest Twoje zdanie. Lenz Grimmer Byłeś moim przewodnikiem w społeczności związanej z serwerem MySQL. Zdecydowanie potrzebowałem pomocy. Dziękuję Tobie i całemu zespołowi zajmującemu się serwerem MySQL. Lynn Stone Dziękuję Ci za to, pomogłaś mi we wstępnej fazie realizacji projektu. Bez Ciebie nie byłoby to możliwe. Tylko ja znam Twoją sekretną tożsamość. Tammy Bednar Będąc tak zajętą kobietą, zapewniłaś mi dokładnie to, co było mi potrzebne do części projektu dotyczącej bazy danych Oracle. Oczywiście wykonałaś znacznie więcej pracy związanej z innymi produktami firmy Oracle, co zresztą widać. Mam nadzieję, że zauważysz w rozdziale poświęconym bazie danych Oracle moje wyrazy uznania dla Twoich osiągnięć. Zmanda Dziękuję za pomoc przy pisaniu rozdziału poświęconego oprogramowaniu Amanda i zapewnienie profesjonalnego wsparcia bardzo popularnemu narzędziu archiwizującemu open source. Mario Obejas Dziękuję Ci bardzo za skierowanie mnie do Leona.
22
|
Przedmowa
Nie wiem wszystkiego Jeśli czegoś się nauczyłem, pisząc tę książkę, to tego, że nie wiem wszystkiego na temat archiwizowania danych. Jeżeli Czytelnik zna lepszy sposób na wykonanie czegoś opisanego w książce, nauczył się jakichś specjalnych sztuczek lub napisał jakieś fajne narzędzia, które według niego mogą innym osobom pomóc w archiwizowaniu i odtwarzaniu danych, proszę o kontakt. Można mi wysłać wiadomość pocztową na adres
[email protected]. Metody lub narzędzia zaproponowane przez Czytelnika mogą zostać uwzględnione w następnym wydaniu książki i od razu udostępnione pod adresem http://www.backupcentral.com.
Jak mogę podziękować? Jak zacząć podziękowania kierowane do setek osób, które mi pomogły? Do Boga: Oby każdy wyraz uznania dla tej książki trafił tylko do Ciebie. Do mojej żony Celynn: Mówię „dziękuję” za wiele nocy, które spędziłaś sama, gdy ja korespondowałem, stukając w klawisze, z kimś mieszkającym w innym miejscu globu. Jesteś wyjątkową kobietą, która nigdy nie walczyła ze mną lub moim marzeniem. Kocham Cię. Do mojej córki Niny: Miałaś zaledwie siedem lat, gdy pojawiła się moja pierwsza książka. Obecnie jesteś piękną młodą damą, która tak szybko dorasta. Zamierzam zdobyć broń i siedzieć na ganku. Do mojej córki Marissy: Miałaś dopiero dwa lata, gdy wyszła moja pierwsza książka. Teraz jesteś śliczną dziewięciolatką. Jak ten czas płynie. Wybierzmy się razem do parku na rower. Do moich rodziców: Cóż mogę powiedzieć? Zawsze we mnie wierzyliście i mówiliście mi: „Nieważne, czy będziesz kopał rowy. Po prostu bądź najlepszym kopaczem rowów na świecie”. Cóż, będąc specem od archiwizacji, w branży komputerowej nie można bardziej zbliżyć się do kopacza rowów. Dlatego napisałem o tym książkę. Podziękowania dla Boba Walkera za to, że pomógł mi znaleźć pierwszą pracę związaną z kopiami zapasowymi, a także dla Rona Rodrigueza za to, że aż zbyt chętnie dał mi tę pracę. Wyrazy wdzięczności dla Susan Davidson, która nie zwolniła mnie, gdy w 1992 r. nie mogłem odtworzyć handlowej bazy danych. Ta druga szansa była wszystkim, co było mi potrzebne, aby stać się ekspertem od archiwizacji, którym jestem obecnie. Jeślibyś mnie wtedy zwolniła (jestem pewien, że kilka osób tego chciało), kto wie, gdzie obecnie bym był (jeżeli jesteś zainteresowana tą historią, zapoznaj się z ramką „Coś, z czym mi się udało” w rozdziale 1.). Dziękuję firmie Collective Technologies za to, że pomogła mi poprawić umiejętności na tyle, abym stwierdził, że chcę się specjalizować w archiwizowaniu i odtwarzaniu danych. Dziękuję również za wspieranie mnie, gdy pisałem pierwszą książkę. Podziękowania składam na ręce następujących osób: Jason Stege, Robin Young, Jeff Williams, Reed Robins i Elia Harris. Dziękuję za wiarę we mnie, gdy zakładałem własną firmę. Mam nadzieję, że według Was postąpiłem właściwie. Wyrazy wdzięczności dla Marka Shirmana i wszystkich przyjaciół z GlassHouse za zapewnienie mi miejsca, w którym wreszcie poczułem, że korzystam ze swoich umiejętności.
Przedmowa
|
23
Do rodziców mojej żony: Dziękuję za tak wspaniałą żonę, a także za traktowanie mnie jak własnego dziecka i wspieranie nas w poszukiwaniach. Pahingi ng sinagang? Podziękowania dla wszystkich nauczycieli, którzy usilnie starali się wydobyć ze mnie pełnię możliwości — wreszcie się to udało. Do wydawnictwa O’Reilly: Dziękuję za możliwość wydania tej bardzo potrzebnej książki. Do moich redaktorów, Deb Cameron i Michaela Loukidesa: Musimy się wreszcie spotkać pewnego dnia! Nie wiem, jak Wy to robicie, że nieustannie czytacie tę samą książkę bez zmęczenia oczu. Jesteście znakomitymi redaktorami. Naprawdę mogę powiedzieć, że daliście z siebie wszystko w czasie realizowania projektu. Dziękuję, dziękuję i jeszcze raz dziękuję (nie edytujcie tego zdania, dobrze?). Do Czytelnika: Dziękuję za nabycie książki. Mam nadzieję, że Czytelnik dowie się z niej tyle co ja, gdy ją pisałem.
24
|
Przedmowa
CZĘŚĆ I
Wprowadzenie
Część I składa się z dwóch rozdziałów: Rozdział 1. „Filozofia archiwizacji” W rozdziale wyjaśniono, dlaczego powinno się archiwizować dane, a także w skrócie pokazano, jak to robić. Rozdział 2. „Archiwizowanie wszystkich danych” W rozdziale szczegółowo przedstawiono zasadnicze elementy dobrego systemu archiwizowania i odtwarzania danych.
ROZDZIAŁ 1.
Filozofia archiwizacji
Archiwizuję, a zatem będę. Gdy patrzę na tytuł tego rozdziału, przypomina mi się stary występ Steve’a Martina, podczas którego powiedział z filozoficzną nutą, że właśnie ktoś dowiedział się wystarczająco, aby być nieszczęśliwym przez resztę swojego życia (Steve analizował ważne pytania, takie jak: „Czy w porządku jest wykrzyknięcie słowa »film« w remizie pełnej ludzi?”. Obiecuję, że nie będę tego robić). Jednakże stwierdzenie „Filozofia archiwizowania” wydało mi się właściwe jako tytuł tego rozdziału, w którym wyjaśnię, dlaczego należy archiwizować dane (wspomnę oczywiście też o tym, jak to robić).
Rozbudowana archiwizacja przy niskim budżecie Dobry system archiwizowania i odtwarzania danych jest kluczowy dla firmy dowolnej wielkości. Niestety, dział informatyczny nie zawsze dysponuje wymaganym budżetem i na system archiwizowania prawie nigdy nie są przeznaczane wystarczające środki. Jeśli uzna się, że potrzeba bardzo dobrego systemu archiwizowania, lecz nie posiada się odpowiednich środków na jego uruchomienie, trzeba wiedzieć, że książka ta przyda się właśnie w tego typu sytuacji. Konieczna jest rozbudowana archiwizacja przy niewielkim budżecie. Jeśli w przypadku Czytelnika tak właśnie jest, witam w klubie. Skromny budżet nie oznacza jeszcze, że trzeba zrezygnować ze sporządzania kopii danych. Większość systemów archiwizacji zaprezentowanych w książce może być zastosowana w niewielkich środowiskach. Koszt instalacji uwzględniającej sprzęt wyniesie kilkaset złotych. Klienci instytucjonalni nie muszą mieć powodów do obaw, ponieważ też znajdą w książce wiele interesujących rzeczy. Im więcej wykorzysta się rozwiązań przedstawionych w książce, tym więcej środków finansowych zaoszczędzi się na potrzeby innych projektów informatycznych. Mam nadzieję, że w czasie, gdy Czytelnik wdroży wszystkie zawarte w niej pomysły, ukończę pracę nad moją następną, równie interesującą książką. Zostaną w niej przedstawione komercyjne rozwiązania w dziedzinie ochrony danych, uwzględniające wieloplatformowe systemy archiwizowania i odtwarzania, ciągłą ochronę danych, niemal ciągłą ochronę danych, systemy archiwizacji danych bazujące na deduplikacji, replikację itp.
27
Gdy już Czytelnik dotarł do tego miejsca, może zadać następujące pytania: • Dlaczego powinno się przeczytać tę książkę? • Czy naprawdę można archiwizować dane za pomocą oprogramowania open source? • Dlaczego powinno się użyć dysku? • Dlaczego w ogóle powinno się archiwizować dane? • Jak określić optymalną metodę archiwizowania?
Pora na odpowiedzi na wymienione pytania.
Dlaczego powinno się przeczytać tę książkę? Jeżeli ktoś przez jakiś czas zajmował się administrowaniem systemem, może zadać sobie takie pytanie. Istnieje na nie wiele odpowiedzi. Być może instynkt samozachowawczy jest podstawowym czynnikiem motywującym. Chciałoby się mieć pewność, że nie straci się efektów pracy, gdy dojdzie do awarii dysku. Być może przyzwoity system archiwizowania już funkcjonuje i po prostu chciałoby się go ulepszyć. Być może Czytelnik szuka jakichś nowych pomysłów, jak poradzić sobie z kolejnymi potrzebami związanymi z archiwizowaniem i odtwarzaniem. Poniżej zamieściłem kilka powodów, dla których według mnie warto przeczytać tę książkę.
Schadenfreude Schadenfreude jest niemieckim słowem na określenie radości z niepowodzenia innych. Właśnie dlatego ludzie oglądają w internecie te dziwne materiały wideo, na których jakiś przygłup próbuje zrobić coś niemądrego i w efekcie sam sobie robi krzywdę. Każda z ramek zawartych w książce przedstawia prawdziwą i groźną historię, która przydarzyła się komuś, kogo znam. Nie są to miejskie legendy lub makabryczne historie krążące między administratorami. Są to katastrofalne w skutkach zdarzenia, o których wiem z pierwszej ręki. Oczywiście czytaniu tych historii towarzyszy zachowanie opisywane słowem schadenfreude. Jednak każda historia niesie w sobie wniosek, który nie jest jedynym powodem, dla którego ją przytaczam. Rzeczy, o których ostrzegam w książce, naprawdę się wydarzyły. Ponieważ w przypadku braku przygotowania archiwizowanie danych może być bardzo utrudnione, należy z uwagą czytać książkę. Na początek można zapoznać się z zawartością ramki „Coś, z czym mi się udało” zamieszczonej w dalszej części rozdziału. Ramka przedstawia ważny epizod z mojej kariery.
Nigdy nie chciałbym znów wypowiedzieć tych słów „Utraciliśmy dane z zaledwie kilku dni”. W ramce „Coś, z czym mi się udało” napisałem, że straciliśmy dane z tylko kilku dni. Przeklinam dzień, w którym wypowiedziałem te słowa. Nigdy nie chciałbym ich użyć ponownie. Wtedy utwierdziłem się w przekonaniu o ważności kopii zapasowych. Nigdy ponownie czegoś nie będę przyjmował za pewnik. Zacząłem studiować wszystko na temat technologii archiwizowania danych. Książka odzwierciedla podjętą przeze mnie próbę zebrania w jednym miejscu tego, czego nauczyłem się o tanich metodach archiwizowania danych. Książka została napisana, aby nikt nie musiał już wypowiadać słów rozpoczynających ten akapit. Uważam, że żadna strata danych nie jest do przyjęcia. Założę się, że trudno byłoby znaleźć użytkownika, który miałby zdecydowanie inne zdanie na ten temat. Niezależnie od tego, czy jest to arkusz kalkulacyjny utworzony przez jedną osobę, czy baza danych klientów z fakturami sprzedaży z okresu wielu godzin lub dni, będąca efektem pracy 28
|
Rozdz ał 1. F lozof a arch w zacj
setek osób, należy dowiedzieć się od osoby używającej danych, jaka skala utraty danych będzie akceptowalna. Każde stwierdzenie, opinia, historia i rozdział w tej książce bazuje na przesłance, że każda utrata danych jest nie do przyjęcia. Poniżej dodatkowo zamieściłem bardzo ważne stwierdzenie.
Coś, z czym mi się udało „Chcesz mi powiedzieć, że bezpowrotnie utraciliśmy kopie zapasowe paryz coś tam?”. Nigdy nie zapomnę tych słów. Odpowiadałem za kopie zapasowe zaledwie od dwóch miesięcy i właśnie dowiedziałem się, że moja kariera dobiegła końca. Sześć tygodni wcześniej przenosiliśmy aplikację Oracle z jednego serwera na drugi. W procesie było coś, o czym zapomniałem — coś kluczowego. W tamtym czasie niewiele wiedziałem o archiwizowaniu baz danych i nie zdawałem sobie sprawy, że przed sporządzeniem bazy danych Oracle musiałem ją wyłączyć. Zadanie to było realizowane na starym serwerze przez narzędzie cron, o którego istnieniu nie miałem pojęcia. O wszystkim tym dowiedziałem się po tym, jak dysk nowego serwera zepsuł się. „Po prostu przekaż nam ostatnią pełną kopię zapasową” — powiedzieli. Zacząłem przeglądać moje dzienniki. Właśnie wtedy zacząłem zauważać błędy. „Żaden problem — pomyślałem. — Po prostu użyję starszej kopii zapasowej”. Starsze dzienniki nie wyglądały wcale lepiej. Zapamiętale przeglądałem kolejne dzienniki, aż znalazłem taki, który wyglądał na poprawny. Został sporządzony ponad 6 tygodni wcześniej. Gdy udałem się po wolumin, uświadomiłem sobie, że firma stosowała 6-tygodniowy cykl rotacji. W efekcie potrzebny wolumin został nadpisany dwa dni wcześniej. To było to! W tamtej chwili wiedziałem, że muszę poszukać innej pracy. Była to baza firmy z danymi dotyczącymi zakupów. Utracone dane firmy o wielomiliardowych obrotach pochodziły z zamówień złożonych w okresie mniej więcej dwóch miesięcy. A zatem przekazałem szefowi wieści. Właśnie wtedy usłyszałem to zdanie: „Chcesz mi powiedzieć, że bezpowrotnie utraciliśmy kopie zapasowe paryz coś tam?”. Czy nie jest zadziwiające, że nie zapomniałem nazwy kopii? Nie pamiętam żadnej innej nazwy systemowej występującej w tej firmie, ale w pamięci utkwiła mi nazwa kopii zapasowej. Poczułem się tak mały, że mógłbym zmieścić się wewnątrz kasety 4-milimetrowej taśmy. Na szczęście w tamtym czasie w firmie pracował administrator systemu, którego nie mogę nazwać inaczej, jak magikiem. Zepsuty dysk został wskrzeszony, a następnie odzyskano z niego dane. Dzięki temu zostały utracone dane z zaledwie kilku dni. Nasz dział musiał rozesłać po całej firmie informację o konieczności ponownego wprowadzenia do bazy wszystkich zamówień, które wpisano w ciągu ostatnich dwóch dni. Powinienem był oprawić w ramkę kopię tego komunikatu, aby mi przypominał, co może się zdarzyć, gdy swojej pracy nie będę traktował wystarczająco poważnie. Jednak nie było to konieczne, ponieważ treść informacji trwale utkwiła w moim umyśle. Część recenzentów książki powiedziała coś takiego: „To naprawdę śmiałe! Pisze Pan książkę na temat kopii zapasowych i na sam początek opisuje, jak sam jedną z takich kopii utracił. Naprawdę trzeba do tego mieć odwagę!”. Dlaczego postanowiłem o tym wspomnieć? Przez te wszystkie lata z licznych awarii to jedno wydarzenie utkwiło mi w pamięci. Być może jest tak dlatego, że właśnie wtedy jedyny raz niemal straciłem pracę. Gdyby nie cudowne działania wspaniałego administratora, Joe Fitzpatricka, moja kariera mogła się zakończyć na samym początku. Opisałem to zdarzenie z następujących powodów: • Zmieniło kierunek mojej kariery. • Związanych z nim jest kilka wartościowych lekcji, z których sporo wyniosłem (więcej o nich
w dalszej części książki).
• Mógłbym go uniknąć, gdybym posiadał książkę taką jak ta.
Muszę przyznać, że było naprawdę przerażające.
Dlaczego pow nno s ę przeczytać tę ks ążkę?
|
29
Biorąc pod uwagę obecnie dostępną technologię, nie ma powodu, aby miało dochodzić do utraty jakichkolwiek danych. Warunkiem jest, aby w przypadku kopii zapasowych był spełniony wymóg właściwej staranności i utrzymania priorytetu.
Ciekawość oprogramowania archiwizującego open source Zaledwie kilka lat temu kopie zapasowe można było wykonać za pomocą niewielu skryptów i narzędzi: dump, tar, cpio lub ntbackup. Zapotrzebowanie na średniej klasy komputery zwiększało się w skali astronomicznej, natomiast proporcjonalnie wzrastała liczba większych baz danych, napędów lub systemów plików, a także długich nazw plików i ścieżek. Pojawienie się dużych baz danych i systemów plików przyczyniło się do powstania sporego rynku dla komercyjnych narzędzi archiwizujących. W tamtym czasie stworzono jeden lub dwa tego typu produkty. Później w sprzedaży były dostępne produkty innych firm. Część tych pierwszych produktów była po prostu narzędziami z graficznym interfejsem użytkownika i funkcją zarządzania woluminami, opartymi na istniejących programach archiwizujących. Narzędzia te zapewniały większą funkcjonalność. Część firm uznała, że ich własne produkty miały wiele ograniczeń, których nie można było wyeliminować. Firmy te postanowiły opracować własne (nawet zastrzeżone) metody archiwizacji danych i podjęły próbę usunięcia ograniczeń, z którymi nie mogły sobie poradzić produkty oparte na narzędziu dump lub tar. W ostatnich latach zapotrzebowanie na scentralizowane archiwizowanie i odtwarzanie danych spowodowało pojawienie się kilku narzędzi open source służących do wykonywania kopii zapasowych i ich odtwarzania. Sześć spośród nich omówiono w książce. Rynek narzędzi archiizujących open source rozwinął się podobnie do segmentu produktów komercyjnych. Oryginalny program archiwizujący open source o nazwie Amanda bazuje na narzędziu wybranym przez użytkownika. Produkt BackupPC pozostawia dane w ich oryginalnym formacie, a narzędzie Bacula używa niestandardowego formatu zaprojektowanego w celu wyeliminowania ograniczeń programu GNU o nazwie tar. Obecnie na rynku produktów archiwizujących open source dostępnych jest kilka narzędzi. Całkiem możliwe jest to, że jeden lub więcej produktów open source przedstawionych w książce spełni oczekiwania Czytelnika dotyczące archiwizowania i odtwarzania danych. Obecnie ta książka jako jedyna omawia wszystkie te narzędzia.
Warto zapoznać się z archiwizowaniem danych wykorzystującym dysk Jeśli ktoś nie słyszał o archiwizacji opartej na dysku lub archiwizacji D2D2T (disk-to-disk-to-tape), najwyższa pora, aby wyłączył cyfrowy rejestrator wideo DVR (Digital Video Recorder) i sięgnął po jedno lub dwa fachowe czasopisma (oczywiście używany rejestrator DVR jest jedynie urządzeniem archiwizującym obraz telewizyjny na dysku; jeśli ktoś okazjonalnie sporządza taśmy magnetowidowe z zapisem urządzenia DVR, ma nawet do czynienia z archiwizacją D2D2T). Zastosowanie dysku w systemach archiwizacji i odtwarzania znacznie zwiększyło się kilka lat temu i naprawdę eliminuje wiele problemów.
30
|
Rozdz ał 1. F lozof a arch w zacj
W rozdziale 9. omówiono urządzenia archiwizujące i bardziej szczegółowo wyjaśniono, dlaczego dyski stały się bardzo atrakcyjnym nośnikiem archiwizacyjnym. Oto krótkie podsumowanie, dlaczego tak jest. Koszt Najważniejszym powodem, dla którego dysk stał się wyjątkowo atrakcyjnym nośnikiem kopii zapasowych, jest to, że w ciągu kilku ostatnich lat koszt dysku znacznie się zmniejszył. Koszt macierzy dyskowej w rozsądnej cenie obecnie w przybliżeniu jest taki sam jak koszt biblioteki taśmowej o podobnej pojemności, wypełnionej nośnikami. Gdy pod uwagę weźmie się kilka rzeczy, które można zrobić w przypadku dysków, takich jak eliminowanie pełnych kopii zapasowych lub nadmiarowych plików, okażą się one jeszcze tańsze. Niezawodność W przeciwieństwie do taśm dyski są bliskie rozwiązaniom, które nie są podatne na zewnętrzne zanieczyszczenia. Ponadto rzeczywisty nośnik dysku twardego w porównaniu z nośnikiem taśmowym jest właśnie twardy. W efekcie pojedynczy napęd dyskowy z założenia jest bardziej niezawodny od napędu taśmowego. Napędy dyskowe stają się jeszcze bardziej niezawodne po umieszczeniu ich w macierzy RAID. Elastyczność Ogólnie mówiąc, napędy taśmowe mogą działać tylko z dwoma szybkościami: zatrzymania i bardzo dużą. Choć niektóre napędy taśmowe obsługują zmienne szybkości, zwykle mogą zwolnić do prędkości stanowiącej 40% nominalnej szybkości urządzenia. Z kolei napędy dyskowe działają z dowolną wybraną szybkością. Aby uzyskać szybkość transferu wynoszącą kilkaset megabajtów na sekundę, wystarczy w ramach grupy RAID zestawić kilka napędów. Ta sama grupa RAID nie będzie miała problemu z zapisaniem danych napływających z szybkością 10 kB/s. W przeciwieństwie do napędów taśmowych napędy dyskowe nie mają problemu z naprzemiennym wolnym i szybkim zapisywaniem. Sprawia to, że dysk idealnie sprawdza się w przypadku nieprzewidywalnych strumieni archiwizowanych danych. Po zapisaniu takich losowych danych w szeregowy sposób na urządzeniu dyskowym z łatwością można przenieść zarchiwizowane dane na taśmę (jeśli jest to wymagane). Część osób całkowicie rezygnuje z tego kroku i zastępuje go replikacją. Warto spróbować zrobić coś takiego przy wykorzystaniu napędu taśmowego. Archiwizacja oparta na dyskach jest wyjątkowo ekonomicznym rozwiązaniem, oferującym małym i średnim firmom całkowicie zautomatyzowane tworzenie kopii zapasowych. Choć duża biblioteka taśmowa może być bardzo tania (kilka złotych za gigabajt) i skalowalna, nie zawsze jest to prawdą w przypadku mniejszych bibliotek przeznaczonych dla rynku niewielkich i średnich firm. Dużym wyzwaniem jest skalowalność. Zwykle im biblioteka taśmowa jest tańsza, tym mniejszą ma skalowalność (oczywiście zawsze zdarzają się wyjątki). Dla porównania, część zupełnie zautomatyzowanych produktów archiwizujących open source wymienionych w książce może być zastosowana razem z jednym napędem dyskowym kosztującym mniej niż 300 złotych. Jeśli jeden napęd dyskowy nie wystarcza, wystarczy nabyć następny dysk i dodać go do menedżera woluminów. Można również kupić kontrolery RAID, które pozwaają zacząć od pojedynczego dysku i wraz ze wzrostem potrzeb dodawać kolejne. W ten sposób można zwiększyć pojemność z kilkuset gigabajtów do wielu terabajtów.
Dlaczego pow nno s ę przeczytać tę ks ążkę?
|
31
Dlaczego należy archiwizować dane? Wszystko już słyszałem. Byłem oskarżany o to, że zajmuję się tylko kopiami zapasowymi. Powiedziano mi, że uważam, że cały świat obraca się wokół szpulki kasety. Stwierdziłem, że pewnego dnia świat spotka katastrofa i pozostanie mi kopia zapasowa. Pytanie brzmi: jak bardzo poważnie Czytelnik traktuje kwestię ochrony danych? Aby ułatwić rozstrzygnięcie tej kwestii, zastanówmy się, co się stanie, gdy nie będą dostępne poprawne kopie zapasowe.
Nie to miałem na myśli! Administrowałem grupą testerów większej firmy tworzącej oprogramowanie. Podczas instalacji aplikacja tworzyła katalog $HOME/foo, żeby umieścić w nim dane użytkownika. Tester dbający o jakość oprogramowania przeprowadzał instalację z uprawnieniami superużytkownika. Aplikacja utworzyła katalog $HOME/foo. $HOME było dosłownie nazwą katalogu. Tester przesłał informację o błędzie i postanowił usunąć bezwartościowy katalog. Czytelnik prawdopodobnie domyślił się, że wykonano następujące polecenie: # rm -rf $HOME
Polecenie zostało wykonane w standardowym systemie uniksowym, w przypadku którego dla superużytkownika w miejsce zmiennej $HOME nadal była wstawiana ścieżka /. Gdy już przestałem się śmiać, udałem się po nośnik instalacyjny, aby ponownie zainstalować system (niestety, nie był dostępny żaden obraz systemu ani kopie zapasowe dla różnych serwerów testerów). Na szczęście większość krytycznych danych znajdowała się na serwerze NFS. — William Birch
Ile będzie kosztować utrata danych? Aby udzielić odpowiedzi na to pytanie, trzeba zastanowić się nad typem archiwizowanych danych. Jest to właściwa pora na skontaktowanie się z osobami, które wcale nie muszą uważać się za ekspertów od komputerów. Aby otrzymać odpowiedź, należy uzyskać informacje z innych działów. Biorąc pod uwagę, że dane mają postać zer i jedynek, o jakim właściwie typie informacji mowa? Czy stosuje się ręczne metody rozliczania lub rekordy finansowe firmy są przechowywane w jakimś programie księgowym? Czy gdy klient zadzwoni i złoży zamówienie, zapisuje się je na formularzu z kalką czy wprowadza dane do odpowiedniego programu przetwarzającego zamówienia? A jak wygląda to w przypadku takich rzeczy, jak budżety, zestawienia, inwentarze i innego rodzaju papierowe dokumenty, które przekłada się każdego dnia? Czy przechowuje się kopię każdej ważnej wysłanej notatki lub zadanie to spoczywa na komputerze? Jeśli Czytelnik żyje jak większość ludzi, w znacznym stopniu jest zależny od tego, co określa się mianem komputerów. Nie pamięta już, ile efektów jego pracy zostało zapisanych w postaci niewielkich magnetycznych bitów na różnych obracających się talerzach. Być może pracuje w środowisku, w którym nigdy nie doszło do awarii dysku. W związku z tym nigdy nie musiał odtwarzać danych. Być może nigdy nie uszkodził klucza lub nie usunął ważnego pliku. Jeśli to prawda, powinien zapamiętać, co mówił mój ojciec: „Można wyróżnić dwie grupy motocyklistów: tych, co się przewrócili, i tych, których dopiero to czeka”. To samo dotyczy napędów dyskowych. Jeżeli komuś nigdy nie zepsuł się dysk, zapewniam, że do tego dojdzie!
32
|
Rozdz ał 1. F lozof a arch w zacj
A zatem co się straci w przypadku utraty danych? Aby to stwierdzić, trzeba przyjrzeć się typom informacji, które mogą znajdować się w środowisku roboczym, a także zastanowić, co by się stało, gdyby wszystkie te dane przepadły. Większość tego, co można stracić, jest bardzo namacalna i da się określić w pieniądzu. To może zaskakiwać. Utraceni klienci Całkiem możliwe, że spośród wszystkich strat ta jest najbardziej widoczna i dotkliwa. Jeśli cała baza danych klientów znajduje się na jakimś komputerze, jak będzie można poznać, kto jest kim, gdy dojdzie do jego awarii? Właściwie można utracić klientów i nigdy ich ponownie nie odszukać. Można również utracić klientów, którzy bazują na danych zlokalizowanych na jednym lub większej liczbie komputerów należących do firmy świadczącej usługi. Jeżeli klient dowie się, że przepadły jego dane, bez wątpienia nie będzie pod wrażeniem firmy, która do tego dopuściła. Może być tak, że utrata danych nie dotknie klienta w sposób bezpośredni. Jednak uzna, że skoro firma utraciła jego dane, może po prostu zakończyć z nią współpracę, ponieważ okazała się niekompetentna. Zamówienia Niezależnie od usługi lub produktu oferowanego przez firmę istnieją metody rejestrowania zamówień dotyczących usługi lub produktu. Przeważnie jest to metoda wykorzystująca komputery. Utrata danych może oznaczać przepadnięcie zamówień złożonych w ciągu godzin, dni, a nawet tygodni. Mogą to być zamówienia, z którymi jest związana ciężka praca sprzedawców! Morale Czytelnik może pomyśleć, jakby się czuł, gdyby był jednym ze sprzedawców, którego zamówienia przepadły. Spędził w dziale sprzedaży wiele dni lub tygodni, a teraz okazało się, że zamówienia zostały bezpowrotnie utracone. Być może powinien udać tam, gdzie ciężka praca nie pójdzie na marne. Im lepszy sprzedawca, tym większa szansa na to, że może opuścić firmę, gdy dojdzie do utraty jego danych. A jak będzie w przypadku przeciętnego pracownika? Jeśli reputacja komputerów jest taka, że mają przestoje i tracą dane, pracowników ogarnia poczucie bezradności. Być może powinni przenieść się tam, gdzie otrzymają sprzęt pozwalający normalnie pracować. Reputacja A co z reputacją w branży? Wieści dotyczące poważnej utraty danych niewątpliwie szybko się rozniosą. Mogą dotrzeć do konkurencji, która na pewno przy pierwszej sposobności wykorzysta je dla własnych korzyści. Mogą też trafić do organizacji nadzorującej firmę. Na przykład dla organu nadzorującego bank niezbyt miła byłaby informacja, że administrator banku przyczynił się do poważnej utraty danych. Taka organizacja może naprawdę dokładnie przyjrzeć się poczynaniom administratora. Nikt nie marzy o czymś takim! Budżet Wystarczy jeden przypadek utraty danych, aby dział komputerowy firmy zyskał złą reputację. Choć zła reputacja może przez jakiś czas pozostać, ze wszelkich sił trzeba próbować ją naprawić. Jest się tak dobrym jak ostatni proces odtwarzania danych (mój przyjaciel powiedział, że jest się tak dobrym jak najgorzej przeprowadzony proces odtwarzania). Jeżeli ludzie nie ufają wykonanym kopiom zapasowym, będą sami je sporządzać, powielając działania administratora. Pracownicy będą tracić czas i pieniądze na lokalne archiwizowanie swoich systemów. Każda osoba może zdecydować się na kupno własnego napędu i oprogramowania archiwizującego, a nawet przynieść z domu samodzielnie utworzony
Dlaczego należy arch w zować dane?
|
33
skrypt. Wykonywanie przez pracowników kopii zapasowych w najlepszym razie będzie nieefektywne i kosztowne, a w najgorszym przyczyni się do dalszej utraty danych. Gdy każdy we własnym zakresie zajmuje się archiwizowaniem, można stracić sporo pieniędzy na opłacenie ludzi i zakup dodatkowego sprzętu. Czas Ile osób obsługuje komputery? Ile pracy pójdzie na marne, gdy w zaprojektowanym środowisku dojdzie do utraty danych? Znam wiele firm mających kilku kontraktowych programistów nieustannie piszących kod. Jeśli przepadnie część kodu przechowywanego w systemie, o jakiej stracie finansowej będzie mowa? W rzeczywistości jest tak, że gdy w dowolnym dziale firmy wyniki pracy są przechowywane na komputerze i dochodzi do utraty danych, kosztuje to dużo czasu i pieniędzy.
Jaki będzie koszt przestoju? Planując procedurę archiwizowania i odtwarzania danych, można wybierać spośród kilku opcji mających wpływ na szybkość odtwarzania. Im szybciej proces ten przebiega, tym bardziej kosztowny jest system archiwizowania. Przed podjęciem decyzji dotyczącej takich opcji trzeba zadać sobie następujące pytanie: „Jak kosztowny będzie przestój?”. Gdy o tym myślę, przypomina mi się reklama kopiarki, która brzmiała tak: „Gdy kopiarka przestanie działać, wystarczy powiedzieć ludziom, że nie ma żadnego problemu, ponieważ po prostu użyje się papieru z kalką!”. Jeżeli przestanie funkcjonować jeden z głównych systemów, czy użytkownicy nadal będą mogli kontynuować pracę, czy może cała firma przejdzie w stan spoczynku? Jeśli wystąpi drugi wariant, czy pracownicy będą w dalszym ciągu opłacani? Wtedy wysłanie ich do domu nie da żadnych oszczędności. Oto kilka godnych uwagi dodatkowych kosztów: Postrzeganie przez klientów Klient nie znosi słuchać takich stwierdzeń, jak „Proszę zadzwonić ponownie, ponieważ nasze komputery obecnie nie są sprawne” lub „Połączenie nie jest aktywne”. Zależnie od profilu działalności firmy klienci mogą po prostu udać się do konkurencji. Im dłużej systemy są wyłączone, tym więcej klientów usłyszy powyższe zdania. Postrzeganie przez pracowników Nikt nie chce pracować w firmie, w której komputery nieustannie nie działają. Im więcej pracowników jest zależnych od komputerów, tym bardziej stwierdzenie to jest prawdziwe. Jeśli Czytelnik byłby sprzedawcą, który przez dzień lub dłużej nie może połączyć się z bazą danych, jak bardzo byłby zadowolony? Czas Znów ma miejsce strata czasu. W efekcie nie ma postępów, a pracownicy zależni od dostępności wyłączonego systemu w rzeczywistości są opłacani za nic.
Znalezienie optymalnej metody archiwizowania Używanie systemu bez kopii zapasowych można przyrównać do prowadzenia samochodu z prędkością 160 km/h po ruchliwej drodze dzień po wygaśnięciu polisy ubezpieczeniowej. Podobnie zastosowanie 3-węzłowego, intensywnie wykorzystywanego klastra na potrzeby mało istotnej aplikacji jest jak pełne ubezpieczenie wykupione dla 20-letniego samochodu. Tak jak polisy mają różne poziomy ubezpieczenia (na przykład kierowców rajdowych szczególnie 34
|
Rozdz ał 1. F lozof a arch w zacj
dotyczą różnego typu uszkodzenia), tak różne metody archiwizowania zapewniają różne poziomy odtwarzania danych.
Było blisko Pamiętny moment miał miejsce, gdy dysponowaliśmy serwerem plików o pojemności 600 GB, który przez jakiś czas nie był poprawnie archiwizowany. Podczas wyjątkowo upalnego weekendu zepsuły się oba klimatyzatory w pomieszczeniu i w efekcie wzrosła temperatura. Oczekując na naprawienie klimatyzacji, wszystko wyłączyliśmy, a następnie, gdy sprzęt się ochłodził, rozpoczęliśmy archiwizowanie danych. Jak można było się spodziewać, zepsuły się dwa dyski znajdujące się obok siebie w tej samej macierzy RAID4. Z trudem udało nam się uniknąć całkowitej utraty danych dzięki temu, że znaleźliśmy wolny dysk i wymieniliśmy układy scalone między nim i jednym z uszkodzonych napędów. Dzięki temu uruchomiliśmy dysk i uzyskaliśmy do niego dostęp. Następnego dnia producent dostarczył nam nowe dyski, po czym spędziliśmy mnóstwo czasu na naprawianiu serwera kopii zapasowych. — Theo Van Dinter
Nie należy przesadzać Nie wszystkie środowiska wymagają odtwarzania danych z dokładnością co do minuty. W przypadku wielu środowisk akceptowalna jest możliwość odtworzenia danych systemów zawartych w kopiach zapasowych wykonanych ostatniej nocy. W określonych środowiskach dopuszczalne jest przywrócenie systemu nawet z kopii sporządzonej w zeszłym tygodniu lub miesiącu. Wydanie tysięcy złotych i spędzenie setek godzin na wdrażaniu najwspanialszego na świecie rozwiązania archiwizującego będzie bezsensowne, jeśli nie jest wymagany taki poziom zabezpieczeń. Tego typu problem nie występuje w przypadku większości organizacji. Z kolei znaczna część organizacji nie przeznacza wystarczających środków lub nie dokłada odpowiednich starań, aby zapewnić systemy archiwizowania i odtwarzania. Jednak w innych sytuacjach pieniądze mogą zostać zmarnotrawione na niepotrzebnie rozbudowane systemy. W obrębie jednej firmy zmieniają się też wymagania dotyczące możliwości odtwarzania danych na poszczególnych komputerach. Wymagania te mogą być determinowane przez ilość pracy, która może zostać zaprzepaszczona, lub przez możliwość zniechęcenia klienta. Przykładowo za dopuszczalną przez jednego lub dwóch pracowników może być uznana utrata wyników całodniowej pracy w edytorze tekstu. Jeśli dotyczyłoby to asystenta wiceprezydenta, pracującego nad budżetem departamentu, zakres tolerancji mógłby wyglądać inaczej. Prawdopodobnie zupełnie nie do zaakceptowania będzie utrata wpisów wprowadzanych do firmowej bazy danych sprzedaży, używanej przez setki osób, nawet jeśli chodzi o wpisy z ostatniej godziny. Chodzi o to, że wymagania dotyczące archiwizowania są określane przez wymogi stawiane procesowi odtwarzania danych. Trudność tkwi w znalezieniu i zastosowaniu narzędzia będącego w stanie zapewnić oczekiwany poziom odtwarzania. Weźmy pod uwagę katalogi domowe użytkowników. Jeżeli są one przechowywane lokalnie na stacji roboczej każdego użytkownika, utrata zapisanych na dysku efektów pracy z minionego popołudnia oznaczałaby zmarnowanych kilka godzin. Jeśli jednak katalogi użytkowników znajdują się na serwerze plików NFS obsługującym tysiące użytkowników, mogą pójść na marne tysiące godzin, gdy zastosuje się tylko tradycyjne narzędzia archiwizujące.
Znalez en e optymalnej metody arch w zowan a
|
35
Jeśli niedopuszczalna jest utrata danych sieciowego serwera plików, pod uwagę można wziąć użycie technologii obrazu (ang. snapshot). Odpowiednie oprogramowanie umożliwia wykonanie obrazu napędu lub systemu plików w określonej chwili, a następnie zastosowanie tego obrazu do sporządzenia kopii zapasowej napędu lub systemu plików. Jeżeli kopia zapasowa napędu lub systemu plików zostanie wykonana za pomocą obrazu, będzie uwzględniać spójną zawartość napędu lub systemu plików z chwili utworzenia obrazu. Jeżeli takie rozwiązanie zainteresuje Czytelnika, może przeczytać rozdział 7., w którym opisano emulowanie technologii obrazu za pomocą narzędzia rsync i dowiązań twardych.
Choć czasami wymagane narzędzie dołączono do używanego systemu operacyjnego lub platformy bazodanowej, po prostu nie jest właściwie użytkowane. Czasami narzędzia archiwizujące nie są w ogóle stosowane. Jeśli na przykład dysponuje się produkcyjną bazą danych Oracle, połączenie gorących nocnych kopii zapasowych z archiwizowaniem dzienników powtórzeń zapewnia możliwość odtworzenia danych z dokładnością co do minuty. Jeśli jednak utraci się dysk wchodzący w skład bazy danych, która nie archiwizuje swoich dzienników transakcji, przepadną wszystkie dane od czasu wykonania ostatniej „zimnej” kopii zapasowej. Więcej informacji można znaleźć w części piątej książki. Jeżeli dysponuje się produkcyjną instancją i nie używa funkcji rejestrowania transakcji mechanizmu bazodanowego, należy ją włączyć jak najszybciej!
A zatem nie wystarczy znaleźć właściwe narzędzie zapewniające wymagany poziom odtwarzania danych, trzeba także z niego odpowiednio korzystać.
Uzyskanie wymaganego poziomu zabezpieczeń Niektóre środowiska nie mogą sobie pozwolić nawet na minutę przestoju i powinny być wyposażone w najlepszy system archiwizowania, niezależnie od jego ceny. Wynika to z rozmiaru straty, która nastąpi, gdy systemy będą niedostępne choćby przez krótki okres (wiem o jednej firmie, która twierdzi, że traci ponad milion dolarów na minutę, gdy systemy są wyłączone). A nawet jeśli pracuje się w środowisku, które pozwala na przestój, wydanie ogromnej ilości pieniędzy na natychmiast dostępny „gorący” serwer1 jest zupełnym marnotrawstwem. Przyjrzyjmy się tabeli 1.1. Nikt nie powinien być zależny od samochodu lub komputera, nie mając przynajmniej podstawowego poziomu zabezpieczenia. Jeśli jedyny samochód nie jest ubezpieczony i pijany kierowca spowoduje poważny wypadek, jak pokryć taką stratę? A co zrobić, gdy zepsuje się dysk twardy w systemie przechowującym krytyczne informacje i przepadną wszystkie dane? Część osób zapomina o tym, że ta zależność działa w dwie strony. Jeżeli ktoś nabył już trzeci samochód i ma on 20 lat (i wcale nie jest to model retro), prawdopodobnie wykupi dla niego wyłącznie ubezpieczenie OC. Można będzie żyć bez tego pojazdu w razie jego zniszczenia. Wydanie setek dodatkowych złotych rocznie na ubezpieczenie samochodu wartego 150 zł nie ma po prostu sensu. Podobnie, jeżeli zarządzane komputery znajdują się w środowisku, w którym można się bez nich obyć przez kilka dni, czy naprawdę będą potrzebne
1
„Gorący” serwer to komputer znajdujący się w stanie oczekiwania, który może natychmiast rozpocząć proces przywracania środowiska.
36
|
Rozdz ał 1. F lozof a arch w zacj
lustrzane napędy z możliwością wymiany podczas pracy? Dla środowiska należy określić właściwy poziom ochrony. Tabela 1.1. Porównanie ubezpieczenia samochodu i ochrony danych Typ zabezp eczen a
Ubezp eczen e samochodu
Komputerowe kop e zapasowe
Minimalne zabezpieczenie
Kolizje i odpowiedzialność cywilna (ch oni jedynie p zed ut atą koszulki gdy spowoduje się wypadek)
• Regula ne nocne wykonywanie kopii zapasowych (ch oni p zed ut atą wyników p acy gdy napęd dyskowy zepsuje się)
Nieoczekiwane nieszczęśliwe zda zenia
Pełne zabezpieczenie (wandalizm boskie wy oki itp )
• Rejest ujące systemy plików
Możliwość natychmiastowego p owadzenia samochodu
Zabezpieczenie dotyczące wynajęcia samochodu (ot zymuje się inny pojazd gdy własny na skutek wypadku t afił do nap awy)
• Zasilacze awa yjne UPS (Uninterruptible Power Supply) • Macie z RA D • Kopie lust zane • Zastosowanie napędów wymienianych podczas p acy • System A (High Availability) o wysokim stopniu dostępności
Poważne nieszczęśliwe zda zenia
• Wysłanie kopii za chiwizowanych woluminów do zewnęt znej lokalizacji aby zabezpieczyć się p zed sytuacją gdy zostanie zniszczone za ówno pomieszczenie kompute owe jak i biblioteka nośników
nna fi ma p zejmie polisę i wymieni samochód jeśli za ówno on jak i dotychczasowa fi ma ubezpieczeniowa zostały zniszczone w wyniku t zęsienia ziemi
• Wysłanie kopii zapasowych za poś ednictwem dedykowanej sieci do dużego systemu magazynowania znajdującego się po st onie dostawcy usług składowania Maksymalna och ona
Fi ma ubezpieczeniowa nie tylko zgodzi się na wcześniej wymienione wa unki ale ównież na umieszczenie tego samego modelu samochodu (będącego do pełnej dyspozycji) w innej lokalizacji gdy wszystkie takie pojazdy w miejscu zamieszkania lub siedzibie fi my zostały zniszczone
• Wykonywanie kopii lust zanych w czasie zeczywistym na systemie umożliwiającym wymianę nośników podczas p acy i znajdującym się w innym oddziale fi my • Wysłanie kopii zapasowych za poś ednictwem sieci lub ku ie a do dostawcy „go ących” se we ów
Trzeba zrównoważyć koszt określonego rozwiązania archiwizującego z przewidywaną stratą finansową spowodowaną przestojem, przed którym rozwiązanie ma chronić. Dla przykładu załóżmy, że analizuje się dwa warianty archiwizowania. Pierwszy wariant uwzględnia wysyłanie kopii zarchiwizowanych woluminów do zewnętrznego dostawcy usług magazynowania (miesięczny koszt wynosi 500 zł). Drugi wariant polega na zastosowaniu natychmiast dostępnego komputera w stanie oczekiwania, umieszczonego w innym mieście. Komputer ten odbiera co minutę z serwera produkcyjnego replikowane dane. Przyjmijmy, że miesięczny koszt tego rozwiązania to 5000 zł. Firma znajduje się w Utopii, gdzie dotąd nie miały miejsca żadne klęski żywiołowe, a dyski są w całości kopiowane. Stwierdzono, że koszt dziennego przestoju wyniósłby tylko 500 zł. Czy naprawdę warto wydać 60 000 zł rocznie na zabezpieczenie przed czymś, co prawdopodobnie nigdy nie nastąpi? Jeśli centrum danych przydarzy się coś katastrofalnego w skutkach, czy równie dobrze nie sprawdzą się jednodniowe kopie przechowywane na zewnątrz? Choć firma miałaby dodatkowy dzień przestoju lub trochę więcej, wcześniej stwierdzono, że na coś takiego może sobie pozwolić. W przypadku takiego środowiska prawdopodobnie znacznie bardziej odpowiednie byłoby rozwiązanie kosztujące rocznie 6000 zł. Znalez en e optymalnej metody arch w zowan a
|
37
Jednak czy zabezpieczono się przed wszystkim, przed czym należałoby się zabezpieczyć? Czy firma jest zlokalizowana w obszarze podatnym na klęski żywiołowe, a jeśli tak, to czy stosuje ochronę przed tego typu zdarzeniami? Być może pod uwagę trzeba wziąć innego typu magazynowanie na zewnątrz firmy. Jeśli dysponuje się bazą klientów wymagającą regularnego dostępu do danych znajdujących się na komputerach, czy zapewniono możliwość szybkiego odtworzenia na wypadek awarii? Być może z myślą o serwerach bazodanowych powinno się uwzględnić użycie „gorącej” lokalizacji lub przechowywanie kopii lustrzanych w wielu miejscach. Tabela 1.1 to przegląd różnych poziomów zabezpieczenia.
Dlaczego używa się terminu „wolumin” zamiast „taśma”? Większość narzędzi archiwizujących pierwotnie stworzono z myślą o zapisywaniu danych na taśmie. W związku z tym książki i sieciowe podręczniki przeważnie omawiają archiwizowanie na taśmie. Jednak wiele osób umieszcza kopie zapasowe na dyskach CD, dyskach magnetooptycznych, a nawet napędach dyskowych. Tego typu nośniki mają wiele zalet, ponieważ pod względem działania przypominają bardziej napędy dyskowe niż taśmowe. Dostęp losowy do zarchiwizowanych danych jest prostszy, a ponadto można je odczytywać w blokach o dowolnym wybranym rozmiarze. Wynika to stąd, że napędy dyskowe, w przeciwieństwie do taśmowych, nie zapisują przerw między rekordami. Ponieważ wiele osób nie korzysta już z taśm, w książce, gdy jest to właściwe, stosuje się bardziej ogólny termin wolumin. Zamiast terminu napęd taśmowy Czytelnik napotka też pojęcie napęd archiwizujący. To dlatego, że napędem archiwizującym może być zarówno nagrywarka dysków CD, jak i napęd dyskowy. W książce terminy taśma i napęd taśmowy są używane tylko wtedy, gdy jest to konieczne i właściwe. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www.backup ¦central.com można znaleźć zaktualizowane informacje lub dodać do nich własne.
38
|
Rozdz ał 1. F lozof a arch w zacj
ROZDZIAŁ 2.
Archiwizowanie wszystkich danych
Gdy już Czytelnik zapoznał się z filozoficznymi wywodami z rozdziału 1., pora przyjrzeć się niektórym istotnym pojęciom dotyczącym archiwizowania i odtwarzania danych. Dzięki nim będzie wiadomo, co uwzględnić w kopii zapasowej, kiedy przeprowadzać archiwizację danych itp.
Nie wolno pomijać tego rozdziału! Zwykły Czytelnik może przyjąć, że niniejszy rozdział stanowi wprowadzenie do podstawowych zagadnień związanych z archiwizowaniem. Choć faktycznie jest to cel tego rozdziału, prawdziwe jest również to, że wielu doświadczonym administratorom przedstawione tu pojęcie są nieznane. Jest tak między innymi dlatego, że administratorzy nieustannie są odciągani od typowych zajęć, takich jak archiwizowanie, aby robić rzeczy uważane za „ważniejsze” (na przykład instalowanie nowych serwerów i stwierdzanie, które systemy wolno działają). Ponadto administratorzy nawet przez kilka lat mogą nie musieć odtwarzać danych. Konieczność regularnego stosowania kopii zapasowych bez wątpienia zmieniłaby sposób postrzegania ich ważności. Napisałem tę książkę, ponieważ przez kilka lat archiwizacja i odtwarzanie danych stanowiły dla mnie podstawowy obszar działalności. Chciałbym przekazać wiedzę, którą zdobyłem w tym okresie. W niniejszym rozdziale pokrótce omówiłem, w jaki sposób powinny funkcjonować kopie zapasowe. Wyjaśniłem też wiele podstawowych, a zarazem wyjątkowo ważnych pojęć, na których powinien bazować każdy dobry plan archiwizowania. Na takim planie są oparte wszystkie wdrożenia przedstawione w książce.
Niewykonalne zadanie, którego nikt nie chce się podjąć Czy ktokolwiek czytający tę książkę powie, że utrata danych jest czymś dobrym? Nie wierzę w to. A zatem dlaczego traktuje się kopie zapasowe tak mało poważnie? Czasami czuję się jak Rodney Dangerfield, gdy walczę o to, aby wykonywać lepsze kopie zapasowe — „Mówię Ci, że nie ma dla mnie za grosz szacunku”. Kopie zapasowe często nie są uwzględniane podczas projektowania systemu. Czy gdy ktoś kupuje nowy serwer, pyta o jego wpływ na obecnie stosowaną metodę archiwizowania danych? Niektóre działy informatyczne nie kontrolują nawet procesu nabywania nowych systemów, ponieważ czasami są one kupowane przez inne centra, odpowiedzialne za finanse. Czy kiedykolwiek próbowano wyjaśnić kierownikowi innego działu, dlaczego jego terabajtowy serwer bazodanowy nie będzie archiwizowany na dołączonym niezależnym napędzie taśmowym używającym taśm o gigabajtowej pojemności? 39
Następną często pomijaną kwestią jest personel odpowiedzialny za archiwizację. Czy kiedykolwiek próbowano szukać osób, które będą zajmować się kopiami zapasowymi? Często jest to dodatkowy obowiązek, którym obarcza się różne osoby, podobnie gdy ja, moja siostra i brat ustalaliśmy, kto tym razem będzie zmywać naczynia. Jeśli szczęśliwie wyznaczono osobę odpowiedzialną za archiwizowanie danych, zwykle będzie to najmłodszy stażem pracownik firmy. Wiem o tym, ponieważ właśnie w ten sposób zacząłem moją pierwszą pracę. W rzeczywistości wiele osób tak właśnie zaczyna pracować. Jak można czemuś tak ważnemu nadać tak niski priorytet? Być może powinno się to zmienić. Czy jedna książka spowoduje zmianę tak długotrwałej tradycji zatrudniania pracowników? Prawdopodobnie nie, ale być może okaże się pomocna. W najgorszym razie, gdy ktoś odpowiedzialny za sporządzanie kopii zapasowych kupi tę książkę, będzie miał kompletny przewodnik pozwalający wykonać to naprawdę pokaźne zadanie. Można zapytać, co w tym takiego pokaźnego? Dlaczego kopie zapasowe są tak istotne przy nowoczesnych systemach komputerowych i niezawodnych napędach dyskowych? Dlatego, że komputery w dalszym ciągu psują się. Ponadto firmy bardziej niż kiedykolwiek wcześniej ufają w ich niezawodność. Niezależnie od tego, jak dobry jest producent używanego systemu Unix lub jak niezawodne są napędy dyskowe, systemy nie będą zawsze sprawne. Nie pomoże tu nawet zatrudnienie Dogberta jako administratora sieci. W przypadku systemów komputerowych obowiązuje prawo Murphy’ego. Systemy nie tylko będą mieć sporadyczne awarie, ale też będzie to następować w porze najmniej odpowiedniej dla firmy i jej klientów. W takiej chwili — a ta chwila kiedyś nadejdzie — zadaniem osoby wykonującej kopie zapasowe będzie odtworzenie danych znajdujących się na dysku lub dyskach, które odmówiły posłuszeństwa. Typowe pytanie brzmi: „Ile to potrwa?”. Jedyna dopuszczalna odpowiedź to: „Już zrobione”. Kto chciałby być tym, który nie poradził sobie z odtwarzaniem danych i w efekcie spowodował, że baza danych klientów była niedostępna przez dodatkowe trzy godziny? Kto chciałby być tym, który musi rozesłać po całej firmie informację o konieczności ponownego wprowadzenia wszystkich zamówień z ostatnich dwóch dni? Kto chciałby być tym, który będzie o tym myśleć codziennie podczas sprawdzania wyników operacji archiwizacji przeprowadzonej zeszłej nocy? Jeśli ktoś nie doprowadził do utraty danych, oznacza to, że po prostu robi to, co powinien. Jeżeli nie wykonuje rzetelnie swoich obowiązków, napotka na spore problemy. Kto chce dostać taką pracę? Z pewnością nikt. Czytelnik kupił tę książkę, ponieważ ma niewykonalne zadanie, którego nikt nie chce się podjąć. Niezależnie od tego, czy archiwizowaniem danych Czytelnik zajmuje się od jakiegoś czasu, czy dopiero zaczął się tym zajmować, może stwierdzić, że jest to spore zadanie. Ilość danych jest ogromna, ich natura ciągle się zmienia, tymczasem dostępne narzędzia nigdy nie wydają się spełniać oczekiwań. Wiem to, ponieważ sam się z tym borykałem. Spędziłem wiele miesięcy, próbując wdrożyć „rozwiązania” oferowane przez systemy operacyjne i bazy danych, które nie były odpowiednio przygotowane. Spotkałem się z firmami wydającymi pieniądze na kosztowne komercyjne narzędzia tylko po to, aby zostać ze złym oprogramowaniem, niespełniającym ich wymagań. Widziałem instalacje nowszych i większych serwerów niemających nawet jednego napędu archiwizującego. Spędziłem również długie noce i weekendy w pomieszczeniach komputerowych, próbując odtworzyć dane w „rozsądnym” czasie. Niestety, termin „rozsądny” jest definiowany przez końcowego użytkownika, który nie ma pojęcia, jak trudnym zadaniem jest odtwarzanie danych.
40
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Obecnie istnieją rozwiązania dla niemal każdego problemu dotyczącego kopii zapasowych. Dla niewielkiego sklepu z zaledwie kilkoma komputerami, z których każdy będzie działał pod kontrolą identycznego systemu operacyjnego, istnieje dobre rozwiązanie. Dla dużego sklepu z setkami komputerów z różnymi odmianami systemów Unix, Linux, Windows i Mac OS lub tylko kilkoma bazami danych o pojemności wielu terabajtów również dostępne jest odpowiednie rozwiązanie. Największym problemem jest dezinformacja. Większość osób po prostu nie wie, co jest dostępne. W związku z tym obchodzą się bez żadnego rozwiązania lub korzystają z gorszego (zwykle poleconego przez obrotnego sprzedawcę). Oto sześć ważnych pytań, które trzeba cały czas zadawać sobie i innymi: Dlaczego? Dlaczego stosujemy ochronę przed awarią? Czy naprawdę stanie się coś złego, gdy dojdzie do utraty danych? Jakie będą tego konsekwencje? Jakiego typu dane mamy i jaka jest ich wartość? Co?
Co będzie archiwizowane? Zawartość całego komputera czy tylko wybrane napędy lub systemy plików? Jakie systemy operacyjne będą archiwizowane? Co jeszcze, poza standardowymi napędami lub systemami plików, powinno zostać uwzględnione w kopii zapasowej?
Kiedy? Kiedy jest najlepszy moment na archiwizowanie systemu? Jak często powinno się wykonywać pełną kopię zapasową? Kiedy powinno się sporządzać przyrostową kopię zapasową? Gdzie? Gdzie zostanie umieszczona kopia zapasowa? Jakie jest najlepsze miejsce do przechowywania woluminów z kopiami zapasowymi? Kto? Kto zapewni sprzęt, oprogramowanie i usługi instalacyjne, które połączą wszystko w jeden system? Jak?
W jaki sposób przeprowadzimy archiwizację? Istnieje kilka różnych metod ochrony przed utratą danych. Należy zapoznać się z odmiennymi rozwiązaniami, takimi jak przechowywanie poza obrębem określonej lokalizacji, replikacja, wykonywanie kopii lustrzanych, macierze RAID, a także różnymi poziomami ochrony oferowanymi przez poszczególne metody (każde z wymienionych zagadnień omówiono szczegółowo w dalszej części książki).
Dlaczego archiwizuje się dane? Jeśli Czytelnik nie umie odpowiedzieć na to pytanie, naprawdę nie ma sensu, aby czytał dalej. Dobrą wiadomością jest to, że na to pytanie naprawdę łatwo odpowiedzieć. Wystarczy pomyśleć o wszystkim, co może przydarzyć się przechowywanym danym, i przyjrzeć się każdemu ich rodzajowi. Należy się zaznajomić z każdą jednostką firmy tworzącą dane, a także dowiedzieć się, jak na ich funkcjonowanie wpłynie utrata lub uszkodzenie danych. Wszystko to uzasadnia dalsze działanie.
Dlaczego arch w zuje s ę dane?
|
41
Co należy archiwizować? Doświadczenie pokazuje, że jednym z najczęstszych powodów utraty danych jest to, że nigdy ich nie uwzględniono w kopii zapasowej. Decyzja dotycząca tego, co należy archiwizować, jest istotna.
Przygotowanie się na najgorsze Przed podjęciem decyzji, jakie pliki należy dodać do kopii zapasowych, powinno się zaprosić na obiad najbardziej pesymistycznie nastawionego pracownika technicznego firmy. W rzeczywistości warto spotkać się z kilkoma takimi osobami. Dodatkowo należy poprosić je o przedstawienie sytuacji, przed którymi chciałyby być chronione. Sytuacje te należy uwzględnić przy decydowaniu, co powinno zostać dodane do kopii zapasowej. Sytuacje te będą też pomocne podczas określania sposobu archiwizowania. Gościom zaproszonym na obiad należy zadać następujące pytanie: „Jakie są absolutnie najgorsze scenariusze, które mogą spowodować utratę danych?”. Oto kilka możliwych odpowiedzi: • Cały system pada ofiarą pożaru i doszczętnie spala się. Pozostaje sterta nierozpoznawal-
nych, stopionych metalowych elementów i sczerniałego, kopcącego się plastyku.
• Ponieważ komputer był tak bardzo ważny, trzeba go było replikować za pomocą następ-
nego węzła, znajdującego się tuż obok. Oczywiście ten komputer zapali się razem z pierwszym.
• Jest centralny serwer, który kontroluje wszystkie kopie zapasowe, monitoruje lokalizacje
woluminów z kopiami zapasowymi i typ przechowywanych na nich plików itp. Serwer, który został zniszczony, umieszczono obok tego „serwera archiwizującego”. W efekcie intensywny żar spowodował również jego dewastację.
• Katastrofalna reakcja łańcuchowa uszkodziła serwery DHCP i Active Directory, główny
serwer NIS, serwery NFS i CIFS z katalogami użytkowników, a także serwer bazodanowy inwentaryzujący wszystkie woluminy z kopiami zapasowymi i ich lokalizacjami. Ostatni z wymienionych komputerów przechowuje też telefoniczną bazę danych z wszystkimi umowami dotyczącymi usług, numerami dostawców i procedurami eskalacji.
• Ktoś nie mógł zapamiętać numeru do nowego dostawcy zewnętrznego magazynu, więc
przykleił go taśmą do ściany tuż obok serwera archiwizującego. Oczywiście płomienie właśnie spaliły kartkę do tego stopnia, że nie można jej odczytać.
• Płomienie uaktywniły system gaszenia i woda leje się na woluminy z kopiami zapasowymi.
Ale zły dzień…
Jak postąpić, gdy jeden z powyższych scenariuszy faktycznie się spełni? Czy w ogóle wiadomo, od czego zacząć? Czy wiadomo: • Jaki wolumin zawiera kopię wykonaną ostatniej nocy? • Gdzie kopię zapisano? • Jak skontaktować się z dostawcą zewnętrznego magazynu, aby pobrać kopie woluminów
z zarchiwizowanymi danymi? A czy po ich znalezieniu serwer i sprzęt sieciowy będą gotowe do przeprowadzenia procesu odtwarzania?
• Do kogo zadzwonić w celu wymiany sprzętu w niedzielę o drugiej w nocy? • Jaka była struktura sieci, zanim spaliły się wszystkie kable? 42
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Najpierw trzeba odtworzyć serwer archiwizujący, ponieważ zawiera wszystkie niezbędne informacje. Przyjmijmy, że udało się znaleźć w portfelu wizytówkę firmy archiwizującej i uzyskać każdy zarchiwizowany wolumin. Ponieważ przepadła baza danych nośników, skąd będzie wiadomo, który z nich przechowuje kopię wykonaną ostatniej nocy? A czas ucieka… Załóżmy, że udało się przeszukać wszystkie woluminy i znaleźć ten, którego trzeba użyć do odtworzenia serwera archiwizującego (łatwiej powiedzieć, niż wykonać!). Dzięki własnym umiejętnościom i sprytowi, a także wydatnej pomocy obsługi technicznej, odtworzono dane. Wszystko jest dostępne i funkcjonuje. Ile dysków znajdowało się w komputerze, który został zniszczony? Jakie to były modele dysków? Jak zostały podzielone na partycje? Czy część dysków nie została za pomocą paskowania połączona w celu uzyskania większych woluminów? Czy niektóre dyski nie stanowiły kopii lustrzanej innych dysków? Gdzie te informacje są przechowywane? Czy w ogóle wiadomo, jaką pojemność miały napędy lub systemy plików? To naprawdę staje się skomplikowane…
Moje oko sprawdzono Firma biotechnologiczna z kilkoma serwerami uważanymi za systemy sprawdzone pod kątem zastosowań FDA CFR21 straciła krytyczną bazę danych uruchomioną na jednym z serwerów. Gdy pracownicy firmy udali się do serwera archiwizującego, aby odtworzyć dane, ku swemu przerażeniu odkryli, że serwer z bazą danych nie był objęty archiwizacją od mniej więcej trzech miesięcy. W jakiś sposób serwer usunięto z harmonogramu archiwizacji. W związku z tym nie były generowane żadne „błędy”. W efekcie pracownicy firmy pozostali bez czegokolwiek, co pozwoliłoby uzyskać aktualną kopię zapasową. Problem był na tyle poważny, że dotarł do samego prezesa zarządu. — Jim Damoulakis
Czy nie przeprowadzono w zeszłym tygodniu sporej aktualizacji jądra na trzech komputerach (poprawkę eliminującą wszystkie ataki sieciowe polegające na zmasowanym wysyłaniu pakietów, które przeciążały sieć w środku dnia)? Czyż nie wykonano kopii zapasowej jądra po jego aktualizacji? Oczywiście poprawka uaktualniła pliki w obrębie całego napędu z systemem operacyjnym. Czyż nie sporządzono pełnej kopii zapasowej? Jak odtworzy się zawartość napędu z systemem operacyjnym? Czy naprawdę zamierza się przejść przez proces ponownej instalacji systemu operacyjnego tylko po to, aby można było uruchomić narzędzie restore i jeszcze raz nadpisać system? Systemy plików nie narzekają na pojemność, dopóki mają wystarczający rozmiar, aby móc przechowywać odtwarzane dane. Dlatego niezbyt trudne jest skonfigurowanie i uaktywnienie takich systemów plików. A jak wygląda to w przypadku bazy danych używającej niesformatowanych partycji? Wiadomo, że będzie to znacznie bardziej złożone. Systemy plików będą wymagały umieszczenia urządzeń: /dev/rdsk/c7t3d0s7, /dev/dsk/c8t3d0s7 i /dev/dsk/c8t4d0s7 dokładnie tam, gdzie znajdowały się wcześniej, i poddania ich partycjonowaniu tak samo jak przed awarią. Dodatkowo właścicielem urządzeń musi być użytkownik bazy danych. Czy wiadomo, których napędów właścicielem był ten użytkownik przed wystąpieniem awarii? A których po? Może się to zdarzyć.
Co należy arch w zować?
|
43
W części czwartej omówiono powyższe sytuacje.
Inwentaryzowanie Trzeba się upewnić, że w razie nieszczęśliwego zdarzenia są dostępne następujące kluczowe informacje: Kopie kopii zapasowych Wiele firm zaczęło centralizować zarządzanie swoimi kopiami zapasowymi, co według mnie jest dobrym posunięciem. Jednak gdy centralizuje się magazynowanie informacji dotyczących wszystkich kopii, z całym planem archiwizowania jest związany pojedynczy punkt awarii. Nie będzie można odtworzyć serwera archiwizującego, ponieważ nie jest dostępna baza danych kopii zapasowych. Nie ma takiej bazy, gdyż trzeba najpierw odtworzyć serwer archiwizujący. Operacja taka byłaby pierwszym krokiem w przypadku dowolnej awarii wielu systemów. W kwestii takiej jak inwentaryzacja nośników nie należy lekceważyć wartości wydrukowanego zestawienia przechowywanego poza obszarem firmy. Wydruk taki może po prostu uchronić przed wieloma problemami. Jeśli punkt awarii jest jeden, odtwarzanie serwera archiwizującego powinno być jak najprostszą i jak najlepiej udokumentowaną operacją. Można nawet rozważyć utworzenie narzędziem tar, ntbackup lub rsync specjalnej kopii zapasowej danych, która jeszcze bardziej uprości odtwarzanie po wystąpieniu awarii. Jakie urządzenia peryferyjne były dostępne? Zakładając, że regularnie archiwizuje się konfigurację napędów dyskowych, można dysponować listą wszystkich dysków. Czy jednak wiadomo, jakie są modele używanych napędów? Jeśli wszystkie napędy są marki X i mają pojemność 500 GB, nie będzie problemu. Jednak wiele serwerów jest wyposażonych w kilka różnych napędów instalowanych w dłuższym okresie. W obrębie jednego komputera może się znajdować kombinacja napędów o pojemnościach 40, 100 i 500 GB. Trzeba zadbać o to, aby w jakiś sposób zapisać te informacje. Systemy Unix i Mac OS rejestrują je w pliku messages, a system Windows w rejestrze. Dlatego mam nadzieję, że Czytelnik archiwizuje plik messages i rejestr systemu Windows. W jaki sposób dokonano podziału na partycje? To pytanie może naprawdę być istotne, gdy trzeba będzie odtworzyć zawartość napędu z systemem operacyjnym lub bazą danych. Oba typy napędów zwykle są partycjonowane przy użyciu niestandardowych partycji, które muszą być określone dokładnie tak samo jak wcześniej, aby można było poprawnie przeprowadzić proces odtwarzania. Zazwyczaj informacje na temat partycji nie są nigdzie przechowywane w systemie. W związku z tym trzeba zrobić coś dodatkowego, aby je zapisać. Przykładowo w systemie Solaris dla każdego napędu można uruchomić program prtvtoc i informacje zapisać w pliku. W internecie można poszukać skryptów, które gromadzą tego typu informacje. Dostępnych jest też kilka przeznaczonych do tego darmowych narzędzi. Jak skonfigurowano menedżery woluminów? Dostępnych jest kilka menedżerów woluminów dołączonych do konkretnych systemów operacyjnych. Spośród nich wymieńmy: Veritas Volume Manager, Windows Dynamic Drives, Solstice (Online) Disk Suite i Logical Volume Manager firmy HP. Jak skonfiguro-
44
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
wano używany menedżer woluminów? Jakie urządzenia są objęte tworzeniem kopii lustrzanych? Jak skonfigurowano urządzenia wielodyskowe? Może trudno w to uwierzyć, ale takie informacje nie zawsze są rejestrowane przez zwykłe narzędzia archiwizujące. Przez wiele miesięcy korzystałem z menedżera Logical Volume Manager, zanim się dowiedziałem o istnieniu narzędzia lvmcfgbackup (archiwizuje dane konfiguracyjne menedżera LVM). Jeśli poprawnie udokumentowano konfigurację menedżera woluminów, czasami odtwarzanie w ogóle może nie być konieczne. Jeśli na przykład zepsuje się dysk systemu operacyjnego, wystarczy skonfigurować dyski tak jak wcześniej, a następnie w identyczny sposób ponownie określić paskowanie. W efekcie dane powinny być nienaruszone. Robiłem coś takiego kilkakrotnie. Jak skonfigurowano bazy danych? Miałem do czynienia z wieloma przestojami baz danych. Gdy pytam administratora baz danych, jak je skonfigurował, prawie zawsze odpowiedź brzmi: „Nie jestem pewien…”. Należy odszukać informacje na temat konfiguracji i zapisać je w widocznym miejscu. Czy udokumentowano konfigurację serwerów: DHCP, Active Directory, NFS i CIFS? Dokumentować i jeszcze raz dokumentować! Istnieją setki powodów, aby poprawnie dokumentować takie rzeczy, jak konfiguracja tych serwerów. Jednym z nich jest odtwarzanie po wystąpieniu awarii. Dobra dokumentacja jest konkretnym elementem planu archiwizowania. Dokumentacja powinna być regularnie aktualizowana i dostępna. Nikt nie powinien mówić: „Od wielu lat nie konfigurowałem od podstaw serwerów NIS, Active Directory i NFS. Jak w takiej sytuacji ponownie wykonać tego typu operację? Czy ktoś ma egzemplarz mojej książki?”. W rzeczywistości w tej sytuacji najlepszym rozwiązaniem jest zautomatyzowanie tworzenia nowych serwerów. Jeśli system operacyjny pozwala na to, należy poświęcić czas na napisanie skryptów automatyzujących instalowanie różnych usług i konfigurujących je pod kątem stosowanego środowiska. Skrypty należy zawrzeć w pakiecie uruchamianym każdorazowo podczas konfigurowania nowego serwera. Jeszcze lepsze będzie sprawdzenie, czy producent systemu operacyjnego oferuje produkty automatyzujące instalację nowych serwerów (na przykład Jumpstart firmy Sun, Ignite-UX firmy HP, Linux Kickstart i funkcje powielania systemu Mac OS). Czy dysponuje się planem działania? Mało przyjemne scenariusze zostały przedstawione na początku, aby zmotywować Czytelnika, by zaczął przygotowywać plan. Nie należy czekać z zakupem szufli, aż przed domem nagromadzi się 6-metrowa warstwa śniegu! Śnieg spadnie. Pytanie tylko kiedy. Warto zaprosić pesymistów z firmy na obiad i pozwolić im, aby wyobrazili sobie najgorsze scenariusze, które mogą mieć miejsce, a następnie przygotować plan działania. Trzeba dysponować w pełni udokumentowanym krok po kroku planem przewidującym koniec świata komputerowego. Jeśli nawet plan będzie wymagał niewielkiej modyfikacji, gdy faktycznie trzeba będzie z niego skorzystać, dobrze będzie móc od czegoś zacząć. Jest to o wiele lepsze niż stwierdzenie: „Co teraz wiemy? Czy ktoś widział moje zestawienie?” (sporządzono jego papierowy wydruk, zgadza się?). Trzeba wiedzieć, co tkwi w komputerach! Dla osoby zajmującej się archiwizowaniem i odtwarzaniem danych najlepszym zabezpieczeniem przed niemal każdego rodzaju stratą jest znajomość chronionych komputerów. Jeśli określony serwer przestanie działać, powinno się od razu wiedzieć, że znajduje się na nim baza danych Oracle lub SQL Server, która obsługuje konkretne woluminy. Dzięki takiej wiedzy można natychmiast rozpocząć odtwarzanie serwera. Należy mocno zaangażować się w instalację każdego nowego systemu lub bazy danych. Powinno się wiedzieć, jakie są Co należy arch w zować?
|
45
używane platformy bazodanowe i jak je skonfigurowano. Powinno się dysponować informacjami na temat wszystkich nowych napędów, systemów plików, baz danych lub systemów. Trzeba bardzo dobrze zaznajomić się z każdym komputerem, z jego przeznaczeniem i zawartością. Wiedza taka jest o tyle istotna, że należy przewidzieć wykonywanie specjalnych kopii zapasowych.
Warto przeglądać dzienniki Było to moje pierwsze zlecenie po ukończeniu uczelni. Miałem przede wszystkim obsługiwać zwykłe komputery, ucząc się u boku dobrze opłacanego konsultanta od Uniksa, któremu nadam imię Fred. Obsługiwaliśmy aplikację walutową ForEx o nazwie Opus, którą uruchomiono pod systemem SunOS. Gdy program zapisywał transakcje walutowe, połowę informacji umieszczał w ścieżce. Jeśli na przykład ktoś zrealizował 15 czerwca walutową transakcję dolarowo-funtową z kimś z banku Bank of New York, ścieżka i nazwa pliku wyglądały tak: /opt/app/opus/transactions/portfolio/thirdparty/...itd...itd.../USD/CAI/GBP/BONY/ask/19970615120453.2372149821335
Choć taki mało sympatyczny zapis nie był z pewnością winą Freda, postanowił uwzględnić go w procesie archiwizowania. Zauważyłem, że zdefiniował zadanie tar z opcją -v, które generowało dzienniki na tyle duże, że nie chciało mu się ich przeglądać. Gdy usunąłem opcję -v i zacząłem sprawdzać dzienniki, stwierdziłem, że kopie zapasowe były niepoprawnie wykonywane. Wersja narzędzia tar dodawana w tamtym czasie do systemu SunOS obcinała ścieżki plików o długości przekraczającej 100 znaków. Ścieżki transakcji walutowych były za długie o mniej więcej 9 znaków. Fred po prostu archiwizował narzędziem tar ogromne drzewo katalogów pozbawione plików. Jeśli kiedykolwiek przejrzałby dzienniki, wiedziałby o tym. Następnego dnia zostałem głównym administratorem systemu Unix. Firma nie przedłużyła kontraktu z Fredem. — Jim „Sparky” Donnellan
Czy archiwizuje się to, co faktycznie zaplanowano? Pamiętam administratora pracującego u jednego z moich poprzednich pracodawców, który mówił: „Czy znalazło się to na taśmie?”. Zawsze zadawał to pytanie z charakterystycznym uśmiechem. Był to taki jego sposób witania się z osobą zajmującą się archiwizowaniem. Jego pytanie ma sens. Istnieje kilka ogólnych metod tworzenia kopii zapasowych, dzięki którym można w znacznym stopniu zwiększyć ich efektywność. Zanim zastanowimy się, czy archiwizować część systemu czy cały system, przyjrzyjmy się powszechnej praktyce używania list dołączeń i stwarzanym przez nie zagrożeniom. Ponadto przeanalizujmy niektóre metody, których można uniknąć w przypadku stosowania list dołączeń. Czym są listy dołączeń i wykluczeń? Ogólnie mówiąc, można wyróżnić dwie metody archiwizowania systemu: • Można poinstruować system archiwizujący, aby zarchiwizował wszystko z wyjątkiem tego,
co znajduje się na liście wykluczeń. Oto przykład: • Serwery z systemami Unix, Linux i Mac OS: Dołącz: * Wyklucz: /tmp, /junk1, /junk2
46
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
• Serwery z systemem Windows: Dołącz: * Wyklucz: *.tmp, *Temporary Internet Files*, ~*.*, *.mp3
• Można poinstruować system archiwizujący, aby zarchiwizował to, co znajduje się na liście
dołączeń. Oto przykład:
• Serwery z systemami Unix, Linux i Mac OS: Dołącz: /data1, /data2, /data3
• Serwery z systemem Windows: Dołącz: D:\, E:\
Po przyjrzeniu się powyższym przykładom można zadać sobie pytanie: „Co się stanie, gdy utworzy się katalog /data4 lub doda napęd F:\?”. Ktoś musi pamiętać o dodaniu katalogu lub napędu do listy dołączeń, w przeciwnym razie nie zostaną uwzględnione w kopii zapasowej. Jest to przepis na spore problemy. Jeśli nie jest się jedyną osobą, która dodaje napędy lub systemy plików, i nie ma się doskonałej pamięci, zawsze przeoczy się jakiś napęd lub system plików. Dopóki są inni administratorzy i w głowie ma się substancję szarą, coś zostanie pominięte.
Nie cierpię, gdy to się dzieje Pracowałem w większej firmie wydawniczej, gdy przestał działać serwer obrazów. Gdy zainteresowane osoby udały się do administratora kopii zapasowych i poprosiły o odtworzenie wszystkich obrazów znajdujących się na serwerze, okazało się, że nie dysponował żadnymi danymi z tego komputera. Powodem było to, że po dodaniu rok wcześniej serwera do środowiska produkcyjnego nikt oficjalnie nie zażądał, aby uwzględnić go w systemie archiwizacji. W efekcie firma straciła tysiące obrazów. — Chris Pritchard
Jeśli jednak narzędzie archiwizujące nie obsługuje automatycznego wykrywania napędu lub systemu plików, niewiele wysiłku trzeba, aby stwierdzić: „Trzeba wszystko zarchiwizować”. W jaki sposób sporządza się listę systemów, napędów, systemów plików i baz danych, które mają zostać uwzględnione przez proces archiwizacji? W tym celu trzeba poszukać plików, takich jak /etc/vfstab lub rejestry systemu Windows, a następnie wyodrębnić listę napędów lub systemów plików, dla których wykona się kopię zapasową. Można następnie za pomocą list wykluczeń wyłączyć wszelkie napędy lub systemy plików, które nie mają być archiwizowane. Serwer bazodanowy Oracle dla systemu Unix ma plik o nazwie oratab, który może posłużyć do przechowywania listy wszystkich instancji bazodanowych serwera1. Oczywiście system Windows przechowuje takie informacje w rejestrze. Za pomocą pliku oratab można wyszczególniać wszystkie instancje wymagające archiwizacji. Niestety, bazy danych Informix i Sybase nie oferują takiego pliku. Trzeba go utworzyć ręcznie. Zachęcam do zrobienia tego z wielu powodów. Dysponując takim plikiem, znacznie łatwiej normalizować proces uruchamiania systemu i wykonywania kopii zapasowych. Jeśli tak skonfiguruje się skrypty startowe, że baza danych nie będzie uaktywniana, gdy nie będzie jej w tym pliku, można być niemal pewnym, 1
Instancję serwera Oracle można zainstalować bez umieszczania jej w tym pliku. Jednakże instancja nie zostanie uruchomiona po ponownym załadowaniu systemu. Zwykle oznacza to, że administrator baz danych woli sam uwzględnić instancję w pliku. Więcej na ten temat można znaleźć w rozdziale 15.
Co należy arch w zować?
|
47
że w pliku znajdą się wszystkie istotne bazy danych. Oznacza to oczywiście, że wszelkie ważne bazy danych są archiwizowane bez konieczności ręcznej interwencji administratora. Oznacza to również, że w przypadku każdego komputera można użyć tych samych skryptów uruchamiających bazy danych Informix i Sybase. Nie trzeba na stałe umieszczać w skryptach nazwy każdej bazy danych. Jak stwierdzić, jakie systemy zarchiwizować? Choć nigdy nie uzyskałem pełnej odpowiedzi na to pytanie, zawsze chciałem napisać skrypty, z których jeden monitorowałby różne bazy danych, szukając nowych systemów. Zależało mi na uzyskaniu z serwera DNS (Domain Name System) kompletnej listy wszystkich hostów i porównaniu jej z główną listą. Po znalezieniu nowego adresu IP chciałem spróbować stwierdzić, czy jest on aktualny. Jeżeli tak by było, oznaczałoby to, że pojawił się nowy komputer, który prawdopodobnie wymaga archiwizacji. Taki skrypt byłby bezcenny. Zapewniłby, że w sieci nie byłoby żadnych nowych systemów, w przypadku których nie byłoby wiadomo, czy wykonuje się kopie zapasowe, czy nie. Po zlokalizowaniu nowego adresu IP za pomocą narzędzia nmap można zidentyfikować typ systemu, któremu adres przypisano. Narzędzie to wysyła niepoprawny pakiet TCP pod adres IP. Odpowiedź otrzymana spod tego adresu pozwala określić, pod kontrolą jakiego systemu operacyjnego komputer działa. Obecnie kilka komercyjnych pakietów oprogramowania zarządzającego ochroną danych oferuje taką możliwość.
Czy archiwizować cały system czy jego część? Zakładając, że wzięto pod uwagę rzeczy, które nie są uwzględniane przez standardowe systemowe kopie zapasowe, trzeba zdecydować, czy zarchiwizuje się cały system czy tylko jego wybrane napędy lub systemy plików. W tym przypadku należy wspomnieć o dwóch różnych szkołach. Z tego, co się orientuję, z wariantem archiwizowania wybranych systemów plików związanych jest zbyt wiele pułapek. Archiwizowanie wszystkiego jest prostsze i bezpieczniejsze od sporządzania kopii zapasowej za pomocą listy. Można zauważyć, że w większości książek pada stwierdzenie: „Choć najlepiej archiwizować wszystko, większość osób postępuje inaczej”. Takiego zdania Czytelnik nie znajdzie w tej książce. Uważam, że nieuwzględnienie wszystkiego w kopii zapasowej jest bardzo niebezpieczne. Pod uwagę warto wziąć poniższe porównanie dwóch metod.
Archiwizowanie tylko wybranych napędów lub systemów plików Oto argumenty za i przeciw sporządzaniu kopii zapasowych dla niektórych danych: Oszczędność przestrzeni nośnika i mniejsze obciążenie sieci. To pierwszy argument, zwykle uznawany za zaletę metody archiwizowania wybranych systemów plików. Polega to na tym, że w kopii zapasowej umieszcza się mniejszą ilość danych. Zwolennicy tej szkoły zalecają tworzenie dwóch grup kopii zapasowych: z danymi systemu operacyjnego i zwykłymi danymi. Chodzi o to, że kopie zapasowe systemu operacyjnego byłyby wykonywane rzadziej. Niektórzy nawet sugerują, aby takie kopie sporządzać tylko po dokonaniu znaczącej modyfikacji, takiej jak zastosowanie poprawki zabezpieczeń systemu Windows,
48
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
zaktualizowanie systemu, zainstalowanie poprawki lub przebudowanie jądra. Z kolei zwykłe dane byłyby archiwizowane codziennie. Pierwszy problem jest taki, że ten argument stracił na aktualności. Wystarczy przyjrzeć się rozmiarowi danych typowego nowoczesnego komputera. Obecnie ilość zwykłych danych znacznie przekracza ilość danych systemu operacyjnego. Nie zaoszczędzi się zbyt wiele przestrzeni lub przepustowości sieci przez zrezygnowanie z archiwizowania systemu operacyjnego, nawet podczas wykonywania pełnej kopii zapasowej. Gdy pod uwagę weźmie się przyrostowe kopie zapasowe, proporcja ta będzie jeszcze większa. Jeżeli nie ma czegoś ważnego, co powinno zostać zarchiwizowane, partycje systemu operacyjnego nie spowodują dużego wzrostu rozmiaru przyrostowej kopii zapasowej! Do ważnych danych można zaliczyć pliki systemów: Unix, Linux i Mac OS, takie jak /etc/passwd, /etc/hosts, syslog, /var/adm/messages, i wszelkie inne pliki, które okażą się przydatne w przypadku awarii systemu operacyjnego. Do istotnych danych należy również dołączyć rejestr systemu Windows. Plik wymiany jest raczej jedyną zupełnie bezwartościową porcją informacji, która może zostać umieszczona na dysku systemu operacyjnego. Plik wymiany można wyłączyć za pomocą listy wykluczeń. Trudniejsze administrowanie. Zwolennicy okazjonalnego wykonywania kopii zapasowych powiedzieliby, że ważne pliki, takie jak wyżej wymienione, można dodać do specjalnej kopii zapasowej. W tym przypadku problem polega na tym, że jest to znacznie trudniejsze od archiwizacji wszystkiego. Zakładając, że z większości kopii zapasowych wyłączy się pliki konfiguracyjne, trzeba będzie pamiętać o przeprowadzeniu ręcznej archiwizacji każdorazowo po zmodyfikowaniu pliku konfiguracyjnego lub bazy danych. Oznacza to, że po wprowadzeniu zmiany konieczne będzie wykonanie czegoś specjalnego, co jest czymś złym. Jeśli po prostu wszystko się zarchiwizuje, można administrować systemami stosownie do wymagań bez konieczności pamiętania o wykonaniu kopii zapasowej przed wprowadzeniem jakiejś zmiany. Łatwiej jest dzielić kopię między woluminami. Jedna z bardzo niewielu rzeczy, które mogą być uznane za plus, ma miejsce wtedy, gdy napędy lub systemy plików rozdzieli się między wieloma kopiami zapasowymi. Łatwiejsze jest rozmieszczenie kopii zapasowych na wielu woluminach. Jeśli kopia zapasowa systemu nie mieści się na jednym woluminie, prościej zautomatyzować archiwizację przez podzielenie kopii na dwie obsługiwane przez różne listy dołączeń. Jednak aby z tego skorzystać, zamiast list wykluczeń trzeba zastosować listy dołączeń, z którymi są związane wcześniej zaprezentowane ograniczenia. Powinno się sprawdzić, czy narzędzie archiwizujące oferuje lepszą metodę rozwiązania tego problemu. Łatwiej napisać odpowiedni skrypt, niż samemu przetwarzać pliki fstab i oratab lub rejestr systemu Windows. Trudno się spierać z takim stwierdzeniem. Jeśli poświęci się czas na to, aby zadanie wykonać dobrze za pierwszym razem, nigdy nie trzeba będzie znów używać list dołączeń. Przychodzi mi w tym miejscu na myśl moje inne ulubione stwierdzenie: „Nigdy nie ma czasu na zrobienie czegoś poprawnie, a zawsze jest czas na wykonanie czegoś jeszcze raz”. Warto znaleźć czas na wykonanie tego zadania dobrze za pierwszym razem. Najgorsze, co może się wydarzyć? Coś przeoczono! W tym przypadku początkowo największe korzyści są takie, że zaoszczędzi się trochę czasu, nie pisząc skryptów, a także zyska kilka bajtów przepustowości sieci. Najgorszy możliwy efekt uboczny to przeoczenie napędu lub systemu plików z budżetem szefa, który właśnie został usunięty.
Co należy arch w zować?
|
49
Archiwizowanie całego systemu Lista zalet archiwizowania całego systemu jest krótsza i znacznie bardziej przekonująca. Oto ona: Pełna automatyzacja. Gdy uda się utworzyć działający skrypt lub program, wystarczy monitorować generowane przez niego dzienniki. Można spokojnie spać, wiedząc, że wszystkie dane znajdą się w kopii zapasowej. Najgorsze, co może się wydarzyć? Straci się przyjaciela pracującego w dziale sieciowym. Można zwiększyć obciążenie sieci o kilka punktów procentowych, co może się nie spodobać osobom zajmującym się okablowaniem sieciowym (oczywiście taki stan rzeczy będzie trwał do momentu, gdy będzie trzeba odtworzyć serwer, na którym osoby te przechowują źródłową bazę danych DNS). Archiwizowanie wybranych napędów lub systemów plików jest jednym z najczęściej popełnianych błędów, na które napotykam podczas analizowania konfiguracji archiwizacji. Bardzo łatwo wpaść w taką pułapkę przez wybiórcze archiwizowanie dla zaoszczędzenia czasu. Dopóki jednak nie przekona się o tym samemu, można nie wiedzieć, w jak dużym niebezpieczeństwo się znalazło. Jeśli konfiguracja archiwizacji bazuje na listach dołączeń, mam nadzieję, że to omówienie przekona Czytelnika do ponownego przemyślenia podjętej decyzji.
Decydowanie o momencie przeprowadzania archiwizacji Mogłoby się wydawać, że jest to najbardziej oczywiste zagadnienie. Czyż nie każdy archiwizuje swój system każdej nocy? W takim razie w czym tkwi problem? Właściwsze pytanie brzmi: „Jakie poziomy są uaktywniane i kiedy?”. Zawsze jest to poważne pytanie. Jak często wykonuje się pełną kopię zapasową? Jak często sporządza się przyrostowe kopie zapasowe? Czy stosuje się różne poziomy archiwizacji przyrostowej uwzględniającej wyłącznie dzisiejsze zmiany, czy ciągłą archiwizację przyrostową obejmującą wszystko, co zmieniło się od czasu wykonania ostatniej pełnej kopii zapasowej? Każdy ma własne odpowiedzi na te pytania. Pewne jest tylko to, że każdej nocy powinien być stosowany co najmniej jeden z poziomów archiwizacji. Zanim przejdziemy dalej, warto zdefiniować kilka pojęć.
Poziomy archiwizowania Poniżej zaprezentowano różne poziomy archiwizowania. Każdy używa tych terminów w inny sposób. Pełna kopia/Poziom 0 Pełna kopia zapasowa. Poziom 1 Przyrostowa kopia zapasowa archiwizująca wszystko, co zmieniło się od czasu wykonania ostatniej kopii zapasowej poziomu 0. Kolejne kopie poziomu 1 nadal uwzględniają wszystko, co zostało zmodyfikowane od chwili sporządzenia ostatniej pełnej kopii zapasowej poziomu 0.
50
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Poziomy 2 – 9 Każdy poziom archiwizuje wszystko, co zmieniło się od momentu wykonania ostatniej kopii następnego najniższego poziomu. Oznacza to, że poziom 2 archiwizuje wszystko, co zmieniło się od chwili utworzenia kopii zapasowej poziomu 1 lub poziomu 0 (jeśli brak poziomu 1). W przypadku niektórych produktów kolejne kopie zapasowe poziomu 9 uwzględniają to, co się zmieniło od czasu sporządzenia ostatniej kopii tego poziomu. Jednak jest to dalekie od powszechności. Kopia przyrostowa Zwykle tego typu kopia zawiera wszystko, co zmieniło się od momentu wykonania ostatniej kopii zapasowej dowolnego rodzaju. Kopia różnicowa Większość osób traktuje kopię różnicową jako taką, która archiwizuje wszystko, co zostało zmodyfikowane od czasu sporządzenia ostatniej pełnej kopii zapasowej. Jednak nie jest to powszechne rozumowanie. W systemie Windows różnicową jest kopia, która nie usuwa bitu archiwizacji. A zatem, gdy wykona się pełną kopię zapasową, a następnie kilka kopii różnicowych, w tradycyjnym znaczeniu będą one funkcjonowały jak kopie różnicowe. Jeśli jednak w systemie utworzy się choćby jedną kopię przyrostową, usunie ona bit archiwizacji i w efekcie następna kopia różnicowa uwzględni tylko te pliki, które zmodyfikowano od czasu sporządzenia ostatniej kopii przyrostowej. Właśnie z tego powodu kopia różnicowa nie jest tożsama z kopią zapasową poziomu 1. Skumulowana kopia przyrostowa Preferuję używanie tego określenia zamiast pojęcia kopii różnicowej. Termin identyfikuje kopię zapasową uwzględniającą wszystkie pliki, które zostały zmodyfikowane od momentu wykonania ostatniej pełnej kopii zapasowej. Narzędzia archiwizujące i administratorzy korzystający z nich nie stosują tych terminów w jednoznaczny sposób. Trzeba się upewnić, jak używany produkt interpretuje określony termin!
Często zadawane jest mi następujące pytanie: „Czy mam archiwizować dane każdej nocy?”. W rzeczywistości pytanie to powinno brzmieć tak: „Czy nawet w weekend?”. Nikt nie pracuje w weekend, zgadza się? Tak, z wyjątkiem klienta, który zrobił wielką awanturę w zeszły weekend. Czytelnik może się domyślić, o jakim kliencie mowa. Taki klient zamiast do działu pomocy technicznej dzwoni do szefa, gdy pojawi się problem. I jeśli nie zastanie szefa lub ten nie poradzi sobie z problemem wystarczająco szybko, klient skontaktuje się z jego przełożonym. W zeszły weekend taki klient był naprawdę zapracowany i spędził go w całości nad przyszłorocznym budżetem. Około pierwszej nad ranem w poniedziałek klient wreszcie ukończył przygotowywanie budżetu. Około czwartej rano przestał działać dysk z domowym katalogiem klienta (czyż wszystko nie odmawia posłuszeństwa w poniedziałkowy poranek?). Od piątkowego wieczoru nie sporządzono kopii zapasowej danych. W efekcie dzwoni szef. Do głowy przychodzą różne powody, dla których szef postanowił zadzwonić. Czy Czytelnik chciałby być tą osobą, która powie temu klientowi, że można było zapisać jego plik, lecz w weekend nie została przeprowadzona archiwizacja danych?
Decydowan e o momenc e przeprowadzan a arch w zacj
|
51
Bit archiwizacji systemu Windows jest złem! Bit archiwizacji systemu Windows jest złem, które musi zostać powstrzymane. W najgorszym razie producenci sprzętu archiwizującego powinni umożliwić niekorzystanie z tego bitu, bez żadnych konsekwencji. Jeśli dla pliku w systemie Windows ustawi się bit gotowości do archiwizacji, będzie to oznaczać, że plik jest nowy lub zmodyfikowany i powinien zostać dołączony do przyrostowej kopii zapasowej. Po zarchiwizowaniu pliku bit archiwizacji jest usuwany. A zatem pierwszy problem związany z tym bitem polega na tym, że powinien być nazywany bitem kopii zapasowej. Kopie zapasowe nie są archiwami. Jednak największym problemem z bitem archiwizacji jest to, że związany z nim proces przyjmuje, że bit ten usunie tylko jedna aplikacja, podczas gdy w rzeczywistości może być ich kilka. Pierwszy program archiwizujący użyty do utworzenia kopii zapasowej katalogu usuwa bit archiwizacji, więc następny program nie dokona archiwizacji tych samych plików katalogu. Załóżmy, że użytkownik postanowi zastosować narzędzie ntbackup w celu zarchiwizowania na dysku CD swoich plików znajdujących się na firmowym serwerze. Jeżeli tak postąpi, program ntbackup usunie bit archiwizacji i firmowy system archiwizacji odpowiedzialny za wykonywanie kopii zapasowej plików katalogu nie doda ich do tworzonej przyrostowej kopii zapasowej. Ponieważ dla plików nie jest ustawiony bit archiwizacji, wynika z tego, że nie ma potrzeby uwzględniania ich w kopii zapasowej. Oznacza to, że każdy użytkownik może spowodować niezgodne z zamierzeniami działanie całego systemu archiwizacji. Zwolennicy bitu archiwizacji podkreślają, że jest on ustawiany dla nowo zainstalowanego oprogramowania, nawet wtedy, gdy pliki są stare. Program archiwizujący, który używa jedynie czasu modyfikacji, nie zauważa takich plików, jeśli są starsze niż najnowsza przyrostowa kopia zapasowa. Dlatego taki program powinien być może stosować kombinację bitu archiwizacji i czasu modyfikacji. Jeżeli to lub to zmieni się, plik powinien zostać uwzględniony w przyrostowej kopii zapasowej. W przypadku archiwizowania danych systemów uniksowych nie występuje bit archiwizacji. W związku z tym aplikacje archiwizujące używają wartości mtime (gdy zawartość pliku w ostatnim czasie zmieniła się) lub ctime (gdy atrybuty pliku zostały w ostatnim czasie zmodyfikowane). Podczas tworzenia kopii zapasowej w systemie Windows różne aplikacje archiwizujące w odmienny sposób stosują bit archiwizacji. Część aplikacji używa go w połączeniu z wartością mtime lub ctime. Część narzędzi stosuje wyłącznie bit archiwizacji, natomiast część w ogóle z niego nie korzysta (biorąc pod uwagę to, co napisałem na temat bitu archiwizacji, może nie być to takie złe rozwiązanie). Microsoft zaoferował w systemie Windows 2000 i jego następcach alternatywę dla bitu archiwizacji w postaci dziennika zmian (ang. change journal). Produkty archiwizujące obsługujące dziennik zmian mogą z niego korzystać przy określaniu, które pliki zostały zmodyfikowane. Tym samym nie muszą w tym celu szukać bitu archiwizacji. Choć domyślnie dziennik zmian nie jest aktywny, można go włączyć poleceniem fsutil usn createjournal. Trzeba określić wartość parametru MaximumSize, która będzie na tyle duża, aby przechować wszystkie zmiany dokonane między sporządzeniem kolejnych kopii zapasowych. Ponieważ w jednym rekordzie o rozmiarze 4 kB mieści się 30 lub 40 zmian, w dzienniku o pojemności 75 MB można pomieścić 500 000 zmian (jeśli dziennik zmian nie jest wystarczająco duży, w celu zrobienia miejsca najstarsze modyfikacje są usuwane z początku dziennika, dlatego ważne jest, żeby dziennik miał odpowiednią pojemność). Sugeruję określić największą liczbę plików, jaką do tej pory umieszczono w przyrostowej kopii zapasowej, a następnie dla dziennika ustawić dwukrotnie większą pojemność. Dzięki temu zwiększy się integralność systemu archiwizacji kosztem niewielkiego wzrostu przestrzeni zajmowanej przez dziennik zmian.
52
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Jakie poziomy są stosowane i kiedy? Jeśli chodzi o odpowiedź na to pytanie, szkół jest kilka. Poniżej przedstawiono kilka propozycji harmonogramów archiwizacji.
Harmonogram tygodniowy — same pełne kopie zapasowe poziomu 0 W tabeli 2.1 zaprezentowano harmonogram archiwizacji dla paranoika (nie oznacza to wcale nic złego). Kopia zapasowa poziomu 0 jest sporządzana codziennie na oddzielnym woluminie (proszę nie nadpisywać wczorajszej poprawnej kopii zapasowej poziomu 0 dzisiejszą kopią, która może być uszkodzona!). Jeżeli system jest naprawdę niewielki, taki harmonogram może być w sam raz. Jeśli jednak systemy mają duży rozmiar, ten harmonogram archiwizacji nie będzie zbyt dobrze skalowalny. Poza tym w przypadku obecnie dostępnego komercyjnego oprogramowania archiwizującego stosowanie takiego harmonogramu naprawdę nie jest konieczne. Tabela 2.1. Same pełne kopie zapasowe N edz ela
Pon edz ałek
Wtorek
Środa
Czwartek
P ątek
Sobota
Pełna kopia/ poziom 0
Pełna kopia/ poziom 0
Pełna kopia/ poziom 0
Pełna kopia/ poziom 0
Pełna kopia/ poziom 0
Pełna kopia/ poziom 0
Pełna kopia/ poziom 0
Harmonogram tygodniowy — tygodniowa pełna kopia zapasowa i codzienne różnicowe kopie poziomu 1 Zaletą harmonogramu przedstawionego w tabeli 2.2 jest to, że dane z okresu tygodnia zwykle trzeba będzie odtwarzać tylko z dwóch woluminów: z pełną kopią poziomu 0 i najnowszą różnicową kopią poziomu 1. Wynika to stąd, że każda różnicowa kopia zapasowa poziomu 1 uwzględnia wszystkie zmiany dokonane od momentu utworzenia w niedzielę pełnej kopii. Następną zaletą tego typu harmonogramu jest to, że uzyskuje się wiele kopii plików modyfikowanych na początku tygodnia. Prawdopodobnie jest to najlepszy harmonogram do zastosowania, gdy korzysta się z prostych narzędzi, takich jak dump, tar lub cpio, ponieważ wymagają one od administratora pełnego zarządzania woluminami. Odtwarzanie z dwóch woluminów jest znacznie łatwiejsze niż z sześciu (można mi zaufać)! Tabela 2.2. Tygodniowa pełna kopia zapasowa i codzienne różnicowe kopie poziomu 1 N edz ela
Pon edz ałek
Wtorek
Środa
Czwartek
P ątek
Sobota
Pełna kopia/ poziom 0
Różnicowa kopia/poziom 1
Różnicowa kopia/poziom 1
Różnicowa kopia/poziom 1
Różnicowa kopia/poziom 1
Różnicowa kopia/poziom 1
Różnicowa kopia/poziom 1
Harmonogram tygodniowy — tygodniowa pełna kopia zapasowa i codzienne kopie poziomów Jeśli produkt archiwizujący obsługuje wiele poziomów, można zastosować harmonogram pokazany w tabeli 2.3. Zaletą tego harmonogramu jest to, że wymaga mniej czasu i nośników niż wcześniej omówiony. Ma on dwie wady. Po pierwsze, każdy zmodyfikowany plik jest archiwizowany tylko raz, co powoduje bardzo dużą obawę o utratę danych, gdy dojdzie do
Decydowan e o momenc e przeprowadzan a arch w zacj
|
53
Tabela 2.3. Tygodniowa pełna kopia zapasowa i codzienne kopie poziomów N edz ela
Pon edz ałek
Wtorek
Środa
Czwartek
P ątek
Sobota
Pełna kopia/ poziom 0
1
2
3
4
5
6
uszkodzenia dowolnego z nośników. Po drugie, w celu pełnego odtworzenia danych w piątek potrzebnych będzie 6 woluminów. Jeżeli używa się dobrego narzędzia archiwizującego open source lub komercyjnego, druga z wymienionych wad tak naprawdę nie stanowi problemu, ponieważ aplikacje te całkowicie wyręczają użytkownika w zarządzaniu woluminami (włącznie z wymienianiem taśm — za pomocą zautomatyzowanego zmieniacza).
Harmonogram tygodniowy — miesięczna pełna kopia zapasowa i codzienne przyrostowe kopie (wieża Hanoi) Jeden z najbardziej interesujących pomysłów, z jakimi się spotkałem, nosi nazwę planu archiwizacyjnego wieży Hanoi. Bazuje on na starożytnej łamigłówce o tej samej nazwie, wykorzystującej ciąg matematyczny. Łamigłówka składa się z trzech kołków i kilku zakładanych na nich pierścieni o różnych średnicach. Pierścień nie może być umieszczony na pierścieniu o mniejszej średnicy. Celem gry jest przemieszczenie wszystkich pierścieni z pierwszego kołka na trzeci przy wykorzystaniu drugiego kołka, służącego w razie potrzeby do tymczasowego magazynowania2. Zadaniem większości harmonogramów archiwizacji jest umieszczenie zmodyfikowanych plików na więcej niż jednym woluminie przy jednoczesnym zredukowaniu całkowitej wykorzystanej pojemności woluminów. Plan archiwizacyjny wieży Hanoi radzi sobie z tym lepiej od każdego innego harmonogramu. Jeśli na potrzeby poziomów archiwizacji zastosuje się tego typu plan, większość zmodyfikowanych plików zostanie zarchiwizowana najwyżej dwa razy. Poniżej przedstawiono dwie różne wersje ciągu (nawiasem mówiąc, są one powiązane z liczbą pierścieni znajdujących się na trzech kołkach). 0325476989 032435465768798 W rzeczywistości te ciągi są naprawdę proste. Każdy składa się z dwóch przeplatających się zestawów liczb (zestaw 2 3 4 5 6 7 8 9 przeplata się z zestawem 3 4 5 6 7 8 9). W tabeli 2.4 pokazano harmonogram ilustrujący działanie planu archiwizacji wieży Hanoi. Tabela 2.4. Podstawowy harmonogram planu archiwizacji wieży Hanoi N edz ela
Pon edz ałek
Wtorek
Środa
Czwartek
P ątek
Sobota
0
3
2
5
4
7
6
Harmonogram rozpoczyna się od niedzielnego poziomu (pełna kopia zapasowa). Załóżmy, że plik zmodyfikowano w poniedziałek. Poniedziałkowa kopia zapasowa poziomu 3 uwzględni wszystko, co się zmieniło od chwili wykonania kopii zapasowej poziomu 0. Oznacza to, że zmodyfikowany plik znajdzie się w poniedziałkowej kopii. Przyjmijmy, że we wtorek zmodyfikowano następny plik. A zatem we wtorkową noc kopia zapasowa poziomu 2 musi poszukać niższego poziomu, prawda? Ponieważ poniedziałkowy poziom 3 nie jest niższy, kopia 2
Aby zapoznać się z całą historią gry i uzyskać adres URL, pod którym można w nią zagrać, należy zajrzeć na stronę znajdującą się pod adresem http://www.math.toronto.edu/mathnet/games/towers.html.
54
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
odwołuje się również do poziomu 0. W efekcie zarchiwizowany zostanie plik zmodyfikowany w poniedziałek, a także plik zmieniony we wtorek. W środę kopia zapasowa poziomu 5 uwzględnia tylko to, co zostało zmodyfikowane tego dnia, ponieważ odwołuje się ona do wtorkowej kopii poziomu 2. Jednak w czwartek kopia poziomu 4 nie odwołuje się do środowego poziomu 5, lecz do wtorkowego poziomu 2. Warto zauważyć, że plik zmodyfikowany we wtorek został zarchiwizowany tylko raz. Aby poradzić sobie z tym problemem, stosuje się zmodyfikowaną wersję ciągu matematycznego planu archiwizacji wieży Hanoi, w przypadku którego każdego tygodnia poziom archiwizacji obniża się do poziomu 1 (tabela 2.5). Tabela 2.5. Miesięczny harmonogram planu archiwizacji wieży Hanoi Dz eń tygodn a
P erwszy tydz eń
Drug tydz eń
Trzec tydz eń
Czwarty tydz eń
Niedziela
0
1
1
1
Poniedziałek
3
3
3
3
Wto ek
2
2
2
2
Ś oda
5
5
5
5
Czwa tek
4
4
4
4
Piątek
7
7
7
7
Sobota
6
6
6
6
Jeśli nie będzie to stanowić problemu dla Czytelnika i stosowanej metody archiwizacji3, a także dla używanego systemu archiwizacji, namawiam do wybrania harmonogramu z tabeli 2.5. Każdej niedzieli uzyska się kompletną przyrostową kopię zapasową wszystkiego, co zmieniło się od czasu wykonania pełnej miesięcznej kopii. W pozostałe dni tygodnia każdy zmodyfikowany plik jest archiwizowany dwukrotnie, z wyjątkiem plików zmienionych w środę. W ten sposób można się uchronić przed awarią nośnika lepiej niż w przypadku każdego z wcześniej opisanych harmonogramów. Choć oczywiście do przeprowadzenia pełnego procesu odtwarzania będzie wymagany więcej niż jeden wolumin, nie stanowi to problemu, gdy dysponuje się zaawansowanym narzędziem archiwizującym z funkcją zarządzania woluminami.
„W środku nocy…” Ten cytat z piosenki Billy’ego Joela identyfikuje porę, która zwykle najlepiej nadaje się do archiwizowania danych. Wykonywanie kopii zapasowych powinno być tak zaplanowane, aby nie miało miejsca w normalnych godzinach pracy firmy. Choć czasami nie można tego uniknąć, nie powinno się to zdarzać zbyt często. Oto dwa podstawowe powody: Spójność Pomijając przypadek sklepu całodobowego, w nocy pliki są najbardziej stabilne (oczywiście w tym czasie mogą być aktywne zadania wsadowe przetwarzające dane i klienci przeglądający witrynę WWW; w związku z tym nie wszystkie pliki będą dostępne). Jeżeli 3
Zawsze jest to brane pod uwagę w przypadku każdej rekomendacji podanej w książce. Jeżeli zalecenie jest kłopotliwe dla Czytelnika lub trudne z punktu widzenia używanej przez niego metody archiwizacji, nie jest dobrze! Jeśli kopie zapasowe powodują dyskomfort, nawet nie będzie próbował odtworzyć z nich danych! Administrator systemu zawsze powinien dążyć do upraszczania wszystkiego.
Decydowan e o momenc e przeprowadzan a arch w zacj
|
55
operację archiwizowania wykonuje się w dzień, pliki są modyfikowane i prawdopodobnie również otwarte. Takie pliki trudniej zarchiwizować. Część pakietów archiwizacyjnych radzi sobie z otwartymi plikami lepiej od innych, natomiast część w ogóle nie może ich dodać do kopii zapasowej. Ponadto, jeśli plik jest modyfikowany w ciągu dnia, nie będzie miało się pewności, która jego wersja faktycznie znalazła się w kopii zapasowej. Szybkość Następnym powodem, dla którego nie należy tworzyć kopii zapasowych w ciągu dnia, jest większe obciążenie sieci, a tym samym mniejsza szybkość. Przepustowość sieci będąca do dyspozycji procesu archiwizacji znacznie spada, gdy sieć jest normalnie obciążona. Jeżeli archiwizowanie nocą też jest problematyczne, można zastosować specjalną sieć tylko na potrzeby sporządzania kopii zapasowych. Wykonywanie kopii w ciągu dnia może znacząco wpłynąć na szybkość innych aplikacji, a ponadto nie jest dobrą praktyką regularne spowalnianie systemów, gdy korzystają z nich użytkownicy. Oczywiście w przypadku obecnej globalnej i internetowej ekonomii pojęcie nocy jest względne. W sklepie, w którym komputery są cały czas dostępne, zadania trzeba wykonywać w dość odmienny sposób. Czytelnik może zajrzeć do rozdziału 8., aby dowiedzieć się, co robią producenci, żeby łatwiej poradzić sobie z takim wyzwaniem.
To ma dobre zakończenie (prawie) Choć nigdy nie zdarzyło mi się, żeby serwer został fizycznie unicestwiony, straciłem całe serwery, konfigurację, wszystko. Na szczęście miałem ich konfigurację zapisaną. Pamiętam też sytuację, w której straciliśmy serwer z firmową bazą danych Informix przechowującą wszystkie dane dotyczące woluminów i ich lokalizacji. Pamiętam, jak powiedziałem: „Jak ja sobie teraz z tym poradzę?”. Na szczęście mieliśmy w zwyczaju przesyłać każdego dnia wydruk woluminów do pracowników innego oddziału firmy. Poprosiłem ich o wydruk z zestawieniem wszystkich woluminów z jednego dnia. Udało się! Co to ma być? Czy Czytelnik pomyślał, że jestem niegodziwą i złośliwą osobą, która ma na celu wywoływanie koszmarów następnego tygodnia? Czy Czytelnik nie ma pojęcia, jak zdobyłby takie informacje, gdyby ich potrzebował? Czy powie, że przez jakiś czas nie będzie z tego powodu spał? Dobrze! Lepiej zarwać część nocy, niż stracić dane. Jednym z podstawowych celów tej książki jest przestraszyć Czytelnika. Osoba odpowiedzialna za kopie zapasowe, która jest zadowolona z siebie, stanowi zagrożenie. Opisana sytuacja była frustrująca i spowodowała utratę danych, które normalnie nie są uwzględniane przez standardowe kopie zapasowe.
Decydowanie o metodzie archiwizowania danych Po podjęciu decyzji o porze archiwizowania danych trzeba zastanowić się, w jaki sposób zostanie to zrealizowane. Jednak najpierw należy przyjrzeć się problemom, przed którymi można się uchronić.
56
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Trzeba być gotowym na wszystko — 10 rodzajów nieszczęśliwych wydarzeń Jak już wspomniano, sposób przeprowadzenia procesu odtworzenia danych determinuje metodę tworzenia kopii zapasowych. Jedno z pytań, które trzeba sobie postawić, brzmi: „Przed czym zamierzam się uchronić?”. Czy w środowisku pracy znajdują się osoby z większymi uprawnieniami, które korzystają ze swoich komputerów w inteligentny sposób i nigdy nie popełniają głupich błędów? Czy firma straci mnóstwo istotnych danych, gdy pliki znajdujące się na komputerach osobistych użytkowników zostaną przypadkowo usunięte? Czy jeśli huragan zniszczy zupełnie firmę, będzie możliwe jej dalsze funkcjonowanie? Trzeba się upewnić, że ma się świadomość wszystkich potencjalnych powodów utraty danych, a następnie, że na wszystkie ma się przygotowane metody archiwizacji. Najbardziej kompletną listę potencjalnych powodów utraty danych, z którą się spotkałem, można znaleźć w książce Practical Unix and Internet Security wydawnictwa O’Reilly, napisanej przez Simsona Garfinkela i Gene’a Spafforda. Poniżej zamieściłem tę listę wraz z moimi komentarzami. Błąd użytkownika Jak dotąd to było powodem największej liczby odtworzeń w każdym środowisku, z którym miałem do czynienia. „Cześć. Coś się stało z moim plikiem i przypadkowo wcisnąłem jakiś klawisz. Czy mogę cię prosić o odtworzenie tego pliku?”. Czyż to zadanie nie jest naprawdę proste? A co Czytelnik powie na takie oto typowe pytanie: „Czy można odtworzyć coś, co usunięto około godzinę temu?”. Będzie to możliwe w przypadku stosowania systemów ciągłej ochrony danych i obrazów. Jednak nie wtedy, gdy kopie zapasowe wykonuje się co noc. Błąd obsługi technicznej komputerów Choć ma to miejsce rzadziej niż błędy użytkowników (chyba że mają uprawnienia administratora), gdy wystąpi, to naprawdę będzie co robić! Co się dzieje, gdy administrator za pomocą narzędzia newfs usunie system plików urządzenia bazy danych lub katalog użytkownika z dokumentami? W takich przypadkach operacje odtwarzania muszą być wykonane przez administratora naprawdę szybko, ponieważ sam zawinił. Sposoby, dzięki którym administrator może się chronić przed tego typu błędami, są te same co w przypadku błędów popełnianych przez użytkowników. Może wystarczyć typowe wykonywanie nocnych kopii zapasowych lub obrazów danych. Awaria sprzętu Choć większość książek omawia metody ochrony przed awariami sprzętu, zwykle nie wspomina, że awaria może mieć dwie postaci: awarii napędu dysku i awarii całego komputera. Ta uwaga jest ważna, gdyż aby zabezpieczyć się przed tymi typami awarii, trzeba zastosować dwie zupełnie różne metody. Wiele osób nie bierze tego pod uwagę, gdy opracowuje plan ochrony danych. Przykładowo, gdy doszło do uszkodzenia napędu lub systemu plików, często słyszałem coś takiego: „Myślałem, że dla dysku była tworzona kopia lustrzana!”. Kopia lustrzana nie chroni przed awarią całego komputera. Mój przyjaciel mawiał, że jeśli wolne elektrony krążące w komputerze postanowią uszkodzić napęd lub system plików, to gdy komputer się zepsuje, kopia lustrzana jedynie sprawi, że zniszczenia będą skuteczniejsze. Również obrazy danych nie uchronią przed awarią sprzętową (jeśli nie znajdują się na woluminie archiwizacyjnym).
Decydowan e o metodz e arch w zowan a danych
|
57
Awaria dysku Obecnie ochrona komputerów przed awarią napędu dysku jest dość prosta. Trzeba jedynie zdecydować, jakiego poziomu bezpieczeństwa się wymaga. Choć mirroring, często określany jako RAID 1, oferuje najlepszą ochronę, podwaja początkowy koszt inwestycji związanej z zakupem napędów i kontrolerów. Z tego właśnie powodu większość osób decyduje się na inne poziomy macierzy RAID (Redundant Arrays of Independent Disks), wśród których największą popularnością cieszą się macierze RAID 5 i RAID 6. Woluminy RAID 5 zabezpieczają przed awarią jednego napędu przez obliczanie bloków parzystości i przechowywanie ich na każdym napędzie dysku. Macierz RAID 6 zwiększa poziom ochrony przez przechowywanie dwóch bloków parzystości. Dzięki temu dopuszczalna jest awaria więcej niż jednego napędu. Awaria komputera Większa część ochrony przed awarią całego komputera polega na dobrych procedurach administrowania komputerami. Należy właściwie dokumentować komputery. Korzystając z dzienników systemowych i wszelkich innych dostępnych metod monitorowania, należy dokładnie obserwować działanie komputerów. Należy reagować na komunikaty dotyczące wadliwych dysków, kontrolerów, procesorów i modułów pamięci. Ostrzeżenia związane z awariami sprzętu dają szansę usunięcia problemów, zanim spowodują poważniejsze konsekwencje. Inna metoda ochrony polega na zastosowaniu rejestrującego systemu plików. Rejestrowanie systemu plików wygląda podobnie jak w przypadku bazy danych. Monitorowane są zatwierdzone i częściowo zatwierdzone operacje zapisu w systemie plików. Gdy komputer jest uruchamiany, rejestrujący system plików może wycofać częściowo zatwierdzone operacje zapisu, tym samym zapobiegając uszkodzeniu systemu plików. Dziennik zmian systemu Windows nie powoduje, że system plików NTFS staje się rejestrującym systemem plików. Dziennik zmian zawiera jedynie listę plików, które zostały zmodyfikowane, bez samych zmian. W związku z tym nie jest w stanie wycofać żadnych zmian.
Awaria oprogramowania Ochrona przed awarią oprogramowania może być trudna. Błędy systemów operacyjnych, baz danych i aplikacji zarządzających systemami mogą spowodować utratę danych. Również w tym przypadku stopień możliwej ochrony przed tego typu błędami zależy od rodzaju wykonywanych kopii zapasowych. Często tworzone obrazy danych lub systemy ciągłej ochrony danych to jedyne rozwiązania pozwalające rzeczywiście zabezpieczyć się przed utratą danych (może być ich sporo) w wyniku awarii oprogramowania. Elektroniczne włamania, wandalizm i kradzież W ostatnich latach miało miejsce kilka takich incydentów. O wielu z nich można było usłyszeć w ogólnokrajowych wiadomościach. Jeśli traci się dane na skutek dowolnego z takich zdarzeń, ma się do czynienia z zupełnie odmienną sytuacją. Choć można odtworzyć dane, możliwe jest, że nigdy nie uzyska się pewności, co się z nimi stało, gdy miał do nich dostęp ktoś inny. A zatem trzeba zrobić wszystko, aby zagwarantować, że nigdy do tego nie dojdzie. Jeżeli ktoś chce się uchronić przed utratą danych w taki sposób, mocno go zachęcam do przeczytania książki Practical Unix and Internet Security autorstwa Simsona Garfinkela i Gene’a Spafforda (wydawnictwo O’Reilly), z której zapożyczyłem tę listę powodów utraty danych.
58
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Klęski żywiołowe Czy jest się przygotowanym na huragan, tornado, trzęsienie ziemi lub powódź? Jeśli nie, nie jest się w tym osamotnionym. Można sobie wyobrazić, że całe województwo zostało zniszczone. Jeżeli korzysta się z magazynowania kopii zapasowych poza obrębem firmy, czy miejsce składowania jest blisko firmy? Czy magazyn jest przygotowany na każdego typu klęskę żywiołową, która wystąpi na obszarze województwa? Jeśli na przykład biuro i firma magazynująca jego dane znajdują się na obszarze powodzi, czy przechowuje ona kopie zapasowe na pierwszym piętrze? Jeśli nie, dane mogą zostać utracone po jednym intensywnym deszczu. Aby naprawdę uchronić się przed poważną klęską żywiołową, należy znaleźć odległe miejsce składowania kopii zapasowych (więcej na ten temat można znaleźć w dalszej części rozdziału, w punkcie „Przechowywanie poza obrębem firmy”).
„Jak udały się kopie zapasowe z zeszłej nocy?” Chyba słyszałem już tysiące dramatycznych historii o błędach popełnianych przez administratorów (takich jak wykonanie polecenia rm -r /*). Pamiętam kogoś, kto chciał usunąć niepotrzebny plik zawarty w katalogu /bin i mający nazwę ?*&(&^JI($SF))FS%$#T lub podobną. W tym celu wykonał polecenie rm /bin/?* (usuwa wszystkie pliki, których nazwa zaczyna się dowolnym znakiem). Jednak zdarzyło się także coś, czego byłem naocznym świadkiem. W dalszym ciągu mnie to rozbawia. Konsultantowi zlecono wyczyszczenie katalogów domowych użytkowników. Zdaje się, że firma, w której byłem zatrudniony, bardzo dobrze radziła sobie z usuwaniem kont osób odchodzących z pracy, lecz już nie tak dobrze wyglądało to w przypadku usuwania ich katalogów domowych. Konsultant napisał program, który przede wszystkim wykonywał następujące operacje:
1. Po wpisaniu polecenia cd przechodził do katalogu /home1. 2. Przy użyciu narzędzia find szukał katalogów, dla których w pliku haseł nie istniały wpisy, a ponadto ich właścicielem nie był użytkownik root lub inny administrator.
3. Dla katalogu wykonywał polecenie rm -r. Katalog domowy każdego użytkownika znajdował się poniżej katalogu, którego nazwą była pierwsza litera identyfikatora użytkownika. Przykładowo ścieżka katalogu domowego użytkownika cnowak wyglądała tak: /home1/c/cnowak. Pora opisać to, co się wydarzyło. Zamysł był taki, że właścicielem katalogu /home1/c jest użytkownik root, dlatego katalog nie zostanie usunięty. Niestety, raz jeden lub dwóch administratorów poleceniem cd przeszło do katalogu /home1/c/cnowak, aby spróbować wyeliminować problem z prawem własności. W tym celu administrator wykonał polecenie chown cnowak .*. Jeśli kiedykolwiek Czytelnik zastosował to polecenie z uprawnieniami użytkownika root, to wie, że .* uwzględnia .., co w tym przypadku oznacza /home1/c. A zatem właścicielem katalogu /home1/c staje się użytkownik cnowak! Konsultant nie przewidział tego i zinterpretował katalog /home1/c jako katalog domowy, a następnie poszukał w pliku haseł użytkownika c. Oczywiście, w pliku nie było takiego użytkownika, dlatego program wykonał polecenie rm -r /home1/c. Nie jestem pewien, kiedy mój znajomy zdał sobie sprawę z tego, co się stało, ale pamiętam, że otrzymałem dziwny telefon, gdy wychodziłem z domu. Kolega zapytał mnie tajemniczo i z zakłopotaniem: „Jak udały się kopie zapasowe katalogu /home1 z zeszłej nocy?”. „Świetnie, jak zawsze — odpowiedziałem. — A dlaczego pytasz?”. Jest coś pięknego w mocy, jaką emanuje osoba archiwizująca dane w tej magicznej chwili, gdy ktoś naprawdę musi mieć możliwość odtworzenia kilku plików. Tak więc jest się kimś, kto przychodzi wcześnie i zostaje do późna, obserwując obracające się napędy archiwizacyjne. W jednej chwili można stać się dla kogoś najważniejszą osobą! To jest fajne.
Decydowan e o metodz e arch w zowan a danych
|
59
Inne nieszczęśliwe zdarzenia Pamiętam, jak testowaliśmy nasz plan odtwarzania danych po awarii dla firmy, w której pracowałem. Przyjęliśmy, że cysterna wybuchła na ulicy, która biegła przy centrum danych firmy. Plan polegał na odtworzeniu danych w alternatywnym budynku. Oznaczało to, że trzeba by było przechowywać nośniki z danymi poza obrębem firmy i dysponować dodatkowym budynkiem przystosowanym tak, aby pomieścił wszystkie używane systemy. Dobrym sposobem jest tu rozmieszczenie systemów produkcyjnych i projektowych w różnych budynkach. Jeśli systemy produkcyjne zepsują się lub nastąpi przerwa w zasilaniu budynku, w którym się znajdują, mogą zostać zastąpione przez systemy projektowe. Zarchiwizowane informacje Okropnie jest uświadomić sobie, że zaginął rzadko używany, lecz bardzo ważny plik. Jednak jeszcze bardziej przerażająca jest sytuacja, kiedy plik jest niedostępny dłużej, niż trwa cykl retencji. Przykładowo kopie zapasowe przechowuje się tylko przez trzy miesiące, po czym ponownie wykorzystuje najstarszy wolumin, nadpisując wszelkie zapisane na nim dane. Jeśli coś takiego ma miejsce, nie będzie możliwe odtworzenie żadnych plików, które nie istnieją od ponad trzech miesięcy. Nie jest istotne, jak bardzo użytkownik będzie podkreślał ważność plików, ani to, ile telefonów wykona do przełożonych administratora. Nie będzie on w stanie nigdy odtworzyć tych plików. Właśnie z tego powodu część kopii zapasowych powinno się przechowywać trochę dłużej. Normalną praktyką jest przeznaczenie każdego miesiąca jednej pełnej kopii zapasowej do magazynowania przez kilka lat. Jeżeli zamierza się przechowywać takie kopie przez długi czas, trzeba zapoznać się z zawartością ramki „Czy magazynuje się archiwa zbyt długo?”, a także z podrozdziałem „Kopie zapasowe a archiwa danych” znajdującym się w rozdziale 24.
Automatyzowanie archiwizowania danych Jeśli Czytelnik pracuje w sklepie o umiarkowanym budżecie, prawdopodobnie po spojrzeniu na tytuł tego podrozdziału stwierdził: „Byłoby fajnie, gdybyśmy mogli sobie na to pozwolić”. Choć automatyzacja wykorzystująca kosztowne szafy i zmieniarki jest fajna, nie o taką automatyzację mi chodzi. Można wyróżnić dwa typy automatyzacji. Pierwszy umożliwia przeprowadzenie całego cyklu tworzenia kopii zapasowych bez konieczności ręcznej interwencji operatora, takiej jak wyciąganie i wsuwanie nowych woluminów. Choć ten typ automatyzacji może znacznie wszystko ułatwić, wiąże się z większymi kosztami. Jeżeli nie można sobie na to pozwolić, tańszą opcją jest nakazać systemowi archiwizowania powiadamianie operatora, że sam musi wykonać jakąś czynność. W najgorszym razie system powinien powiadomić, że trzeba (lub zapomniano) wymienić wolumin. Jeśli coś pójdzie nie tak, trzeba o tym wiedzieć. Zbyt wiele razy ludzie przeglądali dzienniki archiwizacji tylko wtedy, gdy musieli przeprowadzić proces odtwarzania danych. Właśnie w takim momencie dowiadują się, że od kilku dni lub tygodni nie udało się wykonać kopii zapasowych. Bardziej „inteligentny” system archiwizowania może wysłać do operatora wiadomość pocztową lub komunikat na pager, jeśli coś nie pójdzie zgodnie z oczekiwaniami. Drugi typ automatyzacji jest znacznie bardziej istotny. Odnosi się on do sposobu „myślenia” mechanizmu tworzenia kopii zapasowych. Mechanizm archiwizacji powinien wiedzieć, co ma uwzględnić w kopii zapasowej, bez interwencji operatora. Jeżeli administrator bazy danych instaluje nową bazę, mechanizm archiwizacji powinien o tym wiedzieć. Jeśli administrator systemu instaluje nowy napęd lub system plików, kopie zapasowe powinny go automatycznie
60
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
uwzględnić. Jest to rodzaj automatyzacji, który ma zasadnicze znaczenie dla zapewnienia poprawnych kopii zapasowych. Dobry system archiwizowania nie powinien być zależny od tego, że ludzki mózg ma coś zapamiętać.
Czy magazynuje się archiwa zbyt długo? Niektóre organizacje rządowe ustalają przepisy, które mówią, jak długo określonego typu dane mogą być przechowywane w archiwach firmy. Nie chodzi o przepisy, które nakazują składować dane przez określoną liczbę lat, ale o te, które narzucają obowiązek usuwania danych po upływie iluś lat. Przykładowo można zostać poinformowanym, że dział kadr może przechowywać dane dotyczące nagan tylko przez dwa lata. Jeśli pracownik przypuszcza, że jego szanse na awans zmniejszają się, ponieważ akta nagan mają więcej niż dwa lata, może zaskarżyć firmę i żądać odszkodowania za poniesione szkody. W aktach sądowych znalazło się wiele spraw bazujących na takich przepisach. Co się stanie, gdy akta dotyczące nagan mają w rzeczywistości postać pliku znajdującego się na czyimś komputerze? Prawo dotyczy również komputerów. Pliki muszą zostać usunięte. Co jednak będzie, gdy plik zapisano na woluminie archiwizującym przechowywanym przez bliżej nieokreślony okres? Wiele firm ustala zasady archiwizowania danych, które nakazują, aby co roku dla każdego systemu przez nieokreślony czas magazynować jeden wolumin. W ostatnich latach część firm przegrała sprawy sądowe z powodu stosowania takich zasad. Jedynym sposobem obejścia takich komplikacji jest wyłączenie ze zwykłych kopii zapasowych wszelkich katalogów zawierających tego typu informacje i archiwizowanie ich w ramach innego harmonogramu, zgodnego z lokalnymi przepisami dotyczącymi przechowywania dokumentów. Przyznam, że jest to uciążliwe. W mojej książce Czytelnik nie przeczyta, że bezcelowe robienie czegoś specjalnego jest czymś dobrym. Jednak w tych czasach pełnych konfliktów nie należy pomijać tej kwestii.
Uwzględnianie w planie rozbudowy Inny powszechny problem ma miejsce, gdy z czasem system archiwizowania jest rozbudowywany. To, co działa w przypadku jednego lub dwóch komputerów, niekoniecznie poradzi sobie z 200 komputerami. Wraz ze wzrostem objętości danych zwiększa się zapotrzebowanie na ustandaryzowany system archiwizowania. Jest to problem, ponieważ większość administratorów, tworząc skrypt powłoki, który wykonuje kopie zapasową danych z pięciu lub sześciu komputerów, nie uwzględnia tego, że w przyszłości komputerów może być więcej. Pamiętam swoje początki, gdy byłem operatorem kopii zapasowych. Miałem pod opieką 10 lub 11 komputerów. Jeden z nich, z systemem Ultrix, robił wrażenie. W tych czasach mówiliśmy, że był ogromny (przechowywał prawie 8 gigabajtów danych!). Największy napęd taśmowy Exabyte, jakim dysponowaliśmy, oferował pojemność 10 GB (z kompresją). Dla komputera z danymi o pojemności 8 GB stosowaliśmy duży napęd taśmowy 10 GB. Mieliśmy skrypt archiwizujący, moim zdaniem naprawdę dobry, który bez żadnych modyfikacji działał przez dwa lata. Wtedy pojawiły się komputery HP. Najmniejszy z nich miał pojemność 20 GB, największy oferował znacznie więcej. Jednak te duże serwery były wyposażone w niewielki napęd DDS o pojemności 2 GB (4 GB z kompresją). Twórca skryptu archiwizującego nigdy nie pomyślał o komputerze, który będzie przechowywał dane o objętości większej niż pojemność taśmy. Pewnego dnia obudziłem się i dowiedziałem, że nasz serwer miał awarię. Później wiele miesięcy
Decydowan e o metodz e arch w zowan a danych
|
61
zajęło mi tworzenie skryptu powłoki, który obsługiwałby dzielenie zawartości napędu lub systemu plików na dwie taśmy. W końcu zrezygnowałem i kupiłem komercyjny produkt. Zmierzam do tego, że jeśli pomyślałbym o tym wcześniej, być może byłbym w stanie poradzić sobie z wyżej przedstawionym ograniczeniem bez siedzenia tyle po nocach. Gdy projektuje się system archiwizowania lub centrum danych, trzeba wziąć pod uwagę to, że komputery będą pojemniejsze i zwiększy się ich liczba. Ponadto należy zaplanować, co się zrobi, gdy stanie się coś złego. Można mi wierzyć, że tak będzie. Znacznie lepiej dla zdrowia psychicznego (nie wspominając o gwarancji utrzymania pracy) będzie przewidzieć nieuniknione i uwzględnić to od razu podczas projektowania systemu archiwizowania. System ten jest czymś, co powinno być wykonane dobrze już za pierwszym razem. Jeśli przed zaprojektowaniem systemu archiwizowania poświęci się trochę czasu na wyobrażenie sobie, w jaki sposób można spowodować jego awarię, zaoszczędzi się wiele pieniędzy na tabletkach nasennych i przeciwbólowych.
Nie należy zapominać o uniksowych wartościach mtime, atime i ctime Systemy operacyjne Unix, Linux i Mac OS dla każdego pliku rejestrują trzy różne czasy. Pierwszy to czas modyfikacji mtime. Wartość mtime jest zmieniana każdorazowo, gdy plik zostaje zmodyfikowany (na przykład po dodaniu wierszy do pliku dziennika). Następny czas to czas dostępu atime. Wartość atime jest modyfikowana zawsze, gdy plik jest używany (na przykład po uruchomieniu skryptu lub odczytaniu dokumentu). Ostatnim czasem jest czas zmiany ctime. Wartość ctime jest aktualizowana każdorazowo, gdy są modyfikowane atrybuty pliku, takie jak uprawnienia lub prawo własności. Administratorzy korzystają z wartości ctime, szukając śladów włamań hakerów, którzy mogą zmieniać uprawnienia pliku lub próbować lokalizować słabe punkty systemu. Administratorzy monitorują też wartość atime, gdy szukają dużych plików nieużywanych od dłuższego czasu (takie pliki mogą zostać zarchiwizowane, a następnie usunięte).
Kopie zapasowe modyfikują wartość atime Można się zastanawiać, co ma to wspólnego z kopiami zapasowymi. Trzeba wiedzieć, że każde narzędzie wykonujące kopię zapasową przy wykorzystaniu systemu plików podczas odczytu archiwizowanego pliku modyfikuje wartość atime. Niemal wszystkie komercyjne narzędzia, a także programy: tar, cpio i dd4, pozwalają na coś takiego. Ponieważ program dump odczytuje system plików za pośrednictwem pliku urządzenia, nie zmienia wartości atime.
Wartość atime może zostać zresetowana, lecz nie bez konsekwencji Zanim program archiwizujący umieści plik w kopii zapasowej, może sprawdzić jego wartość atime. Po zarchiwizowaniu pliku wartość atime oczywiście zmieni się. Program może następnie za pomocą wywołania systemowego utime zresetować wartość atime do jej oryginalnego ustawienia. Jednak zmiana wartości atime jest uważana za modyfikację atrybutu, z czym wiąże się zmiana wartości ctime. Oznacza to, że gdy użyje się takiego narzędzia, jak cpio lub gtar, 4
Oczywiście program dd modyfikuje wartość atime, gdy za jego pomocą kopiuje się pojedynczy plik systemu plików. Jeśli przy użyciu tego programu kopiuje się plik urządzenia, nie zostaną zmienione czasy dostępu plików systemu plików.
62
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
które może resetować wartość atime, dla każdego zarchiwizowanego pliku zostanie zmieniona wartość ctime. Jeśli ktoś dysponuje systemem monitorującym zmiany wartości ctime, bez wątpienia uzna, że ma do czynienia z hakerem! Zrozumienie, w jaki sposób używane narzędzie traktuje wartości atime i ctime, jest niezbędne.
Nie wolno zapomnieć o listach kontroli dostępu ACL Pliki systemu Windows zapisane w systemie plików NTFS i część plików nowszych linuksowych systemów plików korzysta z list kontroli dostępu ACL (Access Control List), umożliwiających nadawanie lub odbieranie użytkownikom uprawnień. Listy ACL decydują o tym, kto może odczytywać, zapisywać, wykonywać i modyfikować plik lub mieć nad nim pełną kontrolę. Rysunek 2.1 przedstawia przykład list ACL.
Rysunek 2.1. Przykład listy kontroli dostępu
Trzeba sprawdzić, jak wykorzystywany produkt archiwizujący obsługuje listy ACL. Właściwa metoda polega na archiwizowaniu i odtwarzaniu list ACL. Choć w przypadku komercyjnych produktów jest to standardowa funkcja, niestety, nie wszystkie programy open source ją oferują. Podczas analizowania narzędzi open source trzeba pamiętać o sprawdzeniu kwestii przetwarzania list ACL.
Trzeba pamiętać o rozwidleniu zasobów systemu Mac OS Pliki systemu Mac OS zapisane w systemach plików: MFS, HFS lub HFS Plus mają dwa rozwidlenia: danych i zasobów. Rozwidlenie danych zawiera rzeczywiste dane pliku, takie jak tekst. Rozwidlenie zasobów przechowuje powiązane dane strukturalne pliku, takie jak przesunięcia, menu, okna dialogowe i ikony. Dwa rozwidlenia są ze sobą ściśle powiązane, tworząc jeden plik. Choć zwykle rozwidlenie zasobów jest stosowane przez pliki wykonywalne, może z niego
Decydowan e o metodz e arch w zowan a danych
|
63
korzystać każdy plik, a także inne aplikacje. Przykładowo program przetwarzający tekst może przechowywać tekst pliku w rozwidleniu danych, a obrazy pliku — w rozwidleniu zasobów. Podobnie do list ACL systemu Windows rozwidlenia zasobów wymagają archiwizowania. Jednak nie wszystkie produkty archiwizujące wykonują to w poprawny sposób. Trzeba się upewnić, co system archiwizowania robi z rozwidleniem danych i zasobów.
Należy dbać o maksymalne uproszczenie W przypadku kopii zapasowych stwierdzenie to jest dwukrotnie lub trzykrotnie ważniejsze. Im bardziej skomplikowany schemat archiwizowania, tym bardziej prawdopodobne, że zawiedzie. Jeśli schemat nie jest zrozumiały, nie będzie można go wdrożyć. Trzeba pamiętać o tym każdorazowo, gdy do systemu archiwizowania dodaje się nowy mniej lub bardziej ważny element. Każda zmiana powoduje zagrożenie danych. Ponadto każda modyfikacja może jeszcze bardziej zwiększyć złożoność systemu archiwizowania i sprawić, że będzie trudniejszy do objaśnienia nowej osobie odpowiedzialnej za archiwizowanie. Jeden z szefów działu obsługi technicznej komercyjnego produktu archiwizującego stwierdził, że cały czas widzi to samo. Ktoś naprawdę dobrze opanuje oprogramowanie i napisze różne skrypty automatyzujące określone zadania. Kopie zapasowe są dobrze naoliwioną maszyną do momentu, gdy zajmie się nimi praktykant. Ponieważ nie rozumie on wszystkich szczegółów systemu, wszystko zaczyna zawodzić. Nagle dane znajdują się w niebezpieczeństwie. Trzeba o tym pamiętać następnym razem, gdy postanowi się dodać do skryptu archiwizującego jakąś nową fajną funkcję. Poniższy komentarz dotyczy również wcześniejszego podrozdziału „Uwzględnianie w planie rozbudowy”. Jednym z często popełnianych błędów decyzyjnych jest rezygnowanie ze stosowania automatyzacji od samego początku. Znacznie łatwiej po prostu umieścić gdzieś na stałe w pliku listę dołączeń lub wstawić ją do konfiguracji narzędzia cron bądź w samym wpisie zaplanowanego zadania. Jednak w takim przypadku metod archiwizowania jest wiele. Jeśli każdy komputer ma własny, specjalnie dostosowany system archiwizowania, bardzo trudno monitorować mechanizm kopii zapasowych i objaśnić go nowemu pracownikowi. Należy pamiętać, że słowo specjalne nie ma pozytywnego znaczenia. Wystarczy to na okrągło powtarzać, aby w końcu w to uwierzyć.
Nic szczególnego się nie stanie, gdy zarządza się dwoma lub trzema komputerami. Jednak sytuacja zmieni się w przypadku 200 komputerów. Jeżeli trzeba zapamiętywać szczegóły związane z każdym systemem każdorazowo podczas przeglądania dzienników, bez wątpienia wszystko wymknie się spod kontroli. Wyjątki charakterystyczne dla poszczególnych systemów oznaczają również, że pewne rzeczy się przeoczy. Czy administrator pamięta, że dziewięć miesięcy temu dla komputera apollo zdefiniowano wykluczenie katalogu /home*? Lepiej, żeby pamiętał, gdyż właśnie apollo stał się głównym serwerem NFS i ma już siedem katalogów home. Jeśli obcej osobie nie można objaśnić systemu archiwizowania w najwyżej kilka godzin, prawdopodobnie wszystko jest zbyt skomplikowane. Powinno się przyjrzeć kwestiom związanym z wdrożeniem, takim jak scentralizowane rejestrowanie, ustandaryzowane skrypty archiwizujące i określony poziom automatyzacji.
64
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Należy czytać instrukcje Adres IP serwera archiwizującego dużej firmy programistycznej był cały czas zmieniany na inny, prawdopodobnie losowo wybrany. Jedyny identyfikowalny schemat był taki, że każdy nowy adres IP, który zostałby przypisany serwerowi, był adresem jednego z archiwizowanych klientów. Skontaktowano się z działem obsługi dostawców, a ponadto nad rozwiązaniem problemu nieustannie pracowali wszyscy inżynierowie. Jednak nikt nie potrafił znaleźć przyczyny problemu. Okazało się, że operator archiwizacji wyznaczony do rozwiązywania problemów z kopiami zapasowymi stosował standardowe procedury diagnostyczne ustalone dla grupy. Jednak nowy operator pomieszał kilka poleceń. W efekcie, gdy próbował przeprowadzić podstawową operację rozpoznawania nazw archiwizowanych hostów, zamiast polecenia nslookup nazwa_ hosta było wykonywane polecenie ifconfig -a nazwa_hosta. Powodowało ono zmianę adresu IP serwera archiwizującego na adres dowolnego hosta, który miał problemy z archiwizowaniem. Działo się to w losowych porach dnia i tylko w te dni, w które pracował nowy operator. — Jorgen Lie
Przechowywanie kopii zapasowych Żadnego pożytku nie będzie z naprawdę dobrych kopii zapasowych, gdy dojdzie do zniszczenia, zgubienia lub pomieszania woluminów archiwizacyjnych. Trzeba dysponować dobrze zdefiniowanym procesem magazynowania nośników.
Ogólne informacje na temat przechowywania Jeśli Czytelnik przeczytał wcześniejszą treść książki, wie, że kopie zapasowe traktuję bardzo poważnie. Jeżeli wykonane kopie zapasowe są istotne, czy nośnik, na którym je umieszczono, nie jest równie ważny? Czyż nie jest to oczywiste? Cóż, nie wywnioskuje się tego na podstawie obserwacji większości „bibliotek” woluminów. ”Stosy” woluminów to raczej bardziej odpowiednie określenie. Z iloma pomieszczeniami komputerowymi, w których woluminy były rozmieszczone w różnych miejscach, Czytelnik miał do czynienia? Woluminy są układane w stosy, stawiane za komputerami, a napęd taśmowy naprawdę dobrze sprawdza się w roli podstawki na kawę (prawda, że nie chcemy, aby na nowym napędzie zostały jakiekolwiek okręgi po filiżance kawy?). Czy kiedykolwiek Czytelnik potrzebował woluminu i nie mógł go znaleźć? Zdarzyło mi się to. Jest to okropne uczucie, gdy wie się, że plik zapisano na woluminie, lecz nie można znaleźć tego nieszczęsnego woluminu! Dlaczego zatem traktuje się woluminy archiwizujące jak brudne rzeczy do prania? Trzeba uporządkować woluminy! Woluminom należy nadać etykiety, skatalogować je, przypisać im unikatowe nazwy lub liczby i umieścić w określonego typu pojemniku z zachowaniem jakiegoś logicznego uporządkowania. Jeśli tego nie zrobimy, nawiedzi nas demon archiwizowania! Możliwość szybkiego przeprowadzenia dużej operacji odtwarzania zależy bezpośrednio od tego, jak dobrze uporządkowano nośniki.
Przechowywan e kop zapasowych
|
65
Lokalne przechowywanie Jak wygląda sprawa szafy używanej do lokalnego przechowywania nośników z woluminami? Czy Czytelnik jej nie posiada? A może korzysta z szafki na akta? Można zastosować dowolny pojemnik. Jeśli jednak można sobie pozwolić na pojemniki przeznaczone do magazynowania nośników, warto je kupić. . Nikt nie pożałuje takiego zakupu. Przeprowadzanie operacji odtwarzania jest znacznie mniej stresujące, gdy bez problemów można znaleźć wolumin. Kilka firm produkuje takie pojemniki. Można także kupić szafy ognioodporne. Jednak należy pamiętać, że ognioodporność nie oznacza żaroodporności. Tego typu pojemniki na nośniki mają za zadanie ochronić przed krótkotrwałym ogniem, który szybko zostanie ugaszony przez system zraszania. Jeśli tuż przy pojemniku przez długi czas będzie płonął ogień lub w pomieszczeniu znacząco wzrośnie temperatura, z woluminów może nie być żadnego pożytku (jest to kolejny dobry powód, dla którego woluminy trzeba również składować poza obrębem firmy). Niech najbardziej zorganizowana osoba w firmie zaprojektuje system magazynowania nośników. Oto moja propozycja. Warto poprosić najlepszego pracownika działu administracyjnego, aby przyjrzał się systemowi magazynowania i porównał go ze swoją szafą na dokumenty. Należy wyjaśnić, że oczekuje się najszczerszej opinii.
12 000 złotych sztab Instytucja finansowa, w której raz pracowałem, miała magazyn liczący ponad 12 000 nośników. Nigdy nie zdarzyło się, żeby przepadł choćby jeden z nich. Jak się to nam udało? Traktowaliśmy każdy wolumin, jakby był sztabą złota. Nasz system magazynowania był oparty na kilku elementach: • Każdy wolumin miał unikatowy liczbowy identyfikator. • Identyfikator miał postać kodu paskowego umieszczonego na woluminie (mogę zapew-
nić, że etykietowanie więcej niż 500 oryginalnych 5,25-calowych dyskietek instalacyjnych dodanych do serwerów AT&T 3b2/1000 nie było niczym przyjemnym; jednak udało się nam to zrobić z pomocą grupy stażystów!).
• Numer, nazwa, przeznaczenie, typ nośnika, data użycia i lokalizacja każdego woluminu
były przechowywane w bazie danych Informix. • Ta sama baza danych rejestrowała każdą operację przeniesienia woluminu. Gdy wolumin
zabrano do innego budynku w celu przeprowadzenia archiwizacji lub odtworzenia, było to zapisywane w bazie. Jeśli wolumin wysłano do dostawcy zewnętrznego magazynu, informacja o tym trafiała do bazy danych. Jeżeli administrator wypożyczył wolumin archiwizujący lub instalacyjny dysk CD, było to rejestrowane w polu „Wypożyczone”. • Gdy w celu odtworzenia danych na krótki okres wyciągano z biblioteki jeden z nośników,
odpowiednią uwagę zamieszczano ręcznie w dzienniku. W przypadku wykonywanych w ciągu dnia dużych operacji przenoszenia dużej liczby woluminów posługiwaliśmy się czytnikiem kodów kreskowych współpracującym ze skryptem powłoki automatycznie aktualizującym bazę danych. • Co kwartał przeprowadzaliśmy pełną inwentaryzację, a raz w miesiącu wybiórczą. Jeśli
po wykonaniu wybiórczej inwentaryzacji okazało się, że jest zbyt wiele błędów, oznaczało to konieczność przeprowadzenia następnej pełnej inwentaryzacji.
66
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
• Podczas inwentaryzacji porównywaliśmy każdy wolumin z wydrukiem z bazy danych,
a także każdy wpis wydruku z rzeczywistym woluminem (druga część procesu uwzględniała wychwytywanie administratorów, którzy w swoich biurkach pochowali kopie zapasowe lub nośniki instalacyjne).
• Woluminy były przechowywane w zamykanych na klucz szafach firmy Wrightline. Do-
stęp do woluminów mieli wyłącznie operatorzy archiwizacji (były to te same osoby, które odpowiadały za zaginięcie jakiegoś nośnika).
• Inwentaryzacje były nazywane samoinspekcjami. Raz w roku dodatkowo dział inspekcji
dokonywał wewnętrznego audytu, a zewnętrzny audyt przeprowadzała organizacja OCC (Office of the Comptroller of the Currency). Jej pracownicy przeglądali dzienniki, szukając niespójności. Posiadali umiejętność identyfikowania trochę dziwnie wyglądających wpisów. Gdy na takie natrafili, mówili: „Czy możemy to zobaczyć…”.
• Cały proces był dokładnie dokumentowany. Choć prawdopodobnie instytucja ulepszyła
nieznacznie te procedury, w dalszym ciągu z nich korzysta.
Organizacja OCC traktuje kwestię ochrony danych bardzo poważnie (nawiasem mówiąc, w Stanach Zjednoczonych organizacja ta ma możliwość zakazania komuś prowadzenia działalności bankowej). Trzeba się upewnić, że tego typu organizacja jest usatysfakcjonowana procedurami stosowanymi przez kontrolowaną firmę.
Przechowywanie poza obrębem firmy Po uporządkowaniu nośników przechowywanych lokalnie pora wziąć pod uwagę magazynowanie ich na zewnątrz. Można wyróżnić dwie metody składowania danych poza obrębem firmy: • zdalne składowanie danych na nośnikach (z użyciem taśm). • zdalne elektroniczne składowanie danych (bez użycia taśm).
Choć druga metoda może być kosztowna, nie jest tak droga, jak niektórzy myślą. Ponadto znacznie łatwiej z niej skorzystać w przypadku nieszczęśliwych wydarzeń i nie straci się taśm, gdyż takowych nie ma. Oczywiście właśnie na coś takiego (zniszczenie nośników lub budynku, w którym się znajdują) ma przygotować magazynowanie kopii zapasowych poza obrębem firmy. Jeśli dysponuje się w innym miejscu kompletnym zestawem kopii zapasowych, będzie można odtworzyć dane nawet w przypadku najgorszej lokalnej klęski żywiołowej.
Wybieranie dostawcy zdalnego składowania danych na nośnikach Zadanie to jest tak istotne jak wybieranie oprogramowania archiwizującego. Wybranie złego dostawcy może być zgubne w skutkach. Będzie się od niego zależnym, a przecież pełni on rolę ostatniej linii obrony. Właśnie za to mu się płaci. W związku z tym stosowane przez dostawcę procedury przechowywania i segregowania muszą być bez zarzutu. Muszą być lepsze niż w scenariuszu przedstawionym w podrozdziale „12 000 złotych sztab”. Procedura rejestrowania operacji przenoszenia używana przez dostawcę musi być pozbawiona luk. Oto lista rzeczy, które należy uwzględnić podczas wybierania dostawcy usługi zewnętrznego magazynowania: Inwentaryzowanie poszczególnych nośników Pierwszy dostawca usługi składowania danych na nośnikach, z którego oferty skorzystałem, wszystkie moje woluminy przechowywał w pudełkach. Nigdy nie inwentaryzował poszczególnych nośników. Sam musiałem wiedzieć, w którym pudełku znajdował się Przechowywan e kop zapasowych
|
67
każdy wolumin. Gdy potrzebowałem woluminu z jednego z pudełek, pracownik dostawcy musiał pojechać po niego i mi go przywieźć. Wtedy jednak w żaden sposób nie było rejestrowane, gdzie wolumin faktycznie się znajdował. Coś takiego określa się mianem składowania kontenerowego. Większość firm zdalnie składujących dane na nośnikach oferuje również magazynowanie poszczególnych nośników. Rozwiązanie to zapewnia monitorowanie każdego woluminu. Inwentaryzowanie z użyciem kodu kreskowego, bazujące na lokalizacji Każdy wolumin powinien mieć kod kreskowy umożliwiający dostawcy usługi składowania skanowanie wszystkich pobranych i oddanych woluminów. Dostawca powinien wczytywać do bazy magazynu kody kreskowe otrzymanych woluminów i usuwać z bazy kody woluminów oddanych klientowi. Podwójna elektroniczna kontrola Jeśli samemu rejestruje się położenie każdego woluminu i to samo robi dostawca, obie strony powinny się wzajemnie podwójnie sprawdzać. Jedna lub obie strony mogą wydrukować zestawienie lokalizacji woluminów wyeksportowane z bazy danych. Można napisać program, który porównuje położenie każdego woluminu w dwóch różnych magazynach. Nie jestem w stanie powiedzieć, ile razy taki program oszczędził mi problemów. Dobrze jest znaleźć błąd w chwili, gdy wystąpi, niż tygodnie później, gdy trzeba użyć woluminu, który zaginął.
Testowanie usługi wybranego dostawcy Należy sprawdzić, czy dostawca jest czujny. Jeden z umożliwiających to sposobów polega na przekonaniu się, czy dostawca pozwoli na zostawienie nas samych w magazynie. Ponieważ jest się klientem takiej firmy, można jej pracowników poprosić o zgodę na przeprowadzenie inwentaryzacji nośników. Trzeba upewnić się, czy firma udzieli nieograniczonego dostępu do wnętrza magazynu. Jeśli pracownicy pozostawią klienta w środku bez żadnego nadzoru, uzyska on dostęp do nośników innych firm. Oznacza to, że osoby z innych firm mogą mieć dostęp do naszych nośników. Od takiego dostawcy należy nie odejść, lecz uciec. Należy organizować niespodziewane inspekcje, a także wyrywkowe kontrole. Należy poprosić o oddanie losowych woluminów, aby się przekonać, jak szybko dostawca jest w stanie je odnaleźć. Należy poprosić o właśnie wysłane woluminy. Woluminy będące w trakcie inwentaryzowania są najtrudniejsze do odnalezienia. Jednak dostawca powinien być w stanie to zrobić. Jeżeli regularnie każdego dnia wysyła się dostawcy pięć woluminów do zinwentaryzowania, pewnego dnia należy przekazać cztery woluminy, lecz w dokumentach zlecić inwentaryzację pięciu woluminów. Ma to na celu sprawdzenie, czy dostawca zwróci na to uwagę. Jeśli nie, trzeba interweniować! Procedury dostawcy powinny chronić klienta przed tego typu ludzkimi błędami. Jeżeli tak nie jest, procedury wymagają ulepszenia. Trzeba być nieprzewidywalnym, w przeciwnym razie można zostać zignorowanym. Sprawienie, że dostawca będzie cały czas czujny, spowoduje, że dobrze zapamięta klienta i to, jak ważne są dla niego jego woluminy (przy okazji należy wspomnieć, że możliwość przeprowadzania niespodziewanych inspekcji i wyrywkowych kontroli powinna być zawarta w umowie; trzeba się upewnić, że nie stanowi to problemu dla dostawcy, w przeciwnym razie wiadomo, co należy zrobić). Dostawcy przechowują dwa rodzaje woluminów: takie, które ciągle są wymieniane, i takie, które są magazynowane przez nieokreślony czas. Gdy wymienia się cyklicznie woluminy, są one inwentaryzowane. W przypadku archiwizowanych woluminów sprawa wygląda zupeł-
68
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
nie inaczej. Jeśli wolumin przeleżał u dostawcy dwa lata i nigdy nie był używany, jak stwierdzić, że nic się z nim nie stało? Powinno się przynajmniej raz w roku (zaleca się dwa) przeprowadzić pełną inwentaryzację takich woluminów. Należy wysyłać oryginały i zatrzymywać kopie. Jedną z rzeczy, które powinno się regularnie testować, jest stosowana procedura kopiowania. Jeśli wysyła się woluminy poza obręb firmy, niektóre produkty archiwizujące oferują możliwość wysyłania oryginałów lub kopii. Jeżeli jest to możliwe, należy wysyłać oryginały. Gdy konieczne okaże się odtworzenie danych, należy użyć kopii. Gdy coś pójdzie nie tak, zawsze można udać się po oryginał. Ten proces weryfikuje procedurę kopiowania każdorazowo podczas odtwarzania danych. Można wyeliminować błędy obecne w procesie, zanim dojdzie do jakiegoś nieszczęśliwego zdarzenia. Pamiętam kilka sytuacji, w których napęd uszkodził wolumin lub rozlała się na nim woda. Naprawdę bardzo potrzebna nam była wtedy kopia przechowywana na zewnątrz firmy. Jest to nieodpowiednia pora, aby dowiadywać się, że procedura kopiowania nie jest dobra!
Zdalne elektroniczne składowanie danych Elektroniczne składowanie danych staje się dość popularne. Choć może być kosztowne, jest czymś wspaniałym. Jeśli można sobie pozwolić na takie rozwiązanie, szczególnie do niego zachęcam. Chodzi o to, że kopie zapasowe są wysyłane bezpośrednio do systemu magazynowania dostawcy usługi elektronicznego składowania danych. Trzeba sobie zadać jedno pytanie: „Co się stanie, gdy magazyn dostawcy całkowicie spłonie?”. Wszystkie dane mogą zostać utracone. Nie można pozwolić na coś takiego. Trzeba się upewnić, że firma magazynująca dane to niejedyne miejsce, w którym umieszczono zarchiwizowane dane. Dodatkowo należy wiedzieć, jak przeprowadzi się dużą operację odtwarzania. Choć niewielkie łącze sieciowe może być wystarczające do ciągłego wykonywania przyrostowych kopii zapasowych, prawdopodobnie nie sprawdzi się w przypadku odtwarzania 100 GB danych. Jeśli stanowi to problem, należy skontaktować się z dostawcą usługi elektronicznego składowania danych w sprawie opcji lokalnego odtwarzania danych.
Testowanie kopii zapasowych Chciałbym, żeby na ten temat było tyle do powiedzenia, aby pojawiła się potrzeba stworzenia oddzielnego rozdziału. Wynika to stąd, że testowanie kopii zapasowych jest bardzo ważną kwestią. Nie mogę powiedzieć, ile słyszałem historii o osobach, które zwlekały z przetestowaniem swoich kopii zapasowych, aż stwierdziły, że muszą przeprowadzić proces pełnego odtwarzania danych. Właśnie w takich momentach okazuje się, że użyto złego urządzenia lub współczynnika bloków bądź urządzenie wygenerowało błędy wejścia-wyjścia. Kwestia testowania kopii zapasowych nie może być lekceważona, w przeciwnym razie niemiła niespodzianka jest nieunikniona.
Należy wszystko testować! Ważne jest, aby testować każdego typu operację odtwarzania. Jeśli sprawdza się kopie zapasowe systemu plików, trzeba przeprowadzić następujące operacje: • Odtworzenie wielu pojedynczych plików. Czy znajdzie się igłę w stogu siana? • Odtworzenie starszej wersji pliku.
Testowan e kop zapasowych
|
69
• Odtworzenie całej zawartości napędu lub systemu plików i porównanie uzyskanych wy-
ników z oryginalnymi. Czy są jednakowego rozmiaru itd.? • Próba odtworzenia systemu, przy założeniu, że w całości uległ awarii. • Skorzystanie z alternatywnej kopii zapasowej, przy założeniu, że określony wolumin jest zły. • Pobranie kilku woluminów od dostawcy usługi zewnętrznego magazynowania. • Próba poradzenia sobie z sytuacją, w której został zniszczony serwer archiwizujący (jest
to trudne zadanie!). Test ten jest wyjątkowo istotny, gdy korzysta się z darmowego lub komercyjnego narzędzia archiwizującego. Ponieważ część produktów nie radzi sobie dobrze z takimi sytuacjami, można mieć spore problemy. Jeśli testuje się odtwarzanie bazy danych, trzeba wykonać następujące operacje: • Odtworzenie części bazy danych, przy założeniu, że utracono tylko jeden plik danych lub
napęd dyskowy (jeśli jest to możliwe). • Odtworzenie całej bazy danych na innym serwerze (w tym przypadku można się dowie-
dzieć o plikach, których nie dołączono). • Odtworzenie stanu bazy danych z określonej chwili z przeszłości (ćwiczenie to okaże się
pomocne, gdy trzeba będzie odtwarzać dane po błędzie administratora bazy danych lub użytkownika). • Skorzystanie ze starszej kopii zapasowej, przy założeniu, że nie udało się wykonanie kopii
zeszłej nocy. Teoretycznie, jeśli na woluminie archiwizacyjnym zapisano wszystkie dzienniki transakcji, powinno być możliwe użycie kopii sporządzonej kilka tygodni wcześniej, a następnie odtworzenie danych do chwili obecnej za pomocą tych dzienników. Jest to kolejny mocny argument za zastosowaniem dzienników transakcji.
Często należy wykonywać operację testowania Jak już wspomniałem, jeden dzień należy posiedzieć z kilkoma naprawdę pesymistycznymi osobami i poprosić je o wyobrażenie sobie sytuacji kwalifikujących się do przetestowania. Trzeba sprawdzić możliwość regularnego wykonania operacji odtwarzania w przypadku każdej sytuacji. To, co działa w tym miesiącu, może zawieść w następnym. Jedyną pewną rzeczą jest zmienność. Jedną z propozycji jest utworzenie listy procedur odtwarzania i losowe testowanie co miesiąc ich podzbioru. Zmienia się kierownictwo, sprzęt, sieci, a także wersje systemów operacyjnych i baz danych. Każda zmiana, o której wiadomo, powinna pociągać za sobą odpowiedni test.
Monitorowanie kopii zapasowych Jeśli nie monitoruje się kopii zapasowych, pewne jest to, że nie będą się zachowywać zgodnie z oczekiwaniami. Można tu przytoczyć analogię do garnka z zupą, która się nie ugotuje, gdy nie będzie się jej doglądać. Każda kopia zapasowa powinna mieć codziennie sprawdzany dziennik. Zadanie to może zostać też zautomatyzowane. Oto kilka przykładów: Generowanie podsumowania. Narzędzie dump wyświetla całą masę mniej istotnych dla mnie komunikatów, takich jak Pass I, Pass II, % done itp. Gdy monitoruję wykonane za pomocą tego programu kopie zapasowe setek napędów lub systemów plików, większość komunikatów 70
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
nie przedstawia zbyt dużej wartości. W rzeczywistości zależy mi, aby dowiedzieć się, co zostało zarchiwizowane, w jakim miejscu, kiedy, na jakim poziomie, a także czy został wygenerowany nadal popularny komunikat DUMP IS DONE. W celu uzyskania zestawienia tylko tych wierszy w pierwszej kolejności wykonuję polecenie grep -v, aby wykluczyć zbędne informacje i pozostawić jedynie kilka wierszy. Znacznie prościej jest przeglądać mniejszą ilość informacji. Taka metoda może też być zastosowana w przypadku innych poleceń archiwizujących w systemach: Unix, Linux i Mac OS. W systemie Windows coś podobnego realizuje się za pomocą zaplanowanego zadania. Można spowodować, że zadanie utworzy dziennik w jakimś miejscu na dysku C:\, a następnie dziennik zostanie przesłany do administratora za pośrednictwem programu pocztowego SMTP, takiego jak blat (darmowe narzędzie trybu wiersza poleceń przesyłające wiadomość pocztową za pomocą protokołu SMTP lub post do grupy dyskusyjnej Usenet przy użyciu protokołu NNTP). Program blat można pobrać pod adresem http://www.blat.net. Wyświetlanie wszystkiego, co nietypowe. Zadanie to można zrealizować na dwa sposoby. Jeśli znane są komunikaty pojawiające się, gdy coś pójdzie nie tak, można je wychwycić narzędziem grep. Inna metoda polega na zastosowaniu polecenia grep -v usuwającego wszystkie spodziewane wiersze i sprawdzeniu tego, co pozostało. Jeżeli nie ma nic — znakomicie! Jeśli pozostały wiersze, prawdopodobnie zawierają błędy. Można zobaczyć wiersze I/O error i Write error lub coś jeszcze innego. Nie są one wskazane w przypadku kopii zapasowych. Jeśli to samo chce się osiągnąć w przypadku zaplanowanego zadania systemu Windows, trzeba skorzystać z jakiegoś emulatora uniksowego, takiego jak Cygwin, UWIN lub GnuWin32, umożliwiającego uruchomienie w systemie Windows narzędzia grep i innych poleceń powłoki.
Zawsze można to jeszcze bardziej ulepszyć Nie ma znaczenia to, jak dobre są kopie zapasowe, ponieważ zawsze mogą być lepsze. Można spędzać każdą bezsenną godzinę na dostrajaniu i ulepszaniu każdego elementu programu archiwizującego, a także wiedzieć wszystko na temat kopii zapasowych, a i tak możliwe jest dalsze doskonalenie. Moje kopie zapasowe nigdy nie będą wystarczająco dobre. Zawsze znajdzie się jakiś nowy szczegół jakiegoś innego pakietu archiwizacyjnego, większy lub bardziej „inteligentny” automatyczny zmieniacz, szybszy napęd archiwizujący lub jakiś scenariusz, który nie zostanie przeze mnie uwzględniony. Jednak trzeba sobie zdać sprawę z tego, że każda wprowadzona zmiana stwarza zagrożenie utraty danych. W książce często podkreślam, że każdorazowo, gdy pojawia się czynnik ludzki, sprawy się komplikują. Choć można być najlepszym na świecie programistą skryptów powłoki lub języka Perl, nadal będzie się popełniać błędy.
Jeśli coś nie jest barokowe, nie należy tego przyozdabiać Barok wymagał przyozdabiania. Bez przesady! Jedno niezmienne tempo? I klawesyn? To musiało przeminąć. Na szczęście Bartolomeo Cristofori w 1709 r. wynalazł fortepian i ofiarował nam instrument, który mógł grać głośno (fortissimo) i cicho (piano). Niedługo później rozpoczął się klasycyzm i muzyka zaczęła cechować się zmiennością tempa i uczuciem. Jeśli jednak coś nie jest zepsute, nie należy tego naprawiać! Choć pewnie każdy już o tym słyszał, gdy pod uwagę weźmie się ryzyko związane z każdą zmianą, w świecie archiwizowania zdanie to nabiera jeszcze większego znaczenia. Czytając tę książkę lub jakieś czasopismo bądź
Mon torowan e kop zapasowych
|
71
rozmawiając z innymi administratorami, bez wątpienia Czytelnik stworzy listę rzeczy, które chciałby zrobić. Należy skoncentrować się na lukach lub scenariuszach, których stosowany plan archiwizowania i odtwarzania po prostu nie uwzględnia. Zanim pomyśli się o utworzeniu fajnego programu z menu, który chciało się napisać z myślą o operacjach odtwarzania, trzeba się martwić tym, że żaden z woluminów nie jest magazynowany poza obrębem firmy. Zanim zacznie się dekorować stoisko, trzeba zająć się wszystkim tym, co zasadnicze. Zanim pod uwagę weźmie się wprowadzenie nowej zmiany, należy zadać sobie pytanie, czy coś jest jeszcze ważniejsze i czy modyfikacja jest naprawdę konieczne i warta ryzyka.
Postępowanie zgodnie z odpowiednimi procedurami wdrożeniowymi Nie należy wprowadzać zmiany w systemie archiwizacji, a następnie wdrażać jej jednocześnie na wszystkich komputerach. Zmianę należy testować na systemie projektowym, a jeszcze lepiej na systemie, który normalnie nie jest archiwizowany. W ten sposób nie wystawi się żadnej kopii zapasowej na niebezpieczeństwo. Inną dobrą praktyką jest testowanie modyfikacji równolegle z tym, co już zrobiono. Im większa zmiana, tym bardziej istotne jest przeprowadzenie równoległej konwersji. Jest tak szczególnie wtedy, gdy używa się nowej metody, a nie jedynie rozszerza dotychczas stosowaną. Starej metody należy używać do momentu, aż uzyska się pewność, że nowa metoda działa! Należy postępować zgodnie z planem podobnym do następującego: • Zmiany dotyczące archiwizowania należy sprawdzać w miejscu, w którym naprawdę nie
wyrządzą nikomu żadnych szkód, gdy spowodują na przykład awarię systemu! • Operację należy testować na niewielką skalę przy użyciu jednego systemu, przeprowa-
dzając ją tak samo jak w przypadku systemu produkcyjnego. Jeśli na przykład za pomocą programu zamierza się wykonywać zarówno zdalne, jak i lokalne kopie zapasowe, należy sprawdzić obie, ale w ograniczonej skali. • Należy podjąć próbę symulacji każdego błędu, który może wystąpić w systemie. • Wyjęcie woluminu w trakcie operacji tworzenia kopii zapasowej. • Zablokowanie woluminu przed zapisem. • Ponowne uruchomienie systemu w czasie trwania jego archiwizacji. • Przerwanie połączenia sieciowego i odłączenie zasilania napędu dyskowego. • Zapoznanie się z systemem i błędami, pod kątem których się go testuje. Symulowanie
każdego błędu w celu sprawdzenia odpowiedniej części systemu. • Testy należy przeprowadzać na niewielkiej liczbie systemów (preferowane jest uwzględ-
nienie aktualnie wybranej metody). • Gdy zmianę wdraża się na wszystkich systemach, zdecydowanie należy to zrobić rów-
nolegle. Jedna z umożliwiających to metod polega na umieszczeniu wszystkich kopii zapasowych na jak najmniejszej liczbie woluminów, a następnie użyciu pozostałych napędów do równoległego utworzenia nowej kopii. Choć osobom odpowiedzialnym za sieć może się to nie spodobać, naprawdę jest to jedyna metoda pozwalająca przeprowadzić równoległą konwersję z prawdziwego zdarzenia. Gdy dokonywałem migracji na mój pierwszy komercyjny produkt archiwizacyjny, przez niemal rok korzystałem z tej metody.
72
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
• Ze starej metody powinno się zrezygnować tylko po przetestowaniu i dokładnym udo-
kumentowaniu nowego systemu. Trzeba pamiętać o trzymaniu w pobliżu dokumentacji i programów niezbędnych do odtworzenia danych ze starego systemu do momentu, aż w nowym systemie znajdzie się zawartość wszystkich starych woluminów. • Pod uwagę należy również wziąć starsze woluminy archiwizacyjne. Czy jeśli dysponuje
się woluminami mającymi pięć lat, będzie można je odczytać za pomocą rozwiązania archiwizacyjnego nowego dostawcy? Czy będzie w ogóle możliwe odczytanie tych woluminów przy użyciu wersji 14. obecnie stosowanego oprogramowania, jeśli firma zaczęła tworzyć archiwalne woluminy za pomocą wersji 2. narzędzia? Czy sam nośnik będzie nadawał się jeszcze do odczytania? • Tym sposobem przeszliśmy do zupełnie innego zagadnienia, czyli trwałości nośnika. Jeśli
nawet nadal teoretycznie można odczytać woluminy po pojawieniu się 12. wersji oprogramowania, prawdopodobnie są one złe. Jeżeli dysponuje się archiwami przechowywanymi długoterminowo, z określoną częstotliwością trzeba wykonywać ich świeże kopie. Operacja polega na kopiowaniu zawartości starszych taśm na nowsze.
Niepowiązane ze sobą różności Początkowo chciałem nadać temu podrozdziałowi tytuł „Ojej i przy okazji”, lecz wydał mi się naprawdę dziwny.
Należy dbać o własną karierę Jednym z powodów małej popularności kopii zapasowych jest to, że ludzie obawiają się zwolnienia, jeśli źle je wykonają. Ludzie mają kłopoty, gdy nie uda się operacja odtwarzania danych. Jednak poniższe sugestie pomogą uchronić się przed czymś, co można określić jako zwolnienie na skutek nieudanego odtwarzania.
Instynkt samozachowawczy — dokumentować i jeszcze raz dokumentować Czy Czytelnik kiedykolwiek próbował wyjechać na wakacje? Jeśli jest jedyną osobą, która rozumie proces odtwarzania danych lub organizację nośników, może być pewny, że zostanie wezwany, gdy pojawi się konieczność przeprowadzenia dużej operacji odtwarzania. Kopie zapasowe są tą dziedziną administracji systemami, w przypadku której niewłaściwa dokumentacja może naprawdę przysporzyć kłopotów. Trudno wybrać się na urlop, uzyskać awans lub zrobić cokolwiek innego, co sprawi, że można będzie uwolnić się z tej magicznej sfery znanej tylko nam. Procesy archiwizowania i odtwarzania powinny być udokumentowane w stopniu umożliwiającym dowolnemu administratorowi systemu wykonanie ich krok po kroku pod naszą nieobecność. Okazuje się, że konieczność skorzystania z dokumentacji przez kogoś innego to dobra metoda sprawdzania jej przydatności. Oczywiście przeciwieństwem dobrej dokumentacji jest zła lub nieistniejąca dokumentacja. Zła dokumentacja to najpewniejszy sposób, aby musieć szukać nowej pracy. Komu uda się wybrać na prawdziwe wakacje, podczas których nie będzie nosić pagera, sprawdzać skrzynki głosowej lub pocztowej, ten, mówiąc wprost, musi uważać, ponieważ prawo Murphy’ego również dotyczy urlopów. Jest pewne, że gdy będzie na wczasach, jego współpracownicy będą świadkami
N epow ązane ze sobą różnośc
|
73
poważnego przestoju systemów. Jeśli doprowadzą do awarii lub pożaru, ponieważ nie zostawiono wytycznych, jak wykonywać proces odtwarzania, po powrocie z urlopu będą nas szukali. Administrator, który powrócił z wypoczynku, nie będzie się cieszył sympatią, a ponadto może po prostu być zmuszony do przeglądania ofert pracy. Dokumentacja jest też ważnym sposobem pozwalającym innym pracownikom firmy zorientować się, co robi administrator. Jeśli na przykład pominie się określonego typu pliki, napędy lub systemy plików, dobrze będzie poinformować o tym inne osoby. Pamiętam przynajmniej jedną bardzo długą rozmowę z użytkownikiem, który naprawdę nie chciał słyszeć, że nie archiwizowałem katalogu /tmp. „Nie miałem pojęcia, że tmp jest skrótem od temporary (tymczasowe)!” — wołał.
Można biec, lecz nie można się schować W kilku sytuacjach brak dokumentacji spowodował, że traciłem czas. Pamiętam jedne wakacje, w czasie których codziennie spędzałem przy telefonie dwie lub trzy godziny. Pamiętam przesiadywanie całymi nocami w pomieszczeniach komputerowych, ponieważ nikt nie wiedział, który przycisk wcisnąć jako następny. Jednak żadne z tych wspomnień nie jest tak silne jak wspomnienie chwili, kiedy narodziła się moja wspaniała córka Nina. Pewnie czytając to, Czytelnik powie: „Oj, jakie to słodkie”. Zgadza się, Nina i moja druga córka Marissa dały mi całkiem inny powód, aby z ochotą wstawać każdego dnia. Jednak nie o tym jest ta ramka. Szpital, w którym rodziła moja żona, był oddalony o dwie przecznice od budynku mojego biura. Wiedziałem o tym ja i moi współpracownicy (wiedział o tym każdy, kto wyjrzał przez okno!). W dniu, w którym urodziła się Nina, straciliśmy ważny system plików. Wiedziałem, że system ten znajdował się na woluminie archiwizacyjnym, a także to, że miałem wolny dzień. Zostawiłem w domu mój pager, który zwykle nosiłem przy boku. Nie zadzwoniłem do pracy. Wiedziałem, że proces był udokumentowany. Problem polegał na tym, że w pracy nie czytano dokumentacji. „Zadzwoń do Curtisa!”. Byłem w szpitalu, w pokoju mojej żony, i rozmawiałem o naszym wspaniałym dziecku, gdy zadzwonił telefon. Współpracownicy szukali mnie i zadzwonili do szpitala! Poprosili mnie, abym przyjechał. Ponieważ wiedziałem, że system był dobrze udokumentowany, moja odpowiedź była negatywna (myślę, że w rzeczywistości odłożyłem słuchawkę, nie mówiąc nic ponadto)! Jest to przykład tego, co ludzie potrafią zrobić, żeby znaleźć administratora, gdy nie udostępniono odpowiedniej dokumentacji lub nie wyjaśniono, jak z niej korzystać.
Strategia — kopie zapasowe należy wykonywać w ramach procesu instalacyjnego Gdy zostanie zakupiony nowy komputer, ktoś zadba o podłączenie go do zasilania. Ktoś inny będzie odpowiedzialny za podłączenie komputera do sieci, przypisanie mu adresu IP, dodanie do konfiguracji NIS i zainstalowanie odpowiednich poprawek. Wszystko to ma miejsce, ponieważ bez tego nic nie zadziała. Niestety, nikt nie zauważy tego, że serwera nie dodano do listy archiwizowanych komputerów. Oczywiście, taka sytuacja się utrzyma do momentu, aż serwer się zepsuje i trzeba będzie coś odtworzyć. Zadanie jest trudne i polega na sprawieniu, że coś „nieistotnego”, takiego jak kopie zapasowe, stanie się po prostu tak naturalne jak konfigurowanie połączenia sieciowego.
74
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
Nowy komputer, który pojawi się w firmie, zwykle najlepiej nadaje się do przeprowadzenia pełnych testów procesu odtwarzania lub powielania serwera. Niewiele osób zauważy brak komputera, którego jeszcze nie posiada.
Będzie tak jedynie wtedy, gdy administrator kopii zapasowych bardzo zaangażuje się w cały proces. Być może Czytelnik jest młodą osobą, która nigdy nie uczestniczy w spotkaniach dotyczących planowania, ponieważ nie rozumie, o co w tym wszystkim chodzi. Być może Czytelnik jest zorientowany, lecz po prostu nie cierpi brać udziału w takich spotkaniach. Tak jest w moim przypadku. Jeśli ktoś nie chce uczestniczyć w każdym spotkaniu, wystarczy, że się upewni, czy będzie na nim ktoś, kto śledzi interesujące go kwestie. Być może będzie to były operator archiwizacji chodzący na spotkania i pozytywnie do niego nastawiony. Z taką osobą trzeba się spotykać, aby przypominać jej, jak ważne jest podnoszenie na spotkaniach kwestii związanych z archiwizowaniem lub informowanie o wszystkich planowanych nowych komputerach. Od czasu do czasu samemu należy się udać na spotkanie i upewnić się, że ludzie wiedzą o istnieniu operatora archiwizacji i kopii zapasowych. Można mieć nadzieję, że będą o tym pamiętali, gdy następnym razem pomyślą o podłączeniu nowego komputera bez poinformowania o tym operatora kopii zapasowych. Jednak nigdy nie należy liczyć na coś takiego. Trzeba cały czas gorliwie szukać nowych komputerów wymagających archiwizowania. Nowe instalacje nie są jedyną rzeczą, która może mieć wpływ na archiwizację. Z punktu widzenia tworzenia kopii zapasowych istotne jest również pojawienie się nowej wersji systemu operacyjnego, nowych poprawek i nowej wersji bazy danych. Większość administratorów systemu instaluje i uruchamia nową wersję systemu operacyjnego lub bazy danych na nowym lub testowym komputerze, zanim zostanie umieszczona w środowisku produkcyjnym. Trzeba mieć pewność, że programy archiwizujące działają również na nowej platformie. Na myśl przychodzi mi kilka sytuacji, w których nowe wersje spowodowały problemy z archiwizowaniem. Oto kilka przykładów: • Gdy pojawił się system HP-UX 10, obsługiwał pliki o wielkości przekraczającej 2 GB. Jednak
w dokumentacji narzędzia dump napisano, że nie archiwizuje systemu plików z tak dużymi plikami. • Baza danych Oracle zmieniała się kilka razy. Czasami zapewni zgodność wstecz, a cza-
sami nie. • Początkowo po pojawieniu się systemu plików EFS (Encrypting File System) system Win-
dows nie mógł być archiwizowany przez niektóre systemy archiwizujące. • Wersje systemu Mac OS nowsze od wersji Mac OS X zawsze wydają się nieznacznie od-
biegać od „krzywej archiwizacji”. Metody stosowane w poprzedniej wersji systemu do wykonania kopii zapasowej lub obrazu w nowej wersji nie są już przydatne. Daje to pole do popisu wielu nieoficjalnym wersjom narzędzi, które faktycznie się sprawdzają. Im dłużej o tym myślę, tym więcej historii przychodzi mi na myśl. Jeśli Czytelnik zajmuje się archiwizowaniem od jakiegoś czasu, z pewnością też ma kilka własnych opowieści. Wystarczy powiedzieć, że aktualizacje systemu operacyjnego i aplikacji przysparzają problemów operatorowi kopii zapasowych i nadal będą. Dlatego należy testować i jeszcze raz testować!
N epow ązane ze sobą różnośc
|
75
Trzeba zdobyć środki finansowe niezbędne do archiwizowania Ten podrozdział absolutnie nie ma nic wspólnego z kopiami zapasowymi, lecz z polityką, budżetowaniem, pieniędzmi i uzasadnianiem kosztów. Wiem, że chwilami można odnieść wrażenie, iż moim zdaniem kopii zapasowych nie szanuje się. Być może Czytelnik będzie pracować w firmie Utopia S.A., w której pracownicy przede wszystkim myślą o kopiach zapasowych. Z kolei reszta operatorów archiwizacji musi walczyć o każdy wolumin, napęd i oprogramowanie pozwalające wykonać coraz trudniejsze zadanie umieszczenia danych na woluminie archiwizacyjnym. Uzyskanie środków finansowych wymaganych do wykonania powierzonego zadania czasami może być bardzo trudne. Jak poinformować odpowiedni dział, że niewielki zewnętrzny napęd archiwizujący dołączony do wartego milion złotych komputera, który właśnie dostarczono, po prostu do niczego się nie przyda? Ile wyrzeczeń kosztowało firmę wydanie miliona złotych na ten komputer? Jaki jeszcze wydatek ją czeka?
Trzeba być gotowym Po pierwsze, trzeba być gotowym uzasadnić swoje wymagania. Trzeba mieć następujące informacje: • Statystyki dotyczące przeprowadzonych operacji odtwarzania. • Wszelkie dostępne wartości liczbowe określające możliwy koszt poniesiony przez firmę
na skutek przestojów i utraconych danych, z uwzględnieniem wszystkich wymagań oddziałów biznesowych dotyczących docelowego czasu odtwarzania i docelowego punktu odtwarzania (bardziej szczegółowo pojęcia te przedstawiono w rozdziale 24.). • Wartości pokazujące, jak dokonany zakup pomoże zredukować koszty obsługi. • Wartości demonstrujące, jak na obecnie używany system archiwizowania negatywnie
wpływa rozwój lub nowe aplikacje. • Porównanie jednorazowego kosztu związanego z nabyciem nowszego systemu magazy-
nowania z ciągłym kosztem robocizny wynikającej z wymiany woluminów każdej nocy (trzeba być przygotowanym na wyjaśnienie, w jaki sposób większy automatyczny zmieniacz lub wirtualna biblioteka taśmowa zmniejszą ryzyko błędu ludzkiego i jaki będzie to miało pozytywny wpływ na funkcjonowanie firmy). • Udokumentowane argumenty na poparcie twierdzenia , że każdy kolejny gigabajt da-
nych generuje dodatkowe, konkretne koszty. Dobrze przygotowana prezentacja powinna uwzględniać to, co będą zapewniały tworzone kopie zapasowe, i szybkość, z jaką będzie można odtworzyć dane (choć nie należy deklarować uzyskania nierzeczywistych czasów odtwarzania, gdy nowy system może je znacząco poprawić, należy się tym pochwalić!). • Przygotowane pismo, z którego szef będzie zadowolony, wyjaśniające bardzo rzeczowo,
czego firma może się spodziewać, gdy nie zapewni żądanych środków finansowych.
Przeprowadzenie oficjalnej prezentacji Im kosztowniejsze rozwiązanie, tym bardziej jest istotne, aby przeprowadzić oficjalną prezentację, zwłaszcza gdy pracuje się w dużej korporacji. Oficjalna techniczna prezentacja składa się z trzech 76
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
części: podsumowania dla zarządu, przeglądu przechodzącego do szczegółów i technicznej specyfikacji przeznaczonej dla naprawdę zainteresowanych osób. Podsumowanie dla zarządu Powinno liczyć jedną stronę i bardzo ogólnie wyjaśniać, co przedstawiono w pozostałej części prezentacji. Wskazane są ogólne wartości i opisy. Nie należy zbytnio zagłębiać się w szczegóły. Choć prezentacja jest kierowana do wiceprezesa, który musi złożyć podpis, tego samego dnia może mieć do obejrzenia 20 innych prezentacji podobnych do tej. Przede wszystkim należy przedstawić bieżący problem i opisać jego rozwiązanie. Przegląd W przeglądzie należy przejść do szczegółów. W tej części prezentacji należy zastosować wiele nagłówków sekcji, umożliwiających odbiorcom zapoznanie się z ich zawartością lub pominięcie, jeśli nie okażą się godne zainteresowania. Nagłówki pozwalają też osobom czytającym jedynie podsumowanie dla zarządu odszukać konkretne zagadnienia, które nie są dla nich jasne. Zarys przeglądu powinien być zgodny z podsumowaniem dla zarządu. Można dodać odwołania do innych publikacji, takich jak recenzje z czasopism poświęcone konkretnemu produktowi. Jednak nie należy ich cytować. Jeżeli recenzje są stosowne, ich kopie można zawrzeć w części technicznej. Trzeba zadbać o to, aby było widać, że wszystko jest przemyślane. Na ogólnym poziomie należy porównać wybrane rozwiązanie z innymi dostępnymi opcjami, a także wyjaśnić, dlaczego zdecydowano się na zastosowanie konkretnego produktu. Należy opisać, w jaki sposób i w jakim stopniu wybrane rozwiązanie przyczyni się do przyszłego rozwoju firmy do czasu, gdy trzeba będzie ponownie zastanowić się nad zmianą technologii. Dodatkowo należy wyjaśnić, jakie ma się plany w stosunku do dotychczasowej metodologii i jaką metodę konwersji zamierza się zastosować (na przykład tymczasowe jednoczesne korzystanie z obu rozwiązań). W prezentacji sprawdzą się również tabele. Jeśli można użyć rzeczywistych wartości, będzie to znacznie bardziej skuteczne. Trzeba jedynie je zweryfikować. Jeżeli ktoś na prezentacji będzie przekonany, że wartości są nieprawdziwe, całkowicie zdyskredytuje to raport. Warto spróbować porównać początkowy koszt wybranego rozwiązania z możliwym kosztem związanym z utratą danych. Techniczna specyfikacja Trzeba iść na całość. Jeśli ktoś przetrwa dotychczas omówioną część prezentacji, będzie to oznaczać, że naprawdę się nią zainteresował lub jest prawdziwym komputerowcem, tak jak prowadzący! Jeżeli przedstawiany raport uzasadnia koszt zakupu nowego napędu dyskowego, należy poszukać tabeli porównującej względny koszt megabajta w przypadku różnych opcji. Należy dodać potwierdzone wartości i wszelkie dokumenty dołączone do proponowanego produktu. Jeżeli coś uzna się za odpowiednie, lecz będzie to zbyt długie i nudne, najlepiej będzie dodać to do technicznej specyfikacji.
Powodzenia Następne rozdziały dogłębnie prezentują różne metody, które można wykorzystać do archiwizowania systemów, zwłaszcza za pomocą darmowych narzędzi. Omówienie większości z wcześniej przedstawionych zagadnień można też znaleźć w dokumentacji odpowiedniego producenta lub zespołu tworzącego oprogramowanie open source. Książka nie ma zastępować takiej dokumentacji. Próbuję w niej wyjaśnić rzeczy, których nie zawarto w dokumentacji,
Powodzen a
|
77
i w miarę możliwości wybrane zagadnienia opisać w bardziej przystępny sposób niż instrukcja obsługi dostarczona przez producenta. Witamy w świecie kopii zapasowych. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
78
|
Rozdz ał 2. Arch w zowan e wszystk ch danych
CZĘŚĆ II
Narzędzia archiwizujące open source
Część II składa się z pięciu rozdziałów: Rozdział 3. „Podstawowe narzędzia do archiwizacji i odtwarzania” W rozdziale opisano wszystkie podstawowe narzędzia, z którymi należy się zapoznać: dump, cpio, tar i dd (systemy uniksowe), ntbackup i Przywracanie systemu (system Windows), a także ditto (system Mac OS) i wersje GNU programów: tar, cpio i rsync dostępnych dla wszystkich wymienionych platform. Rozdział 4. „Amanda” W rozdziale omówiono projekt o takiej samej nazwie, dotyczący popularnego oprogramowania archiwizującego open source. Rozdział 5. „BackupPC” W rozdziale wyjaśniono, jak korzystać z tego dyskowego systemu archiwizowania i odtwarzania. Rozdział 6. „Bacula” Rozdział pełni rolę przewodnika po produkcie archiwizującym open source, zaprojektowanym tak, aby można go było zastosować zarówno na pojedynczych komputerach, jak i w sieciach korporacji. Rozdział 7. „Narzędzia open source służące do niemal ciągłej ochrony danych” W rozdziale opisano narzędzia i metody uzyskiwania niemal ciągłej ochrony danych.
ROZDZIAŁ 3.
Podstawowe narzędzia do archiwizacji i odtwarzania
Podstawowe narzędzia archiwizujące to takie, na których bazują wszystkie niekomercyjne systemy archiwizowania. Narzędzia takie realizują ważne zadanie, którym jest kopiowanie danych z jednego miejsca w drugie, zwykle z użyciem innego formatu docelowego (na przykład program tar). Żadne z tych narzędzi nie ma wbudowanych możliwości planowania ani katalogowania sporządzonych kopii zapasowych w celu ich rejestrowania. Aby wykonywać takie zadania, trzeba skorzystać z określonego typu aplikacji zewnętrznej i planującej. Może to być prosty skrypt wsadowy i zaplanowane zadanie (system Windows), skrypt powłoki i wpis narzędzia cron (systemy Unix i Mac OS) lub jedno z zaawansowanych narzędzi open source zaprezentowanych w dalszej części książki. Do podstawowych narzędzi archiwizujących należy zaliczyć wersje programów: dump, cpio, tar i dd wbudowane w systemy uniksowe, narzędzia ntbackup i Przywracanie systemu w systemie Windows, program ditto systemu Mac OS, a także wersje GNU narzędzi: tar, cpio i rsync, dostępne dla wszystkich wymienionych platform. Niezależnie od tego, czy ktoś dopiero wkracza w świat archiwizacji czy jest doświadczonym administratorem systemów, musi zaznajomić się z tymi narzędziami.
Przegląd W rozdziale omówiono zalety i wady kilku narzędzi. W przypadku wszystkich wersji systemu Windows począwszy od wersji NT program ntbackup jest jedynym wbudowanym narzędziem pozwalającym archiwizować dane w tradycyjny sposób. Jednak warto się też zapoznać z narzędziem Przywracanie systemu. Użytkownicy systemu Mac OS X w wersji nowszej niż 10.4 mają do dyspozycji kilka uniksowych narzędzi archiwizujących, takich jak cpio, tar, rsync i ditto. Choć w przypadku komercyjnych systemów Unix dość popularne są narzędzia dump i restore, w systemie Linux nie są już tak polecane. Narzędzie dump jest dostępne w systemie Mac OS, lecz nie obsługuje systemu plików HFS+. Wbudowane narzędzie cpio jest kolejnym po dump i restore, które oferuje większość funkcji. Jednak jest mniej przystępne w obsłudze od swojego kuzyna, czyli programu tar. tar jest zadziwiająco prosty w użyciu i bardziej przenośny od narzędzi dump i cpio. Wersje GNU programów tar i cpio mają znacznie większą funkcjonalność niż wersje wbudowane w system. Jeśli za pomocą narzędzia tar lub cpio trzeba zarchiwizować
81
urządzenia o dostępie bezpośrednim lub utworzyć zdalne kopie zapasowe, najlepszym nowym przyjacielem stanie się program dd. Narzędzie rsync może być użyte do kopiowania danych między systemami plików takich systemów operacyjnych, jak Windows, Mac OS, Linux i Unix. Niniejszy rozdział rozpoczyna się od przeglądu każdego z tych narzędzi. W dalszej kolejności jest szczegółowo omawiana składnia każdego polecenia zarówno dla procesu archiwizowania, jak i odtwarzania. Na końcu rozdziału zamieszczono bezcenną tabelę, która może pełnić rolę szybkiego przewodnika pozwalającego porównać narzędzia: tar, cpio i dump.
Jak nie używać programu dump Pewnego razu wybrałem się do klienta, aby usunąć problem z pocztą elektroniczną. Okazało się, że nie miało to nic wspólnego z pocztą, lecz z serwerem DNS. Klient poprosił mnie również, abym przyjrzał się jego kopiom zapasowym. To, co ujrzałem, było przerażające. Kopie były sporządzane przez wykonywanie poleceń uruchamiających program dump bez użycia narzędzia cron. • Klient nie utworzył skryptu. Po prostu z różną częstotliwością wykonywał kolejne pole-
cenia ładujące program dump. Następne polecenia były uaktywniane, zanim poprzednie zakończyły działanie.
• Klient stosował sterownik przewijający taśmę. • Klient był zdziwiony, że wszystko mogło zmieścić się na jednej taśmie!
Zróżnicowanie systemów plików systemu Mac OS Poniższy fragment poświęcony archiwizowaniu w systemie Mac OS powstał przy udziale Leona Towns-von Staubera (autor rozdziału 14.).
To, co może utrudnić archiwizowanie w przypadku systemu Mac OS X, jest domyślnym formatem jego wbudowanego systemu plików HFS+, będącego zaawansowaną wersją starszego systemu plików Macintosh Hierarchical File System. Między systemami plików HFS+ i UFS (Unix File System) występują znaczące różnice, dotyczące między innymi obsługi rozwidleń (wiele zestawów danych powiązanych z pojedynczym plikiem) i specjalnych atrybutów pliku (na przykład typ, twórca i data utworzenia). Choć system Mac OS X może działać z systemem plików UFS, jest on znacznie rzadziej stosowany od powszechnie używanego systemu plików HFS+. Poza tym system plików UFS nie jest dobrze obsługiwany przez firmę Apple i innych producentów oprogramowania. Narzędzie niezaprojektowane pod kątem obsługi tych unikatowych funkcji systemu plików HFS+ może spowodować, że magazynowane kopie zapasowe będą pozbawione ważnych rozwidleń i atrybutów. Tym samym pełne odtworzenie danych będzie niemożliwe. Największym problemem jest rozwidlenie zasobów, czyli zestaw dodatkowych danych powiązanych z wieloma rodzajami plików systemu Macintosh. Pomimo tego, że od czasu pojawienia się systemu Mac OS X firma Apple odradza stosowanie rozwidleń zasobów, w dalszym ciągu wiele aplikacji używa ich do przechowywania informacji, takich jak ikony miniatur plików obrazów. Nawet sama firma Apple korzysta z takich rozwidleń, aby zapisywać zawartość aliasów, które są graficznymi odpowiednikami dowiązań symbolicznych. 82
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Przed pojawieniem się systemu Tiger (Mac OS X 10.4) nawet standardowe uniksowe narzędzia ignorowały rozwidlenia i atrybuty systemu Macintosh. Jeśli korzysta się z systemu Mac OS X w wersji 10.3 lub starszej bez zewnętrznych narzędzi, najlepiej zastosować program CpMac (zgodny z systemem plików HFS+ odpowiednik narzędzia cp dodany do pakietu Developer Tools), ditto (rekursywne narzędzie kopiujące obsługujące rozwidlenia zasobów i atrybuty systemu plików HFS+, gdy użyje się znacznika -rsrc) lub asr (Apple System Restore; narzędzie powielające woluminy). Ze względu na trudność wykonywania kopii zapasowych w systemie Mac OS X przed pojawieniem się jego wersji Tiger w internecie udostępniono kilka przeznaczonych dla tego systemu odmian standardowych narzędzi archiwizujących, takich jak hfstar, xtar, hfspax, rsync_hfs i psync. Dla narzędzi tych utworzono graficzne nakładki (na przykład RsyncX, PsyncX i Carbon Copy Cloner). Aplikacje zgodne z wieloma platformami, takie jak Amanda i BackupPC, w celu umożliwienia wykonywania kopii zapasowych danych systemu plików HFS+ również korzystały z tych narzędzi.
cpio cpio może być narzędziem archiwizującym o bardzo dużych możliwościach. Jego najważniejszą funkcją jest możliwość pobierania ze standardowego wejścia listy plików przeznaczonych do archiwizowania. Jest to jedyne wbudowane narzędzie, które na to pozwala. Funkcję tę można wykorzystać jednocześnie z plikami narzędzia touch i poleceniem find, aby móc utworzyć przyrostowe kopie zapasowe. Jednak w przeciwieństwie do programu dump narzędzie cpio nie pozwala wykonać następujących operacji: • sporządzanie przyrostowych kopii zapasowych bez użycia plików narzędzia touch i pole-
cenia find; • pozostawianie bez zmian wartości atime i ctime po zakończeniu archiwizacji (należy zapoznać
się z punktem „Nie należy zapomnieć o uniksowych wartościach mtime, atime i ctime” z rozdziału 2.); • wykonywanie interaktywnej operacji odtwarzania (na przykład za pomocą opcji -i pole-
cenia restore).
Dlaczego narzędzie cpio nie jest bardziej popularne? Jeśli narzędzie cpio ma tak duże możliwości, dlaczego program tar cieszy się większym powodzeniem? Jednym z powodów jest to, że wykonanie tych samych podstawowych operacji jest znacznie prostsze (i bardziej ustandaryzowane) w przypadku programu tar. Przykładowo każda wersja narzędzia tar umożliwia wykonanie poleceń tar cf nazwa_urządzenia i tar xf nazwa_urządzenia, a program cpio czasami obsługuje opcje -I i -O, a czasami nie. Jeżeli zsumuje się wszystkie opcje programu cpio dostępne dla różnych jego wersji, okaże się, że jest ich ponad 40. Jest też kilka argumentów, które używają identycznych liter, lecz mają zupełnie odmienne przeznaczenie w przypadku różnych wersji systemu Unix. Kolejnym powodem większej popularności narzędzia tar jest to, że rozwijana jest jego wersja GNU, która łączy w sobie możliwości programu cpio i łatwość obsługi narzędzia tar.
Przegląd
|
83
ditto Narzędzie ditto jest dostępne tylko w systemie Mac OS i normalnie służy do powielania zawartości jednego dysku na innym. W ten sposób wykorzystuje się je w rozdziale 14. Może też być użyte do utworzenia pliku programu ZIP lub cpio. Ponieważ narzędzie ditto zastosowano w książce i jest powszechnie używane w środowiskach z systemem Mac OS, uwzględniono je w niniejszym rozdziale.
dd Polecenie dd to narzędzie, którego większość osób nie wykorzystuje. Jest to niskopoziomowe polecenie zaprojektowane z myślą o kopiowaniu bitów informacji z jednego miejsca w drugie. Narzędzie w ogóle nie zna struktury kopiowanych danych, ponieważ jej nie wymaga. A zatem, w przeciwieństwie do narzędzi: dump, tar i cpio, nie jest stosowane do kopiowania grupy plików na wolumin archiwizacyjny. Program dd może skopiować pojedynczy plik, jego fragment, niesformatowaną partycję lub jej część. Narzędzie to może nawet skopiować dane ze standardowego wejścia stdin do standardowego wyjścia stdout, modyfikując je po drodze. Choć program dd może skopiować plik, podczas wykonywania tej operacji nie zna nazwy pliku lub jego zawartości. Narzędzie po prostu kopiuje bajty z miejsca określonego przez użytkownika, a następnie umieszcza je w ustalonej lokalizacji. Choć narzędzie dd jest raczej proste, jest wyjątkowo elastyczne. Może kopiować pliki lub partycje niezależnie od ich formatu. Jest też w stanie przenieść dane między dwoma różnymi platformami (przykładem translacja EBCDIC na ASCII lub Big Endian na Little Endian). Formaty zapisu danych Big Endian i Little Endian szczegółowo objaśniono w rozdziale 23. Doskonałym przykładem elastyczności narzędzia dd jest skrypt archiwizujący bazę danych Oracle zamieszczony w rozdziale 16. Dane bazy Oracle mogą być przechowywane w plikach systemu plików lub na niesformatowanych partycjach dyskowych. Ponieważ skrypt nie może przewidzieć, jaką konfigurację zastosuje każdy administrator baz danych, korzysta z programu dd, który jest w stanie skopiować zarówno pliki, jak i niesformatowane partycje. Dzięki temu administrator baz danych może zastosować taką konfigurację, która przedstawia dla niego największą wartość. Skrypt automatycznie zarchiwizuje dowolną konfigurację. Skrypt utworzy nawet kopię zapasową mieszanej konfiguracji, w przypadku której część danych znajduje się w plikach, a część na niesformatowanych partycjach.
dump i restore Wielu uważa, że narzędzia dump i restore oferują największe możliwości spośród uniksowych programów archiwizujących. Spośród funkcji wyróżniających oba narzędzia wymieńmy możliwość archiwizowania plików bez modyfikowania ich daty dostępu i zastosowania minipowłoki w celu interaktywnego wybierania plików, które wcześniej zamierza się odtworzyć. Narzędzia dump i restore są dość zaawansowanymi poleceniami z prostymi interfejsami, których podstawowe opcje są identyczne w przypadku większości systemów uniksowych. Pojawiło się mnóstwo kontrowersji wokół narzędzia dump i tego, czy potrafi poprawnie archiwizować aktywny system plików. Więcej na ten temat można przeczytać w dalszej części rozdziału, w podrozdziale poświęconym narzędziu dump.
84
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
ntbackup Jest to jedyne wbudowane narzędzie systemu Windows, które może posłużyć do wykonania kopii zapasowej w tradycyjny sposób. Nie zmienia tego to, że niektórzy pobierają z sieci i używają pod systemem Windows wersji GNU narzędzia tar lub rsync. Podobnie do narzędzi uniksowych zaprezentowanych w niniejszym rozdziale, program ntbackup może archiwizować dane na dysku lub taśmie, a także pozwala określić kilka opcji. Można nawet opcje te zapisać w pliku konfiguracyjnym, a następnie nakazać systemowi Windows, aby użył go podczas uruchamiania programu ntbackup. Plik konfiguracyjny umożliwia automatyczne sporządzanie kopii zapasowych za pomocą narzędzia ntbackup.
rsync O narzędziu rsync można myśleć jak o darmowej i ładniejszej wersji uniksowego polecenia rcp, które może posłużyć do synchronizacji dwóch katalogów, nawet wtedy, gdy znajdują się na oddzielnych komputerach. Podstawowa składnia narzędzia jest w zasadzie taka sama jak polecenia rcp. W związku z tym osobom zaznajomionym z tym poleceniem powinno być łatwo zrozumieć narzędzie rsync. Dwa z produktów archiwizujących open source przedstawionych w książce używają programu rsync wraz z innymi narzędziami, aby zapewnić możliwość archiwizowania i odtwarzania. Z tego powodu w tym rozdziale zostaną omówione podstawowe funkcje tego programu.
Narzędzie Przywracanie systemu Choć narzędzie Przywracanie systemu nie przypomina do końca innych narzędzi przedstawionych w rozdziale, zasługuje na wzmiankę. Od czasu pojawienia się systemu Windows 2000 za pomocą programu Przywracanie systemu można tworzyć obraz systemu. Narzędzie wykonuje kopię zapasową kilku krytycznych plików i rejestru, dzięki czemu można przywrócić system do stanu z wybranego momentu w przeszłości.
tar Atrakcyjność narzędzia tar w dużej mierze wynika z łatwości obsługi. Niemal każdy wie, jak odczytać wolumin programu tar. Jeśli ktoś nie wie, naprawdę łatwo można mu wytłumaczyć, jak to zrobić. Jeżeli na dysku zapisano plik utworzony za pomocą narzędzia tar, a nawet skompresowaną wersję pliku, programy takie jak WinZip1 mogą automatycznie go rozpakować i wyświetlić zawartość (WinZip nie obsługuje archiwum sporządzonego przy użyciu programu cpio). Narzędzie tar jest też bardziej przenośne między uniksowymi platformami niż programy dump i cpio2.
1
WinZip jest zarejestrowanym znakiem towarowym firmy Nico Mak Computing Inc. Wersję demonstracyjną narzędzia można pobrać pod adresem http://www.winzip.com.
2
W projekcie DJGPP, mającym na celu utworzenie wersji kompilatora gcc oraz pakietów narzędzi i programów użytkowych GNU dla systemów MS-DOS i Windows, zastosowano program cpio w roli standardowego przenośnego narzędzia archiwizującego, a także przeniesiono wersję GNU narzędzi cpio i tar do systemów DOS i Windows w postaci 32-bitowych plików wykonywalnych.
Przegląd
|
85
Jeśli trzeba szybko wykonać kopię zapasową katalogu lub zestawu plików, pod względem łatwości obsługi program tar będzie trudny do pobicia. Jeżeli jednak konieczne jest regularne sporządzanie kopii zapasowych, oczekuje się funkcji, których wbudowana wersja narzędzia tar jest pozbawiona. Użytkownik między innymi będzie chciał utworzyć przyrostowe kopie zapasowe, pozostawić bez zmian wartość atime i mieć pewność, że są odtwarzane odpowiednie uprawnienia i prawa własności plików. Aby te wymagania zostały spełnione, można skorzystać z wersji GNU narzędzia tar lub przyjrzeć się programowi cpio. Zawarte dalej omówienie podstawowych narzędzi archiwizujących nie ma za zadanie zastępować ich oficjalnej dokumentacji. Zdecydowanie powinno się zapoznać z dokumentacją każdego z tych narzędzi. W takiej dokumentacji można znaleźć wszystko, począwszy od mniej istotnych informacji, a skończywszy na bardzo ważnych, związanych z konkretnym systemem operacyjnym. W określonych sytuacjach producenci dokumentują jedną lub dwie specjalne funkcje. Zawsze należy być na bieżąco z dokumentacją używanego narzędzia archiwizującego, niezależnie od tego, jakie ono jest.
Inne narzędzia W tym punkcie zamieszczono listę poleceń, których z różnych powodów nie zostały omówione w książce.
asr asr (Apple System Restore) jest narzędziem do wykonywania obrazów dostępnym tylko w przypadku systemu Mac OS. Program służy przed wszystkim do wykonywania masowych operacji powielania, podobnie jak narzędzie ghost stosowane przez użytkowników systemu Windows. asr jest narzędziem, które można wykorzystać do bezpośredniego kopiowania danych z jednego dysku twardego na inny lub do tworzenia obrazu zawartości dysku twardego, podobnego do pliku ISO stosowanego w innych systemach operacyjnych. Plik obrazu narzędzia asr ma rozszerzenie .dmg.
pax Narzędzie pax (Portable Archive Exchange) generuje przenośne archiwum zgodne z formatem Archive/Interchange File Format określonym w standardzie IEEE Std. 1003.1-1988. Program potrafi też czytać i zapisywać kilka innych formatów plików, takich jak obsługiwane przez narzędzia tar i cpio. Narzędzie pax jest używane przez program instalacyjny systemu Mac OS. Podobnie do wielu rzeczy w uniksowym świecie program pax ma grupę wiernych miłośników, którzy przekonują, że jest najlepszy z możliwych. Jednak narzędzie nie będzie omawiane, ponieważ większość osób nie korzysta z niego.
psync, rsyncx, hfstar, xtar i hfspax Odkąd system Mac OS X bazuje na jądrze systemu Mach Unix, jest wyposażony w kilka narzędzi uniksowych, takich jak tar, cpio, pax, cp i rsync. Niestety, wczesne wersje tych narzędzi dla systemu Mac OS nie obsługiwały systemu plików z wieloma rozwidleniami, takiego jak HFS+. Podobnie jest w przypadku wersji GNU programu tar.
86
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
psync, rsyncx, hfstar, xtar i hfspax to narzędzia rozprowadzane wśród społeczności użytkowników systemu Mac OS. Zaprojektowano je w celu obejścia ograniczeń wbudowanych narzędzi systemu Mac OS. Programy psync i rsyncx napisano tak, aby działały podobnie do narzędzia rsync i jednocześnie poprawnie obsługiwały rozwidlenia zasobów. Programy hfstar i xtar przypominają narzędzie tar, a ponadto są zgodne z rozwidleniami zasobów. Program hfspax działa jak narzędzie pax i obsługuje rozwidlenia zasobów. Od momentu pojawienia się systemu Mac OS w wersji 10.4.x narzędzia: tar, pax, cp i rsync poprawnie obsługują rozwidlenia zasobów używających formatu AppleDouble (według firmy Apple obecnie polecenia te korzystają z tego samego interfejsu API co narzędzie wyszukujące Spotlight systemu Mac OS). Gdy plik jest kopiowany w formacie, który nie obsługuje wielu rozwidleń, tak jak format narzędzi tar i cpio, a nawet systemu plików UFS systemu Mac OS, wyżej wymienione programy skonwertują plik na dwa pliki. Pierwszy plik będzie zawierać rozwidlenie danych lub rzeczywiste dane pliku. Drugi plik, określany jako plik nagłówka, będzie przechowywał rozwidlenie zasobów oraz informacje wyszukiwania. Pierwszy plik ma nazwę oryginalnego pliku, z kolei na początku pliku nagłówka znajduje się łańcuch ._. dokument.txt ._dokument.txt
Gdy plik z wieloma rozwidleniami jest kopiowany lub przywracany przy użyciu formatu bez obsługi wielu rozwidleń (formaty narzędzi tar i cpio oraz systemu plików UFS) i konwertowany na format zgodny z wieloma rozwidleniami (system plików HFS+), dwa pliki są zamieniane z powrotem na jeden zawierający rozwidlenie danych i zasobów.
Archiwizowanie i odtwarzanie danych za pomocą narzędzia ntbackup Polecenie ntbackup uaktywnia graficzny interfejs narzędzia ntbackup. W przeciwieństwie do wszystkich innych poleceń omówionych w niniejszym rozdziale przy użyciu samego polecenia ntbackup nie można wybrać, co ma być archiwizowane. Operację tę trzeba wykonać z poziomu graficznego interfejsu użytkownika. Jednakże wystarczy raz załadować graficzny interfejs, a następnie określić pliki przeznaczone do archiwizacji i zapisać wynik operacji w pliku z rozszerzeniem .bks, który później można podać w wierszu polecenia ntbackup. Jak w przypadku innych narzędzi przedstawionych w rozdziale, niniejszy podrozdział nie ma zastępować pliku pomocy dołączonego do programu ntbackup. Opisano w niej o wiele więcej opcji niż w tej książce.
Oprócz wybrania plików, które znajdą się w kopii zapasowej, można określić wartości dla kilku innych opcji. Oto one: • typ kopii zapasowej (normalna, kopia, różnicowa lub codzienna), • typ lokalizacji docelowej kopii zapasowej (dysk lub taśma), • ścieżka lokalizacji docelowej (na przykład f:\plik_kopii.bkf), • dołączenie lub nadpisanie danych kopii zapasowych istniejących w lokalizacji docelowej, • poziom rejestrowania (szczegółowy, podsumowanie lub brak).
Arch w zowan e odtwarzan e danych za pomocą narzędz a ntbackup
|
87
Wymienione opcje można określać w wierszu polecenia lub w graficznym oknie narzędzia ntbackup przez zapisanie w pliku .bks. Jednak ze względu na to, że i tak trzeba załadować graficzny interfejs programu ntbackup w celu skonfigurowania go (proces obejmuje powyższe opcje), opcje wiersza polecenia nie będą szczegółowo omawiane. Zamiast tego pokażę, jak spowodować, żeby system Windows automatycznie wykonywał wymagane polecenie.
Tworzenie prostej konfiguracji archiwizowania W celu sporządzenia prostej kopii zapasowej za pomocą graficznego interfejsu narzędzia ntbackup trzeba utworzyć plik opcji archiwizacji, zapisać go, a następnie wczytać podczas przeprowadzania archiwizacji przez uruchomienie polecenia ntbackup. Aby uaktywnić graficzny interfejs narzędzia ntbackup, z poziomu wiersza poleceń należy wykonać polecenie ntbackup lub z menu Start wybrać pozycję Wszystkie programy/Akcesoria/Narzędzia systemowe/Kopia zapasowa. W obrębie karty Kopia zapasowa należy wybrać napędy lub katalogi, które będą archiwizowane. Warto zauważyć, że można również wykonać kopię zapasową stanu systemu (pozycja System State). W dalszej kolejności trzeba wybrać różne opcje związane z archiwizowaniem. Dwie podstawowe opcje to typ kopii zapasowej i jej docelowa lokalizacja. Dostępne są następujące typy kopii: normalna, kopia, przyrostowa, różnicowa i codzienna. Normalna (domyślna) Uwzględnia wybrane pliki i oznacza je jako zarchiwizowane. Kopia Uwzględnia wybrane pliki i nie oznacza ich jako zarchiwizowanych. Przyrostowa Uwzględnia wybrane pliki, jeśli je zmodyfikowano od czasu wykonania ostatniej kopii zapasowej, i nie oznacza ich jako zarchiwizowanych. Różnicowa Uwzględnia wybrane pliki, jeśli zostały zmodyfikowane od czasu wykonania ostatniej kopii zapasowej, i nie oznacza ich jako zarchiwizowanych. Codzienna Uwzględnia wyłącznie pliki zmodyfikowane bieżącego dnia. Aby zastosować coś innego niż normalna kopia zapasowa, z menu Narzędzia należy wybrać pozycję Opcje, a następnie uaktywnić kartę Typ kopii zapasowej. Po otwarciu okna dialogowego Opcje należy przejrzeć pozostałe karty i zdecydować, czy ustawić jakieś inne opcje. W celu zamknięcia okna należy kliknąć przycisk OK. Trzeba następnie zdecydować, czy skorzystać z dysku czy z taśmy. Dysk jest prawdopodobnie najlepszą opcją w przypadku prostej kopii zapasowej, zwłaszcza gdy po prostu mają być archiwizowane dane udziału, który będzie archiwizowany przez inny proces. Dalej trzeba określić nazwę pliku kopii zapasowej. Po wykonaniu tych czynności z menu Zadanie należy wybrać pozycję Zapisz wybory jako i zapisać opcje w pliku (na przykład c:\moja_kopia.bks).
88
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Sporządzanie prostej kopii zapasowej W celu zastosowania ustalonej konfiguracji archiwizacji można wybrać trzy warianty. Pierwszy polega po prostu na kliknięciu przycisku Rozpocznij w graficznym oknie narzędzia ntbackup. Jeśli opcje zapisano w pliku, można również zainicjować tworzenie kopii zapasowej z poziomu wiersza poleceń. Poniższe polecenie zakłada, że nie wybrano żadnych dodatkowych opcji i określono jedynie, które pliki znajdą się w kopii zapasowej. Wszystkie istotne opcje w postaci argumentów są podane w wierszu polecenia ntbackup. Polecenie archiwizuje wybrane pliki, wyszczególnione w pliku C:\moja_kopia.bks, nadaje zadaniu nazwę Codzienna kopia zapasowa i zapisuje dane w pliku kopii zapasowej F:\kopia.bkf. ntbackup backup "@C:\moja_kopia.bks" /M normal /J "Codzienna kopia zapasowa" /F "F:\kopia.bkf"
Następną czynnością jest zdefiniowanie zaplanowanego zadania zawierającego powyższe polecenie. Jeśli ktoś woli, żeby system Windows sam ustawił wszystkie opcje wiersza poleceń, może po prostu użyć kreatora programu ntbackup, który utworzy zaplanowane zadanie. Po uruchomieniu narzędzia ntbackup należy uaktywnić kartę Planowanie zadań, zaznaczyć w kalendarzu datę i kliknąć przycisk Dodaj zadanie. Dalej w oknie dialogowym Co ma zawierać kopia zapasowa należy zaznaczyć pozycje, które mają zostać zarchiwizowane. Następne okno prosi o określenie docelowego katalogu i pliku. W kolejnym pojawi się prośba o wybranie typu kopii zapasowej. Dalej zostanie wyświetlonych kilka opcji, w tym opcja pozwalająca zdecydować, czy po zakończeniu archiwizacji dane mają być sprawdzane, czy nie. Można następnie określić, czy kopia zapasowa powinna zostać dołączona do kopii już istniejących w miejscu docelowym czy ma je nadpisać. Na końcu pojawi się prośba o nadanie nazwy zadaniu i ustalenie harmonogramu jego wykonywania. Gdy zostanie to zrobione, system Windows utworzy zaplanowane zadanie zawierające odpowiednie polecenia. W przypadku przytoczonego przykładu utworzyłem następujące zadanie: C:\WINDOWS\system32\ntbackup.exe backup "@C:\moja_kopia.bks" /a /d "Zestaw utworzony 2007-06-01 o 19:20" /v:no /r:no /rs:no /hc:off /m normal /j "moja_kopia" /l:s /f "C:\kopia.bkf"
Program ntbackup może posłużyć do archiwizowania i odtwarzania serwera Exchange. Więcej na ten temat można znaleźć w rozdziale 20.
Odtwarzanie za pomocą narzędzia ntbackup Przy użyciu programu ntbackup nie można odtwarzać danych z poziomu wiersza poleceń. Trzeba uruchomić jego graficzny interfejs i uaktywnić kartę Przywróć i zarządzaj nośnikiem. W obrębie tej karty pojawi się lista kopii zapasowych znanych programowi ntbackup. Po wybraniu dowolnej kopii zapasowej pojawi się drzewo zawartych w niej plików. Można następnie zaznaczyć pliki, które mają być odtworzone, zdecydować, czy zostaną umieszczone w swoim pierwotnym miejscu czy w innym, a także przez kliknięcie przycisku Rozpocznij przywracanie nakazać programowi ntbackup odtworzenie danych. W dalszej kolejności można określić zaawansowane opcje. Operacja odtwarzania rozpoczyna się po kliknięciu przycisku OK. Naprawdę dużo prościej się już nie da!
Arch w zowan e odtwarzan e danych za pomocą narzędz a ntbackup
|
89
Zastosowanie narzędzia Przywracanie systemu Każdemu, kto korzystał z systemu Windows przez dłuższy czas, zdarzyło się zainstalować oprogramowanie, które spowodowało, że system stał się bezużyteczny. Wcześniej w takiej sytuacji jedyną opcją była ponowna instalacja systemu Windows i wszystkich aplikacji. Jednak to się zmieniło wraz z pojawieniem się narzędzia Przywracanie systemu. Jeśli możliwe jest załadowanie systemu w trybie awaryjnym i uaktywnienie narzędzia Przywracanie systemu, prawdopodobnie będzie można znaleźć stabilną wersję systemu nadającą się do odtworzenia. W efekcie od razu można dysponować działającym systemem operacyjnym! Program Przywracanie systemu różni się trochę od innych narzędzi zaprezentowanych w rozdziale, ponieważ nie tworzy kopii zapasowych w tradycyjny sposób i nie można korzystać z niego w obrębie innego narzędzia. Jednak to narzędzie odtwarzające, dołączone do systemu Windows XP i nowszych, jest bardzo ważne i należy się z nim zaznajomić.
Narzędzie Przywracanie systemu dodane do systemu Windows XP i jego następców archiwizuje rejestr systemowy i krytyczne pliki, tworząc punkt przywracania. System Windows robi to automatycznie, gdy uzna, że użytkownik wykonuje znaczącą operację, taką jak instalacja nowego sterownika lub większa aktualizacja. Ponadto punkty przywracania można tworzyć samemu zawsze, gdy jest to wskazane, lub za pomocą zaplanowanego zadania automatycznie w regularnych odstępach czasu. Można następnie za pomocą dowolnego z punktów przywracania utworzonych przez system przywrócić go do stanu z wybranego momentu w przeszłości.
Tworzenie punktów przywracania Jak wspomniano, system Windows generuje za użytkownika wiele punktów przywracania, o ile nie wyłączono narzędzia Przywracanie systemu. Aby stwierdzić, czy narzędzie jest aktywne, należy zalogować się jako użytkownik należący do grupy Administratorzy, a następnie z menu Start wybrać pozycję Mój komputer i prawym przyciskiem myszy kliknąć w menu podręcznym pozycję Właściwości. Po uaktywnieniu karty Przywracanie systemu można włączyć lub wyłączyć narzędzie. Aby móc skorzystać z narzędzia Przywracanie systemu, trzeba być zalogowanym jako użytkownik Administrator lub inny członek grupy Administratorzy.
Każdy użytkownik należący do grupy Administratorzy może w dowolnej chwili utworzyć punkt przywracania. W tym celu z menu Start należy wybrać pozycję Wszystkie programy/Akcesoria/ Narzędzia systemowe/Przywracanie systemu, a następnie kliknąć opcję Utwórz punkt przywracania. Okno dialogowe poprosi o podanie nazwy punktu przywracania, który zostanie wygenerowany. Może to być dowolna nazwa, taka jak Tuż przed instalacją gry Doom. Następnie system utworzy punkt i nada mu nazwę. Później za pomocą narzędzia Przywracanie systemu można przywrócić system Windows do poprzedniego stanu.
90
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Choć narzędzie Przywracanie systemu można również uruchomić przez załadowanie programu %SystemRoot%\system32\restore\rstrui.exe, jest raczej mało prawdopodobne, że ktoś to zapamięta.
Jeżeli ktoś nie ufa systemowi Windows, jeśli chodzi o tworzenie przez niego punktów przywracania, ale nie chce mu się ręcznie wykonywać takiej operacji, może utworzyć zaplanowane zadanie, które będzie generować punkt przywracania tak często, jak to będzie potrzebne. W tym celu z menu Start należy wybrać pozycję Wszystkie programy/Akcesoria/Narzędzia systemowe/ Zaplanowane zadania, a następnie kliknąć Dodaj zaplanowane zadanie. W otwartym oknie dialogowym należy kliknąć przycisk Dalej, a w następnym — opcję przywracania systemu. Należy określić, jak często zadanie ma być uruchamiane i kiedy, a także podać nazwę i hasło konta użytkownika, będącego członkiem grupy Administratorzy. System Windows utworzy następnie punkt przywracania.
Przywracanie systemu Windows za pomocą punktu przywracania Jeśli wersja używanego systemu Windows stała się niestabilna na skutek ostatniej instalacji aktualizacji lub sterownika, wystarczy uaktywnić narzędzie Przywracanie systemu, wybrać poprzedni stan i nakazać systemowi jego przywrócenie. Jeżeli system Windows jest naprawdę niestabilny, najtrudniejsze może być samo jego załadowanie. Najlepsze w tym przypadku może być uruchomienie systemu w trybie awaryjnym i zalogowanie się jako Administrator. Gdy już jakimś sposobem uda się załadować system, z menu Start należy wybrać pozycję Wszystkie programy/Akcesoria/Narzędzia systemowe/Przywracanie systemu, a następnie kliknąć opcję Przywróć komputer do wcześniejszego stanu. Następnie pojawi się okno dialogowe podobne do pokazanego na rysunku 3.1.
Rysunek 3.1. Wybieranie punktu przywracania Zastosowan e narzędz a Przywracan e systemu
|
91
Automatycznie jest zaznaczany punkt przywracania z najbardziej aktualną datą widoczną w kalendarzu. Punkty przywracania powiązane z wybraną datą są wyświetlane z prawej strony. Można przywrócić system do stanu z tej chwili lub wybrać wcześniejszą datę, jeśli jest się przekonanym, że również najnowszy punkt przywracania może być podejrzany. Po wybraniu punktu przywracania należy kliknąć przycisk Dalej. Oczywiście system Windows poprosi o potwierdzenie wyboru i ostrzeże o konieczności zapisania wszelkich danych i zamknięcia wszystkich otwartych programów, ponieważ operacja odtwarzania wymaga ponownego uruchomienia komputera. Potem należy klikać jedynie przyciski Dalej — do momentu zamknięcia okna dialogowego. Po ponownym załadowaniu systemu należy przetestować odtworzoną wersję systemu Windows, aby się upewnić, czy problemy zostały wyeliminowane. Jeśli tak — to wszystko. W przeciwnym razie po prostu trzeba ponownie przeprowadzić cały proces, aż do znalezienia punktu przywracania, który da pożądane efekty.
Archiwizowanie za pomocą narzędzia dump W wielu środowiskach program dump może być wszystkim, co jest potrzebne do zapewnienia dobrej jakości kopii zapasowych. Istnieje jednak wiele kontrowersji związanych z tym narzędziem, wynikających z tego, że nie uzyskuje dostępu do danych za pośrednictwem systemu plików, przeciwnie niż większość innych narzędzi archiwizujących. dump uzyskuje bezpośredni dostęp do urządzenia systemu plików. Właśnie dlatego program może archiwizować pliki bez modyfikowania ich daty dostępu. Również dlatego zawsze w dokumentacji narzędzia dump jest zaznaczone, aby odłączyć systemy plików przed rozpoczęciem archiwizowania ich. Oczywiście nikt tego nie robi, stąd kontrowersje.
Narzędzie dump w systemach Mac OS i Linux Administratorzy Linuksa powinni być świadomi tego, że narzędzie dump nie oferuje dobrej metody archiwizowania danych. Program ten nie obsługuje też systemu plików HFS+ systemu Mac OS. Firma RedHat oficjalnie odradza stosowanie narzędzia dump w systemie RedHat 9. Poniższy fragment wypowiedzi Linusa Torvaldsa podsumowuje postawę społeczności linuksowej wobec narzędzia dump. „dump po prostu nie będzie stabilnie działał nawet w przypadku jądra 2.4.x. Pamięć podręczna buforowania i stronicowania (znajdują się w niej wszystkie rzeczywiste dane) nie są spójne. Sytuacja tylko się pogarsza w przypadku jądra 2.5.x, gdy do pamięci podręcznej buforowania są również przenoszone katalogi. W związku z tym każdy, kto jest zależny od poprawnego sporządzania kopii zapasowych przez narzędzie dump (dotyczy to systemu Linux), gra w rosyjską ruletkę, w której stawką są kopie. W ogóle nie ma gwarancji, że uzyska się poprawne kopie zapasowe. Może się okazać, że w pamięci podręcznej buforowania będą nieaktualne dane, które ostatecznie zostaną »zarchiwizowane«… Program dump może świetnie zadziałać tysiące razy. Jednak zawiedzie w prostych okolicznościach. I nie ma się na to żadnego wpływu”. Choć trzeba będzie samemu zdecydować, czy narzędzie dump jest dobre, czy nie, zdaje się, że nie jest najlepszą opcją archiwizowania danych w systemie Linux. Choć narzędzia dump i restore są dostępne dla systemu Mac OS, współpracują jedynie z systemem plików UFS. Nie istnieje żadne narzędzie takie jak hfsdump zgodne z systemem plików HFS+. Z tego, co wiem, nie ma planów stworzenia takiego narzędzia.
92
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Aby użyć narzędzi dump i restore do regularnego wykonywania kopii zapasowych danych systemowych, trzeba rozumieć następujące zagadnienia: • zastosowanie narzędzia dump do archiwizowania systemu plików (przy wykorzystaniu
odpowiednich opcji); • sposób finalizowania kopii zapasowej na woluminie; • uzyskiwanie tabeli zawartości woluminu narzędzia dump; • obsługę woluminu i odtwarzanie danych z kopii zapasowej utworzonej za pomocą narzę-
dzia dump; • ograniczenia narzędzi dump i restore; • operacje, które powinny być wykonane, gdy zamierza się regularnie korzystać z progra-
mu dump. W pierwszej kolejności trzeba zapoznać się z opcjami i przeznaczeniem polecenia dump. W tabeli 3.1 zebrano polecenia dump stosowane w różnych wersjach systemu Unix. Poniższy punkt właściwie pełni rolę zunifikowanej dokumentacji tych poleceń, przeznaczonych dla konkretnych systemów operacyjnych. Tabela 3.1. Polecenia dump stosowane w przypadku różnych wersji systemu Unix Wersja systemu Un x P UX 9 x/ P UX 10/SunOS/ R X
Polecen e (r)dump
Sola is
ufsdump
SCO
xdump
Netwo k Appliance
dump
AX
backup i rdump
Linux
dump
SG
dump i xfsdump
T u64 Unix
dump i vdump
Linux/Mac OS
Należy zapoznać się z t eścią amki „Na zędzie dump w systemach Mac OS i Linux”
Choć w systemie Mac OS jest dostępne polecenie dump, nie obsługuje ono systemu plików HFS+, który jest najczęściej stosowany.
Składnia polecenia dump Rozpocznijmy od podstawowej składni polecenia dump: # dump poziomunbdsf współczynnik_bloków gęstość rozmiar nazwa_urządzenia system_plików
Oto praktyczne przykłady powyższego polecenia: • Aby utworzyć pełną kopię zapasową katalogu /home i zapisać ją na lokalnym napędzie
taśmowym /dev/rmt/0cbn, należy zastosować następujące polecenie: # dump 0unbdsf 126 141000 11500 /dev/rmt/0cbn /home
Arch w zowan e za pomocą narzędz a dump
|
93
• W celu sporządzenia pełnej kopii zapasowej /backup/home.dump katalogu /home i umiesz-
czenia jej na urządzeniu optycznym lub dysku CD należy wykonać poniższe polecenie: # dump 0unbdsf 126 141000 11500 /backup/home.dump /home
• Aby utworzyć pełną kopię zapasową katalogu /home na zdalnym napędzie taśmowym
/dev/rmt/0cbn komputera elvis, należy użyć następującego polecenia: # (r)dump 0unbdsf 126 141000 11500 elvis:/dev/rmt/0cbn /home
W powyższych poleceniach zastosowano trzy opcje (0, u i n), które nie wymagają argumentów, i cztery opcje (b, d, s i f) wymagające dołączenia argumentu. Jako swój pierwszy argument polecenie dump pobiera listę opcji. Argument każdej z tych opcji jest wstawiany w wierszu polecenia w takiej samej kolejności, w jakiej wymieniono opcje. Rysunek 3.2 ilustruje, w jaki sposób opcje polecenia dump są powiązane ze swoimi argumentami.
Rysunek 3.2. Proste polecenie dump
Opcje polecenia dump Narzędzie dump ma siedem głównych opcji dostępnych w przypadku większości platform. Oto one: 0–9
Określa poziom operacji archiwizacji, która powinna zostać wykonana przez program dump. b
Określa współczynnik bloków, który powinien zostać użyty przez narzędzie dump. u
Opcja nakazuje programowi dump uaktualnić plik dumpdates. n
Nakazuje narzędziu dump powiadomić członków grupy operatorów, gdy zakończy działanie. dis
Opcja informuje program dump o rozmiarze woluminu archiwizacyjnego. Na podstawie wartości tych opcji dump szacuje dostępną pojemność „taśmy”. f
Opcja przekazuje programowi dump dane na temat urządzenia, które ma być użyte. W, w
Opcje nakazują programowi dump przeprowadzenie próbnej archiwizacji mającej na celu stwierdzenie, jakie systemy plików wymagają utworzenia kopii zapasowej (opcje są rzadko stosowane).
94
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Jeśli przy użyciu narzędzia dump regularnie tworzy się systemowe kopie zapasowe, powinno się korzystać z większości wymienionych opcji. Godne uwagi jest to, że wiele z tych opcji ma domyślne wartości. Dzięki temu eliminuje się konieczność określania w wierszu polecenia dump opcji i jej argumentu. Przykładowo domyślny poziom archiwizacji zwykle wynosi 9. Problem z domyślnymi wartościami jest taki, że są inne w różnych systemach operacyjnych, a nawet w obrębie tego samego systemu (zależnie od takich czynników jak typ nośnika). W celu późniejszego uproszczenia sobie procesu odtwarzania lepiej każdą z opcji określać w taki sam sposób w przypadku wszystkich kopii zapasowych tworzonych przy użyciu narzędzia dump.
Definiowanie pełnej lub przyrostowej kopii zapasowej (0 – 9) Pierwszym argumentem, który można określić jest poziom archiwizacji. Można użyć dowolnej wartości z przedziału od 0 do 9 (w rozdziale 2. objaśniono poziomy archiwizacji). Przyrostowe kopie zapasowe narzędzia dump odwołują się do pliku dumpdates w celu określenia daty sporządzenia ostatniej kopii niższego poziomu (plik omówiono w dalszej części rozdziału w podpunkcie „Aktualizowanie pliku dumpdates (u)”). Jeśli na przykład wykonuje się kopię zapasową poziomu 5, program dump archiwizuje wszystkie pliki, które zostały zmodyfikowane od czasu sporządzenia ostatniej kopii poziomu 4 lub niższego. Narzędzie pobiera datę utworzenia tej kopii zapasowej z pliku dumpdates (zwykle znajduje się w katalogu /etc). Ponieważ plik dumpdates jest wymagany przez przyrostowe kopie zapasowe, trzeba użyć opcji u w celu jego aktualizacji.
Narzędzia dump i restore zapobiegły katastrofie Był to długi i ciężki tydzień. Próbowaliśmy zakończyć kilka spraw, tak aby móc jechać do domu. Właśnie wtedy odebraliśmy telefon. Zawsze w takich chwilach dzwoni telefon. Okazało się, że zniknął z systemu bardzo ważny katalog zawierający rzadko używane, lecz istotne narzędzie. „Żaden problem. Mamy to na taśmie” — odpowiedziałem. Gdy rozpocząłem przygotowania do odtworzenia plików, zdałem sobie sprawę, że katalog nie istniał już od jakiegoś czasu. W rzeczywistości nie było go w systemie na tyle długo, że nie został zarchiwizowany przez stosowane przez nas komercyjne narzędzie. Można sobie wyobrazić, jak się wtedy poczułem. Przyjrzałem się starej szafie na dokumenty, w której przechowywano kiepsko uporządkowane, nieodpowiednio oznaczone i niemal zapomniane taśmy z kopiami zapasowymi wykonanymi za pomocą narzędzia ufsdump. W tamtej chwili taśmy te były najważniejsze na świecie, ponieważ zostały zapisane, zanim zaczęto korzystać z komercyjnego oprogramowania archiwizującego. Umieściłem kolejno taśmy w napędzie i zastosowałem opcję table of contents narzędzia ufsrestore, mając nadzieję, że jedna z taśm okaże się tą właściwą. Stos taśm stawał się coraz niższy. W końcu jedna z taśm wydała się przydatna. Przełączyłem tryby, korzystając z opcji interactive, i okazało się, że mam szczęście. Zaznaczyłem katalog i odtworzyłem go. Katalog został zapisany w systemie, a klient nigdy się nie dowiedział, że niemal nie byliśmy w stanie odtworzyć danych. Był to ten dzień, w którym byłem naprawdę zadowolony, że zaznajomiłem się z narzędziami dump i restore (dowiedziałem się również, jak ważne jest comiesięczne archiwizowanie pełnych kopii zapasowych).
Arch w zowan e za pomocą narzędz a dump
|
95
Określanie współczynnika bloków (b) Opcja b określa liczbę bloków, które zostaną zapisane w ramach jednej operacji na wyjściu. Opcja odwołuje się do liczby fizycznych bloków. Rozmiar całego bloku zapisywanego przez narzędzie dump zależy od wielkości fizycznego bloku pomnożonej przez współczynnik bloków. W przypadku większości wersji systemu Unix rozmiar fizycznego bloku używanego przez narzędzie dump wynosi 1024 bajty. A zatem, jeśli określi się współczynnik bloków o wartości 10, rozmiar rzeczywistego bloku zapisywanego przez program dump wyniesie 10 240 bajtów lub 10 kilobajtów. Opcja b nie jest dostępna w systemie SCO. Przynajmniej jedna odmiana systemu Unix umożliwia zmianę współczynnika bloków na potrzeby narzędzia dump, lecz nie restore. Oznacza to, że za pomocą narzędzia dump można tworzyć woluminy, których nie da się odczytać! Trzeba się upewnić, że używana wersja narzędzia restore pozwala zmodyfikować współczynnik bloków.
Aktualizowanie pliku dumpdates (u) Opcja u powoduje, że narzędzie dump aktualizuje plik dumpdates dla archiwizowanego systemu plików (choć plik ten zwykle znajduje się w katalogu /etc, w systemie HP-UX 10.x umieszczono go w katalogu /var/adm). Jest to zwykły plik tekstowy wyszczególniający urządzenie każdego systemu plików i datę sporządzenia dla tego urządzenia ostatniej kopii zapasowej na każdym poziomie. Oto przykładowa zawartość pliku /etc/dumpdates z systemu Solaris: /dev/rdsk/c0t1d0s0 /dev/rdsk/c0t1d0s0 /dev/rdsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 /dev/rdsk/c0t3d0s0
0 1 0 1 5
Sun Wed Sat Mon Wed
Apr May May May May
30 3 20 29 31
23:07:22 02:49:51 00:31:49 01:33:33 00:28:14
2006 2006 2006 2006 2006
Jak widać, dla urządzenia c0t1d0s0 30 kwietnia 2006 r. wykonano kopię zapasową poziomu 0, a 3 maja — poziomu 1 Dla urządzenia c0t3d0s0 20 maja sporządzono kopię zapasową poziomu 0, 29 maja — poziomu 1, a 31 maja — poziomu 5. W związku z plikiem dumpdates trzeba wspomnieć o kilku ważnych rzeczach. Gdy narzędzie dump uruchamiane jest w systemie po raz pierwszy, konieczne jest utworzenie pustego pliku dumpdates i ustanowienie jego właścicielem superużytkownika. Jeśli plik nie istnieje lub jego właścicielem nie jest superużytkownik, narzędzie dump nie utworzy pliku. Program będzie kontynuował działanie, lecz poinformuje o problemie z plikiem dumpdates. Warto zauważyć, że plik ten jest aktualizowany tylko wtedy, gdy narzędzie dump całkowicie z powodzeniem ukończy tworzenie kopii zapasowej. Jeżeli jakieś błędy spowodują przerwanie działania narzędzia dump, plik dumpdates nie zostanie uaktualniony. Oznacza to, że plik ten dobrze nadaje się do zastosowania przez zautomatyzowany skrypt sprawdzający, czy narzędzie dump utworzyło kopie zapasowe. Poniższa lista prezentuje różne nazwy i lokalizacje pliku dumpdates. • HP-UX 9.x, SunOS, Solaris, AIX, Linux i IRIX: /etc/dumpdates. • HP-UX 10.0: /var/adm/dumpdates. • SCO: /etc/ddate.
Można nie chcieć używać opcji u, gdy jednorazowo tworzy się specjalną kopię zapasową. Wynika to stąd, że zastosowanie opcji u ma wpływ na inne kopie zapasowe. Jeśli na przykład sporządza się jednorazowo kopię poziomu 0 z użyciem opcji u, automatycznie tworzone kopie zapasowe poziomu 1 będą odwoływać się do kopii poziomu 0, którą przekazano komuś innemu i która nie wchodzi w skład normalnej puli archiwizacyjnej. 96
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Plik dumpdates, niezależnie od swojej nazwy, może być przeglądany lub modyfikowany za pomocą standardowego edytora tekstu. Przykładowo można coś takiego zrobić, gdy wiadomo, że taśma z kopią zapasową poziomu 0 z bieżącego tygodnia została wciągnięta przez napęd. Nawet gdy brakuje czasu potrzebnego do ponownego utworzenia kopii tego poziomu, jakąś kopię zapasową chcemy mieć. Jeśli jednak wykonamy kopię zapasową poziomu 1, będzie ona odwoływać się do kopii poziomu 0 z tego tygodnia, która nie jest dostępna. W takiej sytuacji dla wymaganych systemów plików można poddać edycji wiersz kopii zapasowej poziomu 0, zmieniając datę na datę dostępnej kopii tego samego poziomu, sporządzonej w zeszłym tygodniu. Dzięki temu kopia poziomu 1 będzie odwoływać się do kopii poziomu 0 z poprzedniego tygodnia, a nie do kopii z bieżącego tygodnia, która został zniszczona. W ten sposób mimo uszkodzenia kopii poziomu 0 można spać trochę spokojniej bez konieczności ponownego tworzenia pełnej kopii zapasowej poziomu 0.
Powiadamianie operatorów archiwizacji (n) Opcja n powoduje, że narzędzie dump powiadamia każdego członka grupy operatorów (określona w pliku /etc/group), gdy konieczna okaże się ich interwencja. Powiadomienie wygląda podobnie do komunikatu polecenia wall (powiadomienia nie są dostępne w przypadku systemu SCO). Kopia zapasowa tworzona przez narzędzie dump może wymagać interwencji, gdy wystąpi jedno z następujących zdarzeń: • kopia zapasowa osiągnie koniec taśmy lub dojdzie do zapełnienia dysku CD; • napęd archiwizujący przestanie poprawnie działać, powodując błędy zapisu; • pojawią się trudności z odczytem przez napęd dyskowy.
Określanie gęstości i rozmiaru (opcje d i s) Gęstość (opcja d) i rozmiar (opcja s) nie mają wpływu na to, jak dane są zapisywane na nośniku archiwizacyjnym. Polecenie dump używa tych opcji tylko do określenia ilości danych, które mogą się zmieścić na konkretnym woluminie, i do identyfikacji logicznego końca taśmy (miejsce, po którego osiągnięciu narzędzie dump sądzi, że wolumin jest pełny), występującego przed fizycznym końcem taśmy. Gdy zostaje wykryty logiczny koniec taśmy, program dump prosi operatora o zmianę woluminów. Identyfikowanie logicznego końca taśmy ma na celu niedopuszczenie do osiągnięcia przez wolumin fizycznego końca taśmy. Starsze wersje narzędzia dump nie radzą sobie dobrze z taką sytuacją. Poniżej w skrócie omówiono opcje d i s. d (gęstość) Określając gęstość, informuje się program dump o ilości danych, które mogą się zmieścić na jednym calu taśmy (choć w rzeczywistości wartość opcji d nawiązuje do czasów 9-ścieżkowych taśm, narzędzie dump używa jej w połączeniu z opcją s do określenia pojemności woluminu archiwizacyjnego). Aby mieć pewność, że program dump wykorzysta cały wolumin, należy zastosować dużą wartość, taką jak 80 000. s (rozmiar „taśmy” wyrażony w stopach) Opcja s informuje narzędzie dump o długości taśmy. Dysponując wartościami opcji d i s, program oblicza ilość danych, które zmieszczą się na taśmie. Aby mieć pewność, że narzędzie dump wykorzysta cały wolumin, należy użyć dużej wartości, takiej jak 500 000. Podając wartość 80 000 jako gęstość i 500 000 jako rozmiar, skutecznie informuje się program dump, że wolumin jest w stanie pomieścić 480 GB! Choć opcje d i s wydają się bezsensowne, jeśli
Arch w zowan e za pomocą narzędz a dump
|
97
dane archiwizuje się na dysku lub płycie CD, pełnią istotną rolę. W celu uzyskania dodatkowych informacji należy zapoznać się z podpunktem „Czy trzeba używać opcji d i s?”. W praktyce opcje te są bardzo trudne w użyciu i dają znikome korzyści. Większość osób oszukuje narzędzie dump, stosując wartości, które sprawiają, że dla programu taśma ma nieograniczoną pojemność. W efekcie narzędzie używa całego woluminu i jest w stanie wykryć fizyczny koniec taśmy, jeśli aż tyle jej zapisze. Można wymienić wiele powodów takiego stanu rzeczy. Oto one: • Polecenie dump może obecnie wykrywać fizyczny koniec taśmy i odpowiednio reagować
(wcześniej program po osiągnięciu fizycznego końca taśmy przerywał działanie). W systemie Solaris jest nawet dostępna opcja powodująca wysunięcie taśmy i włożenie następnej (jeśli stosuje się automatyczną zmieniarkę). A zatem w przypadku systemu Solaris narzędzie dump może kontynuować działanie bez potrzeby interwencji operatora. • Obliczenia sprawdzają się tylko wtedy, gdy narzędzie dump umieściło na woluminie dopiero
pierwszą kopię zapasową. Przykładowo za każdym razem, gdy stosuje się narzędzie dump, informuje się je, że taśma ma długość wynoszącą 10 000 stóp. Jeśli na woluminie zapisano wcześniej przynajmniej jedną kopię, jej długość nie będzie miała już takiej wartości. • Jeżeli użyje się „rzeczywistych” wartości, prawdopodobnie poda się niewielką gęstość
i bardzo duży rozmiar. Wiele wersji systemu Unix informuje, że coś takiego może spowodować problemy (trzeba to potraktować poważnie!). • Jeśli narzędzie dump ma przerwać działanie przed osiągnięciem fizycznego końca taśmy,
trzeba podać mniejsze wartości. W efekcie zostanie wykorzystana przestrzeń woluminu mniejsza niż rzeczywista (niekiedy budżet obliguje do zapisywania każdego centymetra wszystkich kupionych woluminów). Uwzględnienie w obliczeniach kompresji naprawdę komplikuje proces, ponieważ jest ona tym obszarem, w przypadku którego naprawdę ma zastosowanie stwierdzenie: „długość może się zmieniać”.
Unikanie tworzenia za pomocą narzędzia dump kopii zapasowej na wielu woluminach Przez stwierdzenie „na wielu woluminach” rozumiem to, że pojedyncza kopia zapasowa narzędzia dump rozpoczyna się na jednym woluminie i kończy w miejscu osiągnięcia logicznego lub fizycznego końca taśmy, a następnie jest kontynuowana na następnym woluminie. Jeśli na przykład dysponuje się napędem taśmowym DDS o pojemności 4 GB oraz archiwizuje 2i 3-gigabajtowy system plików, pierwsza kopia zapasowa narzędzia dump powinna się zmieścić na jednej taśmie. Druga kopia powinna zapełnić resztę pierwszej taśmy i wymagać włożenia drugiej taśmy, aby program dump mógł dokończyć archiwizowanie (rysunek 3.3). Według mnie tworzenie kopii zapasowej w ten sposób jest proszeniem się o kłopoty. Jeśli nie ma wyboru, trzeba tak postąpić, lecz wtedy pojawi się kilka nowych kwestii i zwiększy się trudność operacji odtwarzania. Przykładowo przed załadowaniem taśmy nr 2 trzeba włożyć taśmę nr 1 i rozpocząć jej odczyt. W przypadku odtwarzania danych już to jest wystarczającym utrudnieniem! Ponadto zaczynam się zastanawiać nad poziomem bezpieczeństwa plików znajdujących się przy końcu pierwszej taśmy. Czy Czytelnik uważa, że są bezpieczne? Polecenie dump może być czasami zabawne.
98
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Rysunek 3.3. Przykład kopii zapasowej narzędzia dump zapisanej na wielu woluminach
Czy trzeba używać opcji d i s? W kilku nowszych wersjach narzędzia dump zrezygnowano z tych opcji i zaoferowano nową, size in kilobytes, która może posłużyć do określenia rozmiaru woluminu wyrażonego w kilobajtach. Pomimo tego sam w wierszu każdego wykonywanego polecenia dump używam opcji s i d, żebym nie musiał pamiętać o różnicach poszczególnych wersji programu dump. Czytelnik zauważy, że w książce jest to często przeze mnie praktykowane. Im więcej zadań można wykonać w taki sam sposób, tym mniejszą liczbą rzeczy trzeba się martwić. Im więcej operacji dostosowywania wykonuje się dla każdego komputera i systemu operacyjnego, w tym większe kłopoty można wpaść (przykładowo opcja size in kilobytes używa innej litery dla każdej obsługiwanej wersji systemu Unix!). W tym przypadku zastosowanie archaicznych opcji gęstości i rozmiaru w rzeczywistości znacznie ułatwia tworzenie skryptów powłoki, ponieważ w większości wersji systemu Unix można korzystać z tych samych opcji. Co się stanie, gdy nie użyje się opcji s, d lub size in kilobytes? W przypadku niektórych odmian systemu Unix narzędzie dump korzysta z domyślnych wartości opcji gęstości i rozmiaru (z wyjątkiem systemu AIX, w którym całkowicie zrezygnowano z tych opcji). Niestety, domyślne wartości są zwykle ustawiane z myślą o obsłudze 9-ścieżkowych taśm (w systemie Solaris zmieniono domyślne wartości, aby były bardziej rozsądne). W takiej sytuacji narzędzie dump będzie przekonane, że potrzebuje kilku woluminów. Wynik wygenerowany przez program dump wygląda podobnie do poniższego: DUMP: Estimated 5860 blocks (3006KB) on 39.00 tapes.
Warto zauważyć, że narzędzie uważa, że potrzebuje 39 taśm. Właśnie do czegoś takiego może dojść, jeśli do określenia pojemności woluminu nie użyje się opcji gęstości i rozmiaru. Jak wspomniano, z łatwością można wyeliminować taką sytuację przez ustawienie dla tych opcji absurdalnie dużych wartości, tak aby narzędzie dump nigdy nie przewidziało, że braknie taśmy (lubię dla obu opcji podawać takie wartości jak 1 000 000).
Określanie pliku urządzenia archiwizującego (f) Opcja f określa nazwę pliku urządzenia archiwizującego, do którego zostaną przesłane dane (oczywiście tym „urządzeniem” może być rzeczywisty napęd taśmowy lub plik znajdujący się na dysku lub nośniku optycznym). Jeśli dla posiadanego napędu taśmowego zamierza się zastosować sprzętową kompresję, trzeba wybrać urządzenie, które ją obsługuje. Jeżeli dane chce się przesłać do napędu innego komputera, należy użyć formatu nazwa_zdalnego_komputera: urządzenie. Większość wersji systemu Unix pozwala na współpracę narzędzia dump ze zdalnymi urządzeniami, pod warunkiem że poprawnie korzysta się z programu rsh w roli mechanizmu uwierzytelniania.
Arch w zowan e za pomocą narzędz a dump
|
99
Zastosowanie narzędzia rsh i plików /.rhosts powoduje powstanie poważnej luki w zabezpieczeniach. Wiele organizacji nie zezwala na ich użycie! Nie należy wszędzie tworzyć plików /.rhosts i później mnie za to obwiniać. Zanim zacznie się korzystać z narzędzia rsh, trzeba się dokładnie zorientować, czy organizacja zezwala na to, czy nie. Jeśli nie, można wziąć pod uwagę wykorzystanie narzędzia ssh zamiast rsh. Więcej informacji można znaleźć w podrozdziale „Zastosowanie programu ssh lub rsh w roli kanału między systemami”, zamieszczonym na końcu rozdziału.
Zdalne urządzenia wymagają, aby ich host ufał lokalnemu hostowi wykorzystującemu plik /.rhosts. Jeśli spróbuje się użyć zdalnego urządzenia z poziomu niezaufanego komputera, będzie można zobaczyć następujący przerażający komunikat, informujący o braku uprawnień: Permission Denied
Aby sprawdzić, czy dysponuje się zaufanym hostem, należy jako superużytkownik spróbować wykonać poniższe polecenie: # rsh zdalny_system uname -a
Jeśli polecenie nie da oczekiwanych rezultatów, wiersz z nazwą lokalnego komputera trzeba umieścić w pliku /.rhosts zdalnego hosta. Niestety, w przypadku obecnych mieszanych środowisk nie zawsze wiadomo, jaka jest znana innym komputerom nazwa konkretnego hosta. Zdalny komputer może używać serwera DNS, NIS lub lokalnego pliku hosts. Gdy za pomocą programu rsh nawiąże się połączenie z hostem, początkowo będzie on widział adres IP komputera, który zainicjował połączenie. W dalszej kolejności zdalny host użyje funkcji gethostbyaddr() i spróbuje zamienić adres IP na nazwę. Zależnie od konfiguracji konkretnego komputera host może skomunikować się z serwerem DNS, NIS lub skorzystać z lokalnego pliku /etc/hosts. Kolejność sprawdzania wymienionych źródeł również zmienia się w zależności od przeprowadzonej konfiguracji. Jeżeli do translacji adresu zostanie użyty lokalny plik hosts lub serwer NIS, adres może mieć lub nie postać w pełni kwalifikowanej nazwy domenowej, takiej jak apollo.domena.com. Jeśli zostanie zastosowany serwer DNS, nazwa komputera będzie w pełni kwalifikowaną nazwą domenową. Ważne jest, aby o tym wiedzieć, ponieważ taka nazwa musi zostać umieszczona w pliku /.rhosts. Załóżmy, że lokalny komputer nosi nazwę apollo, a zdalny — elvis. Jeśli za pomocą narzędzia rsh z komputera apollo zamierza się nawiązać połączenie z hostem elvis, powinno się najpierw spróbować wykonać prosty krok. Na komputerze elvis należy wykonać następujące polecenie: $ echo apollo >>/.rhosts
Jeśli polecenie nie zadziała, będzie to prawdopodobnie oznaczać, że host apollo jest dla komputera elvis czymś innym (na przykładem hostem apollo.domena.com). Aby się upewnić, że tak jest, za pomocą programu telnet z poziomu komputera apollo należy połączyć się z hostem elvis, a następnie użyć takich poleceń, jak last, who, tty i netstat, w celu sprawdzenia pola zawierającego nazwę zdalnego hosta. Jeśli wartością pola okaże się nazwa apollo.domena.com, należy umieścić ją w pliku /.rhosts na komputerze elvis (przykładowo po stronie jednego klienta nazwa miała postać apollo.DOMENA.COM). Po wstawieniu poprawnej nazwy do pliku /.rhosts narzędzie rsh powinno działać.
Wyświetlanie systemów plików, które muszą zostać zarchiwizowane (opcje W i w) Opcje W i w są dostępne w większości systemów uniksowych i wyświetlają informacje na temat systemów plików, które muszą zostać zarchiwizowane. Opcja w zwykle prezentuje dane dotyczące wszystkich systemów plików, natomiast opcja W wyszczególnia jedynie te systemy 100
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
plików, dla których trzeba utworzyć kopię zapasową, na podstawie wybranego poziomu archiwizacji. Ponieważ opcje w przypadku różnych odmian systemu Unix nieznacznie się różnią, należy zapoznać się z odpowiednią dokumentacją.
Interesujące opcje narzędzia ufsdump systemu Solaris Program ufsdump systemu Solaris oferuje kilka opcji niespotykanych w innych wersjach systemu Unix. Narzędzie obsługuje opcje: l (autoloader), o (offline), a (archive file) i v (verify). Oto opis opcji: l
o
a
v
Opcja automatycznego zmieniania powoduje wysunięcie taśmy, gdy przed zakończeniem działania narzędzia dump zostanie osiągnięty fizyczny koniec taśmy. W takiej sytuacji program dump czeka maksymalnie dwie minuty na włożenie następnej taśmy. Opcja działa dobrze z sekwencyjnymi automatycznymi zmieniarkami. Opcja trybu offline po prostu powoduje wysunięcie taśmy na zakończenie archiwizacji w celu ochrony taśmy przed nadpisaniem przez inny proces. Opcja pliku archiwum powoduje zapisanie tabeli zawartości narzędzia dump w pliku plik_archiwum (jest zapisywany na woluminie przez wszystkie polecenia dump). Plik może być użyty przez narzędzie ufsrestore do sprawdzenia, czy plik znajduje się na określonym woluminie (bez konieczności podłączania jego nośnika). Opcja weryfikacji porównuje kopię zapasową z rzeczywistym systemem plików. Choć może to dobrze wyglądać w teorii, operacja wymaga odłączenia systemu plików, co w przypadku wielu zastosowań nie jest zbyt praktyczne.
Wygląd kopii zapasowej narzędzia dump W tym punkcie objaśniono podstawową różnicę między narzędziem dump a jego krewnymi, czyli programami tar i cpio. dump zapisuje tabelę zawartości na początku każdego woluminu, natomiast programy tar i cpio — nie.
Narzędzie dump zapisuje na woluminie indeks Indeks jest wczytywany podczas interaktywnego procesu odtwarzania, co umożliwia przetwarzanie tabeli zawartości za pomocą takich poleceń, jak cd i ls, oraz przeglądanie i zaznaczanie plików, które mają być przywrócone (narzędzie restore omówiono w dalszej części rozdziału). Funkcja interaktywnego odtwarzania jest jedną z największych zalet narzędzia restore (w porównaniu z programami tar i cpio). Warto zwrócić uwagę na jedną ważną kwestię dotyczącą indeksu: jest tworzony na początku archiwizacji, zanim faktycznie zostanie podjęta próba zapisania czegokolwiek w kopii zapasowej. Obecność indeksu sprawia, że proces interaktywnego odtwarzania jest efektywny, ponieważ nie trzeba wczytywać całego woluminu, aby sprawdzić, co na nim jest. Jednak to, że indeks jest generowany przed zapisaniem zarchiwizowanych danych i być może minuty lub godziny przed umieszczeniem danych na taśmie, powoduje, że w kopii zapasowej nie są uwzględniane pliki utworzone podczas archiwizacji. Ponadto pliki usunięte w czasie tworzenia kopii zapasowej wprawdzie są wyszczególnione w indeksie, lecz w rzeczywistości nie ma ich na woluminie. Arch w zowan e za pomocą narzędz a dump
|
101
Użycie indeksu do utworzenia tabeli zawartości Można utworzyć tabelę zawartości woluminu narzędzia dump przez fizyczne odczytanie zawartości indeksu utworzonego przez program i sprawdzenie, co zamierzał zapisać na woluminie. Warte uwagi jest również to, że odczytanie woluminu nie gwarantuje spójności pliku znajdującego się na woluminie w większym stopniu niż polecenie ls -l sprawdzające integralność pliku zawartego w katalogu. Można się zastanawiać, dlaczego mowa o tym w podrozdziale poświęconym narzędziu dump. Wynika to stąd, że tworzenie tabeli zawartości powinno być częścią każdej operacji archiwizowania realizowanej za pomocą narzędzia dump. Jak w takim razie wygenerować tabelę zawartości pliku programu dump? Przede wszystkim co tak naprawdę należy rozumieć przez plik programu dump? Być może pomocny będzie rysunek 3.4.
Rysunek 3.4. Format taśmy z danymi zapisanymi przy użyciu narzędzia dump
Wolumin tworzony przez narzędzie dump może mieć wiele plików programu dump, czasami nazywanych partycjami. Każdy plik jest zakończony znacznikiem końca pliku EOF (End-Of-File), symbolizowanym na rysunku 3.4 przez ciemniejsze pola. Jeśli zamierza się uzyskać tabelę zawartości pliku 3 programu dump (rysunek 3.4), ma się do wyboru dwie opcje: • Przy użyciu opcji s można nakazać programowi restore odczytanie z taśmy trzeciego pliku.
W efekcie narzędzie pominie pliki pierwszy i drugi, a następnie odczyta trzeci plik (wariant ten nie dotyczy kopii zapasowych zapisywanych przez narzędzie dump na dysku). • Można ręcznie wykonać pozycjonowanie taśmy (za pomocą narzędzia mt lub tpctl), tak
aby zlokalizować początek pliku, a następnie nakazać programowi restore odczytanie go, tak jakby był pierwszym plikiem na taśmie. Trzeba znać współczynnik bloków, przy użyciu którego zapisano wolumin. Jeśli nie ma się pewności, należy spróbować zastosować domyślną wartość współczynnika. Jeżeli to nie pomoże, należy zapoznać się z zawartością podrozdziału „Jak odczytać ten wolumin?” z rozdziału 23.
Pierwsza metoda jest najprostsza, ponieważ uwzględnia tylko jeden krok. Składnia polecenia jest następująca: $ restore tsbfy plik współczynnik_bloków urządzenie
W celu odczytania z taśmy trzeciego pliku narzędzia dump, gdy współczynnik bloków ma wartość 32, należy posłużyć się poniższym poleceniem: $ restore tsbfy 3 32 /dev/rmt/0cbn
Oto lista zastosowanych opcji i ich przeznaczenie: • Opcja t nakazuje programowi restore odczytanie indeksu woluminu i przekazanie tabeli
zawartości. • Opcja s i powiązany z nią argument 3 powodują, że narzędzie restore odczytuje z taśmy
trzeci plik narzędzia dump.
102
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
• Opcja b, mająca argument 32, informuje program restore, że podczas zapisywania pliku
narzędzia dump użyto współczynnika bloków o wartości 32. • Opcja f i jej argument dev identyfikują lokalizację pliku narzędzia dump zapisanego na
urządzeniu. • Opcja y nakazuje programowi restore kontynuowanie działania w przypadku wystąpienia
błędów zamiast pytania operatora, czy tego chce. Jeżeli wybierze się drugą metodę, polegającą na ręcznym użytkowaniu taśmy, trzeba znać uniksową wersję polecenia obsługującego taśmę magnetyczną. Zwykle nosi ono nazwę mt. Polecenie ma pięć opcji: status, rewind, offline, fsf i fsr. Spośród nich cztery mogą być wykorzystywane podczas obsługi taśm zapisanych za pomocą narzędzia dump. Format polecenia jest następujący: $ mt -t urządzenie argument
Jeśli planuje się pozycjonować taśmę, trzeba się upewnić, że korzysta się z urządzenia bez przewijania, takiego jak /dev/rmt/0n. W przeciwnym razie urządzenie zostanie przewinięte od razu po zakończeniu pozycjonowania!
Niektóre wersje programu mt zamiast opcji -t używają opcji -f. Argument urządzenie identyfikuje stosowany napęd taśmowy bez przewijania (na przykład /dev/rmt/0n). Pora w miejsce słowa argument wstawić jedną z następujących opcji: status
Opcja pozwala uzyskać status napędu taśmowego zwrócony przez wywołanie systemowe ioctl. Opcja nie wymaga dołączenia argumentu. rewind
Opcja powoduje przewinięcie taśmy do początku. W przypadku niektórych wersji systemu Unix opcja nosi nazwę rew. Opcja nie wymaga dodania argumentu. offline
Opcja powoduje wysunięcie taśmy z napędu. W przypadku niektórych wersji systemu Unix opcja ma nazwę offl. Opcja nie wymaga podania argumentu. fsf x fsf jest skrótem od forward space file. Opcja pozycjonuje taśmę do momentu osiągnięcia x znaczników plików, gdzie x jest wartością większą od 0 (jeśli nie poda się dla x wartości,
domyślnie będzie to 1). Jeżeli osiągnięto początek taśmy, oznacza to zlokalizowanie pliku 1. Aby przejść do pliku 3, trzeba przewinąć taśmę do przodu o dwa pliki. Wymaga to użycia opcji fsf 2 wstawionej do polecenia mt -t urządzenie fsf 2. fsr x fsr jest skrótem od forward space record. Opcja nie jest wymagana podczas obsługi taśm zapisanych za pomocą narzędzia dump (jeśli nie określi się wartości dla x, zostanie użyta
domyślna, wynosząca 1). Poniżej podano przykłady zastosowania polecenia mt. W celu przewinięcia napędu taśmowego /dev/rmt/0cbn należy wykonać polecenie: # mt -t /dev/rmt/0cbn rewind
Arch w zowan e za pomocą narzędz a dump
|
103
Aby szybko przewinąć taśmę urządzenia /dev/rmt/0cbn do drugiego pliku, należy zastosować polecenie: # mt -t /dev/rmt/0cbn fsf 1
W celu wysunięcia taśmy z napędu /dev/rmt/0cbn należy wykonać polecenie: # mt -t /dev/rmt/0cbn offline
Aby uzyskać status taśmy napędu /dev/rmt/0cbn, należy użyć polecenia: # mt -t /dev/rmt/0cbn status
Po zlokalizowaniu na taśmie właściwego pliku wystarczy użyć tego samego polecenia restore co wcześniej, pomijając opcję s i jej argument. $ restore tbfy 32 /dev/rmt/0cbn
Niezależnie od zastosowanej metody tabela zawartości jest przesyłana do standardowego wyjścia, które powinno się przekierować do pliku. W przypadku tego wyjścia godne uwagi jest to, że nie ma w nim nazwy systemu plików zarchiwizowanego na woluminie. Tabela zawartości jest względna w stosunku do tego systemu plików, niezależnie od jego nazwy. Jeśli na przykład zarchiwizowano katalog /var i szukano by pliku /var/adm/messages, uzyskany rezultat wyglądałby podobnie do poniższego: 345353
./adm/messages
Namawiam do generowania tabeli zawartości dla każdego woluminu w momencie tworzenia go za pomocą narzędzia dump i zapisywania wyniku w pliku o nazwie zgodnej z nazwą woluminu. Oczywiście należy użyć unikatowej nazwy, takiej jak poniższa: ./dump.system.system_plików.poziom0.19Maj.2006
Zapisywanie tabel zawartości w ten sposób bardzo się przydaje, gdy szuka się pliku i początkowo nie można go znaleźć na żadnym woluminie. Szybkie przeszukanie za pomocą narzędzia grep wszystkich plików programu dump pozwoli stwierdzić, który wolumin jest potrzebny.
Odtwarzanie danych za pomocą narzędzia restore Gdy pisałem ten podrozdział, do głowy przyszło mi zdanie pochodzące z reklamy leku na choroby lokomocyjne, który w Stanach Zjednoczonych nazywa się Dramamine. Brzmiało ono tak: „Pora na zażycie Dramaminy jest za późna na to, aby to zrobić” (a zatem mowa o chwili, gdy jest się już chorym). To samo dotyczy nauki korzystania z narzędzia restore. Trzeba bardzo dobrze zapoznać się z różnymi metodami odtwarzania danych (z kopii zapasowej utworzonej przy użyciu narzędzia dump) za pomocą programu restore. Jeśli Czytelnik przeprowadza ważną operację odtwarzania akurat w czasie, gdy czyta ten rozdział, nie ma powodu do obaw. Podrozdział zorganizowano z myślą o takim scenariuszu i w związku z tym uwzględnia każdy szczegół dotyczący narzędzia restore. W poniższym punkcie przyjęto, że wiadomo na pewno, iż wolumin zapisano za pomocą programu dump, i znany jest rozmiar bloku woluminu. Jeśli nie dysponuje się takimi informacjami, należy zapoznać się z zawartością podrozdziału „Jak odczytać ten wolumin?” z rozdziału 23.
104
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Niewystarczające, aby było przydatne Pewnego razu zlecono mi odtworzenie danych komputera wycofanego 10 lat wcześniej. Po otrzymaniu nazwy komputera i orientacyjnej lokalizacji taśm rozpocząłem poszukiwania. Gdy znalazłem taśmy i pożyczyłem napęd taśmowy o wystarczająco niewielkiej gęstości, aby można było je odczytać, stwierdziłem, że zostały utworzone za pomocą narzędzia dump w formacie już nieobsługiwanym! Znalazłem kod źródłowy oryginalnego programu restore (w tym przypadku wchodzącego w skład systemu BSD 4.1), pobrałem go na komputer (z systemem SunOS 4.0.1, podobnym do systemu BSD 4.3) i zacząłem prace nad przeniesieniem starego oprogramowania. Bez powodzenia. Wkrótce zdałem sobie sprawę z tego, że zadanie to zajęłoby mi całe tygodnie, ponieważ formaty systemu plików i narzędzia dump zmieniły się tak znacząco. Ponieważ istniało inne rozwiązanie, przeszukałem magazyny w celu znalezienia dodatkowych taśm. Szczęśliwie udało mi się odszukać następny stos taśm, oznaczonych jako przechowujące kopie zapasowe utworzone za pomocą programu tar. Udało mi się! Większość z tych taśm nadal można było odczytać. Dane uzyskałem już przy pierwszym podejściu. Morał z tej historii jest taki, że gdy wycofuje się komputer, należy sporządzić archiwalną kopię zapasową danych w każdym możliwym formacie i zapisać ją na wszystkich dostępnych typach nośników. Część narzędzi, jak dump, jest bardzo skuteczna, lecz pewnego dnia mogą nie być już obsługiwane. Inne narzędzia, jak tar i cpio, były wykorzystywane przez lata. Ponieważ zmieniają się czasy, nośniki i formaty, należy wykonać tak wiele odmian kopii zapasowych, jak to możliwe, aby dane można było odtworzyć przez jak najdłuższy okres. Powyższa historia sprawiła, że stałem się wielkim zwolennikiem używania narzędzia tar do sporządzania archiwalnych kopii zapasowych. W końcu słowo tar jest skrótem od Tape ARchiver (archiwizator danych na taśmie). — Doug Freyburger
Czy można odczytać wolumin z kopią zapasową? Aby mieć pewność, że znany jest format kopii zapasowej zapisanej na taśmie i rozmiar bloku, należy spróbować wyświetlić tabelę zawartości. Poniższe polecenie generuje tabelę zawartości woluminu utworzonego przy użyciu narzędzia dump. $ restore tbfy rozmiar_bloku nazwa_urządzenia
Przykładowo, aby odczytać tabelę zawartości taśmy zapisanej za pomocą programu dump (z zastosowaniem współczynnika bloków o wartości 32) i umieszczonej w urządzeniu /dev/rmt/ 0cbn, należy wykonać następujące polecenie: $ restore tbfy 32 /dev/rmt/0cbn
Jeżeli polecenie zadziała, reszta będzie już prosta (w przeciwnym razie należy zapoznać się z zawartością podrozdziału „Jak odczytać ten wolumin?” z rozdziału 23).
Współczynnik bloków Czasami narzędzie dump może zapisać kopię zapasową przy użyciu współczynnika bloków, z którym nie może sobie poradzić program restore. Zwykle tego typu problem można bardzo łatwo rozwiązać. Również w tym przypadku konieczna jest znajomość rozmiaru bloku, przy
Odtwarzan e danych za pomocą narzędz a restore
|
105
użyciu którego zapisano wolumin. Zgodnie z tym, co napisano w rozdziale 23., należy określić rozmiar bloku woluminu. Załóżmy, że wielkość bloku woluminu wynosi 65 536. Przy użyciu narzędzia dd należy odczytać wolumin i jego wynik przekazać programowi restore, podając - jako argument plikowy. Poniższe polecenie nakaże narzędziu restore wczytanie swoich danych ze standardowego wejścia. # dd if=nazwa_urządzenia bs=64k|restore tfy -
Dlaczego to działa? Zapisywanie danych na woluminie w postaci bloków w rzeczywistości zmienia sposób fizycznego rozmieszczenia danych na woluminie. Dla narzędzia restore musi być zrozumiały format bloków, aby mogło odczytać zawartość woluminu. Jeśli jednak dane z woluminu odczyta się za pomocą programu dd, zostaną umieszczone w potoku. Polecenie dd jako rozmiar bloku w potoku ustawia wartość 1, pozwalając programowi restore użyć podczas odczytu bloku danych dowolnego rozmiaru bloku.
Różnice w uporządkowaniu bajtów Format kopii zapasowej tworzonej przez narzędzie dump jest bardzo ściśle powiązany z konkretnym systemem plików. Jeżeli występują różnice w kolejności bajtów, prawdopodobnie różne są też wersje programów dump i restore. Najprostsze i chyba jedyne, co należy zrobić, jest poszukanie komputera z identycznym systemem operacyjnym jak ten użyty do zapisania woluminu archiwizacyjnego. Wynika to stąd, że odwrotne uporządkowanie bajtów może umożliwić odczytanie nagłówka kopii zapasowej, lecz odtworzone pliki, zależnie od formatu stosowanego przez program dump, mogą okazać się bezużyteczne.
Różne wersje narzędzia dump Niestety, z upływem czasu problem różnych wersji narzędzia dump tylko się pogłębia. W przeciwieństwie do innych narzędzi omówionych w rozdziale program dump jest mocno powiązany z systemem plików i zwykle współpracuje tylko z jednym typem systemu plików. Problem polega na tym, że twórcy systemów uniksowych cały czas próbują ulepszać system plików. W efekcie wielu dostawców systemu Unix oferuje więcej niż jeden typ systemu plików. Jeśli narzędzie dump w ogóle występuje w wykorzystywanej wersji systemu Unix, może obsługiwać systemy plików tylko starszego typu. Niekiedy istnieje wiele wersji programu dump. Przykładowo system IRIX ma zarówno narzędzie dump, jak i xfsdump. Każda wersja programu dump dysponuje też własną wersją narzędzia restore. Różne wersje programu restore mogą być w stanie odczytać kopię zapasową utworzoną przy użyciu innej wersji narzędzia dump lub nie. Jest to obszar, w przypadku którego zdecydowanie ma zastosowanie stwierdzenie, że „zakres może się zmieniać”. Prawdopodobnie najlepszym przykładem zmiennej natury narzędzia dump jest system plików XFS systemu SGI i jego narzędzie xfsdump. Początkowo można odnieść wrażenie, że jest to stare polecenie efsdump z kilkoma nowymi opcjami. Jednak jest to bardzo dalekie od prawdy. Załóżmy, że korzysta się z utworzonego we własnym zakresie programu, który używa narzędzia dump. Dodatkowo przyjmijmy, że do listy dołączeń programu xfsdump dodano właśnie zainstalowany nowy system plików XFS. W pierwszej kolejności narzędzie xfsdump przewija taśmę, niezależnie od tego, czy wybrano urządzenie z przewijaniem, czy nie. Następnie narzędzie próbuje odczytać z taśmy pierwszy blok danych. Zależnie od złożoności skryptu wywołującego program xfsdump pierwszym plikiem na taśmie może być elektroniczna etykieta zapisana przez
106
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
skrypt lub pierwsza kopia zapasowa sporządzona przez narzędzie dump. Gdy będzie to pierwsza kopia, narzędzie xfsdump poinformuje, że nie znalazło swojej kopii zapasowej i nadpisze dane. Jeśli program xfsdump napotka na własną kopię zapasową, nie nadpisze jej, lecz dołączy do niej dane. Ponadto narzędzie xfsdump — i to jest być może „najciekawsze” — w ramach tworzenia jednej kopii zapasowej zapisuje na taśmie wiele plików. Zwykle każda kopia zapasowa narzędzia dump ma postać jednego pliku zapisanego na taśmie. Z kolei program xfsdump używa algorytmu określającego liczbę plików, które powinny zostać umieszczone na taśmie. Choć przypuszczalnie dzięki temu proces odtwarzania jest szybszy, dodatkowo staje się całkowicie zgodny z niemal wszystkimi możliwymi skryptami powłoki. Najlepszym rozwiązaniem jest bycie przygotowanym. Trzeba wiedzieć, jakich używa się wersji narzędzi dump i restore, a także poeksperymentować z nimi, aby stwierdzić, czy są w stanie odczytać różne woluminy. Jeśli chodzi o dwie wersje narzędzia dump tego samego systemu, prawdopodobnie będą ze sobą współpracować zawsze lub nigdy. Trzeba pamiętać, aby testować, testować i jeszcze raz testować.
Składnia polecenia restore Gdy można odczytać wolumin z kopią zapasową narzędzia dump, trzeba zdecydować, jakie dane muszą zostać odczytane i w jaki sposób. W niniejszym punkcie omówiono powszechnie używane argumenty polecenia restore i wyjaśniono, kiedy je stosować. Zasadniczo należy wyróżnić cztery operacje, które można wykonać w przypadku woluminu zapisanego za pomocą narzędzia dump. Oto one: • odczytanie tabeli zawartości w celu jej przejrzenia, • odtworzenie całego systemu plików, • odtworzenie wybranych plików, • przeprowadzenie interaktywnego procesu odtwarzania.
W przypadku trzech pierwszych zastosowań narzędzie restore może pobrać dane ze standardowego wejścia. Są to właściwe warianty użycia polecenia restore, gdy trzeba do niego w potoku przekazać dane, tak jak we wcześniej przedstawionym przykładzie polecenia dd. Interaktywny proces odtwarzania sprawdza się dobrze tylko wtedy, gdy ma dostęp do całego pliku kopii zapasowej narzędzia dump lub taśmy. Składnia standardowego polecenia restore jest następująca: $ restore [trxi]vbsfy współczynnik_bloków numer_pliku nazwa_urządzenia
Opcje polecenia restore Sposób działania narzędzia restore zależy od typu przekazanych mu argumentów.
Określanie typu operacji odtwarzania Pierwszy argument polecenia restore identyfikuje typ operacji odtwarzania, która zostanie wykonana. Można określić tylko jeden z czterech następujących argumentów:
Odtwarzan e danych za pomocą narzędz a restore
|
107
• t — nakazuje narzędziu restore wyświetlenie tabeli zawartości woluminu; • r — powoduje, że cała zawartość woluminu powinna zostać odtworzona do bieżącego
katalogu roboczego;
• x — nakazuje narzędziu restore wyodrębnienie z kopii zapasowej tylko plików wyszcze-
gólnionych na końcu polecenia; • i — umożliwia przeprowadzenie interaktywnego procesu odtwarzania.
Określanie sposobu przebiegu procesu odtwarzania Reszta argumentów jest opcjonalna i decyduje o sposobie działania narzędzia restore podczas procesu odtwarzania. • v — włącza wyświetlanie szczegółowych wyników; • s — nakazuje programowi restore przed rozpoczęciem odczytu taśmy pominięcie kilku
plików; • b — umożliwia podanie współczynnika bloków dla odczytywanego woluminu; • f — określa ścieżkę pliku urządzenia używanego napędu archiwizującego (lub pliku na
dysku); • y — nakazuje programowi restore, aby spróbował kontynuować działanie mimo wystą-
pienia błędów odczytu.
W następnych podpunktach bardziej szczegółowo omówiono powyższe opcje.
Tworzenie tabeli zawartości woluminu narzędzia dump (t) Opcja t służy do sprawdzenia, jakie pliki znajdują się na woluminie utworzonym za pomocą narzędzia dump. Jest to opcja dobrze nadająca się do tego, aby uwzględnić ją w każdym zautomatyzowanym skrypcie powłoki kontrolującym kopie zapasowe sporządzone przy użyciu narzędzia dump. Opcja jest też przydatna, gdy nie jest się pewnym takich rzeczy, jak wielkość znaków w nazwach plików lub ich lokalizacja. Można umieścić w pliku listę plików wchodzących w skład dowolnego woluminu, a następnie za pomocą narzędzi takich jak grep znaleźć szukane pliki. Oto przykład: # restore tfy urządzenie >/tmp/dump.list
Powyższe polecenie wczytuje z urządzenia tabelę zawartości kopii zapasowej narzędzia dump i wynik umieszcza w pliku /tmp/dump.list. Poniższe polecenie szuka w pliku /tmp/dump.list łańcucha nazwa_pliku. # grep nazwa_pliku /tmp/dump.list 3455 ./jakiś_katalog/nazwa_pliku
Przeprowadzanie procesu całkowitego odtworzenia (rekursywnego) systemu plików (r) Opcję r zaprojektowano z myślą o odtwarzaniu całego systemu plików przez odczytanie pełnej zawartości woluminu zapisanego za pomocą programu dump. Opcja powinna być stosowana tylko wtedy, gdy ma się absolutną pewność, że zamierza się odtworzyć cały system plików. Proces wymaga, aby zacząć od pliku kopii zapasowej poziomu 0. Później opcjonalnie można wczytać wszystkie przyrostowe kopie zapasowe. Proces zapisuje plik restoresymtable (w niektórych wersjach systemu Unix nosi nazwę restoresmtable) i odwołuje się do niego podczas
108
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
wczytywania odtwarzanych danych przyrostowych kopii zapasowych. Przyrostowa kopia zapasowa narzędzia dump rejestruje czas kopii niższego poziomu, na której bazuje. Ponieważ opcję r dodano w celu odtwarzania całego systemu plików, nie pozwala na odczytanie przyrostowej kopii zapasowej narzędzia dump bazującej na woluminie, którego jeszcze nie wczytano. Załóżmy, że są trzy kopie zapasowe programu dump: poziomu 0 z poniedziałku, poziomu 1 z wtorku i poziomu 2 ze środy. Jeśli za pomocą opcji r wczyta się kopię poziomu 0, a następnie spróbuje odczytać kopię poziomu 2 bez uprzedniego wczytania kopii poziomu 1, narzędzie restore zaprotestuje. Po ukończeniu odtwarzania całego systemu plików plik restoresymtable powinno się usunąć (jednak nie należy tego robić do momentu wczytania taśm z kopiami zapasowymi wszystkich poziomów).
W celu użycia opcji r najpierw należy za pomocą polecenia cd przejść do systemu plików, który zamierza się odtworzyć, a następnie wczytać kopię zapasową poziomu 0 i wykonać następujące polecenie: # restore rbvsfy współczynnik_bloków numer_pliku nazwa_urządzenia
Przykładowo, aby odtworzyć całą zawartość taśmy z kopiami zapasowymi narzędzia dump zapisanymi z wykorzystaniem współczynnika bloków o wartości 32 na urządzeniu /dev/rmt/0cbn, należy zastosować poniższe polecenie. $ restore rvbfy 32 /dev/rmt/0cbn
Gdy polecenie zakończy działanie, należy wczytać dowolne przyrostowe kopie zapasowe, począwszy od kopii najniższego poziomu, i ponownie wykonać to samo polecenie. Proces należy powtarzać do momentu załadowania najbardziej aktualnej przyrostowej kopii zapasowej. Jeżeli dysponuje się więcej niż jedną kopią zapasową narzędzia dump tego samego poziomu, trzeba załadować tylko najnowszą. Jeśli na przykład raz w miesiącu tworzy się kopię zapasową poziomu 0, a w pozostałe dni miesiąca sporządza się kopie zapasowe poziomu 1, w celu odtworzenia całego systemu plików trzeba będzie załadować jedynie kopię poziomu 0, a następnie najnowszą kopię zapasową poziomu 1.
Odtwarzanie plików według nazwy (x) Z opcji x można skorzystać, gdy znana jest dokładna nazwa i ścieżka pliku lub plików, które zamierza się odtworzyć (ponieważ nie wszystkie testowane przeze mnie wersje narzędzia restore obsługują w obrębie listy dołączeń symbole wieloznaczne, trzeba znać dokładną nazwę plików). Opcja powoduje, że program restore działa tak jak narzędzie tar, umożliwiając podanie w wierszu poleceń plików, które mają być wczytane z kopii zapasowej. Pamiętając o tym, że wszystkie kopie zapasowe są tworzone przez narzędzie dump z zastosowaniem względnych ścieżek, za pomocą polecenia cd trzeba przejść do systemu plików, w którym mają się znaleźć odtwarzane pliki. W dalszej kolejności należy wykonać poniższe polecenie, wyodrębniające pliki z kopii zapasowej. # restore xbvsfy współczynnik_bloków numer_pliku nazwa_urządzenia ./katalog/plik1 ./katalog/plik2
Przykładowo, aby odtworzyć pliki /etc/hosts i /etc/passwd z taśmy zapisanej za pomocą narzędzia dump przy wykorzystaniu współczynnika bloków o wartości 32 i urządzenia /dev/rmt/0cbn, należy wykonać następujące polecenie: $ restore xvbfy 32 /dev/rmt/0cbn ./etc/hosts ./etc/passwd
Odtwarzan e danych za pomocą narzędz a restore
|
109
Interaktywne odtwarzanie plików (i) Opcja i odróżnia narzędzie restore od programów tar i cpio. Gdy program dump tworzy kopię zapasową, na jej początku zapisuje indeks z tym, co zostanie zarchiwizowane (podobnie jak w przypadku innych trybów działania narzędzia restore, przed jego uruchomieniem za pomocą polecenia cd powinno się przejść do systemu plików, w którym mają znaleźć się odtworzone pliki). Opcja i symuluje podłączenie woluminu narzędzia dump i inicjuje fikcyjną powłokę umożliwiającą wykonanie takich poleceń, jak cd, ls, pwd, add, delete i extract. Przy użyciu tych poleceń można przemieszczać się między katalogami woluminu narzędzia dump bardzo podobnie jak w przypadku katalogów systemu plików. Po natrafieniu na plik, który ma być uwzględniony w procesie odtwarzania, wystarczy wykonać polecenie add nazwa_pliku. Ponieważ większość wersji narzędzia restore obsługuje również symbole wieloznaczne powłoki, można także zastosować polecenie add *wzorzec*. Po wybraniu pliku do odtworzenia, gdy ponownie wykonując polecenie ls, zażąda się listy plików, obok nazwy pliku pojawi się znak gwiazdki. Jeśli zauważy się, że dodano plik, który nie ma być odtworzony, wystarczy wykonać polecenie delete nazwa_pliku lub delete *wzorzec*. Oczywiście nie spowoduje to usunięcia pliku z woluminu, a jedynie z listy plików przeznaczonych do wczytania z kopii zapasowej. Po określeniu plików, które mają zostać odtworzone, wystarczy wykonać polecenie extract. Narzędzie restore zadaje następnie pytanie dotyczące woluminu, od którego ma zacząć. Pytanie jest istotne tylko wtedy, gdy odtwarza się kilka plików rozmieszczonych na wielu taśmach. Ponieważ pliki są zapisywane zgodnie z kolejnością i-węzłów, można najpierw włożyć do napędu ostatnią taśmę i narzędzie restore będzie w stanie odczytać numer i-węzła pierwszego pliku, a następnie od razu stwierdzić, czy musi odczytać cokolwiek z tej taśmy. Jeśli tak, narzędzie musi jedynie odczytać dane aż do ostatniego i-węzła na taśmie. Jeżeli narzędzie restore nadal musi odczytać pliki z innych taśm, należy je umieszczać w napędzie numerami w odwróconej kolejności. Również w tym przypadku narzędzie wie, czy musi odczytać taśmy i w jakim zakresie. Jeśli najpierw włoży się do napędu taśmę 1, urządzenie po prostu odczyta kolejne taśmy. Przy odtwarzaniu systemu plików działa to po prostu świetnie. Jeśli kilka plików odtwarza się z kopii zapasowej utworzonej za pomocą narzędzia dump na wielu taśmach, należy je umieszczać w napędzie w odwrotnej kolejności i wprowadzać odpowiednie numery taśm. Jeżeli jest tylko jedna taśma lub po prostu zamierza się kolejno odczytać taśmy, wystarczy wprowadzić wartość 1. Wybrane pliki są następnie odtwarzane w katalogu uaktywnionym podczas wykonywania polecenia restore (tworzy ono wszystkie katalogi wymagane do zapisania odtworzonych plików). Po ukończeniu odtwarzania narzędzie zadaje pytanie set owner/mode for '.'?. Wiele osób nie rozumie jego znaczenia. Załóżmy, że zarchiwizowano katalog /home/jnowak należący do użytkownika jnowak. Jeśli podczas odtwarzania zawartości tego katalogu do katalogu /tmp na pytanie odpowie się twierdząco, właścicielem katalogu /tmp stanie się użytkownik jnowak! A zatem trzeba zachować ostrożność podczas odtwarzania plików do alternatywnych lokalizacji i odpowiadania na powyższe pytanie. Negatywna odpowiedź powoduje pozostawienie uprawnień katalogu bez zmian. Przykład 3.1 prezentuje prostą sesję narzędzia restore. Większość widocznych poniżej dodatkowych komentarzy, takich jak rozmiar bloku, data utworzenia woluminu przez program dump i inne komunikaty, jest wynikiem użycia opcji v (omówiono ją w dalszej części rozdziału).
110
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
W ramach sesji plik /etc/passwd jest zaznaczany i odtwarzany do katalogu /tmp/etc (właśnie z tego powodu przed rozpoczęciem procesu odtwarzania przeszedłem do katalogu /tmp). Przykład 3.1. Prosta sesja narzędzia restore # cd /tmp # ufsrestore ifvy /tmp/dump Verify volume and initialize maps Media block size is 126 Dump date: Sun Apr 30 23:07:22 2006 Dumped from: Sun Apr 30 22:15:37 2006 Level 9 dump of / on apollo:/dev/dsk/c0t0d0s0 Label: none Extract directories from tape Initialize symbol table. ufsrestore > ls .: 2 *./ 2 *../ 11395 devices/ ufsrestore > cd etc ufsrestore > ls ./etc: 28480 ./ 2 *../ ufsrestore > add passwd Make node ./etc ufsrestore > ls ./etc: 28480 *./ 2 *../
28562
28562
dumpdates
dumpdates
28480
28486
etc/
28486
passwd
*passwd
ufsrestore > extract Extract requested files You have not read any volumes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 extract file ./etc/passwd Add links Set directory mode, owner, and times. set owner/mode for '.'? [yn] n ufsrestore > q # ls -lt /tmp/etc/passwd -rw-r--r-1 root sys 34983 Apr 28 23:54 /tmp/etc/passwd
Odtwarzanie plików do innej lokalizacji Wszystkie nazwy plików zawarte w woluminie archiwizacyjnym narzędzia dump mają względną ścieżkę. Inaczej mówiąc, jeśli archiwizuje się katalog /home zawierający katalogi /home/kaczor i /home/donald, lista plików będzie wyglądać tak: 15643 12456
./kaczor ./donald
W związku z tym odtworzenie plików w innym miejscu jest bardzo łatwe. Wystarczy przejść do katalogów innych niż oryginalny (na przykład do katalogu /home1) i rozpocząć proces odtwarzania. Narzędzie utworzy wymagane katalogi. Jeżeli w poprzednim przykładzie katalog /home zmieni się na /tmp, zostaną utworzone katalogi /tmp/kaczor i /tmp/donald.
Odtwarzan e danych za pomocą narzędz a restore
|
111
Żądanie wyświetlania szczegółowych komunikatów (v) Opcja v nie wymaga argumentu i powoduje pokazywanie szczegółowych informacji. Opcja generuje wiele dodatkowych informacji, takich jak data i poziom kopii zapasowej, a także nazwa każdego odtwarzanego pliku. Opcje: s, b i f wymagają argumentu. Działają one dokładnie tak jak ich odpowiedniki z polecenia dump (nie oznacza to jednak, że opcja s w obu poleceniach pełni identyczną rolę). Wszystkie konieczne opcje wystarczy wstawić za poleceniem restore, a następnie podać argument powiązany z każdą opcją w kolejności zgodnej z ustawieniem opcji. Przykładowo, aby użyć opcji: b, f i s, należy wykonać następujące polecenie: # restore tbfsy współczynnik_bloków plik_urządzenia numer_pliku
Pomijanie plików (s) Opcja s służy do odczytu kopii zapasowej narzędzia dump innej niż pierwsza na taśmie. Gdy dla napędu taśmowego bez przewijania wykona się wiele poleceń dump, każde spowoduje utworzenie oddzielnego pliku. Pliki są od siebie oddzielone znakiem końca pliku. Za pomocą jednego polecenia nie można odczytać wszystkich takich plików (jeśli ktoś miałby przeprowadzać operację odtwarzania, raczej by z niej zrezygnował, ponieważ każdy plik prawdopodobnie byłby kopią zapasową oddzielnego systemu plików). Każdą kopię zapasową trzeba odczytać za pomocą niezależnego polecenia restore. Można w tym miejscu wyróżnić dwa scenariusze. Oto one: • sukcesywne odczytywanie z taśmy każdego systemu plików, tak jak wtedy, gdy chce się
uzyskać tabelę zawartości całej taśmy;
• wczytanie z taśmy wybranego systemu plików.
Wiele systemów plików można kolejno odczytać, po prostu wykonując kilka poleceń restore dla napędu taśmowego bez przewijania. To, czy coś takiego się uda, zależy od sposobu działania systemowego sterownika używanego napędu taśmowego. Po udanym wykonaniu polecenia restore taśma może zatrzymać się przy końcu pliku tuż za znakiem końca pliku. Jeśli urządzenie jest zgodne ze standardem Berkeley, może zatrzymać się przy końcu pliku tuż przed znakiem końca pliku. W tym przypadku następne polecenie restore nie zadziała. Czasami można sobie z tym poradzić przez wykonanie polecenia mt -t urządzenie fsf 1, które ustawia taśmę bezpośrednio za znakiem końca pliku. Można wtedy wykonać następne polecenie restore. Operację odczytania kopii zapasowej narzędzia dump z konkretnym systemem plików można wykonać na dwa sposoby: • Przewinięcie za pomocą polecenia mt lub tctl taśmy do odpowiedniego pliku kopii za-
pasowej, a następnie wykonanie polecenia restore bez argumentu s.
• Przewinięcie taśmy i poinformowanie narzędzia restore za pomocą opcji s, który plik ma
wczytać. W dalszej kolejności taśma jest przewijana do tego pliku, który jest odczytywany. Opcja s wymaga argumentu o wartości z przedziału od 1 do n. W miejsce n należy wstawić numer pliku, który ma być odczytany z taśmy. Ponieważ pierwsza kopia zapasowa zapisana na taśmie ma numer 1, wykonanie polecenia restore tsf 1 urządzenie pod względem funkcjonalnym odpowiada poleceniu restore tf urządzenie.
112
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Warto zwrócić uwagę na różnice między programami mt i restore. Oba narzędzia w odmienny sposób numerują pliki taśmy. Mówiąc dokładniej, numeracja jest przesunięta o 1. Jeśli program mt ma przewinąć taśmę do drugiego pliku, należy wykonać polecenie mt -t urządzenie fsf 1. Aby narzędzie restore odczytało z taśmy drugą kopię zapasową, należy zastosować polecenie restore [irtx]s 2. Tego typu różnica zrobiła zamieszanie niejednemu administratorowi!
Określanie współczynnika bloków (b) Opcja b pozwala przekazać narzędziu restore wartość współczynnika bloków, którego użyto podczas zapisywania woluminu. Opcja wymaga argumentu będącego wartością liczbową, zwykle z przedziału od 1 do 126 (lub maksymalną wartością obsługiwaną przez używaną wersję programu restore). Współczynnik bloków jest mnożony przez minimalny rozmiar bloku obsługiwany przez używaną wersję narzędzia restore. Choć minimalny rozmiar bloku zwykle wynosi 1024, może mieć wartość 512 (należy zajrzeć do dokumentacji dołączonej do wykorzystywanej wersji programu restore). Ponieważ obecnie wiele wersji programu restore może automatycznie wykrywać najbardziej typowe współczynniki bloków, może nawet nie być potrzeby używania opcji b. Jeśli stwierdzi się, że stosuje się współczynnik, który może nie zostać automatycznie zidentyfikowany przez używaną wersję programu restore, za pomocą opcji b należy poinformować go o wartości użytego współczynnika. Jeżeli do odczytu danych stosuje się polecenie dd, a następnie w ramach potoku przekazuje je narzędziu restore, nie trzeba używać opcji b.
Określanie napędu archiwizacyjnego lub pliku (f) Opcja f jest używana dość często. Nakazuje programowi restore odczyt z urządzenia określonego w powiązanym argumencie zamiast z domyślnego napędu taśmowego używanej wersji systemu Unix. Argument może zawierać dowolny z następujących łańcuchów: /dev/rmt/0 Nazwa lokalnego urządzenia (na przykład /dev/rmt0, /dev/rmt/8500compressed) /kopie_zapasowe/plik_kopii_dump Dowolny plik kopii zapasowej utworzony przez narzędzie dump. zdalny_host:/dev/rmt/0 Zdalne urządzenie, którego ścieżka rozpoczyna się nazwą hosta (nie wszystkie wersje programu restore obsługują zdalne hosty). W celu uzyskania informacji na temat bezpieczniejszej metody korzystania ze zdalnych urządzeń trzeba zapoznać się z treścią ostatniego podrozdziału niniejszego rozdziału.
"-"
Standardowe wejście używane na przykład podczas pobierania danych z programu dd lub wysyłania ich przez narzędzie dump do standardowego wyjścia.
Odtwarzan e danych za pomocą narzędz a restore
|
113
Określanie nieprzerwanego działania podczas odtwarzania (y) Normalnie gdy program restore napotka w pliku błąd, zatrzyma się i zapyta operatora, czy kontynuować działanie. Jeśli zastosuje się opcję y, narzędzie nie zada żadnego pytania i po wystąpieniu błędu spróbuje wykonać zadanie najlepiej, jak może.
Ograniczenia narzędzi dump i restore Programy dump i restore oferują wiele możliwości. Dobry skrypt powłoki może zautomatyzować korzystanie z nich i zapewnić wysoki poziom bezpieczeństwa, gdy dysk się zepsuje. Jednak narzędzia te mają następujące ograniczenia: • W przypadku narzędzia dump nie istnieje metoda uzyskania spójnego obrazu całego systemu
plików w dowolnym wybranym momencie. • Polecenie dump czasami nie informuje o otwartych plikach i innych problemach. Wyświetla
komunikaty o błędzie, gdy wszystko naprawdę się skomplikuje. • Choć pliki zostały pominięte, w rzeczywistości narzędzie restore może sprawić, że użyt-
kownik będzie przekonany, iż znajdują się na woluminie. • Trzeba pisać skrypty współpracujące z programem dump. Skrypty te mogą zawierać błędy. • Istnieje wiele wersji narzędzia dump, z których nie wszystkie dobrze ze sobą współpracują. • Podobnie do wszystkich innych wbudowanych narzędzi programy dump i tar są pozba-
wione indeksów dołączanych do komercyjnego oprogramowania (choć wersja programu dump dla systemu Solaris ma opcję wykonującą w pewnym stopniu indeksowanie, zdecydowanie nie jest tym, czego można oczekiwać po komercyjnym produkcie). Dopóki pamięta się o powyższych ograniczeniach, można przez długi czas używać narzędzi dump i restore bez potrzeby wydawania dodatkowych pieniędzy na komercyjne oprogramowanie. Dobrej zabawy!
Funkcje godne sprawdzenia Jeśli zamierza się napisać własny skrypt archiwizujący współpracujący z programem dump lub dowolnym innym poleceniem opisanym w niniejszym rozdziale, trzeba zadbać o to, aby wykonywał niżej wymienione zadania. Kontrolowanie błędów w dużym zakresie Przez lata miałem do czynienia ze zbyt wieloma skryptami powłoki, które zakładały różne rzeczy. Nie należy przyjmować, że proste polecenie zadziałało tylko dlatego, że zawsze jest tak, jak się założyło. Gdy automatyzuje się różne rzeczy, zawsze należy sprawdzać zwrócony kod. Jeśli można przewidzieć, co powoduje określony błąd, należy spróbować utworzyć skrypt, który wyeliminuje go. Powiadamianie, powiadamianie i jeszcze raz powiadamianie Nie sposób napisać wystarczająco dobitnie, jakie to ważne. Jeżeli skrypt stwierdzi coś, z czym się nie spotkał, powinien powiadomić o tym użytkownika. Powinny być też rejestrowane wszystkie poprawne działania, tak aby można było przejrzeć dzienniki w celu upewnienia się, że wszystko zadziałało. Zbyt wiele operacji odtwarzania nie powiodło się, ponieważ 114
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
ktoś nie zapoznał się z dziennikiem archiwizacji. Jeśli dysponuje się skryptem powiadamiającym, gdy coś nie idzie zgodnie z planem, nie należy zakładać, że wszystko jest w porządku, jeśli nie otrzymało się żadnej wiadomości pocztowej. Co się stanie, jeśli program cron będzie wyłączony? Co będzie, gdy jakaś mniej istotna zmiana dokonana w skrypcie spowoduje przerwanie jego działania bez powiadomienia? Co się stanie, gdy program sendmail był lub jest wyłączony? Nigdy nie należy niczego przyjmować za pewnik. Właściwe sprawdzanie polecenia rsh lub ssh Zbyt wiele skryptów sprawdza kod zwracany przez polecenie rsh/ssh, lecz już nie kod wygenerowany przez te polecenia na zdalnym komputerze. Czasami warto spróbować wykonać jedno z poniższych poleceń. $ rsh zdalny_komputer operacja_do_zrealizowania ; echo $? $ ssh zdalny_komputer operacja_do_zrealizowania ; echo $?
Łańcuch zdalny_komputer identyfikuje komputer, z którym można się połączyć za pomocą polecenia rsh lub ssh, a operacja_do_zrealizowania — polecenie niedostępne na tym hoście. Okaże się, że wykonane polecenie nie uda się na zdalnym komputerze, lecz program rsh lub ssh zwróci kod 0, oznaczający pomyślne zrealizowanie operacji. Wynika to stąd, że polecenie rsh lub ssh powiodło się, niezależnie od tego, czy wykonane przez nie polecenie było udane, czy nie. Właśnie z tego powodu wymagane jest użycie składni podobnej do poniższej (w miejsce programu rsh można też zastosować ssh). rsh apollo "ls -l /tmp/* ; echo \$?>/tmp/ls.success" SUCCESS='rsh apollo cat /tmp/ls.success ; rm /tmp/ls.success' if [ $SUCCESS -eq 0 ] ; then # wszystko zadziałało echo "Wszystko zadziałało." else echo "Coś poszło nie tak!" fi
Powyższa składnia zwróci kod zdalnego polecenia, a nie tylko polecenia rsh lub ssh. Przedstawiona składnia nie zadziała w przypadku narzędzia csh, ponieważ nie pozwala ono na przekierowywanie wyjścia. Jeden ze sposobów poradzenia sobie z tym problemem polega na utworzeniu niewielkiego skryptu, który można będzie skopiować za pomocą programu rcp. Skrypt może wywoływać program /bin/sh, aby użytkownik miał pewność, że używa tej powłoki. Uzyskanie tabeli zawartości z woluminu archiwizacyjnego Powody, aby zawsze ponownie odczytywać woluminy archiwizacyjne, są dwa. Pierwszy jest taki, że postępując w ten sposób, można najlepiej sprawdzić poprawność działania kopii zapasowej (uproszczenie rzeczywistego procesu odtwarzania danych). Drugim powodem jest to, że tabele zawartości można zapisać w pliku i użyć go podczas procesu odtwarzania, aby sprawdzić, który wolumin zawiera szukany plik. Najlepszą metodą sprawdzenia, czy wolumin narzędzia dump jest nienaruszony, jest wyświetlenie tabeli zawartości z włączoną opcją szczegółowej informacji, posortowanie według numeru i-węzła i odtworzenie ostatniego pliku. W efekcie jest wczytywany cały wolumin i uzyskuje się pewność, że kopie zapasowe narzędzia dump są nienaruszone aż do ostatniego pliku zapisanego na taśmie.
Funkcje godne sprawdzen a
|
115
Archiwizowanie i odtwarzanie danych za pomocą narzędzia cpio cpio jest narzędziem o dużych możliwościach. W przeciwieństwie do programu dump operuje na poziomie plików. Dlatego radzi sobie ze zmieniającymi się systemami plików trochę lepiej niż program dump. Jednak podczas archiwizowania plików narzędzie cpio modyfikuje ich czas dostępu (wartość atime). Choć narzędzie oferuje opcję resetującą wartość atime, powoduje ona zmianę wartości ctime. Jeśli nie używa się wersji GNU narzędzia cpio, jedną z jego największych zalet jest zgodność z różnymi systemami operacyjnymi. Ponadto program cpio wymaga określenia plików, które zostaną mu przekazane za pośrednictwem standardowego wejścia. Powoduje to, że program ten różni się trochę od innych narzędzi archiwizujących. Korzystanie z narzędzia cpio jest bardziej pracochłonne niż z programu dump. Chodzi o to, że trzeba wiedzieć trochę więcej na temat działania narzędzia cpio, jeśli zamierza się stosować je do regularnego sporządzania systemowych kopii zapasowych. Trzeba znać odpowiedzi na następujące pytania: • Jak używać programu find razem z cpio do tworzenia pełnych i przyrostowych kopii za-
pasowych systemu plików, bez modyfikowania czasu dostępu plików (wartość atime)? • Jakie argumenty dają najlepsze wyniki? • Jak za pomocą polecenia rsh lub ssh przesłać kopię zapasową narzędzia cpio do zdalnego
napędu archiwizującego? • Jak uzyskać tabelę zawartości woluminu? • Jak obsługiwać napęd taśmowy i odtwarzać dane z kopii zapasowej utworzonej przy
użyciu programu cpio? W przypadku narzędzia cpio dobre jest to, że zwykle jego nazwa nie zmienia się (duża zaleta w porównaniu z programem dump!). Użytkownicy systemu MacOS muszą pamiętać o stosowaniu wbudowanego narzędzia cpio, jeśli korzystają z wersji systemu nowszej niż 10.4. W przeciwnym razie trzeba użyć narzędzia ditto, gdy wymagany jest format programu cpio.
Najpierw Czytelnik zapozna się z podstawową składnią programu cpio, a następnie z kilkoma przykładowymi poleceniami. Składnia narzędzia cpio w przypadku archiwizowania danych jest następująca: cpio -o [aBcv]
Składnia narzędzia cpio w przypadku odtwarzania danych jest następująca: cpio -i [Btv] [wzorce]
Oto przykładowe polecenia tworzące pełną kopię zapasową katalogu /home i zapisujące ją na lokalnym napędzie taśmowym: $ cd /home $ touch level.0.cpio.timestamp
116
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Choć polecenie touch jest opcjonalne, umożliwia sporządzanie przyrostowych kopii zapasowych. $ find . -print|cpio -oacvB > urządzenie
Oczywiście urządzeniem w powyższym poleceniu może też być lokalny plik, jeśli dane archiwizuje się na nośniku optycznym. Polecenia tworzą na lokalnym napędzie taśmowym przyrostową kopię zapasową katalogu /home. $ cd /home $ touch level.1.cpio.timestamp $ find . -newer level.0.cpio.timestamp -print \|cpio -oacvB > urządzenie
Polecenia tworzą na zdalnym napędzie taśmowym pełną kopię zapasową katalogu /home. $ cd /home $ find . -print|cpio -oacvB \|(rsh zdalny_host dd of=urządzenie bs=5120)
Oto bardziej bezpieczna metoda, wykorzystująca program ssh: $ find . -print|cpio -oacvB \|(ssh zdalny_host dd of=urządzenie bs=5120)
Składnia narzędzia cpio podczas archiwizowania danych Polecenie cpio pobiera swoją listę plików ze standardowego wejścia (stdin) i domyślnie przesyła strumień danych do standardowego wyjścia (stdout). W celu zapewnienia listy plików przeznaczonych do archiwizacji należy podjąć odpowiednie działania. Oto one: • Zastosowanie programu ls lub find (należy na przykład wykonać polecenie ls | cpio -oacvB). • Utworzenie pliku dołączeń, a następnie przesłanie go do standardowego wejścia (stdin)
narzędzia cpio (przykładowo należy zastosować polecenie cat /tmp/include | cpio -oacvB lub cpio -oacvB
|
117
pełną kopię zapasową, korzystając z polecenia find (na przykład find . -print, wyświetlającego całą zawartość katalogu lub systemu plików). Gdy nadejdzie pora na wykonanie kopii zapasowej poziomu 1, należy utworzyć plik /home1/level.1.cpio.timestamp i ponownie użyć polecenia find (na przykład find . -newer level.0.cpio.timestamp, szukającego plików nowszych od pliku /home1/level.0.cpio.timestamp). Plik /home1/level.1.cpio.timestamp może następnie posłużyć do sporządzenia kopii zapasowej poziomu 2 za pomocą polecenia find szukającego plików nowszych od tego pliku. Stosując taką metodę, można wygenerować wybraną liczbę poziomów kopii zapasowych.
Opcje polecenia cpio Można wyróżnić sześć opcji, które powinny być użyte podczas wykonywania regularnych kopii zapasowych za pomocą narzędzia cpio. Pierwszych pięć opcji zwykle jest podawanych razem (-oacvB), natomiast szósta zazwyczaj jest określana oddzielnie (na przykład -C 5120). Warto zauważyć, że opcje -B i -C wzajemnie się wykluczają. Nie można ich stosować jednocześnie. • o — określa, że powinna zostać utworzona kopia zapasowa; • a — resetuje wartość atime przed rozpoczęciem archiwizowania; • c — nakazuje programowi cpio użycie formatu nagłówka ASCII; • v — uaktywnia tryb szczegółowych informacji; • B, C — umożliwiają określenie rozmiaru bloku;
Ponadto można zidentyfikować urządzenie lub plik, do których program cpio może wysyłać swoje dane wyjściowe zamiast do standardowego wyjścia stdout. Wszystkie z powyższych opcji (i nie tylko te) są dostępne w wersji GNU programu cpio. Wersja ta oferuje również możliwość zastosowania zdalnych urządzeń.
Jeśli to możliwe, należy korzystać z wersji GNU narzędzia cpio! Wersja GNU programu cpio oferuje wiele funkcji. Są trzy bardzo dobre powody, dla których warto z niej korzystać (jeśli tylko jest to możliwe): • Wersja narzędzia cpio wbudowana w system nie jest zbyt przenośna, nawet jeśli w doku-
mentacji jest stwierdzone inaczej. Jeśli utworzy się kopię zapasową za pomocą wersji GNU programu cpio, zawsze będzie można ją odczytać, pod warunkiem że w systemie jest dostępna taka wersja narzędzia cpio (niezależnie od rodzaju platformy). • Przenośny format ASCII też ma ograniczenia. Przykładowo nie radzi sobie z systemem
plików mającym więcej niż 65 536 i-węzłów. Ograniczenia tego jest pozbawiony format nagłówka newc dostępny w przypadku wersji GNU programu cpio. • Tak jak program dump wersja GNU narzędzia cpio obsługuje zdalne urządzenia! Jeśli tylko
nie ma problemu z zastosowaniem uwierzytelniania bazującego na programie rsh, trzeba jedynie wykonać następujące polecenie: $ -0 zdalny_host:/nazwa_urządzenia
Wersja GNU narzędzia cpio jest dostępna pod adresem http://www.gnu.org.
118
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Określanie trybu wyjściowego (o) Opcja o reprezentuje jeden z trzech trybów narzędzia cpio (o, i i p) i służy do tworzenia kopii zapasowych. Opcja jest podawana jako pierwsza w grupie kilku argumentów polecenia cpio.
Przywracanie czasów dostępu (a) Jedną z różnic między narzędziami dump i cpio jest to, że pierwsze archiwizuje dane bezpośrednio na urządzeniu dyskowym, natomiast drugie za pośrednictwem systemu plików. A zatem gdy program cpio odczytuje plik w celu jego archiwizacji, zmienia czas dostępu (wartość atime). Administratorzy systemów zwykle używają tej wartości, aby sprawdzić, kiedy użytkownik po raz ostatni korzystał z pliku. Pliki, które od dłuższego czasu nie były używane, zwykle są usuwane z komputera w ramach procesu czyszczenia. Jeśli program archiwizujący zmienia czas dostępu pliku, wygląda to tak, jakby wszystkie pliki były przetwarzane każdej nocy. Opcja a narzędzia cpio pozwala przywrócić oryginalną wartość atime. Przywracanie czasów dostępu powoduje modyfikację wartości ctime. Może to wygenerować ostrzeżenia dotyczące włamań, jeśli pod tym względem dokładnie monitoruje się system.
Określanie formatu ASCII (c) Gdy program cpio archiwizuje dane, może je przesyłać do urządzenia archiwizującego, używając kilku formatów nagłówka. Formaty te mogą być w dużym stopniu zależne od platformy i w związku z tym być mało przenośne między systemami. Najbardziej przenośny format (jednak nie całkowicie) to ASCII. Opcja c nakazuje programowi cpio zastosowanie tego formatu. Jak wspomniano w ramce „Jeśli to możliwe, należy korzystać z wersji GNU narzędzia cpio!”, format ASCII może nie być tak przenośny, jak można by pomyśleć. Jeśli naprawdę przenośność jest istotną kwestią, pod uwagę powinno się wziąć użycie wersji GNU narzędzia cpio. Jeżeli nie jest to możliwe, powinno się spróbować przenieść pliki narzędzia cpio między różnymi wersjami systemu Unix, z których się korzysta. Przynajmniej będzie wiadomo, na czym się stoi. W każdym razie użycie opcji c jest nieszkodliwe.
Żądanie wyświetlania szczegółowych informacji (v) Opcja v powoduje, że narzędzie cpio kieruje listę archiwizowanych plików do stderr. Faktyczne dane kopii zapasowej narzędzia trafiają do standardowego wyjścia stdout (archiwizowane dane zawsze są kierowane do standardowego wyjścia, jeśli używana wersja programu cpio nie obsługuje opcji -0, umożliwiającej określenie wyjściowego pliku lub urządzenia).
Określanie współczynnika bloków o wartości 5120 (B) Opcja B po prostu nakazuje programowi cpio przesyłanie swoich danych do standardowego wyjścia stdout w postaci bloków o rozmiarze 5120, a nie domyślnym rozmiarze 512. Może to być pomocne w przyspieszeniu procesu archiwizowania. Jednak taki rozmiar ani trochę nie jest bliski wartościom współczynnika bloków preferowanym przez wiele nowoczesnych napędów archiwizujących. W związku z tym powinno się wstawić niżej przedstawioną opcję C, jeśli tylko jest dostępna w systemie. Te dwie opcje wzajemnie się wykluczają.
Arch w zowan e odtwarzan e danych za pomocą narzędz a cp o
|
119
Określanie rozmiaru bloku I/O (C) Opcja C wymaga argumentu i pozwala określić rzeczywisty rozmiar bloku. Jeśli używa się systemu AIX, wartość opcji jest wartością współczynnika bloków pomnożonego przez minimalny rozmiar bloku, wynoszący 512. Większość innych odmian systemu Unix pozwala na podanie wartości w bajtach3. W każdym razie dla opcji C można ustawić dość dużą wartość, dzięki czemu program cpio będzie znacznie lepiej współpracował z nowszymi napędami archiwizującymi. Należy powtórzyć, że opcja ta wyklucza się z opcją B i zwykle jest podawana oddzielnie wraz ze swoim argumentem. Oto przykład: $ find . -print|cpio -oacv -C 129024 >urządzenie
Określanie wyjściowego urządzenia lub pliku (0) Niektóre wersje narzędzia cpio umożliwiają użycie argumentu -0 urządzenie, który powoduje przesłanie danych wyjściowych do urządzenia (opcja nie zawsze jest dostępna). Jednakże wszystkie odmiany programu cpio domyślnie wysyłają archiwizowane dane do standardowego wyjścia stdout. Aby sobie uprościć sprawę, nie trzeba stosować opcji -0 nawet wtedy, gdy jest dostępna. W celu określenia urządzenia archiwizującego wystarczy przekierować standardowe wyjście stdout do pliku lub urządzenia. Metoda ta zawsze się sprawdza, niezależnie od używanej wersji systemu Unix.
Archiwizowanie danych na zdalnym urządzeniu (potokowanie do programu rsh lub ssh) Wersja narzędzia cpio wbudowana w system nie obsługuje automatycznie zdalnych urządzeń tak jak program dump (inaczej jest w przypadku wersji GNU narzędzia cpio). A zatem aby dane zarchiwizować na zdalnym napędzie, w miejsce łańcucha >urządzenie trzeba wstawić potok do polecenia rsh lub ssh. $ find . -print|cpio -oacv \ | rsh zdalny_system dd of=urządzenie bs=5k
Oto bardziej bezpieczna wersja polecenia: $ find . -print|cpio -oacv \ | ssh zdalny_system dd of=urządzenie bs=5k
Warto zauważyć, że dane są potokowane do programu dd uruchamianego na zdalnym komputerze. Ponieważ plikiem wejściowym jest standardowe wejście stdin, trzeba jedynie określić plik wyjściowy (of=) i rozmiar bloku. Konieczne jest podanie rozmiaru bloku równego 5 kB, ze względu na to, że może być odczytany przez dowolną wersję narzędzia cpio.
Odtwarzanie za pomocą programu cpio Dla programu cpio obowiązują te same reguły co w przypadku dowolnego polecenia restore. Mam nadzieję, że Czytelnik nie ma w ręku woluminu narzędzia cpio zawierającego bardzo ważną systemową kopię zapasową i nigdy wcześniej nie odtwarzał danych za pomocą tego programu. Trzeba pamiętać, aby wielokrotnie testować i ćwiczyć wykonywanie operacji! Choć 3
Tym razem dziwny okazał się system Unix firmy HP! Nie oferuje podobnej metody ustawiania rozmiaru bloku, a ponadto opcja -C służy do czegoś zupełnie innego, a mianowicie do stosowania punktów kontrolnych, które nie mają nic wspólnego ze współczynnikiem bloków (punkty kontrolne nie są złym pomysłem, ale czy nie można było przypisać im innej litery opcji?).
120
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
jasno wyraziłem własną opinię, nie ma powodu do obaw. Co prawda odtwarzanie danych z woluminu narzędzia cpio nie jest trudne, jednak jest z tym związanych kilka wyzwań, z którymi można mieć do czynienia podczas próby odczytania woluminu programu cpio. W poniższym podpunkcie przyjęto, że dla Czytelnika wolumin utworzony przy użyciu narzędzia cpio nie jest tajemnicą i wie on, jaki zastosował rozmiar bloku. W przeciwnym razie należy zapoznać się z zawartością podrozdziału „Jak odczytać ten wolumin?” z rozdziału 23.
Różne wersje narzędzia cpio To, że wiadomo, w jakim formacie narzędzia cpio zapisano wolumin archiwizacyjny, nie oznacza jeszcze, że będzie można go z łatwością odczytać. Wynika to stąd, że choć większość wersji programu cpio ma właśnie taką nazwę, nie zawsze generują identyczny format. Nawet nagłówek ASCII mający na celu zapewnienie przenośności nie jest rozpoznawany przez wszystkie platformy. Jeżeli po prostu chce się sprawdzić, czy wolumin można odczytać, należy spróbować wykonać proste polecenie cpio -itv < urządzenie. Jeśli zadziała — świetnie! W przeciwnym razie można zobaczyć błędy podobne do następujących: Not a cpio file, bad header
lub Impossible header type
Wersja GNU programu cpio pozwoli zaoszczędzić wiele godzin. Jeśli Czytelnik nią dysponuje, może pominąć resztę niniejszego punktu. Oto cytat z dokumentacji wersji GNU narzędzia cpio: „Domyślnie program cpio tworzy pliki kopii zapasowych w formacie binarnym, aby zachować zgodność ze starszymi wersjami narzędzia. Gdy wyodrębnia się dane z kopii zapasowej, program cpio automatycznie rozpoznaje typ pliku kopii i może wczytywać pliki kopii utworzonych w systemach z innym uporządkowaniem bajtów”.
Problemy z uporządkowaniem bajtów Jeśli wolumin odczytuje się na platformie różniącej się od tej, na której go zapisano, może wystąpić problem z uporządkowaniem bajtów. W efekcie prawdopodobnie pojawi się pierwszy z dwóch wyżej wymienionych błędów. Opcje: b, s i S narzędzia cpio są po to, aby łatwiej było radzić sobie z problemami z uporządkowaniem bajtów. $ # $ # $ #
cpio -itbv < urządzenie Odwrócenie kolejności bajtów w obrębie każdego słowa. cpio -itsv < urządzenie Odwrócenie kolejności bajtów w obrębie każdego półsłowa. cpio -itSv < urządzenie Zamiana półsłowa w obrębie każdego słowa.
Choć odwrócenie kolejności bajtów może umożliwić odczytanie nagłówka narzędzia cpio, może spowodować, że odtworzone pliki staną się bezużyteczne. Jeżeli przy tworzeniu woluminu nie użyto opcji c, najlepiej będzie odtworzyć jego zawartość w systemie z takim samym uporządkowaniem bajtów (w celu uzyskania dodatkowych informacji na temat uporządkowania bajtów należy zapoznać się z podrozdziałem „Jak odczytać ten wolumin?” z rozdziału 23.).
Arch w zowan e odtwarzan e danych za pomocą narzędz a cp o
|
121
Niepoprawny typ nagłówka Jeśli nie wystąpił problem z uporządkowaniem bajtów, oznacza to, że dane kopii zapasowej narzędzia cpio mogły zostać zapisane przy użyciu innego typu nagłówka. Niektóre wersje narzędzia cpio mogą automatycznie wykryć część nagłówków, lecz nie wszystkie. Część wersji programu cpio jest w stanie zidentyfikować automatycznie tylko jeden typ nagłówka. Może być konieczne poeksperymentowanie z różnymi nagłówkami, aby stwierdzić, którego użyto podczas zapisywania woluminu. Jeśli ma się do czynienia z takim problemem, prawdopodobnie pojawił się komunikat o błędzie Impossible header type (również w tym przypadku wersja GNU narzędzia cpio może być w stanie wykryć automatycznie dowolny typ nagłówka). Należy spróbować wykonać następujące polecenia: cpio -ictv < urządzenie Należy spróbować odczytać dane wejściowe w formacie ASCII. cpio -itv -H nagłówek < urządzenie Należy spróbować odczytać dane z użyciem nagłówka podanego za opcją H.
$ # $ #
W miejsce wartości nagłówek można wstawić łańcuch crc, tar, ustar, odc itp. Należy zajrzeć do dokumentacji, ponieważ opcja H nie jest wszędzie dostępna. $ cpio -ictv -H nagłówek < urządzenie # Połączenie opcji formatu ASCII i nagłówka.
Dziwny rozmiar bloku Wolumin narzędzia cpio może być też zapisany z użyciem rozmiaru bloku innego niż oczekiwany przez program. Jeśli rozmiar bloku kopii zapasowej narzędzia cpio wynosi 5 kB, można spróbować nakazać programowi zastosowanie takiego rozmiaru przez dodanie opcji B do wszystkich wcześniej podanych poleceń (cpio -itBv). Jeżeli rozmiar bloku nie jest równy 5 kB, aby program cpio zastosował taki rozmiar, na końcu polecenia należy wstawić opcję -C rozmiar_bloku (cpio -itv -C 5120).
Czy wykonać pełne czy częściowe odtwarzanie danych, a może tylko wczytać tabelę zawartości? Po stwierdzeniu, że można odczytać wolumin narzędzia cpio, do wyboru będzie kilka operacji: • odtworzenie zawartości kopii do bieżącego katalogu lub systemu plików; • odtworzenie plików zgodnych z podanym wzorcem (wzorcem mogą być dane wynikowe
polecenia); • wykonanie jednej z powyższych operacji w ramach interaktywnego procesu zmieniania
nazw plików; • wczytanie tabeli zawartości.
Opcje narzędzia cpio stosowane podczas odtwarzania Zanim wykona się dowolną z wyżej przedstawionych czynności, należy zapoznać się z kilkoma opcjami odtwarzania danych z woluminu narzędzia cpio. Wiele spośród tych opcji jest takich samych co w przypadku tworzenia woluminu programu cpio. To takie opcje, jak B (pozwala ustawić blok o rozmiarze 5 kB), c (umożliwia odczytanie nagłówka ASCII) i v (uaktywnia tryb wyświetlania szczegółowych informacji). Ponadto dostępne są następujące opcje:
122
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
• i — rozpoczyna łańcuch opcji odtwarzania i nakazuje narzędziu cpio włączenie trybu
wejściowego; • t — jeśli za opcją i znajduje się opcja t, program cpio generuje tabelę zawartości. Opcja t nie
powoduje odtwarzania żadnych danych z woluminu. • k — nakazuje programowi cpio podjęcie próby pominięcia niepoprawnych danych wo-
luminu4;
• d — sprawia, że w razie potrzeby program cpio tworzy katalogi; • m — nakazuje narzędziu cpio odtworzenie dla plików oryginalnych czasów modyfikacji
z chwili, gdy były archiwizowane. Jeśli nie użyje się tej opcji, domyślnie program cpio dla odtwarzanego pliku jako czas modyfikacji ustawi czas odtworzenia. Warto zauważyć, że w tym przypadku domyślne działanie programu cpio jest przeciwieństwem domyślnej operacji wykonywanej przez narzędzie tar.
• u — nakazuje programowi cpio bezwarunkowe nadpisanie wszystkich plików; •
* wzorzec* — odtwarza pliki zgodne z wzorcem; * wzorzec* — powoduje odtworzenie wszystkich plików z wyjątkiem tych, które są zgodne ze wzorcem;
• f
• r — nakazuje narzędziu cpio przeprowadzenie interaktywnego procesu zmiany nazw plików.
Jeśli pliki są odtwarzane, użytkownik w trakcie trwania operacji jest proszony o zmianę nazwy każdego pliku. Jeżeli użytkownik wstawi pustą wartość, plik nie zostanie odtworzony.
Informowanie narzędzia cpio o urządzeniu, którego ma użyć W przeciwieństwie do programu tar lub dump narzędzie cpio nie pobiera jako argumentu nazwy urządzenia archiwizującego5. Dane narzędziu cpio trzeba przekazać za pośrednictwem standardowego wejścia stdin. Można to zrobić, używając programu dd lub cat. $ dd if=urządzenie bs=rozmiar_bloku | cpio -opcje
Alternatywnie można po prostu przekierować standardowe wejście stdin, tak aby program cpio odczytywał dane z urządzenia. $ cpio -opcje < urządzenie
4
Choć opcja ta jest również oferowana przez wersję GNU narzędzia cpio w celu zachowania zgodności ze starszymi skryptami powłoki, w rzeczywistości jest ignorowana. Wersja GNU programu cpio zawsze próbuje pomijać niepoprawne fragmenty taśmy. A zatem jeśli korzysta się z programu gcpio, można zrezygnować z opcji k. Niektóre inne wersje narzędzia cpio w ogóle nie mają tej opcji.
5
Będzie tak, jeśli nie postanowi się zastosować opcji -I obsługiwanej przez niektóre wersje narzędzia cpio. Trzeba w tym miejscu kolejny raz przypomnieć, że w książce skoncentrowano się na opcjach, które można wykorzystać niemal wszędzie.
Arch w zowan e odtwarzan e danych za pomocą narzędz a cp o
|
123
Przykłady odtwarzania danych przy użyciu narzędzia cpio Na tym etapie jedyną kwestią jest to, jakie są wymagane opcje. Najprościej poradzić sobie z tym przez prezentację przykładowych poleceń demonstrujących operacje, które można wykonać na woluminie narzędzia cpio. W tych poleceniach umieszczono kilka opcji, które nie są obligatoryjne. Choć nie są wymagane, wiele z nich ułatwia operację lub sprawia, że przebiega bardziej stabilnie. Ponieważ część opcji może nie być przydatna w przypadku określonego zastosowania, można bez obaw z nich zrezygnować.
Generowanie listy plików woluminu narzędzia cpio Poniższe polecenie odczytuje wolumin narzędzia cpio w blokach liczących 5120 bajtów (opcja B), podczas odczytu nagłówka używa formatu ASCII (opcja c), w miarę możliwości pomija niepoprawne fragmenty woluminu (opcja k) i wyświetla jedynie tabelę zawartości (opcja t) w trybie szczegółowej informacji (opcja v), z uwzględnieniem stylów listy (ls -l). $ cpio -iBcktv < urządzenie
Przeprowadzanie procesu odtwarzania całego systemu plików Poniższe polecenie odczytuje wolumin narzędzia cpio w blokach liczących 5120 bajtów (opcja B), podczas odczytu nagłówka używa formatu ASCII (opcja c) i w razie potrzeby tworzy katalogi (opcja d). Gdy to możliwe, polecenie pomija niepoprawne fragmenty woluminu (opcja k), przywraca oryginalny czas modyfikacji pliku (opcja m), bezwarunkowo nadpisuje pliki (opcja u) i generuje listę nazw plików odtwarzanych po wczytaniu. $ cpio -iBcdkmuv < urządzenie
Oczywiście można zrobić to samo bez bezwarunkowego nadpisywania plików (opcja u). $ cpio -iBcdkmv < urządzenie
Odtwarzanie danych zgodnych ze wzorcem W celu odtworzenia plików zgodnych z określonym wzorcem wystarczy w wierszu polecenia podać szukane wzorce. $ cpio -iBcdkmuv "wzorzec1" "wzorzec2" "wzorzec3" < urządzenie
Wzorzec używa znaków wieloznacznych nazw plików, lecz nie wyrażeń regularnych6. Znaki wieloznaczne nazw plików funkcjonują podobnie jak znaki zastosowane w wierszu poleceń (na przykład *ome* dopasowuje zarówno nazwę home1, jak i rome). Program cpio jest jedynym wbudowanym narzędziem odtwarzającym dane, które obsługuje w ten sposób znaki wieloznaczne. Jeśli na przykład zamierza się odtworzyć wszystkie pliki znajdujące się w katalogu domowym (/home1/jnowak), należy wykonać następujące polecenie: $ cpio -iBcdkmuv "*jnowak*"
6
Czytelnik może dowiedzieć się więcej na temat wyrażeń regularnych, niż mógłby sobie wyobrazić, z książki Wyrażenia regularne napisanej przez Jeffreya Friedla (wydawnictwo Helion), którą gorąco polecam. Zrozumienie, czym są wyrażenia regularne i do czego służą, jest wartościowym doświadczeniem, pozwalającym znacznie bardziej owocnie korzystać z takich narzędzi, jak grep, sed, awk i vi.
124
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Zastosowanie wzorca w powyższej postaci spowoduje użycie rozwinięcia nazwy dla plików znajdujących się w kopii zapasowej. Jeśli wzorca nie umieści się w znakach cudzysłowu, powłoka rozwinie znaki wieloznaczne i program cpio uzyska listę nazw plików istniejących w systemie i zgodnych ze wzorcem *jnowak*. Jeżeli usunie się część plików lub przejdzie do innego katalogu, wyniki nie będą zgodne z oczekiwanymi!
Aby odtworzyć wszystkie pliki z wyjątkiem pasujących do określonego wzorca, należy zastosować opcję f i podać wzorce wykluczające. $ cpio -iBcfdkmuv "wzorzec1" "wzorzec2" "wzorzec3" < urządzenie
Interaktywny proces zmiany nazw plików Choć poniżej podano takie samo polecenie jak we wcześniejszym podpunkcie „Odtwarzanie danych zgodnych ze wzorcem”, prosi ono użytkownika o wykonanie interaktywnego procesu (opcja r) zmiany nazwy odtwarzanych plików. $ cpio -iBcdkmruv < urządzenie
Choć poniżej zamieszczono identyczne polecenie jak we wcześniejszym podpunkcie „Przeprowadzanie procesu odtwarzania całego systemu plików”, prosi ono użytkownika o wykonanie interaktywnego procesu (opcja r) zmiany nazwy wszystkich odtwarzanych plików. $ cpio -iBcdkmruv "wzorzec" < urządzenie
Inne przydatne opcje b, s i S
Opcje te służą do zamieniania miejscami bajtów, gdy występują problemy z uporządkowaniem bajtów. Z opcji należy korzystać w ostateczności, ponieważ do tej pory nie widziałem, żeby zakończyło się to zupełnym sukcesem. Jest jedna sytuacja, w której użycie opcji może okazać się przydatne. Ma ona miejsce wtedy, gdy wolumin utworzony na komputerze z formatem Little Endian próbuje się odczytać przy wykorzystaniu systemu z formatem zapisu danych Big Endian (w celu uzyskania dodatkowych informacji należy zajrzeć do podrozdziału „Jak odczytać ten wolumin?” z rozdziału 23.). Osoba wykonująca kopię zapasową za pomocą narzędzia cpio nie zastosowała opcji -c. W efekcie jedyną możliwością odczytania woluminu jest zamiana bajtów miejscami. $ dd if=urządzenie bs=10240 conv=swab | cpio -opcje
Później okazuje się, że słowa zawarte w kopii zapasowej mają kolejność odwrotną do wymaganej. W związku z tym uzyskano odtworzone pliki, których nie można odczytać. Przypuszczalnie podczas odtwarzania danych program cpio mógł zamienić słowa miejscami. Warto zauważyć, że do zwykłego polecenia cpio dodano opcję b. $ dd if=urządzenie bs=10240 conv=swab | cpio -iBcdkmubv < urządzenie
Użycie opcji b odpowiada jednoczesnemu zastosowaniu opcji s i S. Problem polega na tym, że wszystkie operacje zamiany bajtów miejscami zachodzą, gdy program dd lub cpio nie zna formatu pliku. Co będzie, gdy spodziewane 8-bajtowe słowa nie będą wcale 8-bajtowe? Co się stanie, gdy słowa te będą 10-bajtowe? Nie spotkałem nikogo, komu do końca udało się skorzystać z tych opcji. A zatem jeśli Czytelnik będzie miał więcej szczęścia, niech mi wyśle wiadomość pocztową!
Arch w zowan e odtwarzan e danych za pomocą narzędz a cp o
|
125
6
Opcja pozwala odczytać archiwa szóstej edycji systemu Unix. Z opcji należy skorzystać, aby odczytać naprawdę stare kopie zapasowe narzędzia cpio.
Odtwarzanie danych do innego katalogu Jeśli woluminy archiwizacyjne utworzono przy użyciu względnych ścieżek, nie stanowi to problemu. Wystarczy za pomocą polecenia cd przejść do katalogu, w którym mają się znaleźć odtwarzane dane, a następnie wykonać polecenia cpio. Jeżeli nie wiadomo, czy wolumin zapisano z uwzględnieniem względnych ścieżek, należy wykonać polecenie cpio -itv < urządzenie i poszukać ścieżek plików. Jeśli rozpoczynają się od znaku /, oznacza to, że wolumin utworzono z zastosowaniem bezwzględnych ścieżek. W tym przypadku można zrobić jedną z dwóch rzeczy: Użycie dowiązania symbolicznego Jeśli korzysta się z systemu Unix, powinno być dostępne polecenie chroot. Jeżeli używa się platformy innej niż uniksowa lub nie jest dostępne polecenie chroot, trzeba będzie być bardziej kreatywnym. Gdy dane trzeba odtworzyć do innego katalogu i kopię zapasową utworzono przy użyciu bezwzględnych ścieżek, można zdefiniować dowiązanie symboliczne między katalogami /home2 i /home1 (ln -s /home2 /home1). W ten sposób wszystkie pliki, które mają trafić do katalogu /home1, w rzeczywistości znajdą się w katalogu /home2. Coś takiego zadziała tylko wtedy, gdy w systemie nie podłączono katalogu /home1. Jeśli taki katalog już istnieje, trzeba go odłączyć. Oczywiście, jest to niepożądana sytuacja, dlatego też woluminy archiwizacyjne powinno się zapisywać z zastosowaniem względnych ścieżek. Zastosowanie wersji GNU narzędzia cpio Naprawdę jest to najlepsze rozwiązanie. Wersja GNU programu cpio ma opcję „żadnych bezwzględnych ścieżek”, która z wszystkich bezwzględnych ścieżek usuwa znak / i odtwarza pliki ze ścieżką względną w stosunku do bieżącego katalogu.
Użycie funkcji narzędzia cpio kopiującej katalogi Jeśli trzeba przenieść katalog z jednego miejsca w drugie, można spróbować użyć tej rzadko stosowanej funkcji narzędzia cpio. W tym celu należy wykonać następujące polecenie: $ cd stary_katalog ; find . -print | cpio -padlmuv nowy_katalog
Polecenie przenosi stary_katalog w miejsce nowego_katalogu, resetuje czasy dostępu (opcja a), w razie potrzeby tworzy katalogi (opcja d), w miarę możliwości łączy pliki (opcja l), przywraca oryginalne czasy modyfikacji (opcja m), bezwarunkowo nadpisuje wszystkie pliki (opcja u) i wyświetla szczegółowe informacje na temat kopiowanych plików (opcja v). Niektóre wersje systemu Unix mają też opcję -L, która powoduje, że program cpio uwzględnia dowiązania symboliczne, kopiując zamiast samych dowiązań katalogi i pliki, na które wskazują. Jeśli użyje się tej opcji, trzeba się upewnić, że polecenie find przekazujące programowi cpio plik korzysta z opcji -follow. Jeżeli tak nie będzie, uzyska się nieprzewidywalne rezultaty.
Gdyby skompilować listę wszystkich opcji dostępnych w przypadku każdej platformy uniksowej, byłaby bardzo długa. Zależnie od platformy może istnieć mnóstwo innych przydatnych opcji, które sprawiają, że narzędzie cpio jest jeszcze bardziej pożyteczne. Trzeba też wspomnieć 126
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
o kilku dodatkowych funkcjach wersji GNU narzędzia cpio. Warto zapoznać się z dokumentacją dołączoną do posiadanej wersji programu cpio. Trzeba być świadomym tego, że jeśli zastosuje się dowolną z opcji mających wpływ na sposób tworzenia kopii zapasowej przez program cpio, może zmniejszyć się jej przenośność.
Archiwizowanie i odtwarzanie danych za pomocą narzędzia tar tar jest najbardziej popularnym narzędziem archiwizującym omawianym w niniejszym rozdziale. Wiele spośród plików pobieranych z internetu ma postać zwykłych lub skompresowanych plików tar. Jedno godne uwagi ograniczenie narzędzia tar jest takie, że zawsze miało problemy z wyjątkowo długimi ścieżkami. Choć samo narzędzie tar nie jest zwykle wykorzystywane do codziennych operacji archiwizowania i odtwarzania danych, jego wersja GNU często jest używana przez inne programy open source, takie jak Amanda (rozdział 4.). Jak wspomniano, wbudowana wersja programu tar nie zachowuje czasów dostępu archiwizowanych plików. Jeśli jest to istotna kwestia, należy korzystać z wersji GNU narzędzia tar, która umożliwia pozostawienie czasu dostępu bez zmian.
Składnia polecenia tar w przypadku archiwizowania danych Podstawowe polecenie tar wygląda tak: $ tar [cx]vf urządzenie wzorzec
Przyjrzyjmy się kilku przykładowym poleceniom. W celu utworzenia kopii zapasowej katalogu o nazwie wzorzec należy wykonać poniższe polecenie. $ tar cvf urządzenie wzorzec
Aby zrobić to samo, lecz przy współczynniku bloków o wartości 20, należy zastosować następujące polecenie: $ tar cvbf 20 urządzenie wzorzec
Aby dodatkowo narzędzie tar sprawdzało zapisywane dane (opcja dostępna tylko w wersji GNU programu tar)7, należy użyć poniższego polecenia. $ gtar cvWbf 20 urządzenie wzorzec
Aby utworzyć kopię zapasową wszystkich plików i katalogów w bieżącym katalogu, których nazwy zaczynają się od litery a, należy wykonać następujące polecenie: $ tar cvf urządzenie a*
Jeśli korzysta się z wersji 10.4 systemu Mac OS lub nowszej, trzeba pamiętać, aby użyć narzędzia tar wbudowanego w system. W przypadku starszych wersji systemu konieczne będzie zastosowanie narzędzia hfstar. 7
Jest to kolejny powód, dla którego powinno się korzystać z narzędzia gtar, gdy regularnie sporządza się systemowe kopie zapasowe.
Arch w zowan e odtwarzan e danych za pomocą narzędz a tar
|
127
Opcje polecenia tar Narzędzie tar ma dwie wielkie zalety. Pierwszą jest poziom uzyskanej akceptacji, drugą — naprawdę krótka lista opcji. Oto one: c
Opcja nakazuje programowi tar utworzenie archiwum (kopii zapasowej). v
Opcja uaktywnia tryb narzędzia tar, w którym są wyświetlane szczegółowe informacje. Program pokazuje nazwę i rozmiar każdego archiwizowanego pliku. W
Opcja dostępna wyłącznie w wersji GNU narzędzia tar nakazuje mu podjęcie próby sprawdzenia plików po ich umieszczeniu w kopii zapasowej. b współczynnik_bloków
Opcja nakazuje narzędziu tar odczytywanie i zapisywanie w blokach o rozmiarze n bajtów, gdzie n jest wartością użytego współczynnika bloków pomnożonego przez minimalny rozmiar bloku (dla określonego systemu operacyjnego). Choć zwykle wartość ta wynosi 512, może być to 1024. Wynikowa wartość, nazywana rozmiarem bloku, może zawierać się w przedziale od 512 do 10 240. Blok o rozmiarze 10 240 normalnie wskazywałby na współczynnik bloków wynoszący 20, ponieważ 20 pomnożone przez 512 daje 10 240. Jeśli nie określi się wartości opcji b, zostanie użyta domyślna. Choć zazwyczaj wartość ta wynosi 20, może być nawet równa 1.
f urządzenie
Opcja nakazuje programowi tar zapisywanie danych na urządzeniu określonym za pomocą argumentu urządzenie, a nie domyślnym napędzie taśmowym używanej platformy. Urządzeniem może być plik na dysku, nośnik optyczny, napęd taśmowy lub standardowe wyjście (stdout). Jeśli korzysta się z wersji GNU narzędzia tar, urządzeniem może być też napęd taśmowy zdalnego komputera (należy zapoznać się z poniższą ramką). Aby przesłać dane do standardowego wyjścia stdout, w miejsce nazwy urządzenia należy wstawić znak - (nie jest to możliwe w przypadku wszystkich platform).
wzorzec
Argument ten generuje listę dołączeń narzędzia tar. Ponieważ argument bazuje na składni rozwinięcia nazwy pliku, aby zarchiwizować wszystko, czego nazwa rozpoczyna się od litery a, jako argument należy wstawić a*. W miejsce argumentu można wstawić dowolną nazwę pliku lub katalogu. W efekcie zostanie zarchiwizowane wszystko, co znajduje się w tym katalogu. Choć wersja GNU narzędzia tar może odczytać kopię zapasową utworzoną za pomocą dowolnej innej wersji programu, odwrotna sytuacja niekoniecznie jest możliwa. Niektóre wbudowane wersje programu tar nie są w stanie odczytać kopii zapasowych sporządzonych przy użyciu wersji GNU narzędzia.
Wyświetlanie listy plików standardowego wejścia Podobnie do programu cpio większość wersji narzędzia tar nie pozwala na generowanie listy plików znajdujących się w standardowym wejściu, które mają być zarchiwizowane. Jednak wersja GNU narzędzia tar dzięki opcji -T oferuje taką możliwość. Opcja ta pozwala określić 128
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Jeśli to możliwe, należy korzystać z wersji GNU narzędzia tar Wersja GNU narzędzia tar jest wyjątkowo popularna. Poza możliwością odczytu kopii zapasowej utworzonej przez dowolną inną wersję programu tar zapewnia wiele innych funkcji. Oto kilka z najpopularniejszych rozszerzeń: • Opcja -d, wykorzystując narzędzie diff, dokonuje porównania kopii zapasowej i systemu
plików. Polega to na odczytaniu taśmy i porównaniu jej zawartości z plikami wchodzącymi w skład systemu plików. Zgłaszane są wszelkie różnice.
• Opcja -a resetuje czasy dostępu (wartość atime). • Opcja -F uruchamia skrypt po osiągnięciu przez narzędzie tar końca woluminu. Opcja może
być użyta do automatycznego wymieniania woluminów za pomocą zmieniarki nośników. • Opcje -Z i -z automatycznie przetwarzają kopię zapasową odpowiednio za pomocą pro-
gramu compress lub gzip. • Opcja -f obsługuje nazwy zdalnych urządzeń. • Domyślnie wersja GNU narzędzia tar usuwa znak / z bezwzględnych ścieżek podczas two-
rzenia lub odczytywania kopii zapasowej (można temu zapobiec, używając opcji -p). • Niektórzy preferują styl argumentów oferowany przez wersję GNU programu tar. Zamiast
polecenia tar cvf można zastosować polecenie tar -create -verbose -file.
Wersja GNU narzędzia tar jest dostępna pod adresem http://www.gnu.org.
plik zawierający listę plików przeznaczonych do archiwizacji. Jeśli chce się podać nazwy plików do zarchiwizowania za pośrednictwem standardowego wejścia, należy zastosować wersję GNU narzędzia tar i wstawić znak - jako plik dołączeń. Zwykle znak ten nakazuje programowi tar sprawdzenie standardowego wejścia zamiast podanej nazwy pliku. Załóżmy, że postanowiono z poziomu katalogu /home/jnowak uruchomić program find i zarchiwizować wszystkie znalezione tam pliki. # cd /home/jnowak ; find . -print | tar cvf /dev/rmt/0cbn -T -
Powyższe polecenie spowoduje, że narzędzie tar otrzyma wyniki działania programu find w postaci listy plików, które należy uwzględnić w kopii zapasowej. W tabeli 3.2 wymieniono wbudowane wersje narzędzia tar obsługujące listę dołączeń. Tabela 3.2. Wersje programu tar obsługujące listę dołączeń Wersja programu tar
Opcja
AX
-L
DG UX SunOS Sola is
-I
F eeBSD Linux GNU tar
-T
Składnia narzędzia tar w przypadku odtwarzania danych Kopię zapasową narzędzia tar można bardzo łatwo odczytać. Jeśli nawet podczas tworzenia takiej kopii zastosowano współczynnik bloków, w czasie odtwarzania danych nie będzie potrzebny. Narzędzie tar automatycznie się tym zajmuje (czy może czytając to, Czytelnik pomyślał:
Arch w zowan e odtwarzan e danych za pomocą narzędz a tar
|
129
„Jak cudownie…”?). Aby odczytać kopię zapasową utworzoną za pomocą programu tar, należy wykonać jedno z poniższych poleceń. $ tar xvf urządzenie
lub $ tar xvf urządzenie wzorzec
Opcja x nakazuje programowi tar przeprowadzenie operacji wyodrębniania (odtwarzania) danych z kopii zapasowej. Argumenty: v, f i urządzenie działają tak samo jak w przypadku tworzenia kopii zapasowej.
Odtwarzanie wybranych elementów kopii zapasowej Podczas procesu odtwarzania można określić nazwy plików, które mają być uwzględnione. W tym celu za nazwą urządzenia należy podać jedną lub więcej ścieżek. Jednak ważne jest, aby zwrócić uwagę, że ścieżka musi być idealnie zgodna ze ścieżką zawartą w kopii zapasowej programu tar. Gdy tak nie będzie, dane nie zostaną odtworzone. W przeciwieństwie do narzędzia cpio, w przypadku programu tar nie są obsługiwane znaki wieloznaczne. Jeśli jednak poda się nazwę katalogu, zarchiwizowana zostanie cała jego zawartość. Trzeba pamiętać o tym, że podana nazwa katalogu musi być całkowicie zgodna z nazwą katalogu zawartego w kopii. Rozważmy następujący przykład. Istnieje podkatalog home i za pomocą narzędzia tar tworzymy dla niego kopię zapasową o nazwie plik.tar. W tym celu można wykonać polecenie tar cvf plik.tar home lub tar cvf plik.tar ./home. Przyjrzymy się, jak to wpływa na to, co trzeba zrobić, aby odtworzyć dane. tar cvf home.tar ./home ./home/ OK ./home/plik OK ./home/plik.2 OK
$ a a a
Jeśli dane zarchiwizuje się z zastosowaniem ścieżki ./home, trzeba je odtwarzać z uwzględnieniem tej samej ścieżki. $ tar xvf home.tar home tar: blocksize = 5 $ tar xvf home.tar ./home tar: blocksize = 5 x ./home, 0 bytes, 0 tape blocks x ./home/plik, 0 bytes, 0 tape blocks x ./home/plik.2, 0 bytes, 0 tape blocks
W poniższym poleceniu nazwę archiwizowanego katalogu home podano jako wzorzec. tar cvf home.tar home home/ OK home/plik OK home/plik.2 OK
$ a a a
Warto zauważyć, że jeśli dane zarchiwizuje się z zastosowaniem wzorca home, trzeba je odtwarzać z uwzględnieniem tego samego wzorca. Wzorzec ./home nie zadziała. $ tar xvf home.tar ./home tar: blocksize = 5 $ tar xvf home.tar home tar: blocksize = 5 x home, 0 bytes, 0 tape blocks x home/plik, 0 bytes, 0 tape blocks x home/plik.2, 0 bytes, 0 tape blocks
130
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Jeżeli użytkownik nie zna nazwy pliku, który zamierza odtworzyć, i nie chce mu się odtwarzać całej kopii zapasowej, może utworzyć tabelę zawartości i poszukać w niej tej nazwy. Wykonując poniższe polecenie, musi najpierw wygenerować tabelę zawartości kopii zapasowej. tar tf urządzenie > jakiś_plik
Jeśli operację taką przeprowadzi się dla kopii zapasowej z powyższego przykładu, uzyska się plik z następującą tabelą zawartości: home/ home/plik home/plik.2
Jeżeli zna się nazwę pliku, na przykład plik, można go zlokalizować za pomocą programu grep. # grep plik jakiś_plik home/ home/plik home/plik.2
W takim przypadku powinno się następnie wykonać następujące polecenie: $ tar xvf urządzenie home/plik
Sztuczka powodująca, że narzędzie tar używa znaków wieloznacznych podczas procesu odtwarzania Istnieje zabieg sprawdzający się zwykle w przypadku taśmy, a także plików .tar zapisanych na dysku. Sztuczka polega na jednoczesnym wykonaniu dwóch poleceń tar. $ tar xvf urządzenie `tar tf urządzenie | grep 'wzorzec'`
Jeśli sztuczki tej użyje się w przypadku napędu taśmowego, trzeba sprawdzić, czy oferuje on możliwość przewijania. W przeciwnym razie sztuczka nie zadziała! Można też dodać polecenie sleep, aby ustalić czas przewinięcia taśmy. $ tar xvf urządzenie `tar tf urządzenie | grep 'wzorzec' ; sleep 60`
Zmiana podczas odtwarzania danych właściciela, uprawnień i atrybutów Choć domyślne działania narzędzia tar mogą być inne w różnych systemach, większość jego wersji umożliwia zastosowanie podczas odtwarzania trzech opcji: m
Standardowo odtwarzane pliki zachowują czasy modyfikacji, które miały w czasie ich archiwizowania. Opcja zmienia czas modyfikacji na czas odtwarzania. W przypadku narzędzia cpio jest odwrotnie. Domyślny sposób traktowania czasów modyfikacji przez narzędzie tar podczas procesu odtwarzania jest przeciwieństwem postępowania programu cpio.
o
Opcja nakazuje narzędziu tar, aby użytkownika ustanowił właścicielem wszystkich odtwarzanych plików. Jest to domyślne postępowanie w przypadku innych użytkowników niż root. Jeśli nie użyje się tej opcji, pliki wyodrębnione przez użytkownika root będą miały identyfikatory użytkowników i grup zapisane w pliku kopii zapasowej .tar.
Arch w zowan e odtwarzan e danych za pomocą narzędz a tar
|
131
p
Domyślnie narzędzie tar nie odtwarza wszystkich atrybutów plików. Uprawnienia plików są określane przy użyciu bieżącej konfiguracji umask zamiast uprawnień oryginalnych plików. Ponadto dla wszystkich plików, których użytkownik nie jest właścicielem, nie jest odtwarzany bit setuid i bit „lepkości” (sticky bit). Opcja nakazuje narzędziu tar zastosowanie uprawnień oryginalnych plików, włącznie z wszystkimi specjalnymi atrybutami, takimi jak bit setuid (aby ustawić dla plików innych użytkowników bity setuid i „lepkości”, trzeba mieć uprawnienia użytkownika root).
Kilka innych fajnych rzeczy na temat programu tar Narzędzie tar oferuje wiele opcji. Powinno się przeczytać dokumentację, aby zapoznać się z nimi wszystkimi, ponieważ mogą okazać się bardzo przydatne.
Szukanie wszystkiego, co jest zawarte w katalogu Czasami rzeczy znajdujące się poniżej katalogu nie są tym, na co wyglądają. Jeśli przed usunięciem katalogu tworzy się jego „ostatnie archiwum”, można chcieć sprawdzić wszystkie istniejące dowiązania symboliczne. Do tego służy opcja -h. Trzeba zadbać o to, aby miejsca dostępnego na taśmie było dużo!
Zastosowanie narzędzia tar do przenoszenia katalogu Jak wspomniano, program cpio oferuje wbudowane polecenie służące do przenoszenia katalogów. Problem polega na tym, że wiele osób nie pamięta składni tego polecenia, gdy trzeba z niego skorzystać. Jednak katalog można przenieść również za pomocą narzędzia tar. W tym celu najpierw przy użyciu polecenia cd należy przejść o jeden poziom powyżej katalogu, który zamierza się przenieść. $ cd stary_katalog ; cd ..
W dalszej kolejności za pomocą narzędzia tar i zestawu nawiasów należy utworzyć powłokę podrzędną, która rozpakuje zawartość katalogu w nowym miejscu (warto zwrócić uwagę na użycie opcji p, aby zapewnić, że program tar utworzy nowy katalog z tymi samymi uprawnieniami co stary). $ tar cf - stary_katalog | (cd nowy_katalog ; cd .. ; tar xvpf -)
Znak - widoczny na końcu polecenia tar cf nakazuje przesłanie jego danych do standardowego wyjścia stdout (pominięto opcję v, aby uniknąć dwukrotnego wyświetlania nazw plików). Z kolei znak - wstawiony na końcu polecenia tar xvf nakazuje mu poszukanie danych w standardowym wejściu stdin. Przez umieszczenie w nawiasach poleceń cd nowy_katalog ; tar xvpf - utworzono powłokę podrzędną, aby zawartość katalogu stary_katalog została wyodrębniona w katalogu nowy_katalog. Choć składnia polecenia może wydać się trochę złożona, cechuje się dużą przenośnością. Polecenie będzie trochę krótsze, gdy zastosuje się następujący zapis: $ cd nadrzędny_katalog ; tar cf - stary_katalog | (cd nadrzędny_katalog_nowego_katalogu ; tar xvpf -)
132
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Miałem do czynienia z osobami próbującymi przenieść katalog domowy użytkownika przez przejście do tego katalogu przy użyciu polecenia cd, a następnie utworzenie pliku .tar z wykorzystaniem wzorca *. Problem w tym przypadku polega na tym, że nie zostaną uwzględnione pliki z kropką w nazwie, takie jak .profile, .cshrc i .emacs. Słyszałem, jak jedna z tych osób powiedziała: „Muszę użyć .*, a nie *!”. Trzeba zawsze pamiętać, że z wyrażeniem .* jest zgodny łańcuch .. (nadrzędny katalog). Oznacza to, że kopia zapasowa uwzględni też nadrzędny katalog. Właśnie z tego powodu znacznie prostsze będzie przejście o jeden poziom wyżej w hierarchii katalogów, a następnie zarchiwizowanie za pomocą narzędzia tar zawartości katalogu. Można też utworzyć plik kopii zapasowej z zastosowaniem łańcucha ... Preferuję wcześniejszą metodę, ponieważ w jej przypadku są widoczne katalogi, w których znajdują się archiwizowane pliki. W przytoczonym przykładzie łańcuch nadrzędny_katalog identyfikuje katalog nadrzędny w stosunku do katalogu stary_katalog. Z kolei w miejsce łańcucha nadrzędny_katalog_nowego_katalogu należy wstawić nazwę nadrzędnego katalogu nowego katalogu. Jeśli na przykład przeniesiono by katalog /home1/fred do katalogu /home2, w miejsce łańcuchów: nadrzędny_katalog, stary_katalog i nadrzędny_ katalog_nowego_katalogu należałoby wstawić odpowiednio katalogi: /home1, fred i /home2. Trzeba wiedzieć, co się podaje. Jeden z problemów związanych z narzędziem tar polega na tym, że zbyt często wykonuje się polecenie tar cvf. W efekcie pewnego dnia trzeba będzie zastosować polecenie tar xvf i zamiast opcji x omyłkowo wpisze się c. Można się domyślić, co się wydarzy. Plik archiwum .tar uszkodzi się bezpowrotnie. Jest to jedna z najczęściej poruszanych kwestii na grupach dyskusyjnych — nigdy nie było dobrej odpowiedzi.
Odtwarzanie do alternatywnej lokalizacji Jeśli podczas tworzenia plików archiwum narzędzia tar zastosuje się względne ścieżki, odtworzenie danych do alternatywnej lokalizacji będzie bardzo łatwe. Wystarczy zmienić ścieżkę katalogów na coś innego niż ścieżka oryginalnego punktu podłączenia (na przykład /home1), a następnie rozpocząć proces odtwarzania. W razie potrzeby program tar utworzy katalogi. Jeżeli nie utworzono pliku archiwum programu tar z użyciem względnych ścieżek, w celu usunięcia znaków / można skorzystać z wersji GNU narzędzia tar.
W części rozdziału poświęconej programowi cpio można przeczytać na temat względnych ścieżek i powodów, dla których są tak ważne.
Archiwizowanie i odtwarzanie danych za pomocą narzędzia dd Program dd jest niemal taki sam jak reszta narzędzi archiwizujących. Jednakże do pewnych zastosowań nadaje się w szczególny sposób.
Arch w zowan e odtwarzan e danych za pomocą narzędz a dd
|
133
Podstawowe opcje programu dd # dd if=urządzenie of=urządzenie bs=rozmiar_bloku
Powyższe opcje są stosowane prawie zawsze podczas uruchamiania programu dd. Opcje programu omówiono w dalszej części rozdziału.
Określanie pliku wejściowego Argument if= pozwala określić plik wejściowy lub plik, z którego program dd skopiuje dane. Archiwizowany może być plik lub niesformatowana partycja (na przykład dd if=/dev/dsk/ c0t0d0s0 lub dd if=/home/plik). Jeśli swoich danych program ma poszukać w standardowym wejściu stdin, nie trzeba używać tego argumentu.
Określanie pliku wyjściowego Argument of= pozwala określić plik wyjściowy lub plik, w którym program dd umieści dane. Może to być plik na dysku, nośnik optyczny, inna niesformatowana partycja lub napęd taśmowy8 (na przykład dd of=/kopia/plik lub dd of=/dev/rmt/0n). Jeżeli dane wysyła się do standardowego wyjścia stdout, nie trzeba używać tego argumentu.
Ustalanie rozmiaru bloku Argument bs= określa rozmiar bloku lub ilość danych, które zostaną przesłane w ramach jednej operacji wejścia-wyjścia. Choć wartość argumentu standardowo jest wyrażona w bajtach, w przypadku większości wersji programu dd może być też określona w kilobajtach, przez dodanie litery K na końcu liczby (na przykład 10 K). Rozmiar bloku różni się od współczynnika bloków używanego przez narzędzia dump i tar i mnożonego przez stałą wartość nazywaną minimalnym rozmiarem bloku. Pomnożenie współczynnika bloków wynoszącego 20 przez minimalny rozmiar bloku o wartości 512 daje rzeczywisty rozmiar bloku równy 10 240 bajtów lub 10 kilobajtów. Warto zauważyć, że w przypadku odczytywania lub zapisywania danych za pośrednictwem potoku program dd domyślnie używa rozmiaru bloku równego 1. Zmiana rozmiaru bloku nie ma wpływu na sposób fizycznego zapisywania danych na urządzeniu dyskowym, takim jak dysk lub nośnik optyczny. Używając bloków o dużym rozmiarze, po prostu poprawia się transfer danych. Jednak w przypadku zapisywania danych na urządzeniu taśmowym każdy blok staje się rekordem. Każdy rekord jest rozdzielony przerwą międzyrekordową. Gdy taśmę zapisze się z zastosowaniem bloku o określonym rozmiarze, musi zostać odczytana z uwzględnieniem takiego rozmiaru bloku lub jego wielokrotności (jeśli na przykład na taśmie zapisze się dane z wykorzystaniem bloku o rozmiarze 1024, podczas odczytu trzeba będzie użyć identycznego rozmiaru lub wielokrotności liczby 1024, czyli wartości 2048 lub 10 240). Dotyczy to jedynie urządzeń taśmowych, a nie dyskowych.
Niezależne określanie rozmiaru bloków wejściowych i wyjściowych Ustalając rozmiar bloku za pomocą opcji bs=, określa się zarówno rozmiar bloku wejściowego, jak i wyjściowego. Czasami może być konieczne zastosowanie różnych rozmiarów dla tych dwóch typów bloków. Umożliwiają to opcje ibs= i obs=. Przykładowo, aby odczytać taśmę 8
Oczywiście napęd taśmowy jest kolejnym niesformatowanym urządzeniem.
134
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
z użyciem jednego rozmiaru bloku i zapisać ją z użyciem innego, należy wykonać polecenie podobne do następującego: # dd if=/dev/rmt/0 ibs=10k of=/dev/rmt/1 obs=64k
Określanie liczby odczytywanych rekordów Opcja count=n informuje program dd o liczbie odczytywanych rekordów (bloków). Za jej pomocą można na przykład odczytać kilka pierwszych bloków pliku lub taśmy, aby sprawdzić, jakiego typu dane przechowują (więcej informacji zamieszczono poniżej). Korzystając z tej opcji, można również nakazać programowi dd, żeby podał, jaki rozmiar bloku zastosował podczas zapisywania taśmy.
Użycie programu dd do kopiowania zawartości pliku lub niesformatowanego urządzenia Programu dd można użyć w roli narzędzia archiwizującego, ponieważ umożliwia kopiowanie w inne miejsce bitów pliku lub niesformatowanego urządzenia. Można nawet w ramach potoku przekazać programowi compress strumień bitów i uzyskać kopię danych w skompresowanej postaci (narzędzia: dump, tar i cpio nie oferują takiej możliwości, natomiast wersja GNU programu tar — tak). Najlepszym przykładem zastosowania programu dd w roli narzędzia archiwizującego jest skrypt oraback.sh (więcej na jego temat zamieszczono w rozdziale 16.) bazy danych Oracle, wykonujący gorącą kopię zapasową. Ponieważ baza danych Oracle do przechowywania danych może używać zarówno niesformatowanych partycji, jak i plików, skrypt nie jest w stanie przewidzieć, które polecenie zastosować. Jednak program dd obsługuje niesformatowane partycje i pliki!
Użycie programu dd do konwertowania danych Program dd może też posłużyć do konwersji danych z jednego formatu na drugi w ramach jednej operacji.
Konwertowanie danych przekazywanych innemu poleceniu Operacja taka jest wykonywana przy użyciu bloków wejściowych i wyjściowych o różnych rozmiarach (za pomocą opcji ibs= i obs=). Jeśli polecenie takie jak restore jest w stanie odczytać bloki tylko o określonych rozmiarach i dysponuje się woluminem zapisanym z użyciem bloku o innym rozmiarze, wolumin można odczytać za pomocą programu dd, a następnie wyniki za pośrednictwem potoku przekazać narzędziu restore.
Konwertowanie danych mających nieprawidłowy format Choć można pomyśleć, że program dd jest kopiarką bitów, potrafi też przetwarzać format danych. Program umożliwia przeprowadzenie konwersji między różnymi zestawami znaków, małymi i dużymi znakami, a także rekordami o stałej i zmiennej długości. conv=ascii
Konwertuje z formatu EBCDIC na format ASCII.
Arch w zowan e odtwarzan e danych za pomocą narzędz a dd
|
135
conv=ebcdic
Konwertuje z formatu ASCII na format EBCDIC. conv=ibm
Konwertuje z formatu ASCII na format EBCDIC, używając tabeli konwersji IBM. conv=lcase
Mapuje znaki alfabetu US ASCII na ich odpowiedniki stosujące małe znaki.
conv=ucase
Mapuje znaki alfabetu US ASCII na ich odpowiedniki stosujące duże znaki.
conv=swab
Zamienia miejscami każdą parę bajtów. Opcja może być użyta do odczytu woluminu zapisanego z zastosowaniem innego uporządkowania bajtów.
conv=noerror
Po wystąpieniu błędu nie przerywa przetwarzania.
conv=sync
Uzupełnia każdy blok wejściowy o jego rozmiar.
conv=notrunc
Nie obcina na wyjściu istniejącego pliku.
conv=block
Zamienia rekord wejściowy na rekord o stałej długości określonej przez opcję ibs.
conv=unblock
Konwertuje rekordy o stałej długości na rekordy o zmiennej długości.
conv=..., ...
Używa wielu metod konwersji oddzielonych od siebie przecinkami.
Zastosowanie programu dd do określenia rozmiaru bloku na taśmie Operacja ta jest pewnego rodzaju sztuczką. Jeśli nakaże się programowi dd odczytanie jednego bloku danych, a następnie zapisanie go na dysku, można będzie przyjrzeć się rozmiarowi tego bloku, aby stwierdzić, jaki jest rozmiar bloku taśmy. Ponieważ nie jest znany rozmiar bloku, należy najpierw dla posiadanego urządzenia zastosować największy rozmiar bloku obsługiwany przez system operacyjny, który zwykle wynosi 128 lub 256 kB (może być większy). # dd if=urządzenie bs=128k of=/tmp/junk count=1
Polecenie nakazuje programowi dd odczytywanie danych z zastosowaniem bloku o rozmiarze 128 kB do momentu osiągnięcia pierwszej przerwy międzyrekordowej. Jeżeli rozmiar bloku jest mniejszy niż 128 kB, odczyt danych zakończy się przy przerwie. Gdy rozmiar bloku przekracza 128 kB, program dd interpretuje to jako błąd wejścia-wyjścia i generuje komunikat. Wystarczy zwiększyć rozmiar bloku i spróbować ponownie (warto ustawić tym razem rozmiar 256 kB). Proces tworzy plik /tmp/junk, którego wielkość jest równa rozmiarowi bloku na taśmie!
Użycie programu dd do identyfikacji formatu kopii zapasowej To jeszcze jedna sztuczka. W celu utworzenia pliku /tmp/junk należy zastosować to samo polecenie co w poprzednim punkcie, a następnie wykonać następujące polecenie: # file /tmp/junk
136
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Polecenie używa pliku /etc/magic, aby określić typ pliku. Jeśli plik jest archiwum programu tar lub cpio, zwykle uzyska się odpowiednią informację. Jeżeli polecenie nie jest w stanie odgadnąć typu pliku, po prostu zwraca łańcuch data (dane), który nie jest zbytnio przydatny. Innym interesującym zastosowaniem programu dd jest użycie go z narzędziem ssh lub rsh. Trzeba zapoznać się z podrozdziałem „Zastosowanie programu ssh lub rsh w roli kanału między systemami” zamieszczonym na końcu rozdziału.
Zastosowanie narzędzia rsync O narzędziu rsync należy myśleć jak o prostym poleceniu kopiującym dane między systemami. Choć pod względem składni narzędzie to najbardziej przypomina program rcp, w pewnym stopniu można je też przyrównać do polecenia copy systemu Windows. Jednakże narzędzie rsync to coś znacznie więcej niż tylko prosty program kopiujący, ponieważ dodano do niego następujące funkcje: Kopiowanie dowiązań, urządzeń, właścicieli, grup i uprawnień Oznacza to, że narzędzie rsync może poprawnie kopiować wszystko z miejsca źródłowego do docelowego, z uwzględnieniem specjalnych plików i wszystkich odpowiednich uprawnień. Narzędzie potrafi kopiować zarówno dowiązania twarde, jak i symboliczne. Możliwość użycia dowolnej transparentnej zdalnej powłoki, w tym ssh lub rsh Choć obecnie mechanizm uwierzytelniania narzędziu rsync domyślnie zapewnia program ssh, z łatwością można to zmienić przez ustawienie dla zmiennej RSYNC_RSH wartości rsh. Możliwość uruchamiania narzędzia jako uwierzytelnionego lub anonimowego demona (procesu działającego w tle) Oprócz tego, że jest uwierzytelniane za pośrednictwem programów rsh i ssh, narzędzie rsync może działać jako demon w trybie uwierzytelnionym lub anonimowym. Pierwszy tryb zapewnia bezpieczniejszy mechanizm uwierzytelniania, a drugi naprawdę dobrze sprawdza się w przypadku mirroringu. Możliwość użycia zaawansowanych opcji wykluczających Narzędzie rsync wyklucza pliki w taki sam sposób jak wersja GNU programu tar, stosując w tym celu łańcuchy umieszczane w wierszu polecenia lub tworząc plik wykluczeń i podając jego nazwę obok opcji exclude-from. Dodatkowo narzędzie rsync może zostać skonfigurowane tak, aby pomijać te pliki, które zostałyby zignorowane przez system kontroli wersji CVS (Concurrent Versions System). Wysyłanie tylko zmienionych bloków zmodyfikowanych plików Jest to największa różnica między narzędziami rsync i rcp, a także najwspanialsza funkcja pierwszego z nich. Wiele osób nie wie o jej istnieniu. Podczas aktualizowania danych docelowych lokalizacje źródłowe i docelowe dzielą każdy zmieniony plik na bloki i dla każdego z nich przeprowadzają dwa sprawdzenia sum kontrolnych CRC. Przesyłane są tylko te bloki danych, w przypadku których nie są zgodne sumy kontrolne CRC. W ten sposób program rsync może synchronizować często modyfikowane duże pliki za pośrednictwem znacznie mniejszych potoków. Wysyłanie kilku zmienionych plików w postaci jednego dużego pliku Ponieważ narzędzie rsync przeprowadza mnóstwo operacji na pojedynczych plikach w celu skrócenia czasu oczekiwania, może je skumulować w ramach jednego dużego transferu. Zastosowan e narzędz a rsync
|
137
Możliwość usuwania plików Jest to kolejna znacząca różnica między narzędziami rcp i rsync. Program rsync potrafi usuwać pliki z lokalizacji docelowej, których nie ma już w miejscu źródłowym. Wiele osób, włącznie ze mną, tak naprawdę nie pomyślało o programie rsync jak o narzędziu archiwizującym. Jeden z powodów jest taki, że w rzeczywistości jest to narzędzie synchronizujące, a nie archiwizujące. Oznacza to, że bez określonego rodzaju interwencji użytkownika każde kolejne uruchomienie narzędzia rsync spowoduje nadpisanie kopii zapasowej niepoprawną kopią oryginalnych danych lub usunięcie z kopii zapasowej pliku, który usunięto z oryginału. Czyż nie wydaje się, że nie jest to zbyt dobre narzędzie archiwizujące? Jednak nie trzeba włożyć zbyt wiele pracy, żeby narzędzie rsync zyskało na wartości. Jeśli zapisze się poprzednie wersje danych przed nadpisaniem ich przez nowsze wersje lub usunięciem, narzędzie rsync może stać się znakomitym narzędziem archiwizującym. W książce zamieszczono dwa przykłady zastosowania tego programu. W rozdziale 5. omówiono narzędzie BackupPC, a w rozdziale 7. opisano niemal ciągłą ochronę danych przy wykorzystaniu programu rsync i powiązanych narzędzi.
Podstawowa składnia narzędzia rsync Oto podstawowa składnia programu rsync: % rsync miejsce_źródłowe [miejsce_źródłowe ...] miejsce_docelowe
Polecenie kopiuje jeden lub więcej plików lub katalogów źródłowych do docelowego katalogu znajdującego się na tym samym komputerze. % rsync miejsce_źródłowe [miejsce_źródłowe ...] nazwa_użytkownika@nazwa_hosta:miejsce_docelowe
Polecenie kopiuje jeden lub więcej plików lub katalogów źródłowych do docelowego katalogu innego komputera. Uwierzytelnianie odbywa się za pomocą programu rsh lub ssh, gdy dla zmiennej RSYNC_RSH ustawiono wartość ssh. % rsync miejsce_źródłowe [miejsce_źródłowe ...] nazwa_użytkownika@nazwa_hosta::miejsce_docelowe
Ponieważ najczęstszym zastosowaniem narzędzia rsync związanym z archiwizowaniem danych jest transferowanie całego drzewa katalogów między dwoma komputerami, warto przedstawić odpowiedni przykład. Chcemy przenieść katalog /home do katalogu /kopie_zapasowe komputera serwer_kopii_zapasowych. Ponadto zależy nam na zarchiwizowaniu wszystkiego, co znajduje się w katalogu /home (należy użyć opcji rekursywności -r), sporządzeniu kopii zapasowej dowiązań symbolicznych (opcja -l), zachowaniu ich czasów (opcja -t), uprawnień (opcja -p), a także prawa własności (opcja -o) i uprawnień grupowych (opcja -g). Dodatkowo chcemy przenieść wszystkie pliki specjalne (opcja -D). Polecenie będzie wyglądać podobnie do poniższego. % rsync -rlptgoD /home serwer_kopii_zapasowych:/kopie_zapasowe
Na szczęście twórcy narzędzia rsync zdali sobie sprawę z tego, że wymienione opcje bardzo często stosowano do celów archiwizacyjnych. W związku z tym utworzyli opcję -a, która odpowiada zestawowi opcji -rlptgoD. W efekcie poniższe proste polecenie ma takie samo działanie jak poprzednie. % rsync -a /home serwer_kopii_zapasowych:/kopie_zapasowe
138
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Po dodaniu do polecenia opcji szczegółowych informacji (-v) i kompresji (-z) ma ono następującą postać: % rsync -avz /home serwer_kopii_zapasowych:/kopie_zapasowe
Aby synchronizacja rzeczywiście miała miejsce, do polecenia trzeba dodać znacznik usuwania. % rsync -avz --delete /home serwer_kopii_zapasowych:/kopie_zapasowe
Przy każdym uruchomieniu programu rsync zostanie skopiowana cała zawartość katalogu /home do katalogu /kopie_zapasowe/home, z którego zostaną usunięte wszystkie pliki nieobecne w katalogu /home. Trzeba jedynie po stronie docelowej zastosować jakiś mechanizm gromadzenia danych historycznych i uzyska się system archiwizowania! Czytelnik musi przeczytać rozdział 7., poświęcony systemom open source niemal ciągłej ochrony danych, a także rozdział 5., w którym omówiono narzędzie BackupPC i dokładniej wyjaśniono, jak zastosować program rsync do archiwizowania danych.
Kilka modyfikacji Wszystkie powyższe polecenia kopiują zawartość katalogu /home do katalogu /kopie_zapasowe komputera serwer_kopii_zapasowych. Oznacza to, że tworzą katalog /kopie_zapasowe/home. Jeśli zamierza się skopiować zawartość katalogu /home do katalogu /kopie_zapasowe bez tworzenia podkatalogu /home, wystarczy na końcu nazwy źródłowego katalogu wstawić znak /. % rsync -avz /home/ serwer_kopii_zapasowych:/kopie_zapasowe
Polecenie to wykonuje to samo zadanie co poniższe, tylko wymaga mniejszej liczby wciśnięć klawiszy. % rsync -avz /home serwer_kopii_zapasowych:/kopie_zapasowe/home
Domyślnie program rsync przeprowadza proces uwierzytelniania za pomocą narzędzia ssh. Proces może być realizowany przy użyciu program rsh. W tym celu dla zmiennej RSYNC_RSH trzeba ustawić wartość rsh. Ponadto można również nakazać narzędziu rsync, aby nawiązało połączenie z demonem rsync uruchomionym na innym komputerze. Robi się to przez wstawienie za nazwą hosta dwóch dwukropków zamiast jednego. % rsync -avz /home/ serwer_kopii_zapasowych::/kopie_zapasowe
Jeśli demon rsync, z którym nawiązuje się połączenie, wymaga hasła, można je określić za pomocą zmiennej RSYNC_PASSWORD.
Narzędzie rsync w systemie Windows Choć narzędzie rsync jest programem uniksowym, można je uruchomić pod systemem Windows, jeśli zastosuje się emulator systemu Unix, taki jak cygwin. Część zespołu rozwijającego narzędzie rsync wykonała ciężką pracę i stworzyła prekompilowane binaria uwzględniające pliki cygwin1.dll i rsync.exe. Instrukcje dotyczące uruchamiania narzędzia rsync pod systemem Windows, z uwzględnieniem działania w trybie usługi (demona), można znaleźć na głównej stronie internetowej programu, znajdującej się pod adresem http://samba.org/rsync/nt.html.
Zastosowan e narzędz a rsync
|
139
Narzędzie rsync w systemie Mac OS Użycie narzędzia rsync w systemie Mac OS jest dość proste. Trzeba jedynie dodać opcję -E lub -extended-attributes, które nakazują systemowi przeniesienie dodatkowych atrybutów plików. Opcja -E po prostu instruuje system, aby dokonał transferu rozwidleń zasobów (dziwić może jedynie to, że opcja ta została dodana do narzędzia rsync, które przewidziano do przenoszenia bitu wykonywania transferowanego pliku).
Odtwarzanie danych za pomocą narzędzia rsync Odtwarzanie danych przy użyciu programu rsync wygląda tak samo jak archiwizowanie, z tym że w przypadku pierwszego procesu w wierszu polecenia zmienia się kolejność lokalizacji źródłowej i docelowej. Jako źródłową należy podać lokalizację, która normalnie jest docelową. Z kolei jako docelowe miejsce dla danych należy określić lokalizację, która standardowo jest źródłową. To wystarczy do uzyskania polecenia rsync przeprowadzającego proces odtwarzania danych. Użyjmy komputera z wcześniejszego przykładu i odwróćmy kolejność katalogów źródłowych i docelowych. % rsync -avz serwer_kopii_zapasowych:/kopie_zapasowe/home/ /home
Polecenie nakazuje programowi rsync odtworzenie całej zawartości katalogu /kopie_zapasowe/ home komputera serwer_kopii_zapasowych i zapisanie jej w katalogu /home lokalnego serwera. Oczywiście można też odtworzyć pojedynczy plik. % rsync -avz serwer_kopii_zapasowych:/kopie_zapasowe/home/jnowak/podsumowanie.doc /home/jnowak
Prawdziwym wyzwaniem związanym z odtwarzaniem za pomocą programu rsync nie jest jego składnia, lecz monitorowanie tego, które pliki powinny zostać przywrócone i które pliki w rzeczywistości są uszkodzonymi kopiami, do pominięcia w procesie przywracania. Za coś takiego odpowiada używany program archiwizujący. Jeśli zastosowano by narzędzie wykonujące obrazy danych, takie jak omówione w książce, w celu uzyskania wczorajszej wersji pliku po prostu do łańcucha dodałoby się coś w rodzaju dzienna.1. % rsync -avz serwer_kopii_zapasowych:/kopie_zapasowe/dzienna.1/home/jnowak/podsumowanie.doc /home/jnowak
Więcej na temat tworzenia obrazów danych za pomocą narzędzia rsync można znaleźć w rozdziale 7.
Archiwizowanie i odtwarzanie danych przy użyciu narzędzia ditto ditto jest narzędziem systemu Mac OS X służącym do rekursywnego kopiowania. Podobnie do narzędzia tar i cpio program ten może być użyty do tworzenia plików archiwum. Interesujące w przypadku programu ditto jest to, że jest jedynym wbudowanym narzędziem z możliwością tworzenia pełnych kopii zapasowych dla wszystkich wersji systemu Mac OS X. Jest tak od momentu przeniesienia narzędzia z systemu NEXT-STEP, obsługującego funkcje systemu plików HFS+, takie jak rozwidlenia zasobów (więcej na temat systemu plików HFS+ można znaleźć w punkcie „Zróżnicowanie systemów plików systemu Mac OS”, zamieszczonym wcześniej w rozdziale). 140
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Narzędzie ditto może kopiować pliki i katalogi do jednego z trzech typów lokalizacji docelowych: katalogu, pliku archiwum ZIP lub pliku archiwum programu cpio. Narzędzie ditto nie pozwala skopiować danych bezpośrednio na taśmę. Narzędzie to nie używa jeszcze jednego formatu archiwizowania. W związku z tym nie otrzyma się kopii zapasowych w formacie, którego po kilku latach nie da się odczytać.
Składnia narzędzia ditto w przypadku archiwizowania Narzędzie ditto najczęściej jest używane do rekursywnego kopiowania plików i katalogów. $ ditto -V --rsrc lokalizacja_źródłowa... katalog_docelowy
Opcja -V powoduje wyświetlanie wszystkiego, co jest kopiowane przez narzędzie ditto. Opcja --rsrc zapewnia, że są kopiowane atrybuty i rozwidlenia zasobów systemu plików HFS+ (jest to domyślne działanie począwszy od wersji 10.4 systemu Mac OS X). Dodatkowe informacje dotyczące systemu plików HFS+ są przechowywane w formacie AppleDouble, w przypadku którego dane dla pliku nazwa_pliku znajdują się w pliku ._nazwa_pliku. Użycie narzędzia ditto w taki sposób bardzo przypomina zastosowanie polecenia cp -R, z jedną znaczącą różnicą. Załóżmy, że ktoś zamierza sporządzić kopię katalogu. Gdyby wykonał polecenie cp -R źródłowy_katalog docelowy_katalog, zawartość katalogu źródłowy_katalog znalazłaby się w katalogu docelowy_katalog/źródłowy_katalog/. W przypadku polecenia ditto źródłowy_katalog docelowy_katalog zawartość katalogu źródłowy_katalog trafiłaby bezpośrednio do katalogu docelowy_katalog/ (może to być trochę zaskakujące, jeśli się tego nie oczekuje). Ponadto narzędzie ditto tworzy katalog docelowy_katalog/, jeżeli jeszcze nie istnieje. W większości przypadków program ditto sporządza dokładną kopię danych źródłowych. Jednak jest kilka rzeczy, których narzędzie ditto nie skopiuje. Wiąże się to z brakiem następujących informacji: • Nazwane gniazda. Należy zapoznać się z plikami dokumentacji socket(2) i bind(2) (oka-
zuje się, że z jakiegoś powodu nie istnieją w wersji 10.4 systemu Mac OS X, choć występowały w starszych wersjach). Jednakże gniazda powinny być tworzone dynamicznie przez używające ich programy.
• Nazwane potoki (lub kolejki FIFO). Należy zapoznać się z plikiem dokumentacji mkfifo.
Na szczęście sam system Mac OS X nie stosuje żadnych nazwanych potoków.
• Znaczniki BSD. Należy przeczytać plik dokumentacji chflags. System Mac OS X nie usta-
wia tych znaczników dla żadnego pliku.
• Rozszerzone listy kontroli dostępu ACL. Należy zapoznać się z plikami dokumentacji
chmod i fsaclctl. Domyślnie systemy plików nie mają włączonej funkcji obsługi rozszerzonych list kontroli dostępu ACL. Są to oczywiste ograniczenia mechanizmu binarnych plików BOM (Bill-of-Materials) używanego przez narzędzie ditto (należy przeczytać pliki dokumentacji: bom, mkbom i lsbom). Program mkbom również nie stosuje nazwanych gniazd lub potoków, a format plików BOM nie uwzględnia pól dla znaczników BSD lub rozszerzonych list ACL.
Oprócz wykonywania zwykłych kopii plików i katalogów program ditto może skopiować je do pliku archiwum. W celu utworzenia pliku archiwum narzędzia cpio (z opcjonalną kompresją obsługiwaną przez program gzip) należy zastosować następujące polecenie: Arch w zowan e odtwarzan e danych przy użyc u narzędz a d tto
|
141
$ ditto -V --rsrc -c -z katalog_źródłowy docelowy.cpgz
Aby utworzyć plik ZIP, należy wykonać poniższe polecenie. $ ditto -V --rsrc -c -k katalog_źródłowy docelowy.zip
Gdy podczas tworzenia pliku ZIP użyje się znacznika --sequesterRsrc, w katalogu o nazwie __MACOSX zostaną zapisane specjalne dane dotyczące systemu plików HFS+. Narzędzie zgodne z programem PKZIP (inne niż ditto) mogą radzić sobie z tym lepiej niż format AppleDouble. Podczas tworzenia rekursywnych kopii łańcuch katalog_źródłowy jest usuwany ze ścieżek zapisywanych w pliku archiwum. Aby w ścieżkach zachować ten łańcuch, należy użyć znacznika --keepParent. Narzędzie ditto nie pozwala na jedno: selektywne archiwizowanie tylko części zawartości katalogu. Przykładowo nie można zastosować wzorca nazwy pliku lub sporządzać przyrostowych kopii zapasowych. ditto nadaje się wyłącznie do archiwizowania całych drzew katalogowych. Za pomocą narzędzi ssh i dd można wykonywać kopie zapasowe zdalnych systemów w taki sam sposób jak w przypadku programów tar i cpio. Oto przykład: $ ditto -V --rsrc -c -k źródłowy_katalog - | (sh zdalny_host dd of=docelowy.zip)
Warto zauważyć, że w przykładzie narzędzie ditto może przesłać plik archiwum do standardowego wyjścia, a także jako źródło zaakceptować standardowe wejście. Prawdopodobnie funkcjonalność taka może być wykorzystana na potrzeby archiwizowania i odtwarzania danych z taśmy (jeśli są dostępne odpowiednie sterowniki napędu taśmowego). Jednak nie było to testowane.
Opcje polecenia ditto ditto jest bardzo prostym poleceniem o stosunkowo niewielkiej liczbie opcji i zrozumiałej składni argumentów. Oto część opcji, z których można skorzystać (więcej informacji można znaleźć w dokumentacji): -v -V -c
-z -k -X
Wyświetla nazwę każdego kopiowanego źródłowego katalogu. Wyświetla wiersz dla każdego pliku i katalogu kopiowanego przez narzędzie ditto. Zamiast do innego katalogu zawartość źródłowego katalogu jest kopiowana do pliku archiwum. Jeśli nie zastosuje się opcji -k, domyślnie jest to plik archiwum narzędzia cpio. Za pomocą programu gzip jest kompresowany plik archiwum narzędzia cpio. Zamiast pliku archiwum programu cpio jest tworzone skompresowane archiwum ZIP. Zapobiega w czasie kopiowania przekroczeniu przez narzędzie ditto granicy partycji.
--keepParent
Uwzględnia źródłowy katalog w ścieżkach zapisywanych w pliku archiwum.
142
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
--rsrc
Oprócz standardowych uniksowych atrybutów i rozwidleń danych kopiuje atrybuty i rozwidlenia zasobów systemu plików HFS+. Jest to domyślne działanie w przypadku wersji 10.4 systemu Mac OS X i nowszych. Zamiennie można też zastosować opcję --rsrcFork.
--norsrc
Zapobiega kopiowaniu przez narzędzie ditto atrybutów i rozwidleń zasobów systemu plików HFS+. Jest to domyślne działanie w przypadku wersji 10.3 systemu Mac OS X i starszych bądź wersji 10.4 i nowszych, gdy zostanie ustawiona zmienna DITTONORSRC.
--sequesterRsrc
Zapisuje rozwidlenia danych i zasobów systemu plików HFS+ w katalogu o nazwie __MACOSX zamiast przy użyciu formatu AppleDouble.
--arch
W przypadku wykonywania kopii aplikacji obsługującej architektury wieloprocesorowe (dawniej aplikacje takie nazywano grubymi binariami; obecnie firma Apple określa je mianem uniwersalnych) kopiuje tylko elementy określonej architektury. Architekturą może być ppc (procesory PowerPC) lub i386 (procesory Intel; odniesienie do pierwszego układu Intela obsługiwanego przez system NEXTSTEP).
--bom
Kopiuje jedynie pozycje wyszczególnione w konkretnym pliku BOM (można go utworzyć za pomocą polecenia mkbom katalog; więcej informacji można znaleźć w dokumentacji polecenia). Pliki BOM są używane w przypadku pakietów instalatora firmy Apple, a także uprawnień, praw własności i sumy kontrolnej rekordów dla każdej pozycji instalowanej przez pakiet.
Składnia narzędzia ditto w przypadku odtwarzania Zawartość pliku archiwum utworzonego przy użyciu narzędzia ditto jest odtwarzana za pomocą opcji -x (od słowa extract — wyodrębnianie). W celu odtworzenia danych ze skompresowanego archiwum programu cpio należy wykonać następujące polecenie: $ ditto -V --rsrc -x źródłowy.cpgz docelowy_katalog
Katalog docelowy jest tworzony, jeśli jeszcze nie istnieje. Warto zauważyć, że opcja -z nie jest wymagana. Narzędzie ditto automatycznie obsługuje skompresowane pliki programu cpio. Aby odtworzyć dane z archiwum ZIP, należy zastosować poniższe polecenie. $ ditto -V --rsrc -x -k źródłowy.zip docelowy_katalog
Nie ma nic specjalnego w plikach archiwum tworzonych przez narzędzie ditto. Za jego pomocą można wyodrębnić dane z każdego pliku archiwum ZIP lub programu cpio. Jeśli zamierza się odtworzyć tylko wybrane pozycje pliku archiwum, należy użyć bezpośrednio narzędzia cpio lub unzip, ponieważ nie jest możliwe wykonanie tej operacji za pomocą programu ditto.
Wyświetlanie listy plików archiwum W celu wygenerowania listy plików znajdujących się w skompresowanym archiwum cpio należy wykonać następujące polecenie: $ cpio -itvz < zrodlowe.cpgz
Arch w zowan e odtwarzan e danych przy użyc u narzędz a d tto
|
143
Aby wyświetlić pliki zawarte w archiwum ZIP, należy zastosować polecenie: $ unzip -lv zrodlo.zip
Porównanie narzędzi: tar, cpio i dump Kilka lat temu John Pezzano z firmy Hewlett-Packard sporządził dokument porównujący wbudowane produkty archiwizujące. Ponieważ to najlepsze porównanie, z jakim do tej pory się spotkałem, poprosiłem go o zgodę na nieznaczną aktualizację dokumentu w celu uwzględnienia zmian, które zaszły w narzędziach, a także na zamieszczenie go w tej książce. W tabeli 3.3 porównano narzędzia: tar, cpio i dump. Tabela 3.3. Porównanie wbudowanych narzędzi Cecha
tar
cp o
dump
Ba dzo duża (polecenie tar
Wymaga użycia p og amu find do ok eślenia nazw plików
Duża
c pliki)
Radzenie sobie z błędami wejścia wyjścia
B ak własnego ozwiązania T zeba samemu napisać sk ypt
W p zypadku systemu P UX opcja resync powoduje ut atę części danych
Automatycznie są pomijane niepop awne sekcje
A chiwizowanie specjalnych plików
Późniejsze we sje
Tak
Tak
A chiwizowanie na wielu woluminach
Późniejsze we sje
Tak
Tak
A chiwizowanie za poś ednictwem sieci
Zastosowanie wyłącznie na zędzia rsh lub ssh
Zastosowanie wyłącznie na zędzia rsh lub ssh
Tak
Dołączanie plików do kopii zapasowej
Tak (polecenie tar -r)
Nie
Nie
Wiele niezależnych kopii zapasowych na jednej taśmie
Tak
Tak
Tak
Łatwość gene owania listy plików woluminu
Niewielka T zeba p zeszukiwać całą kopię zapasową (polecenie tar t)
Niewielka T zeba p zeszukiwać całą kopię zapasową (polecenie cpio -it)
Duża na początku woluminu znajduje się indeks (polecenie restore -t)
Łatwość i szybkość szukania ok eślonego pliku
Niewielka B ak znaków wieloznacznych T zeba p zeszukiwać ca y wolumin
Ś ednia Dostępne znaki wieloznaczne T zeba p zeszukiwać ca y wolumin
nte aktywność Ba dzo duża łatwość użycia w p zypadku takich poleceń jak cd i ls
P zy ostowe kopie zapasowe
W p zypadku stosowania we sji GNU na zędzia tar można użyć opcji -newer p og amu find
T zeba użyć p og amu find aby zlokalizować nowe i zmodyfikowane pliki
Możliwa p zy ostowa kopia zapasowa wyłącznie całego systemu plików Wiele poziomów
Two zenie listy plików podczas a chiwizowania
tar cvf 2>plik_dziennika
cpio -v 2>plik_dziennika
Tylko po za chiwizowaniu danych za pomocą polecenia
Łatwość u uchamiania
niewiele opcji
restore -t >plik_dziennika (jednak
p og am dump może pokazać w p ocentach postęp p ocesu) A chiwizowanie opa te na innych k yte iach
144
|
Tak (za pomocą we sji GNU na zędzia tar)
P og am find może użyć wielu k yte iów
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
Nie
Tabela 3.3. Porównanie wbudowanych narzędzi — ciąg dalszy Cecha
tar
cp o
dump
P zyw acanie bezwzględnych ścieżek do postaci względnych
Tak (za pomocą we sji GNU na zędzia tar)
Za pomocą polecenia cpio -I lub we sji GNU na zędzia cpio
Ścieżki zawsze są względne w stosunku do bieżącego katalogu oboczego
Możliwość inte aktywności w czasie odtwa zania danych
Tak B ak możliwości w p zypadku polecenia tar -
Dla każdego pliku można ok eślić nową ścieżkę lub nazwę
W t ybie inte aktywnym można wyb ać poszczególne pliki
w
Zgodność
Wiele platfo m
Wiele platfo m z nagłówkiem ASC lecz nie zawsze możliwość p zeniesienia
Możliwość odczytu między kilkoma platfo mami Jednak nie zawsze można na to liczyć
Podstawowe zastosowanie
A chiwizowanie systemu gdy stosuje się we sję GNU na zędzia tar W p zeciwnym azie a chiwizowanie danych poszczególnych użytkowników i p zenoszenie plików między systemami plików
A chiwizowanie systemu i p zenoszenie plików między systemami plików
A chiwizowanie systemu
Efektywność zapisu woluminu
Ś ednia Zwykle występuje og aniczenie do bloków o ozmia ze 10 kB
Ś ednia Choć zazwyczaj występuje og aniczenie tylko do bloków o ozmia ze 5 kB w p zypadku niektó ych systemów ope acyjnych można ok eślić większy ozmia
Wysoka Zwykle można podać maksymalny ozmia bloku obsługiwany p zez u ządzenie
Stosowanie znaków wieloznacznych podczas p ocesu odtwa zania
Nie
Tak
Tylko w t ybie inte aktywnym
Łatwość zaznaczania a chiwizowanych plików znajdujących się w kilku katalogach
Niewielka T zeba ok eślić niezależnie każdy katalog włącznie z podkatalogami
Ś ednia Zastosowanie opcji p og amu find
B ak możliwości P og am a chiwizuje tylko i wyłącznie jeden system plików
Możliwość odtwo zenia plików zawa tych w katalogu p zez ok eślenie tego katalogu
Tak
Nie T zeba użyć ścieżka/∗
Tak
Zat zymanie odczytu taśmy po znalezieniu odtwa zanego pliku
Nie
Nie
P zestaje czytać taśmę od azu po znalezieniu ostatniego pliku
Śledzenie usuwanych plików
Nie
Nie
Jeśli odtwa za się dane z użyciem opcji -r usuwane są pliki któ e usunięto p zed wykonaniem ostatniej p zy ostowej kopii zapasowej
Wydajność systemów plików
Lepsza
Najgo sza (pliki uzyskują statystyki za ówno z p og amu find jak i cpio)
Najlepsza
P awdopodobieństwo tego że plik istnieje w tabeli zawa tości lecz nie w a chiwum
Niskie
Niskie
Ś ednie (ponieważ jako pie wsza jest two zona tabela zawa tości)
Porównan e narzędz : tar, cp o dump
|
145
Choć standardowe narzędzia archiwizujące mogą być niezbyt atrakcyjne, a nawet pozbawione wielu funkcji, po zapoznaniu się z nimi zawsze będzie można z nich skorzystać. Niektóre częściowo wbudowane polecenia (na przykład wersja GNU programów tar i cpio) również są bardzo przydatne, lecz nie zawsze dostępne. A zatem dobra praktyczna znajomość naprawdę wbudowanych narzędzi może okazać się bardzo przydatna w razie kłopotów lub gdy ktoś wręczy nieznany wolumin z pytaniem: „Czy można to odczytać?”.
Zastosowanie programu ssh lub rsh w roli kanału między systemami W niniejszym podrozdziale wyjaśniono, jak użyć narzędzia rsh lub ssh w roli kanału między systemami, zwłaszcza wtedy, gdy jednocześnie zastosuje się program dd i jakieś inne polecenia czytające lub zapisujące dane w standardowym wejściu stdin. Jeśli nawet narzędzie archiwizujące obsługuje zdalne urządzenia (na przykład rdump), zwykle korzysta z mechanizmu uwierzytelniania programu rsh. Jeżeli Czytelnik zrozumie zawartość podrozdziału, będzie mógł użyć narzędzia ssh, które zapewnia większe bezpieczeństwo kopii zapasowych. Większość innych narzędzi archiwizujących potrafi jedynie odczytywać lub zapisywać dane w standardowym wejściu stdin, natomiast program dd może jednocześnie wykonywać obie operacje. To sprawia, że program dd jest bardzo uniwersalnym narzędziem archiwizującym (i jedynym wbudowanym), które może być użyte do przekazywania strumienia danych między dwoma poleceniami lub między komputerem i urządzeniem zdalnego hosta (przy wykorzystaniu narzędzia rsh lub ssh). Odczytanie kopii zapasowej ze zdalnego urządzenia umożliwią narzędzia: restore, tar (wersja GNU) i cpio (wersja GNU), gdy w ich wierszu polecenia jako nazwę urządzenia po prostu wstawi się łańcuch zdalny_host:zdalne_urządzenie. Jednak wbudowane wersje narzędzi tar i cpio nie pozwalają na coś takiego. W ich przypadku wystarczy za pośrednictwem narzędzia rsh lub ssh wykonać polecenie dd na zdalnym komputerze i odczytać zwrócony strumień danych na lokalnym systemie. # rsh zdalny_host "dd if=urządzenie ibs=rozmiar_bloku" | tar xvBf -
Trzeba pamiętać o tym, że podczas odczytu woluminu z taśmy za pomocą programu dd standardowo trzeba określić rozmiar bloku. Jeśli się tego nie zrobi, program zastosuje rozmiar bloku 512, który spowoduje wygenerowanie błędu wejścia-wyjścia, gdy woluminu na taśmie nie zapisano z wykorzystaniem bloku o takiej wielkości. Warto też zwrócić uwagę na znaki cudzysłowu obejmujące zdalne polecenie dd. W przypadku tego polecenia znaki te właściwie są zbędne, ponieważ potok jest przetwarzany na lokalnym systemie. W innych, bardziej złożonych poleceniach, w których potok będzie wykonywany na zdalnym systemie, umieszczenie zdalnego polecenia w znakach cudzysłowu zagwarantuje poprawne działanie (w powyższym poleceniu znaki cudzysłowu jedynie zwiększają czytelność). Zapisywanie kopii zapasowej na zdalnym urządzeniu jest trochę bardziej złożone. Może być konieczne utworzenie powłoki podrzędnej9, w której będą wykonywane polecenia rsh i dd,
9
Nakład pracy będzie różny, ponieważ nie wszystkie wersje systemu Unix wymagają tworzenia powłoki podrzędnej.
146
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
a także przekazanie za pomocą potoku wyniku lokalnie uruchomionego programu archiwizującego. # tar cvf - . \ | (rsh zdalny_host dd of=urządzenie obs=rozmiar_bloku)
Umieszczenie zdalnego polecenia w nawiasach okrągłych powoduje utworzenie powłoki podrzędnej. Warto zauważyć, że trzeba określić rozmiar zdalnego bloku i zachować przy tym ostrożność. Jeśli zamierza się utworzyć wolumin, który będzie mógł być odczytywany przez program tar, trzeba użyć rozmiaru bloku obsługiwanego przez ten program, takiego jak 10 240 (zwykle jest to największy rozmiar bloku, który może być odczytywany lub zapisywany przez narzędzie tar; aby go ustawić, należy określić współczynnik bloków o wartości 20). Jeżeli nie jest możliwe skorzystanie z programu rsh, zamiast niego można użyć narzędzia ssh. Program ten stosuje znacznie bardziej bezpieczny mechanizm uwierzytelniania i umożliwia użycie tego samego typu poleceń co narzędzie rsh przy braku tworzonych przez nie luk w zabezpieczeniach. Jednak w przypadku zastosowania funkcji obsługi zdalnych urządzeń oferowanej przez wersję GNU narzędzi tar i cpio, a także przez program dump, domyślnie jest używany program rsh. Jeśli nie można skorzystać z narzędzia rsh i dostępne jest tylko ssh, w celu zintegrowania narzędzi: dump, tar i cpio z programem ssh można wykonać polecenia podobne do poniższych. Aby odczytać taśmy zdalnych hostów, należy zastosować polecenia: # ssh zdalny_host "dd if=urządzenie bs=rozmiar_bloku" | tar xvBf # ssh zdalny_host "dd if=urządzenie bs=rozmiar_bloku" \ | restore rvf # ssh zdalny_host "dd if=urządzenie bs=rozmiar_bloku" | cpio -itv
W celu utworzenia kopii zapasowych na taśmach zdalnych hostów należy wykonać polecenia: # dump 0bdsf 64 100000 100000 - \ | ssh zdalny_host "dd if=urządzenie bs=64k" # tar cvf - | ssh zdalny_host "dd if=urządzenie bs=10k" # cpio -oacvB | ssh zdalny_host "dd if=urządzenie bs=5k"
Niektóre polecenia zadziałają z programem ssh, jeśli po prostu dla zmiennej środowiskowej rsh ustawi się ścieżkę /usr/bin/ssh. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Zastosowan e programu ssh lub rsh w rol kanału m ędzy systemam
|
147
148
|
Rozdz ał 3. Podstawowe narzędz a do arch w zacj odtwarzan a
ROZDZIAŁ 4.
Amanda
Celem tego rozdziału jest ogólny techniczny przegląd narzędzia Amanda. Po jego przeczytaniu Czytelnik powinien rozumieć działanie programu, czym program różni się od innych narzędzi archiwizujących i w jaki sposób może okazać się pomocny w spełnianiu wymagań dotyczących ochrony danych. Jednak w rozdziale Czytelnik nie jest przytłaczany technicznymi szczegółami, które mogłyby być ściśle związane z określoną konfiguracją lub procedurą archiwizacji. W rozdziale zamieszczono odnośniki do stron internetowych, na których można znaleźć aktualne i łatwe do wykonania instrukcje i szczegóły dotyczące wszystkiego, co trzeba wiedzieć na temat wdrażania narzędzia Amanda w środowisku produkcyjnym. W tworzeniu niniejszego rozdziału brali udział Dmitri Joukovski i Stefan G. Weichinger1. Dmitri od początku lat 90. rozwiązuje problemy związane z archiwizowaniem i odtwarzaniem danych. Mieszka w Dolinie Krzemowej w Kalifornii ze swoją piękną żoną i dziećmi. Stefan uwielbia pracę w środowisku grupy roboczej i kontynuuje związane z tym poszukiwania.
Amanda (Advanced Maryland Automated Network Disk Archiver) jest najbardziej znanym oprogramowaniem archiwizującym open source. Prace projektowe nad narzędziem rozpoczęły się w 1991 r. na University of Maryland. Ich celem była ochrona plików znajdujących się na dużej liczbie stacji roboczych komunikujących się z jednym serwerem archiwizującym. James da Silva był jednym z pierwszych projektantów oprogramowania Amanda. W 1999 r. projekt Amanda zarejestrowano na stronie internetowej SourceForge.net. W ostatnich latach Jean-Louis Martineau z Uniwersytetu w Montrealu pełnił rolę lidera projektu rozwijającego to narzędzieAmanda. Przez lata nad bazowym kodem źródłowym oprogramowania pracowało ponad 250 programistów. Tysiące użytkowników testowało narzędzie i przekazywało swoje uwagi. W efekcie uzyskano stabilny i solidny pakiet. Amanda jest dołączana do każdej większej dystrybucji systemu Linux. W kwietniu 2006 r. z narzędzia Amandakorzystało ponad 20 000 organizacji z całego świata.
1
Tak wielu specjalistów napisało znakomite artykuły poświęcone narzędziu Amanda, że nie da się wymienić wszystkich. Na szczególne wyrazy uznania zasługują: John R. Jackson, Alexandre Oliva, Æleen Frisch i Paul Bijnens, ale jest wiele innych osób, które mają wkład w bogactwo dostępnych materiałów na temat narzędzia Amanda. Wiele z ich pomysłów odegrało dużą rolę podczas pisania tego rozdziału.
149
To był naprawdę dział komputerowy Gdy pracowałem na uniwersytecie, serwer obsługujący pocztę elektroniczną i sesje studentów był zarządzany przez dział komputerowy, który nabył napęd taśmowy i taśmy, a następnie skonfigurował narzędzie tar w celu archiwizowania danych komputera. Serwer padł ofiarą włamania i poważnej awarii. Ponieważ w tamtym czasie byłem zatrudniony w dziale informatycznym uczelni w niepełnym wymiarze godzin jako administrator sieci, zadzwoniłem do działu komputerowego z prośbą o przekazanie mi kopii zapasowych. Usłyszałem, że najbardziej aktualna z kopii znajdowała się na taśmie umieszczonej w napędzie komputera. Gdy spojrzałem na datę, okazało się, że kopia miała już dwa lata. Próbowaliśmy odtworzyć z taśmy wszystkie dane znajdujące się w katalogu /home, lecz nie został on zarchiwizowany. Doszło do całkowitej utraty danych. Od tamtego czasu dział informatyczny przejął kontrolę nad serwerem i stał się jego właścicielem. Wykonaliśmy kopie zapasowe kilka godzin po tym, jak studenci znów zaczęli się logować, i testowaliśmy odtwarzanie danych. Jedyną dobrą rzeczą związaną z utratą zawartości serwera było to, że wreszcie mogliśmy pozbyć się starych kont, które powinny były zostać usunięte. — Scott Boss
Początkowo Amanda była używana w środowisku produkcyjnym przeważnie przez uniwersytety, laboratoria techniczne i działy badawcze. Obecnie, gdy działy informatyczne powszechnie korzystają z Linuksa, narzędzie Amanda można spotkać w wielu miejscach, zwłaszcza tam, gdzie nacisk kładzie się na zastosowanie aplikacji wdrożonych na podstawie platformy LAMP. Przez lata narzędzie Amanda otrzymało od użytkowników wiele nagród. Przykładowo w 2005 r. uzyskało nagrodę Choice Award czasopisma „Linux Journal Readers” w kategorii na ulubiony program archiwizujący. Amanda umożliwia skonfigurowanie pojedynczego głównego serwera archiwizującego dane znajdujące się na wielu hostach z systemami: Linux, Unix, Mac OS X i Windows. Dane mogą być archiwizowane na bardzo wielu różnorodnych urządzeniach dyskowych, taśmowych i optycznych, wykorzystujących biblioteki taśm, automatyczne zmieniarki, optyczne zmieniarki, macierze RAID, urządzenia NAS i wiele innych. Rysunek 4.1 przedstawia typową sieć wykorzystującą narzędzie Amanda. Można przedstawić kilka rzeczywistych przykładów zastosowania oprogramowania Amanda w środowisku produkcyjnym. Pewna firma używa trzech serwerów Amanda z systemem CentOS, znajdujących się w trzech krajach, aby chronić ponad 30 klientów działających pod kontrolą systemów Solaris, Linux i Windows. W czasie pisania tej książki różne wersje narzędzia Amanda były wykorzystywane w środowiskach produkcyjnych od dziewięciu lat. W sumie chronionych jest ponad 500 GB danych i średnio co tydzień przybywa 8 GB. Jedna z organizacji zapisuje kopie zapasowe tylko na dysku, natomiast dwie inne zarówno na dysku, jak i przy wykorzystaniu automatycznych ładowarek LTO. Administratorzy systemów odtwarzają pliki przynajmniej raz w tygodniu, ponieważ użytkownicy omyłkowo usuwają pliki. Kilkakrotnie w ciągu ostatnich lat firma utraciła serwery z powodu awarii dysków twardych i narzędzie Amanda przychodziło z pomocą, umożliwiając przeprowadzenie odtworzenia całkowitej instalacji serwerów. Duży uniwersytet położony w Wielkiej Brytanii posiada dwa serwery Amanda z systemem Fedora Core i ponad 100 klientów, działających pod kontrolą systemów: Linux (Fedora Core, Red Hat Enterprise Linux), Mac OS X i Solaris. Stacje robocze przechowują w sumie więcej niż 2 TB danych. Jeden z serwerów Amanda służy do wykonywania kopii zapasowych baz danych SAP i Oracle zainstalowanych pod systemem Solaris. 150
|
Rozdz ał 4. Amanda
Rysunek 4.1. Typowa sieć z zastosowanym oprogramowaniem Amanda
Firma kinematograficzna zajmująca się produkcją końcową dysponuje trzema serwerami Amanda z systemem Debian zlokalizowanymi w dwóch oddziałach. Serwery chronią 84 klienty z systemami Linux i IRIX, które przechowują 26 TB danych. Firma odtwarza pliki mniej więcej dwa razy w tygodniu na skutek błędów użytkowników. W ciągu trzech lat istnienia środowiska produkcyjnego miały miejsce trzy przypadki całkowitej utraty woluminu, mimo że stosowano macierze RAID. Narzędzie Amanda było w stanie przywrócić zawartość wszystkich trzech woluminów. W rozdziale przytoczono przykłady faktycznych wdrożeń oprogramowania Amanda. Bazując na opiniach wielu użytkowników narzędzia Amanda, stosujących odmienne konfiguracje i mających zróżnicowane doświadczenie w obsłudze oprogramowania, jesteśmy przekonani, że kluczowe powody, dla których Amanda zyskała tak dużą popularność, to m.in.: • Amanda upraszcza życie administratorowi systemu, ponieważ dzięki niej z łatwością może
skonfigurować pojedynczy serwer, aby archiwizował dane wielu sieciowych klientów i zapisywał je na taśmie, dysku lub optycznym systemie magazynującym.
• Amanda jest zoptymalizowana pod kątem umieszczania kopii zapasowych na dysku lub
taśmie. Ponadto umożliwia jednoczesne zapisywanie kopii na taśmie i dysku. Zupełnie takie same dane mogą być udostępnione w trybie online w celu ich szybkiego odtworzenia, a także przechowywane poza firmą na potrzeby odtwarzania po wystąpieniu jakiegoś kataklizmu i długoterminowej retencji. • Ponieważ narzędzie Amanda nie korzysta z własnych sterowników urządzeń, dobrze będzie
z nim współpracować dowolny sprzęt obsługiwany przez system operacyjny. Administrator systemu nie musi podczas aktualizowania narzędzia Amanda martwić się o to, że urządzenie przestanie być obsługiwane. • Amanda używa łatwo dostępnych standardowych narzędzi, takich jak dump i wersja GNU
programu tar. Ponieważ narzędzia takie nie stosują niestandardowych formatów, dane mogą być odtwarzane za ich pomocą, nawet jeśli nie są obsługiwane przez Amandę.
Podsumowan e ważnych funkcj
|
151
• Unikatowy mechanizm planowania narzędzia Amanda optymalizuje poziomy archiwi-
zowania dla różnych klientów w taki sposób, że całkowity czas archiwizowania jest niemal taki sam w przypadku każdej tworzonej kopii zapasowej. Amanda zwalnia administratora systemu z konieczności określania zmienności transferu danych w zarządzanych środowiskach. • Projekt narzędzia Amanda stał się obiektem zainteresowania dla dużej i aktywnej społecz-
ności, powiększającej się każdego dnia. • Całkowity koszt utrzymania technologii archiwizacyjnej bazującej na narzędziu Amanda jest
znacznie niższy niż w przypadku dowolnego rozwiązania korzystającego z komercyjnego oprogramowania archiwizującego. Oprogramowanie Amanda oferuje kody źródłowe i pliki RPM dla najbardziej popularnych wersji systemu Linux. Można je pobrać pod adresem http://www.zmanda.com. Ponadto kod źródłowy jest dostępny na stronie internetowej SourceForge.net (http://sourceforge.net/projects/amanda). Niektóre starsze (lecz stabilne) wersje narzędzia Amanda są dołączane do wszystkich popularnych dystrybucji systemu Linux, takich jak Fedora Core, Red Hat Enterprise Server, Debian, Ubuntu, OpenSUSE i SUSE Linux Enterprise Server (z uwzględnieniem wersji dla serwerów Itanium, IBM p-Series, a nawet IBM S/390 i z-Series). Napisana przez użytkowników dla użytkowników dokumentacja narzędzia Amanda uwzględniająca szybki przewodnik dla początkujących, a także listę pytań i odpowiedzi, jest dostępna pod adresem http://wiki.zmanda.com na stronie poświęconej oprogramowaniu.
Podsumowanie ważnych funkcji Rozpocznijmy od krótkiego przeglądu architektury oprogramowania Amanda. Będzie to pomocne w zrozumieniu najważniejszych zagadnień związanych z funkcjonowaniem Amandy.
Architektura klient-serwer wykorzystująca niestandardowe narzędzia Choć narzędzie Amanda zostało zaprojektowane do obsługi dużej liczby klientów i danych, jego instalowanie i zarządzanie nim jest dość proste. Prawda jest taka, że więcej czasu zajmie zamówienie pizzy niż skonfigurowanie serwera Amanda współpracującego z dwoma klientami linuksowymi i jednym z systemem Windows, a następnie rozpoczęcie testowej archiwizacji danych. Dokument dostępny pod adresem http://amanda.zmanda.com/quick-backup-setup.html zawiera szczegółowe informacje dotyczące konfigurowania w mniej niż 15 minut procesu archiwizacji realizowanego przez narzędzie Amanda. Amanda dobrze skaluje się zarówno w górę, jak i w dół. W związku z tym możliwe są niewielkie konfiguracje, nawet takie jak pojedynczy klient. Wielu użytkowników archiwizuje tylko jednego klienta, który pełni rolę serwera Amanda. Jednak wielu użytkowników korzystających z narzędzia Amanda archiwizuje setki, a nawet tysiące systemów plików (na chronionym komputerze może występować wiele systemów plików), stosując duże biblioteki taśmowe z wieloma napędami.
152
|
Rozdz ał 4. Amanda
Oprogramowanie open source wybawieniem W 1999 r. rozpocząłem pracę jako konsultant dla niewielkiej firmy usługowej podlegającej departamentowi rządu Stanów Zjednoczonych. W firmie znajdowało się około 40 komputerów PC z systemem Windows i trzy serwery firmy Sun z bazą danych Oracle. Na potrzeby archiwizacji firma używała dwóch oddzielnych komercyjnych produktów, z których nie była zadowolona. Zakupiono czwarty serwer firmy Sun, który miał być odpowiedzialny m.in. za wykonywanie kopii zapasowych danych systemów Unix. Zostałem poproszony o opinię na temat wymiany używanego przez firmę oprogramowania archiwizującego przed nabyciem dodatkowej kopii i odnowieniem umowy na obsługę techniczną. Przeprowadziłem niewielkie poszukiwania i znalazłem narzędzie Amanda. Zainstalowałem je na swoich domowych komputerach. Po tygodniu testowania zaproponowałem zarządowi firmy zastosowanie tego oprogramowania. Jednak jak to często było w tamtym czasie, zarząd nie był skłonny wziąć pod uwagę użycia darmowego oprogramowania. Kto im zapewni wsparcie techniczne? Co będzie, gdy coś pójdzie nie tak i zostanie stwierdzone, że bezpłatne oprogramowanie było używane do tak ważnej rzeczy jak kopie zapasowe? Jak dobre może być coś, co jest darmowe? Dziękujemy, lecz nie skorzystamy. Dokonamy pewnego wyboru, czyli zapłacimy tysiące dolarów za oprogramowanie, które nam nie odpowiada, tylko dlatego, że jest sprzedawane przez dużą firmę. A zatem, z niewielkimi problemami, firma przeniosła archiwizowanie danych na inny serwer. Tymczasem bez powiadamiania zarządu skonfigurowałem równoległy system archiwizujący bazujący na narzędziu Amanda oraz najstarszym serwerze firmy Sun i wolnym napędzie DAT. Około miesiąc później miał miejsce kryzys. Niezbędne było drzewo katalogowe sprzed kilku tygodni. Choć nie byłem zaangażowany w odtwarzanie danych, pomyślałem, że była to dobra okazja do porównania czasów trwania procesu realizowanego przez dwa systemy. W ciągu około 20 minut za pomocą narzędzia Amanda przeprowadziłem operację przywracania tego, co według mnie było potrzebne, i skopiowałem dane do katalogu znajdującego się na serwerze firmy w katalogu /var/temp. Cały poranek słyszałem mnóstwo przekleństw dochodzących z pomieszczeń, w których trwał proces odtwarzania danych realizowany przy użyciu komercyjnego oprogramowania. Popołudniu zakończyłem te męki i wskazując na katalog /var/temp, zapytałem: „Czy to jest to, czego potrzeba?”. Później dowiedziałem się, że problem z kopiami zapasowymi sporządzanymi za pomocą komercyjnego oprogramowania polegał na tym, że taśmy były powiązane z serwerem archiwizującym. W efekcie operacje odtwarzania mogły być wykonane tylko przy użyciu tego samego serwera. Wymagane dane były archiwizowane na wcześniejszym serwerze, który obecnie nie miał zainstalowanego oprogramowania lub miał oprogramowanie, na które licencja wygasła. Taśmy z kopiami zapasowymi były po prostu bezwartościowe. W takiej sytuacji zarząd postanowił dać szansę narzędziu Amanda w roli podstawowego systemu archiwizującego. Ostatecznie za pomocą Amandy archiwizowano dane komputerów PC. Gdy ostatni raz sprawdzałem, Amanda w dalszym ciągu była wykorzystywana w tej firmie. — Jon LaBadie
Kod źródłowy oprogramowania Amanda napisano w języku C (z zastosowaniem kilku skryptów powłoki i języka Perl). Kod można przenieść na dowolną odmianę systemów Linux i Unix, w tym systemu Mac OS X. Obecnie stacje robocze z systemem Windows mogą być archiwizowane za pośrednictwem oprogramowania Samba lub klienta Cygwin, który oferuje linuksowe Podsumowan e ważnych funkcj
|
153
środowisko przeznaczone dla systemu Windows. Społeczność związana z narzędziem Amanda aktywnie pracuje nad tym, aby udostępnić wbudowanego klienta dla systemu Windows. Ten nowy klient będzie korzystał z takich technologii Microsoftu jak usługa VSS (Volume Shadow Copy Service), która zapewnia obrazy woluminów systemowych z uwzględnieniem otwartych plików. W porównaniu z każdym innym oprogramowaniem archiwizującym największą zaletą narzędzia Amanda jest to, że nie stosuje żadnych niestandardowych formatów danych. Amanda korzysta ze standardowych narzędzi systemu operacyjnego, takich jak dump i tar, lub narzędzi open source dostępnych w wielu systemach (na przykład programów: tar w wersji GNU, Schily, smbtar). Amanda zapisuje na nośniku archiwum w jednym formacie. Zależnie od tego, jaki format będzie najlepszy w przypadku znajdujących się na dyskach systemów plików, katalogów i plików, dowolnie można łączyć ze sobą wymienione narzędzia. Ponieważ stosuje się standardowe narzędzia, można być pewnym, że zawsze będą dostępne. Kolejną zaletą wynikającą z używania standardowych narzędzi jest to, że w przypadku konieczności odtwarzania danych po wystąpieniu nieszczęśliwego zdarzenia proces ten można przeprowadzić nawet bez narzędzia Amanda (jak to zrobić, zostanie wyjaśnione podczas omawiania odtwarzania danych za pomocą Amandy). Ponieważ Amanda używa standardowych narzędzi, oferuje: • kopie zapasowe rzadko stosowanych plików; • kopie zapasowe dowiązań twardych; • pozostawianie podczas archiwizacji bez zmian znacznika czasu pliku; • wykluczenia plików i katalogów.
Z punktu widzenia administratora systemu bardzo ważne jest to, że Amanda nie korzysta z niestandardowych sterowników urządzeń. Każde urządzenie obsługiwane przez system operacyjny będzie dobrze współpracować z narzędziem Amanda. W praktyce oznacza to, że Amanda jest zgodna z szeroką gamą taśmowych urządzeń magazynujących i nowym sprzętem, który zwykle można bez problemów dodać. Wiele zmieniarek taśm, zasobników i bibliotek taśmowych jest obsługiwanych za pomocą specjalnych skryptów zmieniających taśmy, których zadaniem jest zapewnienie naprawdę sprawnej i zautomatyzowanej archiwizacji. Jeśli można odczytać i zapisać dane za pomocą napędu taśmowego i wykonując standardowe polecenie systemu operacyjnego, takie jak mt, przemieści się taśmy wewnątrz biblioteki taśmowej, Amanda będzie w stanie z nią współpracować. Ponieważ Amanda nie korzysta z niestandardowych sterowników urządzeń, kolejną korzyścią jest to, że nie trzeba się martwić o to, że po uaktualnieniu oprogramowania do najnowszej wersji urządzenie przestanie być obsługiwane. Aby zrozumieć architekturę i wewnętrzne mechanizmy funkcjonalne narzędzia Amanda, przyjrzymy się jego uproszczonej konfiguracji i przeanalizujemy przykład cyklu archiwizacyjnego zaprezentowanego na rysunku 4.2. Aby uprościć omówienie, przyjmijmy, że dostępne są tylko dwa klienty Amanda uaktywnione na dwóch stacjach roboczych: Miedź z systemem Solaris i Żelazo z systemem Linux. Każda stacja robocza ma dwa systemy plików z danymi użytkowników, które mają być chronione. Serwer Amanda o nazwie Kwarc zainstalowano na innym komputerze z systemem Linux. Dla uproszczenia nie będą archiwizowane dane samego serwera (w zarządzanych środowiskach produkcyjnych i testowych zawsze powinno się tworzyć kopie zapasowe dla serwera Amanda). Załóżmy też, że co cztery dni chcemy sporządzać pełną kopię zapasową, a między nimi — kopie przyrostowe.
154
|
Rozdz ał 4. Amanda
Rysunek 4.2. Serwer Amanda z dwoma archiwizowanymi klientami
Amanda została zaprojektowana na podstawie tradycyjnej architektury klient-serwer. Serwer Amanda, dawniej nazywany również hostem taśmowym, jest połączony bezpośrednio lub za pośrednictwem sieci SAN (Storage Area Network) z napędem taśmowym lub zmieniarką taśm. Każdy program archiwizujący klienta jest poinstruowany o tym, żeby zapisywać w standardowym wyjściu, z którego Amanda zbiera dane i transmituje je do serwera taśm. Architektura klient-serwer oferuje następujące korzyści: • Zapewnia narzędziu Amanda możliwość skalowania ze środowisk z pojedynczym klien-
tem i napędem CD-ROM do środowisk liczących setki klientów i obejmujących duże biblioteki taśmowe z wieloma napędami i setkami taśm. • Umożliwia przeprowadzanie wszystkich konfiguracji na serwerze Amanda. Po wstępnym
skonfigurowaniu oprogramowania Amanda z łatwością można dodawać klientów bez obaw, że przestaną działać sprawdzone procedury archiwizacyjne. • Przed przesłaniem serwerowi Amanda obrazów kopii zapasowych architektura klient-serwer
pozwala na realizowanie po stronie klienta niektórych operacji intensywnie obciążających procesor, takich jak kompresja lub szyfrowanie. Jednak w określonych sytuacjach, na przykład wtedy, gdy klienty Amanda działają w obrębie wirtualnych maszyn, tego typu operacje mogą też być wykonywane po stronie serwera Amanda. Ponieważ z punktu widzenia ochrony prywatności i zgodności rola bezpieczeństwa archiwizowanych danych cały czas się zwiększa, Czytelnik w skrócie zapozna się teraz z zabezpieczeniami oferowanymi przez oprogramowanie Amanda.
Zabezpieczenia narzędzia Amanda Klienty Amanda komunikują się z serwerem Amanda przy wykorzystaniu własnych protokołów sieciowych funkcjonujących ponad protokołami TCP i UDP. Łączność między klientami i serwerami Amanda nie jest narażona na luki w zabezpieczeniach występujących w przypadku polecenia rmt, tradycyjnie używanego przez program dump (przykładowo używany jest plik .rhosts znajdujący się w katalogu domowym użytkownika root).
Podsumowan e ważnych funkcj
|
155
Jak w przypadku każdej innej konfiguracji klient-serwer, powinno się zadbać o to, aby tylko własny i zaufany serwer Amanda mógł komunikować się z klientami Amanda. Narzędzie Amanda zapewnia to za pomocą pliku .amandahosts. Na rysunku 4.2 widać, że są stosowane trzy takie pliki, po jednym na serwerze Amanda (Kwarc) i dwóch klientach. Po stronie klienta trzeba dodać nazwę serwera Amanda (lub serwerów, jeśli preferuje się ochronę tego samego hosta przez wiele komputerów) i konta użytkownika, który może archiwizować dane klienta. Przykładowo plik .amandahosts klienta Żelazo z systemem Linux (rysunek 4.2) powinien zawierać następujący wpis: kwarc.zmanda.com
amanda_kopia_zapasowa
Wpis nakazuje klientowi Amanda o nazwie Żelazo umożliwienie serwerowi Amanda (Kwarc) nawiązanie połączenia przy wykorzystaniu konta użytkownika amanda_kopia_zapasowa. Podczas procesu odtwarzania trzeba mieć dostęp do serwera Amanda. W przypadku konfiguracji przedstawionej na rysunku 4.2 plik .amandahosts zapisany na serwerze taśmowym Kwarc powinien zawierać poniższe wpisy: zelazo.zmanda.com miedz.zmanda.com
root root
Wpisy nakazują serwerowi Amanda umożliwić użytkownikowi root przeprowadzenie na każdym kliencie procesu odtwarzania. Ze względów bezpieczeństwa Amanda została tak zaprojektowana, aby odtwarzać dane mógł wyłącznie użytkownik root. W celu zwiększenia bezpieczeństwa transportowanych danych Amanda może też korzystać z technologii OpenSSH. Umożliwia ona narzędziu Amanda ochronę transferowanych danych między klientami a serwerami archiwizującymi przy użyciu silnych mechanizmów uwierzytelniania i autoryzowania. Amanda oferuje również abstrakcyjny interfejs API bezpiecznej komunikacji, który pozwala projektantom na łatwe umieszczanie różnych dodatków komunikacyjnych między serwerem archiwizującym i klientem. Nawet w przypadku pojedynczego serwera archiwizującego oprogramowanie Amanda może stosować różne mechanizmy komunikacji dla różnych klientów. W celu ochrony danych na samym nośniku archiwizacyjnym narzędzie Amanda zapewnia możliwość szyfrowania kopii zapasowych za pomocą symetrycznych lub asymetrycznych algorytmów (oferowane są przez program aespipe lub gpg). Biorąc pod uwagę obciążenie procesora, szyfrowanie jest kosztowną operacją. Z tego powodu w przypadku Amandy proces szyfrowania może być przeprowadzany po stronie serwera lub klienta (należy go wykonywać tam, gdzie dostępnych jest więcej cykli procesorowych). Oprócz zmniejszania obciążenia procesora serwera Amanda szyfrowanie po stronie klienta zapewnia bezpieczeństwo danych przesyłanych w sieci, co może być istotne, gdy archiwizuje się zdalne klienty. Ze względu na ograniczenia związane z procesorem można zdecydować się na szyfrowanie tylko niektórych danych. Amanda jest na tyle elastyczna, że pozwala skonfigurować szyfrowanie danych dla jednego katalogu, a nawet pliku. Jeśli narzędzie aespipe lub gpg nie spełnia wymagań dotyczących szyfrowania, oprogramowanie Amanda będzie współpracować z niestandardowymi narzędziami szyfrującymi. Amanda nie zarządza kluczami szyfrującymi. Administrator systemu powinien zająć się zabezpieczeniem kluczy i udostępnić je podczas procesu odtwarzania.
156
|
Rozdz ał 4. Amanda
Amanda jest zgodna z oprogramowaniem SELinux (Security-Enhanced Linux) i dość dobrze współpracuje z popularnymi typami firewalli umieszczonych między serwerami Amanda a klientami, pod warunkiem że podczas początkowej konfiguracji określi się zakresy portów UDP lub TCP. Szczegóły dotyczące instalacji i konfiguracji firewalla można znaleźć pod adresem http://wiki.zmanda.com. W ramach podsumowania tego krótkiego przeglądu zabezpieczeń narzędzia Amanda chcemy podkreślić, że elastyczność konfiguracji zabezpieczeń umożliwia mu dobre dopasowanie się do zasad i procesów związanych z bezpieczeństwem i stosowanych przez większość środowisk informatycznych, w tym w organizacjach mających rygorystyczne wymagania dotyczące zabezpieczeń.
Dysk magazynujący Jak wcześniej można było zauważyć, w rzeczywistości Amanda jest skrótem, a litera D odpowiada słowu Disk. Aby objaśnić, jak Amanda przenosi dane z klienta do ich ostatecznej lokalizacji na taśmie lub dysku, trzeba zapoznać się z pojęciem dysku magazynującego. Rysunek 4.2 przedstawia serwer Amanda (Kwarc), do którego podłączono dysk magazynujący. Terminem tym określa się jeden lub kilka katalogów dowolnego systemu plików dostępnego z poziomu serwera Amanda. Dyskiem magazynującym może być pojedynczy katalog o pojemności 10 GB znajdujący się na napędzie serwera Amanda lub macierz RAID o pojemności od 5 do 10 TB, podłączona za pomocą światłowodu. Jak nazwa sugeruje, dysk magazynujący pełni rolę magazynu przechowującego zarchiwizowane dane pochodzące z wszystkich klientów Amanda. Każdy zestaw zarchiwizowanych danych systemu plików lub katalogu klienta jest po prostu grupą plików zapisanych na dysku magazynującym. Aby napęd taśmowy był efektywnie użytkowany, niezależny proces narzędzia Amanda przenosi z maksymalną możliwą wydajnością poszczególne obrazy kopii zapasowych z dysku magazynującego na taśmę lub wirtualną taśmę. Zastosowanie dysku magazynującego w roli tymczasowego miejsca przechowywania kopii zapasowych daje kilka korzyści. Nowoczesne napędy taśmowe są bardzo szybkie. Nawet gigabitowe sieci nie są w stanie przesyłać archiwizowanych danych z jednego klienta do nowoczesnych napędów taśmowych (za pośrednictwem serwera Amanda) na tyle szybko, żeby uniknąć zjawiska shoe-shining (występuje, gdy podczas archiwizowania szybkość transferu danych spada poniżej szybkości napędu taśmowego), które redukuje przepustowość i skraca żywotność zarówno nośnika, jak i napędu (w rozdziale 9. zamieszczono szczegóły dotyczące tego zjawiska). Dysk magazynujący zbiera dane od wszystkich klientów i od razu po ukończeniu tworzenia pierwszej kopii zapasowej rozpoczyna dostarczanie danych do napędu taśmowego tak szybko, jak pozwala serwer Amanda. Jednak wielu użytkowników przed rozpoczęciem procesu przenoszenia danych na taśmę woli ukończyć tworzenie kopii zapasowych dla wszystkich klientów. Dysk magazynujący może równolegle odbierać strumienie danych od wielu klientów, aby poradzić sobie z sekwencyjnym dostępem do taśmy. Zamiast zapisywać kopie na taśmie jedną po drugiej, można skonfigurować równoległe przesyłanie kopii zapasowych i w ten sposób w pełni wykorzystać dostępną przepustowość sieci, a także zmniejszyć całkowity czas archiwizowania. Jeśli z punktu widzenia wydajności sieć staje się wąskim gardłem, można zredukować całkowity czas archiwizowania przez dodanie do serwera archiwizującego kolejnej karty sieciowej lub przeznaczenie oddzielnej sieci na potrzeby kopii zapasowych. Stosując wiele dysków magazynujących, można poprawić ogólną wydajność procesu archiwizacji.
Podsumowan e ważnych funkcj
|
157
Użycie dysku magazynującego zapewnia dodatkowy poziom bezpieczeństwa w sytuacji, gdy zastosuje się złą taśmę lub nie jest ona w ogóle dostępna. Kopie zostaną utworzone nawet wtedy, gdy przed wzięciem wolnego dnia zapomni się włożyć nową taśmę. Dysk magazynujący będzie zawierał kopię zapasową również wtedy, gdy podczas zapisywania kopii na taśmie wystąpi błąd nośnika lub zabraknie na taśmie wolnego miejsca. Amanda obsługuje różne algorytmy przenoszące dane z dysku magazynującego na nośnik. Oczywiście wybrany algorytm będzie miał wpływ na efektywność wykorzystania taśmy. Ponieważ Amanda może współpracować z wieloma dyskami magazynującymi, obrazy kopii zapasowych z różnych klientów mogą być wysyłane do różnych dysków. Zwiększa to skalowalność narzędzia Amandai zapewnia lepsze równoważenie obciążenia wejścia-wyjścia, ponieważ dyski magazynujące mogą być podłączone do różnych kontrolerów. Nowi użytkownicy narzędzia Amanda często pytają, jak duży powinien być dysk magazynujący. W typowym cyklu archiwizacyjnym uwzględniającym pełne i przyrostowe kopie zapasowe większość kopii to niewielkie kopie przyrostowe. W związku z tym nawet dysk magazynujący o małej pojemności może zapewnić lepszy transfer obrazów kopii zapasowych na taśmę. Dobra reguła mówi, że na dysku magazynującym powinna być wystarczająca ilość miejsca na jednoczesne pomieszczenie dwóch największych obrazów kopii, tak aby jeden obraz mógł być zapisywany na dysku, natomiast drugi mógł być przesyłany do napędu taśmowego. Jeśli na przykład pełna kopia zapasowa obu systemów plików serwerów Miedź i Żelazo zajmuje odpowiednio 50 i 30 GB (rysunek 4.2), optymalna pojemność dysku magazynującego serwera Kwarc powinna wynosić co najmniej 80 GB. Jeżeli nie jest to praktyczne, dowolna przestrzeń mieszcząca przynajmniej kilka mniejszych przyrostowych kopii zapasowych jest lepsza niż zupełny brak dysku magazynującego. Przy dzisiejszych niskich cenach dysków zakup dysku magazynującego o odpowiedniej pojemności będzie dobrą inwestycją. Część użytkowników narzędzia Amanda posiada dyski magazynujące o znacznie większych pojemnościach. Przykładowo bardzo duży japoński producent dysponuje czterema serwerami Amanda z systemami Solaris i BSD, które chronią ponad sto klientów, działających pod kontrolą systemów: BSD, Windows, Linux, HP-UX i Solaris (z bazą danych Oracle). Jeden z dysków magazynujących serwerów wchodzi w skład macierzy RAID o całkowitej pojemności 4 TB. Szybkie macierze i serwery Amanda o dużej wydajności operacji wejścia-wyjścia pozwalają uzyskać przepustowość między dyskiem a napędami taśmowymi wynoszącą w przybliżeniu 120 Mb/s. Choć elastyczność narzędzia Amanda pozwala na konfigurację bez dysku magazynującego, kopie zapasowe mogą być zapisywane na taśmę tylko sekwencyjnie, zamiast równolegle, jak w przypadku dysku. Oczywiście brak dysku magazynującego znacznie zmniejsza wydajność procesu archiwizacji. Jeśli dysk magazynujący służy do tymczasowego przechowywania plików kopii zapasowych, w jaki sposób Amanda decyduje, co umieścić na nim w pierwszej kolejności? Przyjrzyjmy się unikatowej metodzie harmonogramowania kopii zapasowych stosowanej przez narzędzie Amanda.
Harmonogramowanie kopii zapasowych Większość produktów archiwizujących oferuje właściwie to samo harmonogramowanie kopii zapasowych. Administrator systemu konfiguruje oprogramowanie, aby pełną kopię zapasową sporządziło w niedzielę albo wykonywało ją co niedzielę lub w każdy ostatni dzień miesiąca, 158
|
Rozdz ał 4. Amanda
a między pełnymi kopiami wykonywało przyrostowe kopie na różnych poziomach. W przypadku takiego rozwiązania największym problemem jest to, że nie zapewnia żadnego równoważenia obciążenia. Trzeba się upewnić, że są dostępne wystarczające zasoby, żeby zaspokoić maksymalne zapotrzebowanie na cykle procesora serwera archiwizującego, przepustowość sieci i operacje wejścia-wyjścia podczas tworzenia pełnych kopii zapasowych. Ponieważ pełne kopie zapasowe wykonuje się raz na jakiś czas, przez większość czasu zasoby nie są całkowicie wykorzystywane. Częściej, niż można by przypuszać, administrator systemu stwierdza w poniedziałkowy poranek, że tworzenie niedzielnej pełnej kopii zapasowej nie zostało ukończone, ponieważ brakło taśm w bibliotece. Innym razem w poniedziałek może się okazać, że nadal trwa tworzenie pełnej kopii zapasowej i użytkownicy dzwonią do administratora, żeby coś z tym zrobił. Oczywiście do administratora należy decyzja, jak w cyklu tygodniowym lub miesięcznym ustalić harmonogram dystrybuowania przez oprogramowanie archiwizujące pełnych kopii zapasowych między klientami, aby zrównoważyć obciążenie. Jednak w takim przypadku trzeba upewnić się, że w środowisku nie wystąpiły żadne zmiany. Nowe klienty mogą zaburzyć funkcjonowanie schematu równoważenia. Unikatowy mechanizm harmonogramowania narzędzia Amanda optymalizuje równoważenie obciążenia związanego z kopiami zapasowymi i ułatwia administratorowi życie. Zamiast przekazywać oprogramowaniu Amanda dokładną instrukcję: „Wykonaj pełną kopię zapasową dla klientów A, B i C w każdą niedzielę, dla klientów D, E i F w środę, a w pozostałe dni wykonaj przyrostowe kopie zapasowe”, wystarczy zdefiniować kilka podstawowych reguł kontrolujących harmonogram narzędzia Amanda. Przykładowo można utworzyć regułę: „Sporządź co najmniej jedną pełną kopię zapasową w ciągu siedmiu dni, a w pozostałe dni wykonaj przyrostowe kopie zapasowe, przy czym maksymalny odstęp między utworzeniem pełnych kopii ma wynosić siedem dni”. Maksymalny okres między utworzeniem pełnych kopii zapasowych jest określany mianem cyklu zrzutu. Dla każdego określonego cyklu zrzutu narzędzie Amanda znajdzie optymalną kombinację tworzenia pełnych i przyrostowych kopii zapasowych dla wszystkich klientów. Ma to na celu uzyskanie jak najmniejszej ilości archiwizowanych danych przypadających na jeden proces archiwizacji i zapewnienie ciągłości między kolejnymi archiwizacjami. Aby określić takie zrównoważenie, narzędzie Amanda uwzględnia: • całkowitą ilość danych do zarchiwizowania zgłoszoną przez każdego klienta na podsta-
wie rozmiaru danych, które zmieniły się od czasu wykonania ostatniej kopii zapasowej; • maksymalny ustalony okres między sporządzeniem pełnych kopii zapasowych (cykl zrzutu); • pojemność nośnika archiwizacyjnego (taśma lub dysk) dostępną dla każdej operacji ar-
chiwizacji. W celu wyznaczenia optymalnego poziomu archiwizacji narzędzie Amanda każdą archiwizację rozpoczyna od fazy szacowania. Każdy klient Amanda uruchamia specjalny proces stwierdzający, jakie pliki zostały zmodyfikowane, a także określający całkowity rozmiar wszystkich zmienionych plików. Faza szacowania może trochę potrwać, zwłaszcza wtedy, gdy jest wiele klientów i systemów plików. Jeśli jakieś systemy plików nie zmieniają się zbyt dynamicznie i pliki nie są często modyfikowane, można o tym poinformować narzędzie Amanda i zyskać na czasie podczas fazy szacowania. Po zebraniu danych od wszystkich klientów Amanda rozpoczyna fazę planowania i określa optymalną kombinację pełnych i przyrostowych kopii zapasowych dla wszystkich klientów.
Podsumowan e ważnych funkcj
|
159
Rysunek 4.3 pokazuje, jak Amanda tworzy harmonogram wykonywania kopii zapasowych dla klientów z rysunku 4.2, przy założeniu, że każdy katalog domowy ma 100 GB, dane zmieniają się w 15%, a cykl zrzutu trwa cztery dni. Dla uproszczenia przyjmijmy, że Amanda dane utworzone podczas każdej archiwizacji zapisuje na nowej taśmie oznaczonej etykietą DziennyZestawn, gdzie n jest liczbą z przedziału od 1 do 4. Dodatkowo załóżmy, że wszystkie przyrostowe kopie zapasowe są poziomu 1 (poziom 0 zwykle jest przypisywany pełnym kopiom). Oznacza to, że zostanie zarchiwizowane wszystko, co zmieniło się od wykonania ostatniej pełnej kopii zapasowej.
Rysunek 4.3. Przykład harmonogramowania przez narzędzie Amanda
W przypadku każdej operacji archiwizacji Amanda planuje sporządzenie części pełnej kopii zapasowej, o rozmiarze równym całkowitej pojemności danych podzielonej przez liczbę dni cyklu zrzutu. Ponieważ cykl trwa cztery dni, na taśmie DziennyZestaw1 Amanda zapisze pełną kopię 1/4 danych, czyli zawartość katalogu /home1. Na taśmie DziennyZestaw2 Amanda umieści pełną kopię kolejnej 1/4 danych, czyli zawartość katalogu /home2, a także przyrostową kopię zapasową katalogu /home1 o wielkości 15GB (15% ze 100 GB). Na taśmie DziennyZestaw3 Amanda zapisze pełną kopię zapasową katalogu /home3 i przyrostowe kopie katalogów /home1 i /home2. Po upływie pierwszego czterodniowego okresu narzędzie Amanda utworzy pełną kopię zapasową dla jednego z katalogów /home i przyrostowe kopie dla wszystkich pozostałych. Obliczmy całkowitą ilość danych znajdujących się na każdej taśmie DziennyZestaw (tabela 4.1). Obliczenie ilości danych przypadających na taśmy DziennyZestaw1 i DziennyZestaw2 jest banalnie łatwe. W przypadku trzeciej archiwizacji katalogu /home1 pod uwagę trzeba wziąć to, że 15% danych zostało zarchiwizowanych na taśmie DziennyZestaw2. Oznacza to, że 15% ze 100 GB danych ponownie się zmieniło (rysunek 4.4). Aby uniknąć podwójnego liczenia, konieczne jest odjęcie od 30 GB niewielkiego obszaru nałożenia. W związku z tym w przypadku taśmy DziennyZestaw3 rozmiar przyrostowej kopii katalogu /home1 wyniesie 30 GB – (15 GB*15%), czyli 27,75 GB. Dalej obowiązuje taka sama logika. Zapisywana na taśmie DziennyZestaw4 przyrostowa kopia zapasowa katalogu /home1 nie ma rozmiaru 45 GB, lecz 40,84 GB (45 GB – (27,75 GB*15%)). Przytoczony przykład tak 160
|
Rozdz ał 4. Amanda
Tabela 4.1. Przykładowe rozmiary kopii zapasowych (w gigabajtach) Katalog
Dz ennyZestaw1
Dz ennyZestaw2
Dz ennyZestaw3
Dz ennyZestaw4
/home1
100 0
15 0
27 75
40 84
100 0
15 0
27 75
100 0
15 0
142 75
183 59
/home2 /home3 /home4 Suma
100 0 100 0
115 0
Katalog
Dz ennyZestaw1
Dz ennyZestaw2
Dz ennyZestaw3
Dz ennyZestaw4
/home1
100 0
15 0
27 75
40 84
/home2
40 84
100 0
15 0
27 75
/home3
27 75
40 84
100 0
15 0
/home4
15 0
27 75
40 84
100 0
Suma
183 59
183 59
183 59
183 59
Rysunek 4.4. Nakładanie się danych w kolejnych archiwizacjach
naprawdę jest znacznym matematycznym uproszczeniem. W rzeczywistości Amanda używa wszystkich dziewięciu poziomów przyrostowych kopii zapasowych, aby zoptymalizować całkowitą ilość danych zapisywanych na taśmie. Oprócz tradycyjnego schematu z pełnymi i przyrostowymi kopiami zapasowymi Amanda obsługuje następujące warianty: • Okresowe wykonywanie archiwalnych kopii zapasowych, takich jak pełne kopie trans-
portowane poza obręb firmy. • Tworzenie za pomocą narzędzia Amanda wyłącznie przyrostowych kopii zapasowych. Może
to mieć miejsce w przypadku bardzo aktywnych serwerów, które muszą być przełączane w tryb offline. Mogą też nie być w ogóle wykonywane pełne kopie zapasowe dla komputerów, które z łatwością można przywrócić przy użyciu nośników producenta (takich jak instalacyjny dysk CD systemu operacyjnego). • Wykonywanie zawsze pełnych kopii zapasowych baz danych, które zmieniają się całkowicie
między kolejnymi archiwizacjami, lub dla dowolnych innych krytycznych obszarów, z którymi łatwiej można sobie poradzić po wystąpieniu awarii, jeśli są objęte pojedynczym procesem odtwarzania.
Z łatwością można zarządzać wieloma konfiguracjami na tym samym serwerze Amanda (przykładem cotygodniowe wykonywanie tradycyjnych pełnych kopii zapasowych i przyrostowych,
Podsumowan e ważnych funkcj
|
161
a także sporządzanie dodatkowych comiesięcznych pełnych kopii do przechowywania poza obrębem firmy). Jeśli dostępnych jest kilka napędów taśmowych, na tym samym serwerze może być jednocześnie aktywnych wiele konfiguracji. Określając długość cyklu zrzutu, trzeba wiedzieć, że krótsze cykle, trwające od trzech do czterech dni, ułatwiają proces odtwarzania, ponieważ występuje mniej przyrostowych kopii zapasowych, które jednak zajmują więcej miejsca na taśmie i wymagają dłuższej archiwizacji. Choć dłuższe cykle zrzutu umożliwiają oprogramowaniu Amanda lepsze rozłożenie obciążenia na wielu taśmach, w czasie trwania procesu odtwarzania mogą wymagać większej liczby kroków. Więcej informacji na temat wyboru rozsądnie zrównoważonego cyklu zrzutu na podstawie ilości danych, pojemności napędu taśmowego i innych czynników można znaleźć pod adresem http://wiki.zmanda.com. Pora przyjrzeć się zarządzaniu taśmami przez narzędzie Amanda.
Zarządzanie taśmami Przed użyciem każdej taśmie należy nadać etykietę poleceniem amlabel. Istnieje domyślny szablon etykiet, można też zdefiniować własne szablony. Etykietowanie zapobiega nadpisywaniu taśm z poprawnymi obrazami kopii zapasowych i umożliwia serwerowi Amanda rejestrowanie wszystkich taśm, którym nadano etykietę. Amanda do każdej operacji archiwizacji (takiej jak wykonywanie każdej nocy kopii zapasowej) stosuje nową taśmę i nie zapewnia mechanizmu zapisywania nowej kopii zapasowej na tej samej taśmie, na której umieszczono poprzednią kopię. Bazując na ustalonych zasadach retencji, narzędzie Amanda monitoruje datę ważności każdej etykietowanej taśmy i ponownie jej używa do tworzenia nowych kopii zapasowych, gdy data upłynie. Jednak można tak skonfigurować narzędzie, aby nie stosowało wybranych taśm. Można zdecydować, że niektóre obrazy kopii zapasowych nigdy nie stracą ważności, i wykorzystać oprogramowanie Amanda do tworzenia archiwaliów (obsługa nośników optycznych przez narzędzie jest w tym przypadku bardzo przydatna). Z myślą o archiwizowaniu dużych ilości danych Amanda zapewnia możliwość użycia wielu taśm w ramach pojedynczej operacji archiwizacji. Przykładowo kopie zapasowe z klientów: A, B i C mogą zostać zapisane na jednej taśmie, a kopie z klientów: E, F i G — na innej. W przeszłości Amanda nie mogła umieszczać pojedynczego obrazu kopii zapasowej na wielu taśmach i administratorzy systemu musieli dzielić duże systemy plików na mniejsze fragmenty, liczące na przykład kilka katalogów. Wersja 2.5 Amandy pozwala rozmieszczać kopię zapasową na wielu taśmach. Rozmiar obrazów kopii zapasowych nie jest już ograniczony do jednej taśmy i nie jest konieczne, żeby administrator systemu sztucznie dzielił dane na segmenty mieszczące się na jednej taśmie.
Zarządzanie urządzeniami Amanda nie używa żadnych niestandardowych sterowników urządzeń taśmowych i optycznych. Trzeba upewnić się, że urządzenia taśmowe są skonfigurowane jako urządzenia bez przewijania (na przykład jako urządzenia /dev/nst0 i /dev/nst1). Konieczne jest również wybranie definicji typu taśmy powiązanej z używaną technologią napędu taśmowego. Amanda oferuje wiele takich domyślnych definicji. Oto przykład definicji dla urządzenia LTO-3: 162
|
Rozdz ał 4. Amanda
define tapetype LTO3-400-HWC { comment "LTO Ultrium 3 400/800, compression on" length 401408 mbytes filemark 0 kbytes speed 74343 kps }
Warto zauważyć, że Amanda nie stosuje wartości określającej długość taśmy. Próbuje zapisywać dane na taśmie aż do momentu wygenerowania błędu. Trzeba wybrać skrypt obsługujący wykorzystywaną zmieniarkę taśm. Przykłady definicji taśm dla najczęściej stosowanych napędów taśmowych i szczegóły dotyczące konfigurowania napędów i skryptów zmieniarek można znaleźć pod adresem http://wiki.zmanda.com. Od dłuższego czasu Amanda zapewnia możliwość użycia dysku w roli docelowego nośnika kopii zapasowej. Dedykowane katalogi są stosowane w roli wirtualnych taśm, określanych terminem vtapes. Z wirtualnymi taśmami pracuje się tak samo jak z rzeczywistymi. Przykładowo, zanim narzędzie Amanda będzie mogło skorzystać z wirtualnych taśm, trzeba nadać im etykiety. Wirtualnych taśm i zapisywania kopii zapasowej na dysku można użyć do testowania narzędzia Amanda, zanim podejmie się decyzję o inwestycji w kosztowną bibliotekę taśmową. Ponadto z punktu widzenia kosztów archiwizowanie na dysku stanowi obecnie istotną opcję dla środowiska produkcyjnego. Uzyskuje się wszystkie korzyści wynikające z archiwizowania danych bez wyzwań w postaci zarządzania kłopotliwymi napędami taśmowymi. Najbardziej interesującym scenariuszem jest jednoczesne zastosowanie taśm i dysku. Amanda zapewnia funkcję RAIT (Redundant Array of Inexpensive Tapes). Funkcja ta została stworzona z myślą o zwiększeniu nadmiarowości. Jest to takie samo rozwiązanie jak macierz RAID, w której dane są rozmieszczane na kilku dyskach. Amanda obsługuje zestawy RAIT liczące dwa, trzy i pięć napędów taśmowych. W przypadku zestawu RAIT z trzema napędami taśmowymi są zapisywane dwa strumienie danych i jeden strumień parzystości. Rozwiązanie takie oferuje podwojoną pojemność i przepustowość, a także kwadrat wartości wskaźnika awaryjności (przykładowo wskaźnik awaryjności o wartości 0,01 przyjmuje wartość 0,0001, ponieważ do utraty danych dochodzi tylko wtedy, gdy dwie taśmy uszkodzą się lub będą niedostępne). Zestaw RAIT z pięcioma napędami zapewnia czterokrotnie większą pojemność i przepustowość. Dwunapędowy zestaw RAIT duplikuje strumień wyjściowy. Każdy taki strumień może korzystać z takich samych lub różnych docelowych nośników. Jeśli używa się identycznych docelowych nośników (na przykład dwóch napędów taśmowych), uzyska się dokładne kopie zarchiwizowanych danych, nazywane klonami. Jeden z klonów można przechowywać lokalnie w celu sporadycznego wykonywania operacji odtwarzania, natomiast drugi — poza obrębem firmy na potrzeby przywracania danych w przypadku wystąpienia nieszczęśliwych zdarzeń. Jeżeli dysponuje się różnymi docelowymi nośnikami, zarchiwizowane dane można przechowywać na dysku od dwóch do trzech tygodni z myślą o sporadycznych operacjach odtwarzania. W przypadku długoterminowej retencji kopię zapisuje się na taśmie. Większość procesów odtwarzania ma miejsce w ciągu 10 dni od utraty pliku. Możliwość szybkiego odtworzenia danych z dysku staje się wtedy bardzo ważna.
Podsumowan e ważnych funkcj
|
163
Konfigurowanie narzędzia Amanda Przyjrzyjmy się konfiguracji procesu archiwizacji realizowanego przez narzędzie Amanda. Dokładne instrukcje dotyczące instalowania i konfigurowania klienta i serwera Amanda zamieszczono pod adresem http://wiki.zmanda.com. Poniżej przedstawiono wytyczne konfiguracyjne. Preferowana metoda instalacji narzędzia Amanda polega na użyciu plików RPM dostępnych pod adresem http://www.zmanda.com. Jeśli jednak ktoś chciałby skompilować oprogramowanie za pomocą kodu źródłowego, w niniejszym podrozdziale znajdzie opis podstawowych procedur instalacji klienta i serwera. Choć na komputerze może znajdować się zarówno klient, jak i serwer, nie ma potrzeby wykonywania dwóch procedur instalacyjnych. Instalacja serwera standardowo uwzględnia klienta.
W celu skompilowania kodu źródłowego klienta Amanda należy wykonać następujące kroki:
1. Utworzyć konto użytkownika amanda_kopia_zapasowa w grupie zajmującej się dyskami. Musi to być konto operatora kopii zapasowych.
2. Rozpakować, skompilować i zainstalować narzędzie Amanda przy użyciu archiwum kodu
źródłowego. Trzeba określić opcje kompilacji wyłącznie dla klienta, a następnie przeprowadzić instalację.
3. Wpisy narzędzia Amanda dodać do katalogów /etc/services i /etc/xinetd.d, a następnie ponownie uruchomić program xinetd.
4. Zdecydować, z którymi serwerami klient będzie mógł się łączyć. W tym celu należy zmodyfikować plik .amandahosts, aby umożliwić uwierzytelnianie między klientem i serwerem.
Aby zainstalować serwer Amanda, można też skorzystać z plików RPM. W celu skompilowania kodu źródłowego serwera Amanda należy wykonać następujące kroki:
1. Utworzyć konto użytkownika amanda_kopia_zapasowa w grupie zajmującej się dyskami. Konto to powinno należeć do grupy mającej możliwość odczytu i zapisu nośnika.
2. Rozpakować, skompilować i zainstalować narzędzie Amanda przy użyciu archiwum kodu źródłowego. Trzeba określić opcje dla kompilacji klienta i serwera, a następnie przeprowadzić instalację.
3. Wpisy narzędzia Amanda dodać do katalogu /etc/xinetd.d, a następnie ponownie uruchomić program xinetd.
Po zainstalowaniu serwera Amanda należy go skonfigurować, wykonując następujące kroki:
1. Utworzyć katalog konfiguracyjny Amandy: /etc/amanda/
(w przypadku gdy używa się pakietów Zmanda).
2. Skopiować do katalogu /etc/amanda/ przykładowy plik amanda.conf.
3. Utworzyć w katalogu /etc/amanda/ plik disklist. 4. Zmodyfikować plik .amandahosts w celu umożliwienia uwierzytelnienia między klientem i serwerem.
164
|
Rozdz ał 4. Amanda
5. Zmodyfikować pliki konfiguracyjne amanda.conf i disklist. 6. Dodać do pliku disklist konfigurację klienta. 7. Skonfigurować urządzenie (przez utworzenie węzłów lub katalogów urządzeń), jeśli używa się wirtualnych taśm.
8. Za pomocą programu amlabel nadać nośnikowi (taśma lub wirtualna taśma) etykietę. 9. Skonfigurować program cron w celu zaplanowania archiwizacji wykonywanych przez narzędzie Amanda.
10. Uruchomić program amcheck, aby sprawdzić, czy nie występują problemy z konfiguracją, komunikacją klient-serwer, dyskiem magazynującym lub taśmą.
Rysunek 4.5 prezentuje pliki konfiguracyjne przykładowej sieci.
Rysunek 4.5. Pliki konfiguracyjne narzędzia Amanda
W konfigurowaniu oprogramowania Amanda najważniejszym plikiem jest amanda.conf. Choć przykładowy plik jest dość duży (liczy ponad 700 wierszy, dlatego nie zamieszczono go tutaj; więcej szczegółów można znaleźć pod adresem http://wiki.zmanda.com), właściwie nie wymaga objaśnień. Plik określa, w jaki sposób będą tworzone kopie zapasowe. Umożliwiają to następujące informacje: • Ustawienia lokalne, takie jak nazwa organizacji, adres e-mail, pod który ma być wysłany
raport potwierdzający ukończenie archiwizacji i ostrzeżenia, a także lokalizacja katalogów narzędzia Amanda. • Ustawienia sieciowe i sprzętowe, takie jak nazwy urządzeń taśmowych, definicje typów
taśm, skrypt zmieniarki taśm, szablon etykiet taśm i przepustowość sieci dostępna dla narzędzia Amanda. • Ustawienia procedury archiwizacji, takie jak długość cyklu zrzutu, szczegóły dotyczące
przyrostowych kopii zapasowych, liczba operacji archiwizacji przypadających na cykl zrzutu i liczba taśm wykorzystywanych w rotacji. • Lokalizacje dysków magazynujących z ich pojemnościami udostępnionymi oprogramo-
waniu Amanda.
Konf gurowan e narzędz a Amanda
|
165
• Instrukcje dotyczące sposobu tworzenia kopii zapasowych (na przykład czy ma być użyty
program dump czy wersja GNU narzędzia tar), a także szczegóły związane z indeksowaniem danych, szyfrowaniem i kompresją. Plik disklist identyfikuje to, co ma zostać zarchiwizowane. Przykładowo do sporządzenia kopii zapasowej katalogów /home klientów Żelazo i Miedź (rysunek 4.5) są wymagane następujące wpisy listy dysków: # nazwa_hosta nazwa_dysku typ_zrzutu miedz /home1 stable miedz /home2 stable zelazo /home3 normal zelazo /home4 normal
Typy zrzutu są określane w pliku amanda.conf. Definiują parametry archiwizacyjne decydujące o tym, czy kompresować kopie zapasowe i czy w pliku /etc/dumpdates rejestrować wyniki archiwizacji, względny priorytet dysku i listy wykluczeń. Poniżej zamieszczono przykładowe definicje typów zrzutów normal i stable zastosowane we wpisach klientów Żelazo i Miedź umieszczonych w pliku disklist. define dumptype normal { comment "gnutar backup" holdingdisk yes # (dysk magazynujący domyślnie jest włączony) index yes program "GNUTAR" priority medium } define dumptype stable { comment "ufsdump backup" holdingdisk yes # (dysk magazynujący domyślnie jest włączony) index yes program "DUMP" priority medium }
Choć wiele parametrów pliku amanda.conf ma domyślne wartości, obszerna grupa różnych parametrów, które można modyfikować, oferuje pełną kontrolę środowiska archiwizacji. Nowy użytkownik oprogramowania Amanda powinien przyjąć, że będzie musiał poświęcić na naukę jego obsługi od około dwóch do czterech tygodni, zanim będzie mógł utworzyć pełną kopię zapasową dla środowiska produkcyjnego. Nie oznacza to, że początkująca osoba spędzi cały miesiąc na zapoznawaniu się z dokumentacją narzędzia Amanda i czytaniu kodu źródłowego. Tak naprawdę skonfigurowanie serwera Amanda z dwoma klientami linuksowymi i jednym z systemem Windows, a następnie rozpoczęcie testowej archiwizacji zajmuje mniej niż 15 minut. Dokument dostępny pod adresem http://amanda.zmanda.com/quick-backup-setup.html zawiera szczegółowe informacje na temat rozpoczęcia procesu archiwizacji danych za pomocą narzędzia Amanda w mniej niż 15 minut. Jednakże powinno się przewidzieć trochę czasu na to, aby na spokojnie przyjrzeć się działaniu oprogramowania Amanda i przetestować kilkakrotnie proces odtwarzania, zanim użyje się narzędzia w środowisku produkcyjnym. W przypadku dużych organizacji dobrym pomysłem jest dodawanie każdego dnia jednego lub dwóch klientów, aż do momentu, gdy narzędzie Amanda będzie chroniło wszystkie klienty. Do tej pory opisano najbardziej typową sytuację: klient Amanda skonfigurowany w systemie, który ma być chroniony. Jednak administrator systemu może zdecydować o podłączeniu do serwera Amanda systemów plików za pośrednictwem technologii NFS lub Samba i uruchomieniu na serwerze klienta Amanda w celu archiwizowania takich systemów plików.
166
|
Rozdz ał 4. Amanda
Wszyscy popełniamy błędy Właśnie zacząłem używać narzędzia Amanda do archiwizowania danych głównego serwera w niewielkim sklepie internetowym. Ponieważ czułem się zbyt pewny siebie i chciałem posłuchać płyty CD włożonej do napędu serwera, spróbowałem podłączyć kabel audio odtwarzacza CD do karty dźwiękowej komputera, bez uprzedniego wyłączenia go. Choć udało mi się podłączyć odtwarzacz, przy okazji poruszyłem kabel SCSI łączący trzy dyski RAID5 z kontrolerem RAID. Był to serwer archiwizujący. W związku z tym, gdy karta RAID odmówiła posłuszeństwa i serwer nie chciał się załadować, zacząłem myśleć o odtwarzaniu od podstaw serwera archiwizującego! Na szczęście osoby z firmy VALinux, które przygotowały ten serwer, były w stanie skontaktować mnie ze swoim inżynierem. Znany mu był tajemny sposób komunikowania się z kartą RAID, dzięki czemu urządzenie to zignorowało fakt, że dyski znajdowały się w nieznanym stanie, i po prostu przywróciło je do działania. Od tamtego czasu miałem do czynienia z kilkoma podobnymi sytuacjami, gdy karta RAID odmawiała posłuszeństwa na skutek zaniku zasilania podczas ładowania komputera. Musiałem wtedy przejechać wiele kilometrów tylko po to, aby otrzymać dyskietkę z oprogramowaniem i dokumentacją karty RAID. Wniosek 1: Tak, nawet Czytelnik może popełniać błędy. Wniosek 2: Dokumentację i nośnik dołączony do karty RAID należy mieć przy sobie. — Jason z Kalifornii
Archiwizowanie klientów za pośrednictwem protokołu NFS lub Samba W porównaniu z tradycyjną metodą archiwizowania przy użyciu klienta Amanda zainstalowanego na komputerze, który ma być chroniony, archiwizowanie danych za pośrednictwem protokołu NFS (Network File System) lub Samba2 oferuje kilka korzyści: • Nie trzeba na komputerze instalować i konfigurować oprogramowania klienta Amanda,
aby był chroniony. Przez modyfikację plików znajdujących się na jednym komputerze można dodać więcej systemów do listy chronionych.
• Klient Amanda może nie być dostępny dla określonego systemu operacyjnego. Metoda
wykorzystująca protokół NFS lub Samba umożliwia zarchiwizowanie takiego systemu. • Zużywanych jest znacznie mniej zasobów procesora i pamięci chronionych komputerów. • Jeśli ważne dane chronionych komputerów są już dostępne za pośrednictwem protokołu
NFS lub CIFS, metoda ta zapewni lepszą integrację z zasadami ustalonymi przez dział informatyczny firmy. Jednak należy też wziąć pod uwagę następujące wady metody archiwizowania opartej na protokole NFS lub Samba: 2
Samba jest wersją open source protokołu SMB, który jest też nazywany CIFS (Common Internet File System). Protokół SMB/CIFS jest powszechnie wykorzystywany w systemie Windows.
Arch w zowan e kl entów za pośredn ctwem protokołu NFS lub Samba
|
167
• Trzeba zastanowić się nad kwestią bezpieczeństwa mechanizmu podłączania, niezależnie
od tego, czy użyje się protokołu SMB czy NFS. Nie będzie możliwe użycie mechanizmu oferowanego przez narzędzie Amanda do szyfrowania danych przesyłanych od klienta do serwera. Przede wszystkim konieczne będzie również zrozumienie konsekwencji wynikających z zastosowania protokołu NFS lub Samba na komputerze, który ma być chroniony. Jeśli na przykład nie chce się, aby serwer NFS był zawsze uruchomiony na komputerze przeznaczonym do archiwizacji, trzeba wykonać schemat synchronizacji, w którym serwer NFS będzie uaktywniany tylko przed rozpoczęciem tworzenia kopii zapasowej. • Prawa dostępu muszą być starannie określone. Serwer Amanda wymaga od punktu pod-
łączenia NFS zarówno prawa odczytu, jak i zapisu. Prawo odczytu jest niezbędne podczas fazy archiwizacji, zapisu — przy odtwarzaniu danych.
• Nie będzie możliwe zastosowanie mechanizmów lokalnego systemu plików do optyma-
lizowania procesu archiwizacji. Przykładowo nie będzie można użyć programu dump lub xfsdump dla systemu plików, do którego dostęp jest uzyskiwany za pośrednictwem sieci. • Nie można archiwizować żadnych otwartych plików udostępnianych za pośrednictwem
protokołu Samba. Podobnie jest w przypadku rozszerzonych atrybutów plików.
Archiwizowanie danych za pośrednictwem protokołu NFS Aby móc archiwizować dane przy wykorzystaniu protokołu NFS, na docelowym komputerze trzeba zainstalować i skonfigurować serwer NFS, a po stronie serwera Amanda — klienta NFS. W dalszej kolejności należy wyeksportować systemy plików przeznaczone do archiwizacji (przez wyszczególnienie ich w pliku /etc/exports po stronie komputera klienta). Trzeba się upewnić, że serwer Amanda może uzyskać dostęp do plików, które muszą zostać zarchiwizowane. W wielu sytuacjach oznacza to włączenie dla archiwizowanego udziału NFS opcji no_root_ squash, tak aby serwer Amanda mógł uzyskać dostęp do wszystkich plików. Warto zauważyć, że nazwa hosta podana w odpowiednim wpisie listy dysków powinna identyfikować komputer, na którym podłączono udział NFS, a nie komputer będący klientem. W przypadku przykładowej sieci widocznej na rysunku 4.6 we wpisie listy dysków znalazłaby się nazwa hosta Kwarc.
Rysunek 4.6. Konfigurowanie archiwizacji opartej na protokole NFS
Archiwizowanie danych za pośrednictwem protokołu Samba W celu zarchiwizowania danych przy wykorzystaniu protokołu Samba na serwerze Amanda należy zainstalować klienta Samba. Nie trzeba jawnie podłączać zdalnego systemu plików. Amanda jest dobrze zintegrowana z narzędziem smbclient (klient podobny do programu ftp, 168
|
Rozdz ał 4. Amanda
udzielający dostępu do zasobów serwerów bazujących na protokole SMB/CIFS). Narzędzie Amanda używa opcji -T, aby utworzyć zgodne z programem tar kopie zapasowe wszystkich plików udziału SMB/CIFS. Amanda usuwa bit archiwizacji dla zarchiwizowanych plików znajdujących się na docelowym komputerze z systemem Windows, dzięki czemu możliwe jest sporządzanie przyrostowych kopii zapasowych. W systemie Windows trzeba utworzyć konto użytkownika dysponującego pełnymi prawami dostępu (odczyt i zapis) do udziału (w przypadku przykładowej sieci z rysunku 4.7 konto użytkownika nosi nazwę amanda_kopia_zapasowa). Amanda łączy się z udziałem jako ten użytkownik. Jeśli użytkownik nie ma pełnego dostępu, nie uda się utworzyć przyrostowych kopii zapasowych i każdorazowo będzie archiwizowany cały udział, ponieważ w takiej sytuacji bity archiwizacji nie są nigdy resetowane. Warto zauważyć, że jeśli dowolny inny program w systemie Windows zresetuje bit archiwizacji pliku, Amanda nie uwzględni go podczas tworzenia przyrostowej kopii zapasowej.
Rysunek 4.7. Archiwizowanie danych komputera z systemem Windows za pośrednictwem protokołu Samba
Oprócz przeprowadzenia standardowej konfiguracji narzędzia Amanda trzeba utworzyć plik /etc/amandapass w systemie z uaktywnionym programem smbclient. W pliku tym znajdują się dane uwierzytelniania pozwalające uzyskać dostęp do konkretnych udziałów systemu Windows. Warto również zauważyć, że nazwa hosta zawarta w odpowiednim wpisie listy dysków odnosi się do komputera z uruchomionym narzędziem smbclient, a nie do archiwizowanego komputera z systemem Windows. W przypadku rysunku 4.7 nazwa hosta dotyczyłaby serwera Amanda o nazwie Kwarc. Wiele instalacji oprogramowania Amanda chroni serwery i stacje robocze z systemem Windows umieszczone w środowisku produkcyjnym. Przykładowo wydział radiologii dużego uniwersytetu położonego w środkowo-zachodniej części Stanów Zjednoczonych korzysta z narzędzia Amanda od 1999 r. W przeszłości ich serwer Amanda działał w systemach: IRIX, AIX i Solaris. Jednak obecnie serwer Amanda uruchomiono w systemie Linux z indeksami replikowanymi na innym serwerze. Wydział archiwizuje ponad 70 klientów działających pod kontrolą systemów: Linux, Solaris, IRIX, Mac OS X i Windows. W sumie na klientach jest przechowywanych około 4 TB archiwizowanych danych. Dysk magazynujący ma pojemność 1,4 TB, a cykl zrzutu trwa 90 dni. Każdy klient z systemem Windows jest chroniony za pośrednictwem protokołu Samba. Kilka razy w miesiącu pracownicy wydziału przywracają pliki na skutek błędów użytkowników lub awarii dysku twardego. Nigdy nie doszło do utraty danych, ponieważ Amanda zawsze była w stanie przywrócić pliki. W poniższym punkcie omówiono proces odtwarzania danych za pomocą narzędzia Amanda.
Arch w zowan e kl entów za pośredn ctwem protokołu NFS lub Samba
|
169
Odtwarzanie danych przy użyciu narzędzia Amanda Programy amrecover i amrestore odtwarzają dane z kopii zapasowych utworzonych przy użyciu Amandy. Program amrecover przywraca pliki za pomocą interfejsu umożliwiającego przeglądanie indeksu pliku kopii zapasowej dla konkretnej daty i wybieranie plików, które zostaną odtworzone. Oczywiście, aby można było zastosować program amrecover, należy uaktywnić indeksowanie zarchiwizowanych plików podczas określania typu zrzutu w pliku amanda.conf. Po zaznaczeniu plików Amanda odszuka wymaganą taśmę i obraz kopii zapasowej, a następnie w razie potrzeby dokona jego dekompresji, prześle za pośrednictwem sieci obraz do klienta i przekaże go odpowiedniemu programowi odtwarzającemu z argumentami niezbędnymi do wyodrębnienia żądanych plików. W sytuacji gdy trzeba przywrócić pliki zawarte w przyrostowych kopiach zapasowych, Amanda ustala poprawną kolejność taśm. Ze względów bezpieczeństwa program amrecover musi zostać uruchomiony po stronie klienta z uprawnieniami użytkownika root. Ponadto tego użytkownika powinno się podać jako zdalnego użytkownika w pliku .amandahosts znajdującym się na serwerze Amanda. Proces przywracania całego systemu plików powinien być realizowany za pomocą programu amrestore, który pobiera z taśmy całe obrazy systemów plików. Narzędzie amrecover można załadować na dowolnym kliencie, włącznie z serwerem Amanda. Z kolei program amrestore można uruchomić wyłącznie na serwerze Amanda. Programu tego trzeba użyć, gdy nie jest dostępny indeks kopii zapasowej. Jeśli zasady dotyczące archiwizowania uwzględniają wykonywanie kopii zapasowej wszystkiego, włącznie z systemem operacyjnym, za pomocą narzędzia Amanda można przeprowadzić proces odtwarzania od podstaw. Oto procedura:
1. Wymiana dysku. 2. Uruchomienie komputera przy użyciu dysku Live CD (na przykład systemu Knoppix). 3. Formatowanie i partycjonowanie dysku. 4. Zastosowanie programu amrestore na serwerze Amanda w celu odtworzenia wszystkiego na nowym dysku, włącznie z systemem operacyjnym (może być konieczne również odtworzenie danych z przyrostowych kopii zapasowych).
5. Zainstalowanie na nowym dysku programu ładującego. Format zapisu danych na taśmie stosowany przez oprogramowanie Amanda jest na tyle prosty, że w przypadku wystąpienia problemów można odtworzyć dane bez pomocy żadnego z narzędzi Amanda. Jako pierwszy na taśmie występuje plik etykiety woluminu zawierający numer seryjny woluminu i datę jego utworzenia. Jest to zwykły plik tekstowy. Każdy następny plik przechowuje jeden obraz używający bloków o rozmiarze 32 kB. Pierwszy blok zawiera nagłówek narzędzia Amanda z oznaczeniem klienta, lokalizacji i opcji użytych przy tworzeniu obrazu. Podobnie jak etykieta woluminu nagłówek jest plikiem tekstowym. Dalej znajduje się plik obrazu, rozpoczynający się od kolejnego bloku taśmy. Ponieważ nagłówek obrazu jest plikiem tekstowym, można go przejrzeć, wykonując poniższe polecenia. # mt rewind # mt fsf NN # dd if=$TAPE bs=32k count=1
170
|
Rozdz ał 4. Amanda
Oprócz opisu obrazu format zapisu na taśmie używany przez narzędzie Amanda uwzględnia tekst z poleceniami wymaganymi do przeprowadzenia procesu odtwarzania. Poniżej zamieszczono typowy wpis dla systemu plików /home2 komputera zelazo.zmanda.com. Wpis dotyczy zrzutu poziomu 1 wykonanego bez kompresji poleceniem ufsdump systemu Solaris. AMANDA: FILE 20060418 zelazo.zmanda.com /home2 lev 1 comp N program /usr/sbin/ufsdump
W celu odtworzenia danych należy przewinąć taśmę do początku pliku i wykonać następujące polecenie: # dd if=$TAPE bs=32k skip=1 | /usr/sbin/ufsrestore -f... -
Aby obraz pobrać za pomocą standardowych narzędzi uniksowych, gdy nie jest dostępny program amrestore, taśmę należy przewinąć do obrazu, a następnie odczytać go przy użyciu programu dd. # mt rewind # mt fsf NN # dd if=$TAPE bs=32k skip=1 of=obraz_zrzutu
Opcja skip=1 nakazuje programowi dd pominięcie pliku nagłówka narzędzia Amanda. Bez opcji of= program dd zapisuje obraz w standardowym wyjściu, które w razie potrzeby może zostać przekierowane do programu dekompresującego, a następnie narzędzia odtwarzającego po stronie klienta. Jeżeli w roli nośnika zastosowano zestaw RAIT, do odtworzenia danych z taśm bez użycia poleceń narzędzia Amanda trzeba użyć skryptu powłoki wykorzystującego polecenia dd i mt. Tak jak w przypadku dowolnego systemu archiwizowania, powinno się wielokrotnie przetestować procedury odtwarzania, aby było dokładnie wiadomo, jak postępować, gdy dojdzie do nieszczęśliwego zdarzenia.
Społeczność użytkowników i opcje wsparcia Przedstawiono podstawowe funkcje oprogramowania Amanda. Jednak jest znacznie więcej rzeczy, z którymi należy się zapoznać. Aby uzyskać szczegółowe informacje na temat monitorowania, raportowania, samokontroli, szyfrowania i wielu innych funkcji narzędzia Amanda, należy skorzystać z poniższych zasobów. Amanda jest jedynym archiwizującym oprogramowaniem open source z opcją obsługi przedsiębiorstw, dostępną w formie subskrypcji na stronie internetowej firmy Zmanda Inc. (http://www. zmanda.com). Firma oferuje też dla wybranych nabywców swojej subskrypcji Amanda Enterprise Edition odszkodowanie za wszelkie problemy związane z naruszeniem własności intelektualnej. Dodatkowo firma Zmanda, a także kilka innych organizacji, świadczy profesjonalne usługi instalacji i konfiguracji oprogramowania Amanda. Dokumentacja narzędzia Amanda napisana przez użytkowników dla użytkowników jest dostępna pod adresem http://wiki.zmanda.com. Łatwość wprowadzania zmian przez wielu użytkowników, bieżące archiwizowanie zmian i możliwość wyszukiwania to kluczowe cechy strony internetowej z dokumentacją. Społeczność związana z oprogramowaniem Amanda korzysta z różnych narzędzi pracy grupowej, w tym z forów Amandy (http://forums.zmanda.com). Użytkownicy Amandy mają też do dyspozycji bardzo wygodną listę wysyłkową (amanda-users@ amanda.org) z archiwami dostępnymi pod adresem http://groups.yahoo.com/group/amanda-users.
Społeczność użytkown ków opcje wsparc a
|
171
Przyszły rozwój Obecnie jednym z głównych wyzwań branży informatycznej jest ogólne bezpieczeństwo systemów. Ponieważ bezpieczeństwo stanowi fundamentalny element archiwizacji (zwłaszcza gdy ludzie gubią taśmy pozbawione szyfrowania), społeczność związana z narzędziem Amanda planuje nadal poprawiać wszystkie aspekty zabezpieczeń Amandy. W branży związanej z archiwizowaniem danych zachodzi zasadnicza zmiana: dysk staje się podstawowym nośnikiem kopii zapasowych. Nawet pomimo tego, że narzędzie Amanda zostało stworzone z myślą o archiwizowaniu danych na dysku, jego projektanci planują wiele udoskonaleń tego rozwiązania, takich jak możliwość jednoczesnego wykonywania wielu operacji archiwizowania i odtwarzania. Wielu użytkowników oprogramowania Amanda nieustannie toczy bój z przytłaczającym wzrostem ilości danych. Amanda musi temu podołać i jej projektanci pracują nad poprawą skalowalności i wydajności. Ogólna akceptacja produktów open source (zwłaszcza dla systemu Linux) powoduje, że narzędzie Amanda trafia do środowisk produkcyjnych z bazami danych: Oracle, MySQL i SAP, a także wieloma innymi aplikacjami. Wielu użytkowników z powodzeniem wdraża narzędzie Amanda w tak wymagających środowiskach. Zespół rozwijający oprogramowanie Amanda pracuje nad API, które ułatwi archiwizowanie danych takich aplikacji. Twórcy Amandy zawsze dążyli do ułatwienia życia administratorowi systemu. Kontynuowane są prace mające na celu uproszczenie instalowania aplikacji, administrowania nią i przywracania kopii zapasowych, a jednocześnie danie administratorowi pełnej kontroli nad przebiegiem procesu ich tworzenia. Jak widać, prace rozwojowe związane z narzędziem Amanda cały czas uwzględniają rzeczywiste wymagania użytkowników. Zespół projektowy oprogramowania Amanda i związana z nim społeczność dalej będą rozwijać ten bogaty w możliwości i dobrze rozpoznawalny pakiet aplikacji. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
172
|
Rozdz ał 4. Amanda
ROZDZIAŁ 5.
BackupPC
Większość sieci domowych i w niewielkich firmach zawiera różne komputery, które należy archiwizować: stacje robocze, serwery, laptopy. Te komputery często działają pod kontrolą różnych systemów operacyjnych. Związane z tym wyzwanie dodatkowo się zwiększy, gdy przyjmie się, że sieci takie są pozbawione automatów taśmowych lub środków finansowych na zaawansowane technologie taśmowe. Dodatkowo trzeba uwzględnić problem związany z laptopami, które z założenia są mobilne i mogą nie znajdować się w lokalnej sieci w środku nocy, gdy zwykle wykonuje się kopie zapasowe. Większości darmowych technologii nie zaprojektowano pod kątem rozwiązywania takiego konkretnego zestawu problemów. Część z tych technologii nie obsługuje klientów odłączonych lub używających protokołu DHCP i systemu Windows, a część nie pozwala użytkownikom planować we własnym zakresie wykonywania operacji archiwizowania lub odtwarzania. Wreszcie większość z tych technologii wymaga instalacji na archiwizowanym komputerze dodatkowego oprogramowania, co powoduje pojawienie się nowych wyzwań, związanych z komputerami, które nie są centralnie zarządzane (są to na przykład komputery z systemem Linux lub laptopy z systemem Mac). W tworzeniu niniejszego rozdziału brał udział Don Harper, pracujący w firmie JP Morgan Chase na stanowisku inżyniera linuksowego. Don reprezentuje drugie pokolenie informatyków (jego ojciec był w latach 70. wiodącym analitykiem systemów, pracującym w firmie Shell Oil) i zarabia na życie, zajmując się od 1987 r. systemami uniksowymi w różnych firmach, od zupełnie nowych do wielkich międzynarodowych korporacji.
Funkcje systemu BackupPC BackupPC jest systemem archiwizowania i odtwarzania danych całkowicie bazującym na dyskach. System ten oferuje kilka zalet, z których część jest unikalna. Oto one: Obsługa dowolnego systemu operacyjnego klienta Używając standardowych narzędzi, które mogą wchodzić w skład podstawowej dystrybucji lub zostać z łatwością dodane do systemu, oprogramowanie BackupPC może obsługiwać obszerną grupę klientów. Ponadto nie ma potrzeby instalowania żadnego oprogramowania klienta z wyjątkiem standardowych narzędzi (tar, ssh i rsync). Dodanie systemów
173
operacyjnych nowych klientów staje się proste, zwłaszcza wtedy, gdy klient używa odmiany systemu Unix, takiej jak Mac OS X. Sprawowanie kontroli przez użytkownika i dostęp do kopii zapasowych za pośrednictwem interfejsu internetowego Ponieważ każdy ważniejszy system operacyjny dysponuje przeglądarką internetową, zastosowanie jej jest kolejną metodą przyspieszenia procesu obsługi nowych systemów operacyjnych. Interfejs internetowy powinien być tak zaprojektowany, aby pozwalał bezpiecznie kontrolować klienta w jak największym zakresie. Użytkownik powinien być w stanie zażądać operacji przywracania bez potrzeby szukania operatora archiwizacji, a także z łatwością przeglądać i odtwarzać wybrane pliki. Jednakże użytkownik nie powinien mieć możliwości wglądu do komputera innego użytkownika. Obsługa klientów odłączonych i korzystających z protokołu DHCP Stosując standardowe narzędzia, system BackupPC obsługuje klienty DHCP, dopóki są zarejestrowane przy użyciu usługi nazewniczej, takiej jak DNS, Active Directory lub LDAP. Problem z hostami, które znikają z sieci powinien być rozwiązywany przez sprawdzanie obecności klienta w sieci i niegenerowanie błędu do momentu upłynięcia ustalonego czasu.
Zasady działania systemu BackupPC W modelu systemu BackupPC na jednego klienta przypada jeden użytkownik. Jest to dopasowane do sposobu funkcjonowania typu środowiska, które stworzono specjalnie z myślą o archiwizowaniu komputerów PC kilku użytkowników (stąd obecność skrótu PC w nazwie systemu). Zwykle powinien to być użytkownik, który jest właścicielem danych znajdujących się na komputerze. W przypadku dużego serwera plików powinien to być administrator. System BackupPC za pośrednictwem poczty elektronicznej powiadamia właściciela, jeśli po upływie ustalonego czasu nie może zarchiwizować klienta. Właściciel danych może kontrolować proces odtwarzania przy użyciu interfejsu internetowego. Poniższa lista opisuje działanie systemu BackupPC. Zapisywanie kopii zapasowych bezpośrednio na dysku System BackupPC magazynuje wszystkie swoje kopie zapasowe bezpośrednio na dysku. Identyczne pliki zlokalizowane w obrębie dowolnego katalogu lub klienta są zapisywane tylko raz, co w znaczącym stopniu zmniejsza zapotrzebowanie na przestrzeń dyskową serwera. Pliki są umieszczane w puli dyskowej. Oprócz puli kopie zapasowe znajdują się w drzewie katalogowym uporządkowanym według hosta, a następnie według kopii zapasowej z twardymi dowiązaniami do puli dyskowej. System BackupPC realizuje też nocny proces mający na celu odzyskanie przestrzeni puli dyskowej, do której nie odwołuje się już żadna kopia zapasowa. Ułatwia to zapobiegnięcie przekroczeniu górnego limitu ogólnego wykorzystania dysków. Jest to automatyczny proces, którego administrator nie musi konfigurować. Obsługa systemu operacyjnego dowolnego klienta Choć serwerowa część oprogramowania BackupPC w celu uzyskania jak najlepszej wydajności została zaprojektowana pod kątem uruchamiania w systemie uniksowym z wykorzystaniem skryptów języka Perl i modułu mod_perl serwera Apache, może być załadowana na dowolnym serwerze WWW obsługującym język Perl i programy Perl CGI (wymagany jest moduł mod_perl lub skrypt języka Perl ustawiający atrybut setuid). Na 174
|
Rozdz ał 5. BackupPC
potrzeby przechowywania kopii zapasowych serwer powinien dysponować dużym dyskiem lub macierzą RAID. Jeśli chodzi o klienty, niemal każdy uniksowy system operacyjny lub do niego podobny może być z łatwością archiwizowany. Większość nowszych wersji komercyjnych odmian systemu Unix (Solaris, AIX, IRIX, HP-UX) ma narzędzia: tar, compress, gzip, rsync, a także rsh i (lub) ssh w podstawowej dystrybucji dostępnej w internecie. Inne uniksowe systemy operacyjne (Linux, FreeBSD, OpenBSD, NetBSD i Mac OS X) też dysponują tymi programami. Klienty z systemem Windows mogą być archiwizowane na kilka różnych sposobów. Jeśli lokalne zasady uniemożliwiają uruchamianie dodatkowego oprogramowania, system BackupPC może skorzystać z aplikacji pakietu Samba (http://www.samba.org), aby sporządzić kopię zapasową udziałów SMB klienta. Jeżeli oprogramowanie może być lokalnie zainstalowane, po stronie klienta można zastosować narzędzie rsync razem z zestawem programów Cygwin (http://www.cygwin.com). Obsługa wbudowanych narzędzi Do realizowania swoich zadań system BackupPC używa standardowych narzędzi uniksowych. Spośród nich wymieńmy: perl, tar, rsync, compress, gzip, bzip2, zip, apache i samba. Dzięki temu przeniesienie serwera do nowego systemu operacyjnego jest znacznie prostsze niż przy wykorzystaniu kodu języka C. Do przechowywania informacji na temat kopii zapasowych system BackupPC nie używa bazy danych lub katalogu. Zamiast tego korzysta z drzewa dyskowego. Oznacza to, że aktualizacja systemu operacyjnego serwera BackupPC (lub aktualizacja jego samego) przebiega bezproblemowo. Kontrolowanie przez użytkownika procesu archiwizowania lub odtwarzania za pośrednictwem interfejsu przeglądarki internetowej Przeglądarka internetowa jest podstawowym interfejsem systemu BackupPC. Po przeprowadzeniu wstępnej konfiguracji systemu BackupPC, aby nim administrować, nie trzeba będzie uzyskiwać dostępu do serwera z poziomu wiersza poleceń. Interfejs internetowy napisano w języku Perl i zaprojektowano z myślą o uruchamianiu z wykorzystaniem modułu mod_perl lub zwykłych programów CGI i skryptu Perl ustawiającego atrybut setuid. Interfejs pozwala użytkownikom na zalogowanie się i kontrolowanie na żądanie operacji archiwizowania i odtwarzania. Użytkownik może zażądać jednorazowej archiwizacji bądź utworzenia pełnej lub przyrostowej kopii zapasowej. Jeśli użytkownik musi odtworzyć plik, dostępnych jest kilka opcji. Poszczególne pliki mogą zostać wyodrębnione po prostu przez ich zaznaczenie. Grupy plików lub katalogów mogą zostać przywrócone w docelowe miejsce lub użytkownik może pobrać pliki w postaci archiwum programu tar lub zip (po dokonaniu odpowiedniej konfiguracji). Użytkownik ma pełną kontrolę nad odtwarzanymi plikami lub katalogami, a także może określić ich docelową lokalizację. Funkcja historii informuje, które pliki każdego katalogu zmieniły się podczas wszystkich archiwizacji. Obsługa klientów DHCP i odłączonych Ponieważ klienty systemu BackupPC są identyfikowane za pomocą nazw hostów, gdy w archiwizowanej sieci stosuje się protokół DHCP i włączono funkcję dynamicznego rozwiązywania nazw, nie trzeba będzie nic robić, żeby serwer BackupPC tworzył kopie zapasowe dla klientów DHCP. Jeżeli jednak tak nie jest i klienty działają pod kontrolą systemu Windows, system BackupPC można tak skonfigurować, aby poszukał puli adresów dla klientów, lokalizując je za pośrednictwem ich nazw smb.
Zasady dz ałan a systemu BackupPC
|
175
Jeśli w czasie zaplanowanej normalnej archiwizacji klient nie jest dostępny w sieci, serwer BackupPC nie wygeneruje błędu do momentu upłynięcia ustalonego czasu, który jest liczony od chwili ukończenia ostatniej archiwizacji zakończonej powodzeniem. Gdy do tego dojdzie, serwer wyśle wiadomość pocztową do właściciela klienta i powiadomi go, aby podłączył komputer do sieci w celu przeprowadzenia jego archiwizacji (serwer może również za pośrednictwem poczty elektronicznej przesyłać wszystkie błędy do administratora). Klienty zlokalizowane w zdalnej sieci lokalnej mogą być archiwizowane lokalnie, przy założeniu, że między sieciami istnieje połączenie. Oznacza to, że mogą być archiwizowane klienty połączone za pośrednictwem wirtualnej sieci prywatnej VPN. Jeśli użytkownik nie chce w danej chwili tworzyć kopii zapasowej, bieżącą operację archiwizacji może anulować, korzystając z graficznego interfejsu przeglądarki internetowej. Aby trwale poradzić sobie z tym problemem, klienty mogą też opcjonalnie blokować możliwość wykonywania kopii zapasowych. System BackupPC używa czasu przesyłania pakietu programu ping, aby stwierdzić, czy jest dostępny klient zdalnej sieci. Nie będzie go archiwizował, gdy czas ten będzie dłuższy od ustalonego. Pula archiwizacji Jeśli wiele klientów używa identycznego systemu operacyjnego, zostanie zarchiwizowanych wiele duplikatów plików. Przechowywanie wielu pełnych kopii zapasowych zwiększa liczbę duplikatów plików, co z kolei zwiększa zapotrzebowanie na przestrzeń dyskową serwera. Choć system BackupPC przechowuje drzewo katalogowe dla kopii zapasowej klienta, sprawdza, czy wcześniej zapisano już jakikolwiek plik pochodzący z dowolnego klienta. Jeśli jakiś plik już zarchiwizowano, system BackupPC za pomocą twardego dowiązania wskaże na plik istniejący we wspólnej puli dyskowej, co zaoszczędzi sporo miejsca. Ponadto, aby zyskać dodatkową przestrzeń, opcjonalnie system BackupPC może użyć kompresji. Przykładowo w przypadku serwera z dziewięcioma klientami (osiem z systemem Linux i jeden z systemem Windows 2000) archiwizuje się wyłącznie konfigurację systemową i pliki użytkowników. Przed zastosowaniem puli archiwizacji i kompresji serwer zawiera kopie zapasowe o rozmiarze 195 GB. Po zastosowaniu tych rozwiązań w rzeczywistości ilość wykorzystanej przestrzeni dyskowej spada poniżej 40 GB. Przykład dotyczy dwóch pełnych kopii zapasowych i kopii wykonywanych codziennie przez dwa tygodnie dla każdego klienta. Stosowanie puli wspólnych plików i kompresji zwykle redukuje wymagania dotyczące przestrzeni dyskowej serwera od sześciu do ośmiu razy. Prosta konfiguracja poszczególnych klientów Gdy administrator zdefiniuje zasady dotyczące archiwizowania danych środowiska, bardzo łatwo będzie mu nadpisać dowolną opcję konfiguracyjną ustawioną dla wybranego klienta. W ten sposób uzyskuje się sporą elastyczność, jeśli chodzi o to, co archiwizować na kliencie, a także kiedy i w jaki sposób. Choć nie istnieją klasy klientów jako takie, można je uzyskać przez zastosowanie w konfiguracji klientów dowiązań symbolicznych wyprowadzonych z elementu nadrzędnego do „klasy”.
Instrukcje instalacyjne Serwer BackupPC działa w systemie Unix lub Linux w obrębie serwera Apache używającego modułu mod_perl. Nie są to wymagania trudne do spełnienia. Serwer BackupPC nie został zaprojektowany pod kątem uruchamiania pod systemem Windows, ponieważ jego systemy plików nie radzą sobie dobrze z twardymi dowiązaniami systemów uniksowych. 176
|
Rozdz ał 5. BackupPC
Wstępne wymagania określają sposób sporządzania kopii zapasowych. W tabeli 5.1 wymieniono ogólne wymagania i zaproponowano narzędzia, które mogą je spełnić. Tabela 5.1. Wymagania systemu BackupPC Oprogramowan e
Proponowane narzędz e
Se we
Apache
TTP
Cecha
nne narzędz a
Uwag
Kont ola z poziomu g aficznego inte fejsu użytkownika
Dowolny se we TTP obsługujący p og amy CG
CG
mod_perl
Szybkość
Pe l
Pe l 5 8
Se we napisany w języku Pe l
tar
tar (we sja GNU)
Umieszczanie plików a chiwum w kontene ze p og amu tar w celu p zesłania do se we a
Dowolny p og am tar z wie szem polecenia
Jeśli używa się na zędzia tar
rsync
rsync (we sja GNU)
T anspo t od klienta do se we a
Dowolny p og am rsync z wie szem polecenia
Jeśli używa się na zędzia rsync
smbclient
Samba
T anspo t od klienta do se we a
Jeśli stosuje się p otokół SMB
ssh
OpenSS
Wa stwa t anspo towa
Jeżeli używa się p og amu tar lub rsync
Opcjonalne
Ilość wymaganej przestrzeni dyskowej zależy od pojemności i rodzaju danych, które będą archiwizowane. Im bardziej zróżnicowane dane, tym więcej potrzeba miejsca na dysku. Choć podsystem dyskowy RAID nie jest konieczny, warto z niego skorzystać ze względu na wydajność, ochronę danych i skalowalność. Serwer nie wymaga niczego więcej poza procesorem 1,5 GHz i pamięcią RAM o pojemności przynajmniej 512 MB. Ponieważ większość obliczeń wykonywanych podczas archiwizowania ma związek z kompresowaniem, w przypadku dużej liczby klientów trzeba będzie użyć większej ilości pamięci i szybszego procesora. Oczywiście szybsze technologie dyskowe i mniej obciążone sieci też przyczynią do zwiększenia wydajności.
Bezpieczeństwo kontra łatwość obsługi Jak to często bywa, trzeba pójść na kompromis między łatwością użytkowania i bezpieczeństwem. W domowej instalacji łatwość wykonywania operacji zwykle ma wyższy priorytet niż bezpieczeństwo. Odwrotnie może być w przypadku oddziału globalnej firmy. W domyślnej konfiguracji usługa systemu BackupPC działa na serwerze z uprawnieniami własnego użytkownika, a w celu połączenia się z klientami jako superużytkownik korzysta ze wspólnych kluczy programu ssh bez zdefiniowanych haseł lub z protokołu SMB z ustawionym hasłem (w przypadku klienta z systemem Windows). Może to być niezgodne z lokalnymi zasadami bezpieczeństwa organizacji. Z innych opcji należy wymienić konfigurowanie serwera rsync po stronie klienta używającego zapisanych haseł i dwuetapowy proces polegający na
nstrukcje nstalacyjne
|
177
połączeniu się za pomocą programu ssh z kontem klienta o niewielkich przywilejach, a następnie zastosowaniu polecenia sudo z konfiguracją umożliwiającą uruchomienie tylko narzędzia rsync (lub tar). Wszystkie procesy systemu BackupPC uruchomione na serwerze używają jednego identyfikatora użytkownika. Użytkownik ten powinien mieć w systemie ograniczone przywileje. Proces instalacji zapewnia, że wybrany identyfikator użytkownika ma poprawne uprawnienia w obszarach magazynowania danych. Jeśli zastosuje się nowy identyfikator użytkownika, konfiguracja interfejsu internetowego będzie wymagać kilku dodatkowych kroków. Jeżeli wykorzysta się istniejący identyfikator serwera WWW, będzie trzeba wykonać mniej kroków konfiguracyjnych, lecz system będzie mniej bezpieczny. Gdy zamierza się zastosować nowy identyfikator użytkownika, należy go utworzyć przed rozpoczęciem procesu instalacji.
Określanie wymaganej przestrzeni dyskowej Ilość potrzebnego miejsca na dysku w dużej mierze zależy od liczby i typów archiwizowanych klientów. Im mniej zróżnicowane klienty, tym bardziej efektywna pula dyskowa i mniejsze zapotrzebowanie na przestrzeń dyskową. Im bardziej klienty się różnią, tym mniej efektywna jest pula dyskowa i tym większe są wymagania dotyczące przestrzeni dyskowej. Ponadto, jeśli dane są dość statyczne, mniej miejsca będzie potrzebne na przyrostowe kopie zapasowe. W przypadku dużej zmienności danych przyrostowe kopie będą większe. Na wymagania dotyczące przestrzeni dyskowej wpływ ma również zasada retencji. Oczywiście im więcej pełnych kopii zapasowych i dłuższe okresy retencji, tym większe zapotrzebowanie na przestrzeń dyskową.
Czym jest usługa NIS+? Zadzwonił do mnie klient po tym, jak miał trochę problemów z usługą NIS+. Tamtejszy kierownik (inżynier, lecz nie informatyk) chciał usunąć niepotrzebne pliki ze swojej partycji /var. Wśród plików, które uznał za nadające się do usunięcia, znalazło się kilka przydatnych plików dzienników (były to dzienniki transakcji głównego serwera usługi NIS+). Serwer NIS+ od razu stwierdził, że jego dzienniki transakcji są niedostępne, i przestał działać. Gdy się tam pojawiłem, poprosiłem administratora zajmującego się archiwizowaniem danych o taśmy z kopiami zapasowymi. Firma co tydzień sporządzała pełne kopie zapasowe bez przyrostowych. Stwierdziłem, że taśmy z wszystkich czterech tygodni nie były kompletne. Przez ponad sześć tygodni podczas tworzenia kopii zapasowych występowały błędy i nikt nic w związku z tym nie zrobił. Musiałem ponownie utworzyć bazy danych na podstawie wszelkich informacji, które udało mi się znaleźć, i usunąłem problem ze skryptem archiwizującym. Zmieniłem również wyjście skryptu, dzięki czemu w przypadku pojawienia się błędów informował o tym bardziej otwarcie (mam nadzieję, że na tyle, aby nie zostać całkowicie zignorowanym). — Michael Rice
W celu określenia ilości przestrzeni dyskowej wymaganej przez kopie zapasowe należy zsumować wykorzystanie miejsca na dysku przez każdego klienta, a następnie wynik pomnożyć przez liczbę skonfigurowanych pełnych kopii zapasowych. Uzyskana wartość identyfikuje
178
|
Rozdz ał 5. BackupPC
pojemność wymaganą przez pełne kopie zapasowe (przed użyciem puli dyskowej i kompresji). Dalej należy oszacować, jaki procent danych zmieni się w przypadku każdej przyrostowej kopii zapasowej. Wartość tę należy pomnożyć przez całkowitą pojemność danych, a następnie przez liczbę skonfigurowanych przyrostowych kopii zapasowych. Wynik należy dodać do wartości otrzymanej dla pełnych kopii zapasowych. Kompresja i pula dyskowa zmniejszają wymagania na przestrzeń dyskową od sześciu do ośmiu razy. W związku z tym uzyskaną sumę należy podzielić przez liczbę z tego przedziału. Aby zapewnić zapas miejsca na dysku, gdy wzrośnie na nie zapotrzebowanie klienta i doda się większą liczbę klientów, na początku można przeznaczyć do przechowywania kopii zapasowych dwu- lub trzykrotnie większą pojemność od wyznaczonej. Oto przykład. Archiwizujemy dane użytkowników 100 laptopów, w przypadku których na jednego klienta średnio przypadają 4 GB danych. Ponadto każda przyrostowa kopia średnio ma około 0,4 GB. Na przechowanie pełnych kopii zapasowych z okresu trzech tygodni potrzeba około 1200 GB, a sześć przyrostowych kopii zajmuje dalszych 240 GB. W sumie archiwizowanych jest 1440 GB danych. Dzięki zastosowaniu puli dyskowej i kompresji wymagana przestrzeń dyskowa w przybliżeniu wyniesie od 180 do 240 GB. Pojemność 500 GB lub większa powinna wystarczyć także w długim okresie, gdy zwiększy się ilość danych użytkowników i liczba klientów. Ponieważ system BackupPC używa twardych dowiązań do bardziej zwartego przechowywania identycznych plików, cały magazyn danych musi znajdować się w obrębie jednego systemu plików. Gdy użyje się macierzy RAID lub konfiguracji LVM, taki system plików w razie potrzeby może być z czasem rozszerzany.
Instalowanie systemu BackupPC Po zidentyfikowaniu serwera, a także spełnieniu wymagań wstępnych i sprawdzeniu, czy są spełnione, pora przejść do konkretów. Spod adresu http://backuppc.sourceforce.net należy pobrać najnowsze archiwum programu tar. Nie należy używać wersji beta, jeśli nie ma konkretnego powodu, aby to zrobić. Jeżeli jest dostępny plik poprawek, też należy go pobrać. Plik archiwum programu tar należy przenieść do roboczego katalogu i rozpakować. Dalej należy przejść do nowo utworzonego katalogu. Jeśli pobrano plik poprawek, należy wykonać następujące polecenie: $ patch -p0 < [ścieżka_pliku_poprawek]
Jeśli pojawi się komunikat o błędzie, taki jak Hunk #1 FAILED at 58, oznacza to, że coś poszło nie tak i powinno się sprawdzić, czy wersja pliku poprawek jest zgodna z pobraną dystrybucją. Jeżeli w dalszym ciągu nie udało się usunąć problemu, należy poszukać pomocy na liście wysyłkowej (więcej informacji można znaleźć na końcu rozdziału w podrozdziale „Społeczność związana z systemem BackupPC”). Następnym logicznym krokiem jest odczytanie pliku README w celu zapoznania się z wszystkimi szczegółami, które mogły zmienić się w przypadku pobranej wersji. Dodatkowo w katalogu doc/ zamieszczono aktualną i kompletną dokumentację. Czytając plik BackupPC.html, należy zwrócić uwagę na konkretne wymagania wymienione w sekcji instalacyjnej. Zwykle trzeba zainstalować kilka modułów języka Perl, w zależności od sposobu skonfigurowania systemu.
nstrukcje nstalacyjne
|
179
Pora wykonać następujące polecenie z uprawnieniami superużytkownika: # perl ./configure.pl
W efekcie zostanie sprawdzony system i użytkownik zostanie poproszony o wprowadzenie kilku informacji instalacyjnych. Oto one: Full path to existing conf/config.pl Ma to zastosowanie tylko w przypadku aktualizacji. Gdy przeprowadza się nową instalację, należy wcisnąć klawisz Enter. Are these paths correct? Należy sprawdzić, czy lista programów została całkowicie zakwalifikowana. Jeśli programu nie znaleziono, lecz nie planuje się z niego korzystać, bezpiecznie będzie go zignorować. Jeżeli na liście znajdują się wszystkie wymagane programy, należy wcisnąć klawisz Y. Jeśli brakuje jakiegoś ważnego programu, należy wcisnąć kombinację klawiszy Ctrl+C, aby przerwać instalację. Po usunięciu problemu należy ponownie uruchomić skrypt konfiguracyjny. BackupPC will run on host Skrypt odgaduje nazwę hosta. W razie potrzeby należy ją poprawić. BackupPC should run as user Chodzi o identyfikator użytkownika, który będzie uaktywniał na serwerze wszystkie procesy systemu BackupPC. Należy utworzyć użytkownika bez żadnych specjalnych przywilejów lub wybrać istniejącego z ograniczonymi przywilejami. Install directory (full path) Dotyczy to miejsca przechowywania plików programów i bibliotek systemu BackupPC. Data directory Chodzi o lokalizację danych. Powinny one być zapisywane na własnej partycji i w razie możliwości na dedykowanym dysku lub macierzy RAID. Compression level Dotyczy to poziomu kompresji używanego podczas archiwizowania danych. Trzeba pójść na kompromis między poziomem kompresji i szybkością procesu. Ustalona wartość powinna zawierać się w przedziale od 0 do 9, gdzie 0 oznacza brak kompresji, a 9 — jej najwyższy poziom, powodujący największe obciążenie procesora. Domyślna liczba 3 jest dobrą średnią wartością. CGI bin directory Pełna ścieżka katalogu serwera WWW przechowującego programy CGI. Apache image directory Dotyczy to katalogu przechowującego pliki obrazów dla internetowego graficznego interfejsu. Powinien to być katalog, do którego serwer WWW ma dostęp. URL for image directory (omit http://host; starts with "/") Dotyczy to zawartości ostatniej części adresu URL, którą jest ścieżka katalogu obrazu. Na tym etapie powinny być udzielone odpowiedzi na większość pytań. Skrypt pyta następnie, czy przed faktycznym zmodyfikowaniem systemu użytkownik chce kontynuować. Wciśnięcie klawisza Y umożliwi skryptowi zdefiniowanie niezbędnej struktury katalogowej i zainstalowanie skryptów, które będą uruchamiane. Jak w przypadku każdego skryptu instalacyjnego należy monitorować wyjście pod kątem wszelkich błędów. Kilka skryptów inicjalizujących jest 180
|
Rozdz ał 5. BackupPC
aktualizowanych przy użyciu ustawień zależnych od odpowiedzi udzielonych na pytania konfiguracyjne. Jednak skrypty te nie są automatycznie instalowane. Znajdują się w podkatalogu init.d, z którego uruchomiono skrypt konfiguracyjny. Aby podczas ładowania systemu była uruchamiania usługa, odpowiedni skrypt należy skopiować we właściwe miejsce. Warto zauważyć, że począwszy od wersji 3.0 systemu BackupPC skrypt configure.pl jest zgodny ze standardem HFS (Filesystem Hierarchy Standard). Jedną ze zmian jest to, że domyślnie wszystkie pliki konfiguracyjne zamiast w magazynie danych są przechowywane poniżej katalogu /etc. Jak wspomniano, po uruchomieniu skryptu konfiguracyjnego można zmienić dowolną z domyślnych lokalizacji. Jeśli po raz pierwszy aktualizuje się system BackupPC do wersji 3.0 lub nowszej, skrypt configure.pl w dalszym ciągu korzysta z oryginalnych lokalizacji magazynu danych, plików konfiguracyjnych i programów wykonywalnych.
Pakiety instalacyjne Alternatywą dla wyżej przedstawionej procedury ręcznej instalacji jest poszukanie i zainstalowanie pakietu systemu BackupPC przeznaczonego dla wykorzystywanego systemu operacyjnego. Istnieją pakiety dla systemów: Debian, Ubuntu, Gentoo i innych. Przykładowo, wykonując poniższe polecenie, pakiet BackupPC można zainstalować pod systemem Debian. # apt-get install backuppc
Uruchamianie serwera BackupPC Serwer BackupPC jest ładowany przez skrypt katalogu init.d utworzony podczas instalacji. Oznacza to, że skrypt jest automatycznie wczytywany po ponownym uruchomieniu systemu.
Zastosowanie interfejsu CGI Domyślnie interfejs CGI powinien być dostępny za pośrednictwem adresu URL http://localhost/ cgi-bin/BackupPC/BackupPC_Admin. Zależnie od konfiguracji serwera Apache może być konieczne utworzenie pliku htaccess na potrzeby uwierzytelniania użytkownika.
Pliki konfiguracyjne Począwszy od wersji 3.0 ustawienia hosta i konfiguracyjne mogą być edytowane przy użyciu interfejsu CGI. Przez ręczną edycję plików konfiguracyjnych i hosta można też skonfigurować serwer. W tym celu należy przejść do katalogu danych określonego w czasie instalacji. Dalej należy przejść do katalogu conf. W wersji 3.0 i nowszych domyślnym katalogiem konfiguracyjnym jest /etc/BackupPC/conf. W katalogu conf znajdują się dwa pliki, które muszą być zmodyfikowane, zanim będzie można skorzystać z systemu BackupPC. Pierwszy plik nosi nazwę hosts i przechowuje wszystkie nazwy hostów, które będą archiwizowane przez serwer. Format pliku jest następujący: host
dhcp
użytkownik
więcej_użytkowników
Łańcuch host identyfikuje nazwę hosta klienta. Łańcuch dhcp ma wartość 0, jeśli komputer może być zlokalizowany za pomocą zwykłych mechanizmów rozwiązywania nazw, lub wartość 1, gdy usługa musi poszukiwać hosta w puli DHCP. Łańcuch użytkownik określa nazwę lub
Urucham an e serwera BackupPC
|
181
adres e-mail podstawowego właściciela komputera. Łańcuch więcej_użytkowników jest listą użytkowników (oddzielonych przecinkami), którzy będą w stanie uzyskać dostęp do hosta za pośrednictwem graficznego interfejsu przeglądarki internetowej. Plik config.pl zawarty w katalogu konfiguracyjnym pełni rolę głównego pliku konfiguracyjnego. Jak nazwa wskazuje, jest to skrypt Perl. W związku z tym wszystkie zmienne są ustawiane z zastosowaniem składni języka Perl, który pozwala użyć tablic do przechowywania wartości. Plik określa liczbę wykonywanych kopii zapasowych (zmienna $Conf{MaxBackups}), liczbę zapisywanych pełnych kopii (zmienna $Conf{FullKeepCnt}) i czas upływający między sporządzeniem pełnych kopii (zmienna $Conf{FullPeriod}). Należy zapoznać się z zawartością pliku config.pl, który jest dobrze udokumentowany i uwzględnia wiele modyfikowalnych ustawień.
Trzeba ufać, ale też weryfikować W firmie petrochemicznej, w której pracowałem, każda stacja robocza miała lokalny napęd danych, a także napęd taśmowy. Bardzo oczywiste dla każdego, kto dysponował komputerem z napędem taśmowym, było to, że odpowiadał za archiwizowanie własnych danych. Utworzyliśmy skrypty i zadania programu cron, a także przeprowadziliśmy szkolenie w zakresie metod archiwizowania danych. Raz na kwartał pojawialiśmy się w firmie, żeby wyczyścić napędy taśmowe. Jednak nie mogliśmy wykonywać kopii zapasowych (w firmie było trzech administratorów, którym podlegało 300 oddziałów; po prostu fizycznie było niemożliwe archiwizowanie danych w tak wielu miejscach). W tamtym czasie nie było możliwe sporządzanie kopii zapasowych za pośrednictwem sieci. Pewnego dnia zadzwonił do nas dobrze opłacany geofizyk, mówiąc, że zepsuł się jego napęd dyskowy o pojemności 9 GB (w tamtym czasie było to sporo). Wymieniliśmy uszkodzony dysk i poprosiliśmy tę osobę o taśmę archiwizacyjną, z której odtworzymy dane. W odpowiedzi usłyszeliśmy: „Jaka taśma?”. Wysłaliśmy uszkodzony napęd dyskowy, aby przeprowadzono dla niego „odtwarzanie danych”. Operacja zajęła kilka miesięcy i kosztowała ponad 20 000 dolarów. Większość danych udało się przywrócić — to były wyniki pracy geofizyka z ostatnich sześciu miesięcy (przez tyle czasu napęd działał). Geofizyk niemal został zwolniony za to, że „nie dbał o bezpieczeństwo zasobów firmy”. Choć nie udało nam się zmienić tego, że geofizyk odpowiadał za wykonywanie kopii zapasowej swoich danych, bardziej dokładnie i częściej przyglądaliśmy się temu, co robią pracownicy firmy. — Jack
Konfigurowanie klienta Bardzo łatwo nadpisać domyślne ustawienia klienta. Poniżej katalogu danych znajduje się katalog pc, w którym dla każdego klienta jest tworzony jeden katalog. Aby dla klienta określić niestandardowe ustawienia, w odpowiednim katalogu wystarczy utworzyć nowy plik config.pl z wymaganymi ustawieniami. W przypadku wersji 3.0 pliki z konfiguracją klientów są przechowywane poniżej katalogu /etc/BackupPC/pc. Pliki konfiguracyjne klientów służą do określania różnych ustawień związanych z transferem, a także haseł, wykluczonych plików i liczby kopii zapasowych, które będą zapisywane. Przykładowo główny plik konfiguracyjny może ustawić zmienną XferMethod o wartości smb dla klientów z systemem Windows. Z kolei pliki konfiguracyjne klientów z systemem Linux mogą 182
|
Rozdz ał 5. BackupPC
zmienić wartość tej zmiennej na tar lub rsync. W pliku konfiguracyjnym klienta można nadpisać niemal każde ustawienie. Wyjątkiem są wszelkie ustawienia mające związek z samym serwerem, takie jak ustawienie harmonogramu aktywacji.
Społeczność związana z systemem BackupPC Ile istnieje instalacji systemu BackupPC? Biorąc pod uwagę charakter projektu oprogramowania open source, bardzo trudno podać dokładne liczby, lecz na podstawie poniższych można się ogólnie zorientować. Od września 2001 r. do końca lutego 2006 r. było ponad 87 000 pobrań podstawowej wersji systemu BackupPC z witryny internetowej SourceForge.net. Pobrania te nie uwzględniają instalacji przy użyciu pakietów stworzonych dla standardowych dystrybucji Linuksa, takich jak Debian. W tamtym okresie strona projektu systemu BackupPC wchodząca w skład witryny SourceForge.net została wyświetlona przez ponad cztery miliony internautów. Projekt mieści się w rankingu pierwszych pięciuset projektów witryny SourceForge.net (wszystkich projektów jest ponad 110 000). Na stronie internetowej Freshmeat projekt systemu BackupPC w rankingu popularności wśród użytkowników znalazł się w pierwszej pięćdziesiątce (wszystkich projektów było ponad 40 000). Obecnie różnej wielkości organizacje korzystają z systemu BackupPC, począwszy od domowych użytkowników i niewielkich firm, a skończywszy na organizacjach pozarządowych, szkołach, uniwersytetach, działach korporacji i dużych spółkach. Część z największych instalacji systemu BackupPC uwzględnia dużą uczelnię z 1500 klientami i oddział sporej firmy z 4000 klientów. Każda z tych instalacji obejmuje wiele serwerów z kilkoma terabajtami przestrzeni dyskowej. Społeczność związana z systemem BackupPC jest bardzo aktywna i pomocna. Istnieje kilka sposobów, aby się do niej przyłączyć i wziąć aktywny udział w jej działalności. Jeśli pojawią się problemy, z prośbą o pomoc można skierować się w wiele miejsc. Strona internetowa systemu BackupPC (http://backuppc.sourceforge.net) oferuje społeczności użytkowników wiele pomocnych narzędzi. Dokumentacja obejmuje szczegółowy opis konfiguracji i na bieżąco jest uaktualniana o zmiany wprowadzone w kodzie. Witryna SourceForge.net zawiera również listę najczęstszych pytań i odpowiedzi na nie. Jeśli nie można znaleźć odpowiedzi w tej witrynie, zwykle wystarczy poszukać jej w archiwum listy wysyłkowej lub wysłać do niej wiadomość. Adres podstawowej listy wysyłkowej to [email protected]. Główni projektanci są bardzo aktywni na liście i poświęcają swój czas, aby pomóc początkującym użytkownikom. Choć objętość samej listy nie jest duża, poziom dyskusji jest bardzo wysoki. Uczestnicy listy są bardzo tolerancyjni w stosunku do początkujących i starają się im pomóc. Projektanci odpowiadają bardzo szybko, a w przypadku zidentyfikowania nowego błędu współpracują z osobą, która go zgłosiła, aby znaleźć rozwiązanie. Wysyłając na listę wiadomość, należy próbować dołączyć jak najwięcej informacji, takich jak nazwa systemu operacyjnego serwera i klienta, kopia plików konfiguracyjnych i sekcje błędów z dzienników.
Przyszłość systemu BackupPC System BackupPC jest cały czas wzbogacany o nowe funkcje. Ostatnie dodatki obejmują edytor konfiguracji w pełni oparty na interfejsie CGI i poprawioną obsługę międzynarodową. Obecnie aktywne prace projektowe są prowadzone nad projektem BackupPCd, realizowanym Przyszłość systemu BackupPC
|
183
jednocześnie z projektem dotyczącym głównego serwera systemu BackupPC. BackupPCd jest klientem serwera BackupPC, który będzie zajmował się wszystkim, co dotyczy klienta. Klient BackupPCd będzie też dysponował własnym protokołem komunikowania się z serwerem. Protokół ten oparty jest na protokole narzędzia rsync, zapewniającym pewny i efektywny mechanizm transportowy. System BackupPC w dalszym ciągu będzie obsługiwał istniejące mechanizmy transportowe, takie jak protokół SMB i narzędzie tar, wykorzystujące programy ssh i rsync. Gdy jednak dodatkowo zastosuje się klienta BackupPC, możliwe będzie archiwizowanie list kontroli dostępu ACL i innych metadanych plików, uniknie się konieczności instalowania dla programu rsync narzędzia cygwin na komputerach z systemem Windows, umożliwi użycie jednego protokołu archiwizacji w przypadku różnych systemów operacyjnych klientów, a także zapewni lepszą wydajność. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www.backup central.com można przeczytać aktualizowane informacje lub dodać do nich własne.
184
|
Rozdz ał 5. BackupPC
ROZDZIAŁ 6.
Bacula
Bacula jest archiwizującym oprogramowaniem open source, zaprojektowanym tak, aby można było je zastosować na pojedynczych komputerach, a także w sieciach przedsiębiorstw. Narzędzie to jest w stanie archiwizować dane przy użyciu dowolnej kombinacji nośników dyskowych, taśmowych lub optycznych. Obecnie serwer Bacula działa na komputerze z systemem Linux lub Unix, a klienty są dostępne dla różnych odmian systemów Unix i Linux, wersji systemu Windows nowszych od wersji 98 SE i systemu Mac OS X. Trwają aktywne prace projektowe nad serwerem Bacula dla systemu Windows. Pierwsza wersja narzędzia Bacula ma oznaczenie 1.40. Jak w przypadku początkowej wersji dowolnego oprogramowania, przed zastosowaniem narzędzia Bacula w środowisku produkcyjnym warto je intensywnie przetestować. W tworzeniu niniejszego rozdziału brał udział Adam Thornton. Od 1989 r. Adam zajmuje się administrowaniem systemami, a także ich analizą i architekturą. Oprócz systemów archiwizujących jego pasje to stare komputery, miksologia, a także spędzanie czasu z psami.
Narzędzie Bacula zostało oryginalnie napisane w 2000 r. przez Johna Walkera i Kerna Sibbalda. Niedługo po rozpoczęciu projektu John odszedł i od połowy 2000 r. Kern (obecnie jest główną osobą zajmującą się oprogramowaniem Bacula) sam się nim zajmował aż do publicznego udostępnienia pierwotnej wersji narzędzia w kwietniu 2002 r. Od tego czasu w projekcie wzięli udział także inni projektanci, wspierając nieustanne działania Kerna. Narzędzie Bacula jest dostępne w ramach zmodyfikowanej licencji publicznej GNU w wersji 2. Dodatkowe ograniczenia dodane do tej licencji są dostępne w pliku LICENSE umieszczonym na najwyższym poziomie drzewa katalogowego oprogramowania Bacula. Strona główna projektu znajduje się pod adresem http://www.bacula.org. Pliki do pobrania i repozytorium CVS są obsługiwane przez witrynę SourceForge.net.
Architektura oprogramowania Bacula Narzędzie Bacula jest złożone z kilku współpracujących ze sobą komponentów, które w celu komunikowania się za pośrednictwem sieci używają gniazd TCP. Zastosowanie stosu protokołów TCP/IP w roli warstwy transportowej składników ma kluczowe znaczenie w filozofii projektowania narzędzia, ponieważ umożliwia wdrażanie komponentów na wielu lub pojedynczych komputerach (stosownie do możliwości lub dostępu do specjalistycznego sprzętu), 185
a także zapewnia uniwersalną metodę dla poleceń wykonywanych między składnikami. W celu ochrony danych podczas transmisji protokół transportowy TCP można umieścić w standardowej warstwie szyfrującej TLS (Transport Layer Security). Warstwę tę bardziej szczegółowo omówiono w dalszej części rozdziału w podrozdziale „Zaawansowane funkcje”.
Składniki oprogramowania Bacula Rysunek 6.1 przedstawia strukturę narzędzia Bacula i sposób powiązania jego składników.
Rysunek 6.1. Interakcje występujące między składnikami oprogramowania Bacula (źródło: dokumentacja narzędzia Bacula)
Niezależne składniki narzędzia Bacula zaprezentowane na rysunku zapewniają podstawowe funkcje w jego środowisku. Poniższa lista identyfikuje każdy komponent i opisuje funkcję, którą zapewnia całej aplikacji.
186
|
Rozdz ał 6. Bacula
Nadzorca Nadzorca odgrywa w środowisku oprogramowania Bacula centralną rolę. Zarządza definicjami puli nośników, planowaniem, śledzeniem zależności, kontrolą dostępu i raportowaniem. Nadzorca odpowiada za niemal wszystkie konfiguracje oparte na zasadach. Większość zmian konfiguracji narzędzia Bacula jest dokonywana w pliku konfiguracyjnym nadzorcy. Serwer bazodanowy Katalog (indeks lokalizacji zarchiwizowanych plików) jest kolejnym zasadniczym elementem filozofii projektowania oprogramowania Bacula. Katalog jest przechowywany w relacyjnej bazie danych i udostępniany za pomocą zapytań pobierających i aktualizujących języka SQL. Obecnie oprogramowanie Bacula obsługuje trzy bazy danych: SQLite, MySQL i PostgreSQL. Demon magazynowania Demon magazynowania narzędzia Bacula zarządza interakcją z nośnikiem używanym do przechowywania zarchiwizowanych danych. Demon ten jest jedynym składnikiem oprogramowania Bacula, który faktycznie komunikuje się z woluminami (taśma, dysk twardy lub DVD-ROM) służącymi do archiwizowania. Wszystkie inne komponenty narzędzia Bacula korzystają z interfejsu TCP/IP demona magazynowania, aby połączyć się z nim, i nie są „świadome” metod faktycznie stosowanych do zapisywania i odczytywania danych. Demon magazynowania zarządza podłączaniem i odłączaniem woluminów magazynujących, etykietowaniem taśm (przy wykorzystaniu kodów paskowych OCR, jeśli są dostępne), a także zautomatyzowanymi ładowarkami i bibliotekami taśmowymi. Konsola administracyjna Konsola administracyjna zapewnia operatorowi interfejs użytkownika umożliwiający zarządzanie zadaniami, przetwarzanie wiadomości i informacji o stanie. Z poziomu konsoli można również realizować operacje związane z administrowaniem woluminami (na przykład ręczne etykietowanie nowego woluminu magazynującego). Występuje wiele odmian konsoli. Dostępna dla wszystkich platform konsola z trybem wiersza poleceń jest przeważnie dobrze obsługiwana i wybiera ją większość administratorów. Konsola z graficznym interfejsem użytkownika jest dostępna w systemach z bibliotekami wxWidgets. Obecnie w graficznym interfejsie użytkownika jest wbudowany interfejs wiersza poleceń. Dzięki temu proces interaktywnego odtwarzania plików jest trochę łatwiejszy, a ponadto dostępna jest funkcja uzupełniania klawiszem Tab i natychmiastowa interaktywna pomoc dla wykonywanych poleceń. Konsola trybu wiersza poleceń często jest preferowana głównie dlatego, że za jej pomocą łatwo wykonywać operacje w przypadku połączeń o niewielkiej przepustowości (zdalne administrowanie staje się prostsze). Konsola narzędzia Bacula nie musi być uruchomiona na tym samym komputerze co nadzorca. Jeden z głównych obecnie realizowanych projektów związanych z oprogramowaniem Bacula ma na celu utworzenie graficznego interfejsu użytkownika bazującego na języku Python, który będzie znacznie bardziej rozszerzalny i elastyczny niż obecnie stosowany graficzny interfejs oparty na bibliotekach wxWidgets.
Demon plików Demon plików zajmuje się przenoszeniem danych z klienta na serwer magazynujący. Musi być zainstalowany na każdym komputerze, który będzie archiwizowany. Składnik ten komunikuje się z nadzorcą, aby stwierdzić, jakie dane klienta będą archiwizowane i który
Arch tektura oprogramowan a Bacula
|
187
demon magazynowania zostanie użyty, a następnie transmituje dane bezpośrednio do wybranego demona magazynowania, włącznie z metadanymi (rozmiar pliku, parametry kontroli dostępu i dane na temat praw własności) dotyczącymi przesyłanych plików. Narzędzie Bacula zapewnia też niewielkie monitory umieszczane na pasku aplikacji systemu Windows, a także środowisk graficznych GNOME i KDE (częściowo są obsługiwane również inne środowiska zgodne ze standardem paska systemowego umiejscawianego w dowolnym miejscu pulpitu), które informują o stanie. Monitor jest po prostu ikoną znajdującą się na pasku systemowym i wskazującą, czy składniki narzędzia Bacula na lokalnym komputerze znajdują się w stanie bezczynności, realizowania zadania lub błędu. Ikony takich monitorów stanu mogą być rozszerzane, aby wyświetlały pełną informację na temat stanu.
Interakcja między składnikami Rysunek 6.2 pokazuje przepływ informacji między komponentami oprogramowania Bacula w przypadku typowego zadania archiwizacyjnego.
Rysunek 6.2. Przepływ informacji w środowisku oprogramowania Bacula
W czasie działania nadzorca instruuje demona plików, żeby połączył się bezpośrednio z odpowiednim demonem magazynowania. Dzięki temu nadzorca nie bierze udziału w mocno obciążonej ścieżce procesu archiwizowania danych. Ponieważ nadzorca dysponuje własną usługą planowania, zadania mogą być realizowane (o ustalonych porach) bez potrzeby używania konsoli lub wykonywania poleceń przez dowolnego użytkownika. Wynik zaplanowanych zadań jest przekazywany za pośrednictwem poczty elektronicznej do jednego lub większej liczby administratorów ustalonych podczas konfigurowania nadzorcy.
Uwierzytelnianie Każda ścieżka komunikacyjna między składnikami oprogramowania Bacula używa nazwy komponentu i hasła. Hasła są znane obu łączącym się stronom i przechowywane w postaci niezaszyfrowanej w plikach konfiguracyjnych narzędzia Bacula (jednak metody instalacyjne pakietu zwykle definiują hasła jako losowo wybrane łańcuchy). Hasła są stosowane podczas uwierzytelniania w celu zakodowania wezwania i znaczników odpowiedzi. Hasła nigdy nie 188
|
Rozdz ał 6. Bacula
są przesyłane bezpośrednio w sieci. Możliwe jest również skonfigurowanie narzędzia Bacula z wykorzystaniem warstwy TLS. Warstwę tę bardziej szczegółowo omówiono w dalszej części rozdziału, w podrozdziale „Zaawansowane funkcje”.
Konfigurowanie Każdy składnik oprogramowania Bacula (z wyjątkiem serwera bazodanowego, który jest kontrolowany przez pliki konfiguracyjne bazy danych) ma własny plik konfiguracyjny składający się z jednego lub większej liczby zestawów instrukcji określających zasoby, które opisują obiekty oprogramowania Bacula, a także sposób, w jaki powinny być obsługiwane przez system. Bardziej złożone konfiguracje, takie jak wykorzystujące automatycznie generowane składniki, mogą być dzielone na wiele plików i indywidualnie dołączane. Choć domyślna podstawowa konfiguracja dołączona do pakietu jest rozsądna, definicje zasobów mogą być edytowane za pomocą dowolnego standardowego edytora tekstu.
Funkcje oprogramowania Bacula Narzędzie Bacula ma kilka funkcji odróżniających je od innych systemów archiwizujących open source. Poniżej znajduje się przegląd tych funkcji. Katalog SQL Katalog zawiera listę zarchiwizowanych plików, podstawowe atrybuty każdego z nich, włącznie z sumą kontrolną, nazwę hosta klienta, z którego pochodzi plik, a także woluminy przechowujące kopie zapasowe plików. Z tego powodu katalog odgrywa kluczową rolę w operacji archiwizowania i odtwarzania. Katalog przechowuje rekordy z informacjami, co zostało zarchiwizowane i kiedy. Choć dołączony program bscan może pomóc w rekonstrukcji katalogu, gdy ten się uszkodzi, zwykle katalog powinien być niezależnie archiwizowany po każdym cyklu archiwizacyjnym. Kopie zapasowe na wielu woluminach Jedną z cech wyróżniających narzędzia Bacula jest jego znakomita obsługa zapisu kopii zapasowych na wielu woluminach. Gdy oprogramowanie Bacula ma do dyspozycji automatyczną zmieniarkę, może po prostu wymieniać taśmy bez interwencji operatora (jeśli się je odpowiednio skonfiguruje, narzędzie może dynamicznie etykietować nowe woluminy). Nawet w przypadku komputera z pojedynczym napędem Bacula automatycznie prosi (za pośrednictwem konsoli lub poczty elektronicznej) o następną taśmę, gdy musi użyć dodatkowego nośnika. Elastyczna obsługa nośników Bacula może archiwizować dane na różnego typu nośnikach, korzystając z dysku lub taśmy z podobną łatwością. Automatyczne zmieniarki SCSI po prostu działają od razu po zainstalowaniu. Narzędzie Bacula obejmuje narzędzia upraszczające przenoszenie kopii zapasowych na dysk CD (program bimagemgr) lub DVD (program dvd-handler). Obsługa przenośnych automatycznych zmieniarek pozwala bez większych problemów integrować z oprogramowaniem Bacula bardzo duże magazyny danych. Poziomy archiwizacji Podobnie do większości innych systemów archiwizujących oprogramowanie Bacula umożliwia tworzenie kopii zapasowych: pełnych (przechowują wszystkie archiwizowane dane), różnicowych (zawierają pliki zmienione od momentu sporządzenia ostatniej pełnej kopii Funkcje oprogramowan a Bacula
|
189
zapasowej) i przyrostowych (obejmują pliki zmienione od czasu utworzenia ostatniej kopii dowolnego rodzaju). Wymagany poziom archiwizacji jest określany w definicji lub harmonogramie zadania archiwizacyjnego i może zostać nadpisany, gdy zadanie zostanie ręcznie uaktywnione. Jeśli zaplanowano wykonanie pełnej kopii zapasowej, lecz w katalogu nie ma jeszcze zapisu dotyczącego tego typu kopii, narzędzie Bacula automatycznie zamieni zadanie mające na celu sporządzenie różnicowej lub przyrostowej kopii na zadanie tworzące pełną kopię. Format przechowywania narzędzia Bacula Wszystkie dane archiwizowane przez oprogramowanie Bacula są zapisywane na woluminach. Wolumin jest po prostu repozytorium zarchiwizowanych danych. Może to być taśma, nośnik optyczny lub po prostu plik. Narzędzie Bacula używa unikatowego formatu zamiast standardowego, takiego jak format programu tar lub dump. Taka decyzja projektantów zapewnia spójność między platformami i instalacjami oprogramowania Bacula. Załóżmy, że użyto formatu archiwum narzędzia tar. Choć wersja GNU programu tar jest obecna w większości instalacji systemu Linux, w pozostałych jego instalacjach mogą być stosowane inne wersje narzędzia. W efekcie instalacje te nie zawsze będą ze sobą zgodne. Może to utrudnić rozpakowanie archiwum utworzonego na innej platformie. Oprogramowanie Bacula eliminuje ten problem przez pełne określanie formatu przechowywania. Choć powyższa decyzja ma wyraźne korzyści, powoduje też, że do wyodrębniania danych z kopii zapasowych narzędzia Bacula (gdy nie jest zainstalowane) trzeba użyć specjalizowanych narzędzi. Generalnie w celu odtworzenia plików najlepiej skorzystać z aktywnego nadzorcy narzędzia Bacula, katalogu i konsoli. Jednak oprogramowanie Bacula oferuje niezależne programy bls i bextract, umożliwiające odtwarzanie ratunkowe, mające miejsce, gdy nie jest dostępna baza danych. Format woluminu dokładnie udokumentowano w kodzie źródłowym oprogramowania Bacula, a także w przewodniku projektanta. Blokowa architektura magazynowania narzędzia Bacula umożliwia też przeplatanie plików. Dzięki temu jednocześnie wiele demonów plików może komunikować się z demonem magazynowania. Jednak ze względu na większą liczbę operacji przeszukiwania woluminu magazynującego taka symultaniczność spowalnia proces odtwarzania plików. Obsługa wielu pul W przypadku oprogramowania Bacula nośnik archiwizujący jest pobierany z pul, które w zasadzie są listami dostępnych woluminów nadających się do użycia. Choć w niewielkiej konfiguracji jedna pula może być wystarczająca, narzędzie Bacula wyjątkowo dobrze obsługuje też wiele pul i urządzeń archiwizujących. Obsługując wiele pul, za pomocą różnych pul archiwizacyjnych Bacula pozwala w prosty sposób klasyfikować różnego typu komputery lub wymagania dotyczące przetwarzania danych. Realizowany projekt umożliwi przenoszenie zadań między pulami (zostało to omówione w dalszej części rozdziału w podrozdziale „Zamierzenia na przyszłość”). Obsługa systemu plików HFS+ firmy Macintosh Wersja 1.38.2 narzędzia Bacula obsługuje rozwidlenia zasobów woluminów z systemem plików HFS+ firmy Macintosh. Dzięki temu możliwe jest poprawne archiwizowanie i odtwarzanie plików używających rozwidleń zasobów i danych. Obsługa jest zupełnie niezauważalna dla użytkownika.
190
|
Rozdz ał 6. Bacula
Obsługa usługi VSS systemu Windows Klient Win32 narzędzia Bacula w wersji 1.38 jest zgodny z usługą VSS (Volume Shadow Copy Service). Dzięki temu można tworzyć spójne kopie zapasowe otwartych plików systemu Windows. Sprawia to, że archiwizowanie danych tego systemu jest znacznie łatwiejsze i bardziej niezawodne. Warto zauważyć, że obsługa usługi VSS dotyczy wyłącznie systemów Windows XP i Windows Server 2003, a także ich następców. W przypadku systemu Windows w wersji 95, 98, ME, NT lub 2000 takiej obsługi nie ma. Wynika to z ograniczenia systemu Windows, a nie oprogramowania Bacula. Autonomiczny proces przywracania Narzędzie Bacula sprawia, że utworzenie ładowalnego dysku CD systemu Linux zawierającego wszystko, co jest niezbędne do przeprowadzenia procesu przywracania systemu od podstaw i rozpoczęcia odtwarzania plików, jest dość proste. Nieznacznie bardziej złożone (jednak nadal skuteczne) procesy są możliwe w przypadku systemów: Solaris, FreeBSD i Windows. Trochę bardziej szczegółowo zostało to przedstawione w dalszej części rozdziału, w podrozdziale „Zaawansowane funkcje”. Dokumentacja Dokumentacja jest piętą achillesową wielu projektów oprogramowania open source. Na szczęście nie jest tak w przypadku narzędzia Bacula. Choć w czasie pisania książki sposób zorganizowania dokumentacji pozostawiał nieco do życzenia, Bacula jest dokładnie i ściśle udokumentowana. Skalowalność Oprogramowanie Bacula zostało zaprojektowane jako system archiwizacji dla przedsiębiorstw. Ponieważ narzędzie jest w jasny sposób zbudowane i ma logicznie rozdzielone składniki, możliwe, że z liczba jego instalacji naprawdę bardzo wzrośnie. Modułowa budowa oprogramowania zapewnia łatwość skalowania rozrastającej się architektury związanej z archiwizowaniem danych organizacji. Zwykle zwiększenie pojemności po prostu sprowadza się do wskazania dodatkowych demonów plików lub demonów magazynowania i dołączenia ich do konfiguracji nadzorcy. Wykonano wiele pracy, aby narzędzie Bacula współpracowało z wieloma magazynami taśm dla przedsiębiorstw i było zgodne ze schematami etykietowania. Dzięki temu oprogramowanie to może współistnieć z dużymi komercyjnymi systemami zarządzania danymi i operacyjnymi. Pomimo przydatności narzędzia Bacula do zastosowania w bardzo dużych sieciach jego konfiguracja jest na tyle prosta, że wyjątkowo wskazane jest jego użycie także do archiwizowania bardzo małych sieci, a nawet pojedynczych komputerów. Bacula równie dobrze poradzi sobie z zapisywaniem kopii zapasowych danych 300 klientów na ogromnym magazynie taśmowym, jak i zawartości jednego laptopa, co tydzień umieszczanej na dysku DVD. Testowanie napędu taśmowego Jedno z najczęściej zadawanych pytań dotyczących oprogramowania Bacula (i prawdopodobnie każdego innego systemu archiwizacji) brzmi: „Czy to będzie współpracować z używanym napędem taśmowym?”. Choć internetowa dokumentacja zawiera sporą liczbę napędów, o których wiadomo, że dobrze współpracują z narzędziem Bacula, znacznie bardziej autorytatywną odpowiedź można uzyskać po zastosowaniu programu btape. Wczytuje on konfigurację ustaloną dla używanych napędów taśmowych i korzystając z niej, przeprowadza serię obszernych testów zgodności, uwzględniających odczyt, zapis i różne operacje wyszukiwania. Jeśli program btape z powodzeniem ukończy wszystkie testy, można być pewnym, że używany napęd taśmowy zarówno jest zgodny z oprogramowaniem Bacula, jak i poprawnie skonfigurowany. Funkcje oprogramowan a Bacula
|
191
Przykładowa konfiguracja Najlepszym sposobem zilustrowania zastosowania narzędzia Bacula jest przedstawienie rozbudowanego przykładu. Przykładowa sieć widoczna na rysunku 6.3 zawiera trzy komputery: intelowski z systemem Linux i uruchomionymi serwerowymi składnikami narzędzia Bacula, klienta z systemem Windows XP i klienta działającego pod kontrolą systemu Mac OS X. Dla uproszczenia przyjęto, że komputery są podłączone do tego samego segmentu sieci. Jednak nie jest to wymóg, dopóki między serwerem a klientami występuje połączenie sieciowe oparte na protokole IP.
Rysunek 6.3. Przykładowa konfiguracja oprogramowania Bacula
W przytoczonym przykładzie użyto nowej dystrybucji narzędzia Bacula (co najmniej w wersji 1.38.2, aby była dostępna obsługa usługi VSS systemu Windows i rozwidleń zasobów systemu Mac OS X) zainstalowanej w systemie Linux. Ponadto skonfigurowano serwer linuksowy, żeby archiwizował część własnych plików. Gdy już serwer będzie działał, zainstalujemy i skonfigurujemy klienty z systemami Windows i Mac OS X, a następnie wykonamy kopie zapasowe katalogów znajdujących się na każdym z nich. W przykładowej konfiguracji zostanie zarchiwizowany katalog /etc systemu Linux. Zamiast taśmy lub nośnika optycznego w roli urządzenia archiwizującego zostanie zastosowany katalog serwera.
Konfigurowanie serwera W celu zainstalowania narzędzia Bacula zostaną użyte pliki RPM (dostępne pod adresem http://www.bacula.org), które mogą być rozpakowane za pomocą standardowych linuksowych metod i narzędzi zarządzania. Pakiety RPM instalują pliki konfiguracyjne oprogramowania Bacula dla systemu Linux w katalogu /etc/bacula, co jest zgodne ze standardem LSB (Linux Standard Base). Dla ułatwienia instalacji zostanie wykorzystana baza danych SQLite (w środowisku produkcyjnym powinno się zastosować serwer bazodanowy MySQL lub PostgreSQL). Narzędzie Bacula jest też dostępne dla dystrybucji Debian i w innych formatach pakietów. Choć wersja narzędzia Bacula dołączona do linuksowej dystrybucji Debian Sarge jest przestarzała, dystrybucja Debian Etch uwzględnia najnowsze wersje oprogramowania Bacula. Ponadto istnieją poprawki nowych wersji narzędzia Bacula przeznaczone dla dystrybucji Debian Sarge. 192
|
Rozdz ał 6. Bacula
W omawianym prostym przykładzie po prostu zostanie zmieniony domyślny identyfikator klienta z Client1 na test1, a także, za pomocą poniższego wiersza, zdefiniowany zasób FileSet. File = /etc
Zasób FileSet określa pliki, które zostaną zarchiwizowane w ramach danego zadania Job.
Poniższy wiersz musi być umieszczony w domyślnej definicji pul, aby w razie potrzeby narzędzie Bacula utworzyło nowe, kolejno numerowane woluminy. Label Format = TestVol
Inne domyślne ustawienia są odpowiednie w przypadku większości niewielkich konfiguracji. Konfigurowanie demona magazynowania jest równie proste. Bazując ponownie na domyślnych rozsądnych ustawieniach oprogramowania Bacula, należy użyć zasobu magazynowania FileStorage i zamiast katalogu /tmp przypisać mu katalog /opt/backups (jego właścicielem jest użytkownik bacula). Dalej trzeba sprawdzić, czy istnieje wiersz Label Media = yes, i upewnić się, że są zgodne hasła nadzorcy, a także demonów plików i magazynowania. Po dokonaniu tych zmian należy ponownie uruchomić usługi narzędzia Bacula, korzystając ze skryptów katalogu /etc/init.d zainstalowanych z pakietem, a następnie załadować konsolę bconsole, aby przetestować instalację.
Wstępna archiwizacja (klient z systemem Linux) Po załadowaniu konsoli narzędzia Bacula za pomocą dodanych definicji zadań należy zainicjować zadanie archiwizacji (test1 jest zadaniem utworzonym przy użyciu wcześniej omówionych ustawień). *run A job name must be specified. The defined Job resources are: 1: test1 2: BackupCatalog 3: RestoreFiles Select Job resource (1-3): 1 Run Backup job JobName: test1 FileSet: Etc Level: Incremental Client: test1-fd Storage: File Pool: Default When: 2006-01-20 09:30:38 Priority: 10 OK to run? (yes/mod/no): yes Job started. JobId=4
Po chwili konsola wyświetli następujący wiersz: You have messages.
Oto komunikaty: *messages [… pominięte wiersze dotyczące automatycznego tworzenia/etykietowania woluminu…] JobId: 4
Przykładowa konf guracja
|
193
Job: test1.2006-01-20_09.30.39 Backup Level: Full (upgraded from Incremental) Client: "test1-fd" i686-redhat-linux-gnu,redhat,(Heidelberg) FileSet: "Etc" 2006-01-19 10:47:39 Pool: "Default" Storage: "File" [… pominięte wiersze…] FD Bytes Written: 40,129,258 SD Bytes Written: 40,656,235 [… pominięte wiersze…] Termination: Backup OK
Powyższe komunikaty potwierdzają, że archiwizacja się powiodła i utworzono kopię zapasową o rozmiarze około 40 MB. W rzeczywistości została sporządzona pełna kopia zapasowa, nawet pomimo tego, że określono kopię przyrostową (jest to wynik tego, że jeszcze nie wykonano pełnej kopii zapasowej).
Wstępne odtwarzanie (klient z systemem Linux) W celu przetestowania kopii zapasowej zostanie odtworzony plik. Po wybraniu losowego pliku (na przykład /etc/protocols) w celu zainicjowania procesu odtwarzania należy skorzystać z polecenia restore konsoli bconsole. W oknie konsoli należy wykonać polecenie restore, wybrać opcję 7, aby wyświetlić listę plików, określić klienta i plik, który zostanie odtworzony, i wcisnąć klawisz Enter. Następnie zostanie sprawdzone, czy plik protocols znajduje się w katalogu /tmp/bacula-restores/etc. Choć możliwe jest odtworzenie plików w ich docelowym miejscu, domyślna konfiguracja narzędzia Bacula przywraca je do katalogu /tmp/bacula-restores, aby umożliwić sprawdzenie, czy odtworzone pliki są poprawne, zanim umieści się je we właściwym miejscu systemu plików.
„Nie mogę sobie pozwolić na kopie zapasowe” Mój znajomy Greg jest ekspertem od efektów specjalnych, który zajmuje się modelowaniem, teksturowaniem, animacją i fotografią o bardzo dużej rozdzielczości. Zwykle przetwarza obrazy, których rozmiar jest wyrażany w gigapikselach, a samo zapisanie pliku na komputerze może zająć do trzech godzin. Greg nabył dyski o pojemności kilku terabajtów, aby przechowywać wszystkie swoje projekty zrealizowane przez lata. Jednak nie tworzy kopii zapasowych. Greg nie dysponuje pomieszczeniem na komputery ani żadnym specjalnym systemem chłodzenia lub magazynowania używanych przez siebie komponentów sprzętowych. Cały sprzęt jest umieszczony na zakurzonej drewnianej podłodze. Pod koniec zeszłego roku zepsuła się terabajtowa macierz RAID z zastosowanym paskowaniem. W efekcie Greg utracił wyniki pracy z okresu pięciu lat. Obecnie jego głównym celem jest zebranie odpowiedniej kwoty na naprawę dysków przez firmę DriveSavers. W międzyczasie kupuje kolejne dyski i zapisuje na nich efekty swojej pracy, również bez wykonywania żadnych kopii zapasowych. Greg twierdzi, że nie może sobie pozwolić na system archiwizujący będący w stanie obsłużyć naprawdę ogromne ilości danych, z których regularnie korzysta. Po prostu ma nadzieję, że jeśli nabędzie nowe, „bardziej niezawodne” napędy i wsłucha się dobrze w dźwięki potwierdzające, że napęd dziwnie się zachowuje, znów będzie mógł poczuć się pewnie — przynajmniej do następnej fatalnej w skutkach awarii. — Jason
194
|
Rozdz ał 6. Bacula
Archiwizowanie komputera z systemem Windows Zarchiwizujmy kilka plików znajdujących się na stacji roboczej z systemem Windows. Najpierw za pomocą edytora tekstu w pliku bacula-dir.conf należy zdefiniować nowe zasoby: Job, FileSet i Client. Job { Name = "WinXP-test" Client = winxp-fd JobDefs = "DefaultJob" FileSet = "WinTest" } FileSet { Name = "WinTest" Enable VSS = yes Include { [… pominięte wiersze…] File = C:/Windows/SYSTEM32/DRIVERS/ETC File = "C:/Program Files/Wizards/eTools/User" } [… pominięte wiersze…] } # Archiwizowany klient (usługi plikowe) Client { Name = winxp-fd Address = vpc-xp2.fsf.net ... }
Godny uwagi jest wiersz Enable VSS = yes (uaktywnia usługę VSS systemu Windows) zawarty w sekcji zasobu FileSet i format tego zasobu. Ścieżki plików systemu Windows zawierają znaki /. Jeśli nazwa pliku zawiera spacje, musi być umieszczona w znakach cudzysłowu. Aby uaktywnić nadzorcę w celu wczytania zmian dokonanych w jego plikach konfiguracyjnych, w oknie konsoli należy wykonać polecenie reload. Dalej na stacji roboczej z systemem Windows należy zainstalować klienta Bacula. Instalacja standardowego pakietu dla systemu Windows przebiega podobnie jak w przypadku dowolnej innej aplikacji. Pliki konfiguracyjne wymagają edycji, żeby uwzględnić nadzorcę (test1-dir) i jego hasło. Po zainstalowaniu demon plików działa jako usługa systemu Windows. Na pasku zadań systemu jest widoczna wspomniana niewielka ikona kasety z taśmą. Uruchomienie programu wx-console znajdującego się w katalogu instalacyjnym oprogramowania Bacula spowoduje wyświetlenie okna podobnego do pokazanego na rysunku 6.4. Uaktywnianie zadania archiwizacyjnego wygląda bardzo podobnie jak w przypadku klienta linuksowego, z tą różnicą, że zamiast zadania test1 uruchamia się zadanie WinXP-test. Dzienniki nadzorcy wyglądają niemal identycznie jak wygenerowane podczas wcześniejszej archiwizacji. 20-Jan 14:49 winxp-fd: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C" [… pominięte wiersze…] Termination: Backup OK
Spróbujmy czegoś trochę innego, odtwarzając następujący plik: C:\Program Files\Wizards\eTools\User\Characters\lola13.chr
Przykładowa konf guracja
|
195
Rysunek 6.4. Okno programu wx-console
Zamiast wprowadzać listę plików, wybierzmy opcję odtwarzania najnowszej kopii zapasowej klienta z systemem Windows. Aby to zrobić, zamiast programu wx-console użyjmy narzędzia bconsole, które udostępnia interfejs z zestawieniem katalogów. Poleceniem cd można przemieszczać się w strukturze katalogów, a przy użyciu programu mark można wybrać plik do odtworzenia (konsola wx-console pozwala na nawigację w obrębie drzewa katalogowego przy wykorzystaniu myszy; nazwy plików są zaznaczane przez kliknięcie). Ponowne uaktywnienie zadania odtwarzania spowoduje umieszczenie pliku w katalogu /tmp/bacula-restores, który w systemie plików systemu Windows odpowiada katalogowi C:\tmp\ bacula-restores. Z tego katalogu plik można przekopiować do jego ostatecznej lokalizacji.
Archiwizowanie komputera z systemem Mac OS X System Mac OS X w rzeczywistości jest zamaskowanym systemem BSD Unix. W związku z tym nie powinno być zaskoczeniem to, że narzędzie Bacula działa w systemie Mac OS X równie dobrze jak w przypadku każdego innego systemu uniksowego lub linuksowego. Konfigurowanie nadzorcy zasadniczo wygląda tak samo jak podczas dodawania klienta z systemem Windows. Jednak w sekcji zasobu FileSet umieszcza się następującą dyrektywę: HFS Plus Support = yes
Powyższe ustawienie, które umożliwia poprawne archiwizowanie rozwidleń zasobów, zawsze powinno być określane dla klientów z systemem Mac OS X. W ramach omawianego przykładu zdefiniujmy katalog, który zostanie zarchiwizowany: File = "/Uzytkownicy/adam/Dokumenty/Emulatory/Virtual II"
196
|
Rozdz ał 6. Bacula
Warto zauważyć, że ponieważ nazwa pliku zawiera spację, trzeba ją umieścić w znakach cudzysłowu.
Wybrano taki katalog ze względu na to, że przechowuje pakiet aplikacji. Aplikacje dla systemu Macintosh mają postać struktur katalogowych zawierających nie tylko programy wykonywalne, ale też zasoby i pliki wspomagające. Jeśli aplikacja ma działać poprawnie, musi być utrzymywana cała struktura, łącznie z wszelkimi powiązanymi rozwidleniami zasobów. Proces archiwizacji danych systemu Macintosh i jego rezultat wyglądają tak samo jak w przypadku każdego innego klienta. Po zarchiwizowaniu powyższego katalogu należy go całkowicie usunąć, aby nie było plików aplikacji Virtual II. Wykonując tym razem operację odtwarzania, użyjemy polecenia restore all, którego działanie odpowiada zaznaczaniu wszystkich plików drzewa w przykładzie klienta z systemem Windows (oczywiście, polecenie jest znacznie szybsze). W efekcie proces odtwarza cały katalog do katalogu /tmp/bacula-restores. Po przeniesieniu katalogu w jego właściwe położenie aplikacja Virtual II będzie działać bez żadnych problemów. Przykład demonstruje archiwizowanie i odtwarzanie dla trzech różnych klientów z systemami: Linux, Windows XP i Mac OS X. W przypadku każdego z tych klientów procesy przebiegają bardzo podobnie. Podstawowa różnica dotycząca używania poleceń nie ma związku z konkretnym systemem, lecz po prostu z wybraną opcją przywracania: odtwarzanie pojedynczego pliku o podanej nazwie, zaznaczanie plików w drzewie systemu plików lub przywracanie całego drzewa katalogowego. Po stronie serwerowej dla każdego klienta bez systemu Linux do konfiguracji trzeba dodać jeden wiersz, aby zachować unikatowe funkcje, takie jak obsługa usługi VSS (system Windows) i systemu plików HFS+ (system Mac OS X). Domyślna metoda odtwarzania plików umieszcza je w katalogu /tmp/bacula-restores (domyślna lokalizacja), a następnie kopiuje w ostateczne miejsce przeznaczenia, gdy użytkownik upewni się, że przywrócono pliki o odpowiednich wersjach. Po zaznajomieniu się z działaniem oprogramowania Bacula wielu użytkowników decyduje się na odtworzenie plików bezpośrednio w ich oryginalnej lokalizacji.
Zaawansowane funkcje Oprócz możliwości archiwizowania i odtwarzania plików za pośrednictwem sieci narzędzie Bacula oferuje wiele zaawansowanych funkcji, które w skrócie omówiono poniżej. Kompletne informacje na temat tych funkcji można znaleźć w dokumentacji oprogramowania Bacula dostępnej pod adresem http://www.bacula.org.
Przywracanie komputera od podstaw Zaawansowana funkcja o największym znaczeniu dla większości użytkowników umożliwia przeprowadzenie przy użyciu narzędzia Bacula procesu przywracania komputerów od podstaw. Bacula zapewnia narzędzia służące do tworzenia dostosowanych i ładowalnych obrazów na dyskach CD, które mogą być użyte do przywracania. W przypadku systemu Linux tego typu funkcja obsługi jest dość kompletna. W systemach Solaris i FreeBSD proces ten w większej
Zaawansowane funkcje
|
197
części jest realizowany ręcznie. Bardzo różny, lecz dość efektywny proces występuje w przypadku systemu Windows. Obecnie proces przywracania od podstaw nie jest możliwy dla klientów Macintosh. Narzędzie Bacula może zostać uruchomione z ładowalnego ratunkowego dysku CD-ROM systemu Linux. Na dysku takim znajduje się minimalna kopia systemu operacyjnego komputera, statycznie dowiązany demon plików Bacula i pliki konfiguracyjne opisujące komputer, dla którego utworzono ratunkowy dysk CD-ROM. Podstawowa strategia związana z ratunkowym dyskiem CD polega na załadowaniu systemu, ponownym partycjonowaniu dysku twardego zgodnie z opisem zawartym na dysku CD-ROM, podłączeniu komputera do sieci i przywróceniu plików na nowo sformatowanym napędzie. Proces tworzenia dysku CD-ROM obejmuje generowanie skryptów zajmujących się konfiguracją sieciową, partycjonowaniem dysku i zapisywaniem odpowiedniego rekordu rozruchowego (za pomocą programu grub lub lilo). Pojedynczy dysk CD-ROM może być stosowany dla wielu klientów, pod warunkiem że każdy z nich ma na dysku własny katalog konfiguracyjny. Jeśli jest dostępny odpowiedni dysk ratunkowy i zarchiwizowano wszystkie ratunkowe pliki generowane przez skrypt tworzący zawartość dysku CD, ostatnią szansą powinna być możliwość uzyskania nadającego się do użycia dysku CD oprogramowania Bacula służącego do odtwarzania, nawet wtedy, gdy klient został zniszczony. W przypadku systemów Solaris i FreeBSD sytuacja wygląda podobnie, lecz nie jest dostępny dedykowany dysk CD umożliwiający przywracanie. Kolejno są wykonywane takie operacje, jak załadowanie systemu z nośnika ratunkowego lub instalacyjnego, odpowiednie formatowanie dysków, podłączenie do sieci, zainstalowanie statycznie dowiązanego demona plików i odtworzenie wszystkich zarchiwizowanych plików. Wprawdzie system Solaris oferuje zautomatyzowane tworzenie skryptu, ale nie w tak dużym zakresie jak system Linux. Ponieważ tworzenie ratunkowego dysku CD-ROM wymaga ręcznego przeprowadzenia dla każdego klienta oddzielnego procesu, część użytkowników systemu Linux może uznać za prostsze zastosowanie jego dystrybucji Knoppix (należy zajrzeć do rozdziału 11.). Knoppix jest uruchamiany z dysku CD zawierającego narzędzie bacula-fd. Jeśli skorzysta się z tej dystrybucji, konfigurowanie sieci, a następnie partycjonowanie i formatowanie dysku trzeba będzie wykonać ręcznie, ale gdy już użytkownik się z tym upora, operacja odtwarzania będzie przebiegać dokładnie jak w przypadku każdego innego zadania narzędzia Bacula mającego na celu przywrócenie danych. W tym przypadku ręcznie trzeba też utworzyć rekord rozruchowy. System Windows wymaga, aby przed wykonaniem kopii zapasowej za pomocą oprogramowania Bacula użytkownik uruchomił program ntbackup w celu zapisania kopii krytycznych plików systemowych (należy zajrzeć do rozdziału 3.). Może to zostać wykonane po stronie klienta (więcej na ten temat Czytelnik znajdzie w dalszej części rozdziału). W tym przypadku należy najpierw zainstalować minimalną wersję systemu Windows, a następnie klienta Bacula i odtworzyć zawartość kopii zapasowej z uwzględnieniem danych utworzonych przez narzędzie ntbackup. Na końcu z obrazu utworzonego przez program ntbackup należy przywrócić „tożsamość” systemu. Użytkownicy systemu Windows XP mają trochę łatwiej. Za pomocą programu PEBuilder mogą utworzyć ratunkowy dysk CD BartPE z klientem Bacula. Program ten, generujący obraz zapisany na dysku CD, jest dostępny pod adresem http://www.nu2.nu/pebuilder. Narzędzie pomaga użytkownikowi w procesie tworzenia ładowalnego ratunkowego dysku CD z systemem Windows.
198
|
Rozdz ał 6. Bacula
W celu dostarczenia niezbędnych plików systemu Windows program PEBuilder wymaga dostępu do instalacyjnego nośnika systemu.
Obciążenie generowane przez archiwizację i szyfrowanie magazynowanych danych Często trzeba za pośrednictwem sieci zarchiwizować komputery, które nie są godne zaufania. Najbardziej oczywisty jest przypadek archiwizowania za pośrednictwem sieci rozległej WAN lub internetu. Procedury firmy mogą wymagać, aby dane transmitowane w sieci były szyfrowane. Zawsze możliwe było tunelowanie danych narzędzia Bacula za pomocą programu stunnel lub ssh (przekierowywanie portów). Wymaga to od oprogramowania Bacula jedynie wskazywania różnych demonów w odpowiednich portach. Uwierzytelnianiem zajmuje się program stunnel lub ssh. W nowszych wersjach narzędzie Bacula obsługuje warstwę TLS. Dzięki temu można mieć pewność, że dane między demonem plików, nadzorcą i demonem magazynowania nie są przesyłane w sieci w niezaszyfrowanej postaci. Ponadto warstwa TLS zapewnia kolejny poziom uwierzytelniania ponad poziomem wymagającym zgodności haseł demonów. Bacula może korzystać z certyfikatów podpisywanych we własnym zakresie i tworzonych za pomocą lokalnie wdrożonego urzędu certyfikacji CA (Certificate Authority). W dokumentacji narzędzia Bacula zamieszczono źródła informacji dotyczących tworzenia lokalnego urzędu certyfikacji. Wszystkie typowe ograniczenia związane z tego typu certyfikatami dotyczą również oprogramowania Bacula. Użytkownik nie wie, czy certyfikat został podpisany przez zaufany urząd. Dopóki administrator systemu ma zaufanie do podpisywanych i wdrażanych przez siebie certyfikatów, niewiele zyska się, płacąc za podpisany certyfikat na potrzeby wewnętrznej infrastruktury archiwizacji. Jednak jeśli archiwizowanie jest oferowane w postaci zarządzanej usługi, być może warto nabyć dla niej poprawnie podpisany certyfikat SSL. Bacula w wersji 1.39 i nowszych obsługuje szyfrowanie magazynowanych danych, aby zapobiec nieautoryzowanemu dostępowi do zawartości kopii zapasowych. Powoduje to dodatkowe obciążenie ruchu między składnikami oprogramowania Bacula. Duże organizacje zaczynają wymagać, aby zarchiwizowane dane były szyfrowane podczas przesyłania i magazynowania. Jednak rozwiązanie takie jest równie przydatne dla zwykłego użytkownika archiwizującego dane na dyskach DVD-R, który chciałby, żeby ktoś, kto ukradł mu plecak z archiwizacyjnym dyskiem DVD, nie mógł uzyskać dostępu do jego prywatnych danych. Mechanizm szyfrowania używa certyfikatów TLS do zarządzania kluczami szyfrującymi zabezpieczającymi dane. Umożliwia to opcjonalne określenie wielu głównych kluczy deszyfrujących na potrzeby depozytu. W ten sposób można łatwiej uchronić się przed utratą danych w sytuacji, gdy przepadnie jedyny klucz prywatny. Szyfrowanie może być włączane dla poszczególnych klientów.
Obsługa skryptów Python Bacula pozwala na wykonanie skryptu przed wykonaniem określonego zadania archiwizacyjnego lub po nim. Dzięki temu zadanie może wywołać zewnętrzny program, który następnie może połączyć się z oprogramowaniem Bacula za pośrednictwem swojego standardowego
Zaawansowane funkcje
|
199
wyjścia. Choć obsługa skryptów nie jest zbyt zaawansowana, może skutecznie zapewnić, że wszystkie bufory zostaną opróżnione przed rozpoczęciem procesu archiwizacji. Nowsze wersje narzędzia Bacula oferują też wbudowany interpreter języka Python obsługujący nadzorcę, demona plików i demona magazynowania. Skrypt Python wykonywany w obrębie przestrzeni adresowej nadzorcy narzędzia Bacula może realizować proces rejestrowania w celu obsługi dowolnej liczby działań. Typowym zastosowaniem w tym przypadku jest dynamiczna zmiana parametrów zadania w odpowiedzi na środowisko. Jeśli na przykład wymagana jest nowa nazwa woluminu, obsługa skryptów Python może zostać wykorzystana do jej dynamicznego utworzenia (być może przez zwiększenie wartości licznika generującego kolejną z serii logicznych nazw woluminów). Osadzony interpreter języka Python ma pełną wiedzę na temat wewnętrznego stanu narzędzia Bacula. Rozwiązanie takie zapewnia oprogramowaniu Bacula znacznie większą elastyczność niż w przypadku zastosowania zewnętrznego programu, któremu jako parametry można przekazać tylko kilka porcji informacji. Osadzony interpreter demona plików umożliwia bardzo zaawansowane przetwarzanie zadania po stronie klienta zarówno przed, jak i po jego wykonaniu.
Obsługa skryptów klienta Bacula umożliwia użytkownikowi określenie w ramach zadania programu, który zostanie uaktywniony po stronie klienta przed lub po przeprowadzeniu archiwizacji. Jest to szczególnie przydatne w przypadku archiwizowania serwerów bazodanowych. Przykładowo użytkownik może zażądać utworzenia przez serwer bazodanowy pliku obrazu (za pomocą jego własnych narzędzi) uwzględniającego stan bazy przed rozpoczęciem wykonywania zadania. Po zakończeniu archiwizacji plik obrazu można usunąć, aby zwolnić miejsce na kliencie. Innym typowym zastosowaniem funkcji po stronie klienta jest użycie programu ntbackup do archiwizacji istotnych plików konfiguracyjnych systemu Windows w pliku, który może zostać odtworzony przez oprogramowanie Bacula.
Obsługa automatycznych zmieniarek Bacula całkiem dobrze współpracuje z automatycznymi zmieniarkami taśmowymi SCSI. Choć zwykle oprogramowanie używa polecenia mtx, aby zarządzać automatyczną zmieniarką, umieszcza je wewnątrz własnego skryptu o nazwie mtx-changer. Skrypt można edytować w celu dostosowania polecenia mtx do zarządzanego środowiska. Automatyczna zmieniarka może nadawać etykiety nowym woluminom, które znajdzie. Nazwy woluminów bazują na wzorcu, czytniku kodów paskowych lub skrypcie Python. Woluminy są następnie automatycznie podłączane. W przypadku dużych kopii zapasowych, dla których jedno zadanie używa wielu taśm, obsługa automatycznej zmieniarki przez narzędzie Bacula pozwala zastosować taką liczbę taśm, jaka jest wymagana, bez potrzeby interwencji operatora. Tego typu obsługa automatyzuje również proces odtwarzania, ponieważ oprogramowanie Bacula może zażądać od automatycznej zmieniarki odpowiedniej taśmy, aby odczytać wolumin z potrzebnymi kopiami zapasowymi. W przypadku większości zastosowań wystarczający jest dołączony skrypt zawierający wskazówki dla niewielkich modyfikacji dotyczących środowiska roboczego. Przykładowo z łatwością można zmodyfikować skrypt, żeby symulował kody kreskowe dla automatycznych zmieniarek, które nie obsługują identyfikowania taśm przy użyciu kodów kreskowych.
200
|
Rozdz ał 6. Bacula
Jednak skrypt mtx-changer oferuje znacznie większe możliwości zastosowania. Skrypt tworzy interfejs narzędzia Bacula komunikujący się z automatyczną zmieniarką. W związku z tym skrypt może być całkowicie zastąpiony. Dzięki temu Bacula może współpracować z urządzeniami, które radykalnie różnią się od automatycznych zmieniarek SCSI. Nie wymaga to żadnych zmian w podstawowym kodzie oprogramowania Bacula. Przykładem obsługi automatycznych zmieniarek jest użycie serwerowych magazynów taśmowych. W ich przypadku skrypt mtx-changer jest zastępowany klientem i serwerem sieciowym, tak aby narzędzie Bacula mogło żądać taśm od systemu zarządzania taśmami działającego pod systemem z/VM. Wszystko to jest możliwe pomimo tego, że magazyn taśm nie ma nic wspólnego z interfejsem automatycznej zmieniarki SCSI.
Etykiety taśm ANSI i IBM Narzędzie Bacula w wersji 1.38 może używać standardowych etykiet taśm ANSI i IBM. Umożliwia to narzędziu bezproblemową koegzystencję z innymi systemami archiwizacji dla przedsiębiorstw i współużytkowanie zunifikowanego katalogu taśm.
Wykrywanie intruzów bazujące na systemie plików Jednym z najprostszych metod monitorowania statusu hosta jest obserwowanie zmian w obrębie systemu plików. Narzędzie Bacula monitoruje system plików i przechowuje w katalogu informacje na jego temat, uwzględniające nazwy plików, rozmiary, uprawnienia i sumy kontrolne. Przez okresowe uruchamianie zadania dokonującego porównania z zawartością katalogu oprogramowania Bacula można użyć w roli prostego systemu wykrywającego intruzów (korzystając jednocześnie z programu tripwire).
Zamierzenia na przyszłość Głównym długoterminowym celem postawionym przed oprogramowaniem Bacula jest uzyskanie pozycji konkurencyjnego systemu archiwizacji odpowiedniego dla przedsiębiorstw. Niektóre rozszerzenia (a zwłaszcza szybkie przeszukiwanie dużych katalogów) są niezbędne do tego, aby oprogramowanie Bacula na równi rywalizowało z komercyjnymi systemami archiwizacji dla przedsiębiorstw. Równie istotne są rozszerzenia związane z użytecznością. Najważniejszym z nich jest utworzenie dla narzędzia Bacula bardziej kompletnego i zarządzalnego graficznego interfejsu użytkownika. Lista realizowanych projektów związanych z oprogramowaniem Bacula jest dostępna pod adresem http://bacula.cvs.sourceforge.net/bacula/bacula/projects?view=markup i aktualizowana mniej więcej co pół roku. Poniżej dokładniej omówiono pięć najważniejszych nieukończonych projektów w czasie, gdy była pisana książka (w momencie opublikowania książki wyniki części lub wszystkich z tych projektów mogą być uwzględnione w podstawowym kodzie narzędzia Bacula).
Zam erzen a na przyszłość
|
201
Migracja puli Projekt ten ma na celu utworzenie mechanizmu migracji magazynowanych danych z jednej puli do drugiej. Umożliwia to wdrożenie warstwowego przechowywania danych. Przykładowo kopie zapasowe początkowo mogą być umieszczone na dysku, a następnie w ramach kontrolowanego harmonogramu przeniesione na inny nośnik magazynujący. Migracja magazynowanych danych ma dwie zalety. Przez umożliwienie opcjonalnego zastosowania docelowego nośnika migracja puli może lepiej wykorzystać nośnik magazynujący. Oznacza to, że migracja puli funkcjonuje jak zaawansowany mechanizm buforujący, który jest szczególnie ważny podczas korzystania z nośnika jednokrotnego zapisu. W tym przypadku najlepiej użyć jak najwięcej miejsca na każdym woluminie. Drugą zaletą jest wygoda. Choć taśma lub nośnik optyczny może być pożądanym długoterminowym miejscem przechowywania danych, narzędzie Bacula najczęściej jest wykorzystywane do odtwarzania pojedynczego ostatnio usuniętego pliku lub katalogu. Znacznie wygodniej jest, gdy nowsze kopie zapasowe są trzymane na dysku twardym, tak aby użytkownik nie musiał szukać nośnika archiwizacyjnego. Jednak ilość wymaganej przestrzeni dyskowej może pozostać stosunkowo niewielka, ponieważ zgodnie z ustalonym harmonogramem kopie zapasowe są automatycznie przenoszone na nośnik archiwizujący. Tworzenie puli kopiowania jest podobną funkcją (na liście projektów znajduje się na ósmej pozycji), zaprojektowaną z myślą o archiwizowaniu poza obrębem firmy. Pojedyncze zadanie zapisuje jednocześnie zarchiwizowane dane na woluminach wielu puli. Ułatwia to na przykład przygotowywanie nośnika na potrzeby przechowywania za zewnątrz firmy. W listopadzie 2006 r. funkcja migrowania puli działała, choć nadal trochę nieprecyzyjnie. Gdy książka zostanie wydana, funkcja powinna już funkcjonować stabilnie i być w pełni obsługiwana.
Śledzenie plików usuniętych i ze zmienioną nazwą Gdy narzędzie Bacula tworzy różnicową lub przyrostową kopię zapasową, nie zwraca uwagi na to, czy plik lub katalog zniknął, lecz jedynie na to, czy ich zawartość została zmodyfikowana. W związku z tym odtwarzanie zestawu plików mających określoną datę (proces wymaga najpierw przywrócenia pełnej kopii zapasowej, a następnie wykonania operacji odtwarzania z różnicowej lub przyrostowej kopii) spowoduje przywrócenie plików zawartych w pełnej kopii zapasowej, lecz w rzeczywistości usuniętych lub mających nazwy zmienione w czasie, gdy sporządzano różnicową lub przyrostową kopię. Podobna sytuacja ma miejsce w przypadku plików, dla których zmieniła się wartość licznika dowiązań twardych. Warto zauważyć, że narzędzie Bacula nie powoduje utraty żadnych danych. Gdy jednak korzysta się z pełnych i różnicowych lub przyrostowych kopii zapasowych, mogą zostać odtworzone niepożądane dane, które trzeba ręcznie usunąć. Podstawowym zastosowaniem śledzenia plików usuniętych i ze zmienioną nazwą jest tworzenie poprawnego obrazu danych z określonej chwili.
Graficzny interfejs użytkownika oparty na języku Python Istniejący graficzny interfejs użytkownika wxWidgets napisano w języku C++ i trudno go rozwijać. Rozszerzony graficzny interfejs oparty na języku Python stworzony w środowisku Qt Designer będzie prostszy w utrzymaniu, bardziej podatny na modyfikacje użytkownika i bardziej przenośny. 202
|
Rozdz ał 6. Bacula
Obsługa podstawowego zadania Podstawowym zadaniem określa się zadanie archiwizujące pliki, które mają zgodnie z oczekiwaniami zmieniać się bardzo rzadko i prawdopodobnie być identyczne na wielu klientach. Jeśli dysponuje się 50 komputerami z taką samą dystrybucją i wersją systemu Linux, większość jego binariów jest identyczna dla każdego klienta i raczej niezbyt często modyfikowana. Pojedyncze zadanie, które mogłoby reprezentować początkowy wspólny stan tych komputerów, znacznie zredukowałoby liczbę zarówno wymaganych nośników archiwizacyjnych, jak i niezbędnych zmian nośników, jeśli w ogóle byłoby konieczne zbiorcze przywracanie danych wszystkich tych komputerów.
Archiwizowanie danych inicjowane przez klienta Rozważmy organizację z okresowo podłączonymi komputerami, taką jak firma z wieloma użytkownikami, którzy często podróżują ze swoimi laptopami i danego dnia mogą nie być obecni w biurze. W przypadku takiej organizacji bardzo przydatna byłaby możliwość inicjowania archiwizacji przez klienta, gdy stwierdzi, że jest podłączony do domowej sieci i może skomunikować się z nadzorcą narzędzia Bacula.
Obsługa dodatków demonów plików Choć projekt ten znajduje się na liście niżej niż pięć wcześniej przedstawionych projektów, daje wyjątkowo interesującą możliwość tworzenia ogólnej struktury związanej z archiwizowaniem za pomocą narzędzia Bacula aplikacji, których archiwizowanie jest prawdziwym wyzwaniem (takich jak aktywne bazy danych). Chociaż istniejący demon plików pozwala na archiwizowanie czegokolwiek, co można zapisać w postaci pliku, to, że oprogramowanie Bacula cały proces realizuje za pośrednictwem protokołu TCP/IP, stwarza możliwość zastosowania specjalnych dodatków demonów plików zaprojektowanych w celu archiwizowania bardziej złożonych aplikacji. Przykładowo jak dotąd co najmniej jeden użytkownik poinformował, że udało mu się utworzyć prosty dodatek demona plików dla systemu Windows, który zamiast archiwizować pliki, wie, jak współpracować z serwerem bazodanowym SQL Server, aby sporządzić poprawne pełne kopie zapasowe. Trwają prace nad wykorzystaniem dodatków do zintegrowania oprogramowania Bacula z systemem VM/CMS i systemem plików AFS. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Zam erzen a na przyszłość
|
203
204 |
Rozdz ał 6. Bacula
ROZDZIAŁ 7.
Narzędzia open source służące do niemal ciągłej ochrony danych
W rozdziale 8. omówiono komercyjne oprogramowanie archiwizujące i pojęcie systemów niemal ciągłej ochrony danych, która jest po prostu mechanizmem replikowania powiązanym z określonego typu produktem tworzącym migawkę danych. Zanim zajmiemy się komercyjnymi narzędziami, w niniejszym rozdziale zostaną przedstawione trzy darmowe systemy niemal ciągłej ochrony danych. W pierwszym podrozdziale zaprezentowano program rsync z migawkami, a także objaśniono to rozwiązanie (pierwotnie zostało ono spopularyzowane przez Mike’a Rubela). W podrozdziale poświęconym narzędziu rsnapshot opisano projekt open source bazujący na tym programie. Został on zaprojektowany w celu zautomatyzowania archiwizacji plików użytkowników. Program nie współpracuje zbyt dobrze z bazami danych i innymi dużymi plikami. W ostatnim podrozdziale przedstawiono odmienny projekt oprogramowania rdiffbackup, oferującego takie funkcje, jak zaawansowane możliwości związane z metadanymi i obsługa dużych plików. W tworzeniu rozdziału brali udział m.in. Michael Rubel, David Cantrell i Ben Escoto. Mike jest studentem ostatniego roku studiów aeronautyki na uczelni w Caltech, gdzie przechowuje kilka kopii zapasowych swojej pracy naukowej (ma nadzieję, że wkrótce ją ukończy). David nie jest przekonany do ciasta z nadzieniem warzywnym. Ben jest obecnie analitykiem w firmie ubezpieczeniowej Aon Re.
Sama replikacja nie zadziałałaby. Nie można po prostu zsynchronizować za pomocą programu rsync dwóch komputerów, aby na jednym z nich zapisać kopię zapasową, ponieważ mógłby zostać w niej zreplikowany logiczny element zaburzający, taki jak wirus lub błąd użytkownika. Potrzebna jest metoda utrzymywania wielu wersji danych na docelowym komputerze, tak aby w razie konieczności można było powrócić do wcześniejszej wersji. Jeśli coś takiego jest możliwe, można uzyskać ciągły system przyrostowy, który zawsze ma pełną kopię zapasową każdej dostępnej wersji. Oczywiście, wymaga to przestrzeni dyskowej wystarczającej do magazynowania jednej pełnej kopii zapasowej, a do tego kopii przyrostowych. Można nawet zrobić to na różne sposoby: przez przesyłanie do serwera (wyżej przedstawiona metoda), pobieranie ze źródła lub lokalne zapisywanie (na przykład na wymiennym napędzie dysku twardego).
205
Program rsync z migawkami Pomysł zastosowania replikacji do utworzenia systemu migawkowego został spopularyzowany przez Mike’a Rubela w sieciowym artykule poświęconym narzędziu rsync z migawkami (http://www.mikerubel.org/computers/rsync_snapshots). Pomysł jest zarówno prosty, jak i bogaty w możliwości. Najpierw trzeba skopiować jeden katalog do drugiego. W tym celu należy skopiować źródłowy katalog do docelowego (cp -a /home /backups/home.0). Ponieważ katalogi będą później potrzebne, katalog docelowy musi obsługiwać dowiązania twarde (bardziej szczegółowo omówiono je w dalszej części rozdziału). W dalszej kolejności trzeba wykonać następną kopię zarchiwizowanych danych. Kopia ta będzie pełnić rolę poprzedniej wersji, gdy uaktualni się aktualną wersję. W tym celu należy skopiować docelowy katalog do katalogu mającego w nazwie łańcuch ., gdzie n jest dowolną cyfrą. Jeśli operację wykona się przy użyciu dowiązań twardych, druga kopia nie zajmie żadnego miejsca. Aby podczas tworzenia kopii skorzystać z dowiązań twardych, należy użyć opcji -l polecenia cp (cp -al /kopie_zapasowe/home.0 /kopie_zapasowe/home.1). Po wykonaniu operacji będą istnieć dwie identyczne kopie źródłowego katalogu systemu archiwizującego (/kopie_zapasowe/home.0 i /kopie_zapasowe/home.1), łącznie o rozmiarze tylko jednej kopii. Po skopiowaniu kopii zapasowej w inne miejsce pora sporządzić następną kopię. W tym celu należy zidentyfikować wszelkie pliki źródłowe, które są nowe lub zmieniły się, a następnie usunąć je z docelowego katalogu, jeśli tam występują, i skopiować do tego katalogu pliki źródłowe. Jeżeli w docelowym katalogu znajduje się już aktualna wersja pliku, trzeba najpierw go odłączyć. Aby zrobić to wszystko w jednym kroku, należy użyć polecenia rsync (rsync -delete -av /home/. /kopie_zapasowe/home.0/). Krok ten stanowi sedno całego pomysłu. Przez usunięcie pliku już znajdującego się w katalogu kopii zapasowej (/kopie_zapasowe/home.0) przerywa się dowiązanie twarde do poprzedniej wersji kopii (/kopie_zapasowe/home.1). Jednak ze względu na to, że zastosowano dowiązania twarde, poprzednia wersja kopii zapasowej nadal istnieje (w katalogu /kopie_zapasowe/home.1), a nowsza znajduje się w bieżącym katalogu archiwizacyjnym (/kopie_zapasowe/home.0).
Powód wykonywania kopii zapasowych Gdy pracowałem na uniwersytecie, przyszedł do mnie student ostatniego roku i poprosił o odtworzenie zawartości jego katalogu domowego. Nie było problemu. Przywróciłem dane. Następnego dnia ten sam student wrócił do mnie i znów poprosił o odtworzenie danych. Powiedziałem mu, aby bardziej uważał, i utworzyłem dla niego alias rm dla polecenia rm -i. Następnego dnia student jeszcze raz się u mnie pojawił. Ciekawy tego, czemu cały czas się to dzieje, sprawdziłem plik .history. $ echo y | rm *
Po tym odkryciu utworzyłem alias rm dla polecenia echo no. — Brian O’Neill
206
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
Aby sporządzić kolejną kopię zapasową, należy przenieść starszy katalog (/kopie_zapasowe/home.1) do katalogu mającego w nazwie wyższą cyfrę (/kopie_zapasowe/home.2), a następnie powtórzyć operację kopiowania z użyciem dowiązań twardych, odłączania i kopiowania. Proces można powtórzyć dowolną liczbę razy i przechowywać wymaganą liczbę wersji. Wymagania dotyczące przestrzeni dyskowej są skromne. Jedyny wzrost zapotrzebowania na miejsce występuje w przypadku plików, które są nowe w kopii zapasowej.
Przykład Zarchiwizujmy katalog /home. Przykładowy katalog zawiera następujące trzy pliki: $ echo "mój oryginalny plik" >/home/plik.txt $ echo "mój oryginalny drugi plik" >/home/drugi_plik.txt $ echo "mój oryginalny trzeci plik" >/home/trzeci_plik.txt $ ls -l /home total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul 8 19:35 plik.txt -rw-r--r-- 1 jnowak mkgrupa-1-d 21 Jul 8 19:35 drugi_plik.txt -rw-r--r-- 1 jnowak mkgrupa-1-d 21 Jul 8 19:35 trzeci_plik.txt
Utwórzmy kopię katalogu /home w katalogu /kopie_zapasowe/home. $ cp -a /home /kopie_zapasowe/home.0 $ ls -l /kopie_zapasowe/home.0 total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul -rw-r--r-- 1 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 1 jnowak mkgrupa-1-d 21 Jul
8 19:35 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
$ du -sb /kopie_zapasowe 58 /kopie_zapasowe
Warto zauważyć, że przy każdym pliku w kolumnie dowiązań widnieje wartość 1. Oznacza to, że w katalogu /kopie_zapasowe istnieje jedna kopia katalogu /home zawierająca te same pliki co ten katalog. Cały katalog /kopie_zapasowe ma rozmiar 58 bajtów, czyli tyle samo, ile wynosi liczba bajtów zajmowanych przez wszystkie trzy pliki. Utwórzmy drugą kopię, korzystając z dowiązań twardych. $ cp -al /home /kopie_zapasowe/home.0 /kopie_zapasowe/home.1 $ ls -l /kopie_zapasowe/* /kopie_zapasowe/home.0: total 3 -rw-r--r-- 2 jnowak mkgrupa-1-d 16 Jul 8 19:35 plik.txt -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul 8 19:35 drugi_plik.txt -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul 8 19:35 trzeci_plik.txt /kopie_zapasowe/home.1: total 3 -rw-r--r-- 2 jnowak mkgrupa-1-d 16 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul
8 19:35 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
$ du -sb /kopie_zapasowe 58 /kopie_zapasowe
Można zauważyć, że w katalogu /kopie_zapasowe występują dwie kopie katalogu /home, z których każda zawiera te same pliki co ten katalog. W dalszym ciągu kopie zajmują tylko 58 bajtów, ponieważ zastosowano dowiązania twarde. Powinno się też zwrócić uwagę na to, że obecnie w kolumnie dowiązań (wyświetlana po wykonaniu polecenia ls -l) znajduje się wartość 2. Zmodyfikujmy plik w katalogu źródłowym. Program rsync z m gawkam
|
207
$ ls -l /home/plik.txt -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul 8 19:35 /home/plik.txt $ echo "ZMODYFIKUJMY PLIK.TXT" >/home/plik.txt $ ls -l /home/plik.txt -rw-r--r-- 1 jnowak mkgrupa-1-d 20 Jul 8 19:41 /home/plik.txt
Warto zauważyć, że zmienił się rozmiar i data modyfikacji pliku plik.txt. Pora wykonać kopię zapasową. Opisany wcześniej proces zauważyłby, że plik /home/plik.txt zmodyfikowano i powinien zostać usunięty z katalogu archiwizacyjnego i skopiowany z katalogu źródłowego. A zatem wykonajmy te operacje. $ rm /kopie_zapasowe/home.0/plik.txt $ cp -a /home/plik.txt /kopie_zapasowe/home.0/plik.txt $ ls -l /kopie_zapasowe/* /kopie_zapasowe/home.0: total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 20 Jul 8 19:41 plik.txt -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul 8 19:35 drugi_plik.txt -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul 8 19:35 trzeci_plik.txt /kopie_zapasowe/home.1: total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul
8 19:35 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
$ du -sb /kopie_zapasowe 78 /kopie_zapasowe
Widać, że plik plik.txt znajdujący się w katalogu /kopie_zapasowe/home.1 dysponuje tylko jednym dowiązaniem (ponieważ usunięto drugie dowiązanie dla katalogu /kopie_zapasowe/home.0). Jednak nadal ma ten sam rozmiar i datę modyfikacji co wcześniej. Można również zauważyć, że teraz katalog /kopie_zapasowe/home.0 zawiera nową wersję pliku plik.txt. Być może najważniejsze jest to, że obecnie rozmiar katalogu /kopie_zapasowe jest równy oryginalnemu powiększonemu o wielkość nowej wersji pliku plik.txt (20 bajtów). W sumie daje to 78 bajtów. Pora przygotować się do sporządzenia kolejnej kopii zapasowej. Najpierw trzeba utworzyć starsze wersje przez przeniesienie katalogów. $ mv /kopie_zapasowe/home.1 /kopie_zapasowe/home.2 $ mv /kopie_zapasowe/home.0 /kopie_zapasowe/home.1
W dalszej kolejności poleceniem cp -al trzeba utworzyć nową poprzednią wersję. $ cp -al /kopie_zapasowe/home.1 $ ls -l /kopie_zapasowe/* /kopie_zapasowe/home.0: total 3 -rw-r--r-- 2 jnowak mkgrupa-1-d -rw-r--r-- 3 jnowak mkgrupa-1-d -rw-r--r-- 3 jnowak mkgrupa-1-d
/kopie_zapasowe/home.0
20 Jul 21 Jul 21 Jul
8 19:41 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
/kopie_zapasowe/home.1: total 3 -rw-r--r-- 2 jnowak mkgrupa-1-d 20 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:41 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
/kopie_zapasowe/home.2: total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:35 plik.txt 8 19:35 drugi_plik.txt
208 |
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
-rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:35 trzeci_plik.txt
$ du -sb /kopie_zapasowe 78 /kopie_zapasowe
Teraz dysponujemy katalogiem /kopie_zapasowe/home.2, zawierającym najstarszą wersję, i katalogami /kopie_zapasowe/home.1 i /kopie_zapasowe/home.0, przechowującymi bieżącą kopię zapasową. Warto zauważyć, że rozmiar katalogu /kopie_zapasowe nie zmienił się od czasu, gdy po raz ostatni go sprawdzano. W dalszym ciągu rozmiar wynosi 78 bajtów. Zmodyfikujmy następny plik i zarchiwizujmy go. $ echo "ZMODYFIKUJMY DRUGI_PLIK.TXT" >/home/drugi_plik.txt $ rm /kopie_zapasowe/home.0/drugi_plik.txt $ cp -a /home/drugi_plik.txt /kopie_zapasowe/home.0/drugi_plik.txt $ ls -l /kopie_zapasowe/* /kopie_zapasowe/home.0: total 3 -rw-r--r-- 2 jnowak mkgrupa-1-d 20 Jul 8 19:41 plik.txt -rw-r--r-- 1 jnowak mkgrupa-1-d 25 Jul 8 19:45 drugi_plik.txt -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul 8 19:35 trzeci_plik.txt /kopie_zapasowe/home.1: total 3 -rw-r--r-- 2 jnowak mkgrupa-1-d 20 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:41 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
/kopie_zapasowe/home.2: total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:35 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
$ du -sb /kopie_zapasowe 103 /kopie_zapasowe
Jak widać, obecnie katalog /kopie_zapasowe/home.0 zawiera inną wersję pliku drugi_plik.txt niż znajdujące się w pozostałych katalogach. Rozmiar katalogu /kopie_zapasowe zwiększył się z 78 do 103, co daje różnicę 25 bajtów, czyli wielkość nowej wersji pliku drugi_plik.txt. Przygotujmy się na następną kopię zapasową. $ $ $ $
mv mv mv cp
/kopie_zapasowe/home.2 /kopie_zapasowe/home.3 /kopie_zapasowe/home.1 /kopie_zapasowe/home.2 /kopie_zapasowe/home.0 /kopie_zapasowe/home.1 -al /kopie_zapasowe/home.1 /kopie_zapasowe/home.0
Zmieńmy ostatni z plików i zarchiwizujmy go. $ echo "ZMODYFIKUJMY TRZECI_PLIK.TXT" >/home/trzeci_plik.txt $ rm /kopie_zapasowe/home.0/trzeci_plik.txt $ cp -a /home/trzeci_plik.txt /kopie_zapasowe/home.0/trzeci_plik.txt $ ls -l /kopie_zapasowe/* /kopie_zapasowe/home.0: total 3 -rw-r--r-- 3 jnowak mkgrupa-1-d 20 Jul 8 19:41 plik.txt -rw-r--r-- 2 jnowak mkgrupa-1-d 25 Jul 8 19:45 drugi_plik.txt -rw-r--r-- 1 jnowak mkgrupa-1-d 29 Jul 8 19:51 trzeci_plik.txt /kopie_zapasowe/home.1: total 3 -rw-r--r-- 3 jnowak mkgrupa-1-d 20 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 25 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:41 plik.txt 8 19:45 drugi_plik.txt 8 19:35 trzeci_plik.txt
Program rsync z m gawkam
| 209
/kopie_zapasowe/home.2: total 3 -rw-r--r-- 3 jnowak mkgrupa-1-d 20 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:41 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
/kopie_zapasowe/home.3: total 3 -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul -rw-r--r-- 2 jnowak mkgrupa-1-d 21 Jul -rw-r--r-- 3 jnowak mkgrupa-1-d 21 Jul
8 19:35 plik.txt 8 19:35 drugi_plik.txt 8 19:35 trzeci_plik.txt
$ du -sb /kopie_zapasowe 103 /kopie_zapasowe
Również w tym przypadku rozmiar katalogu /kopie_zapasowe zwiększył się z 103 do 132 bajtów, co daje różnicę 29 bajtów, czyli wielkość nowej wersji pliku trzeci_plik.txt. Czyż dowodem nie jest proces odtwarzania? Przyjrzyjmy się zawartości wszystkich wersji każdego z plików przez zastosowanie polecenia cat. $ cat /kopie_zapasowe/home.3/* mój oryginalny plik mój oryginalny drugi plik mój oryginalny trzeci plik $ cat /kopie_zapasowe/home.2/* ZMODYFIKUJMY PLIK.TXT mój oryginalny drugi plik mój oryginalny trzeci plik $ cat /kopie_zapasowe/home.1/* ZMODYFIKUJMY PLIK.TXT ZMODYFIKUJMY DRUGI_PLIK.TXT mój oryginalny trzeci plik $ cat /kopie_zapasowe/home.0/* ZMODYFIKUJMY PLIK.TXT ZMODYFIKUJMY DRUGI_PLIK.TXT ZMODYFIKUJMY TRZECI_PLIK.TXT
Jak widać, najstarsza wersja kopii zapasowej (katalog /kopie_zapasowe/home.3) zawiera oryginalną wersję każdego pliku, nowsza przechowuje zmodyfikowany plik plik.txt, jeszcze nowsza obejmuje ten plik i zmodyfikowany plik drugi_plik.txt, z kolei w najnowszej wersji umieszczono zmodyfikowane wersje każdego pliku. Czy to nie piękne?
Coś więcej niż tylko przykład Choć powyższy przykład działa i jest prosty do zrozumienia, w pewnym sensie trudno coś takiego wdrożyć. Część kroków, takich jak dodanie katalogów powiązanych za pomocą dowiązań twardych, identyfikowanie nowych plików, usuwanie plików, które się nadpisze, i przesyłanie nowych plików, trzeba raczej wykonać ręcznie. Ponadto przytoczony przykład nie dotyczy plików, które usunięto ze źródłowej lokalizacji. Takie pliki pozostaną w kopii zapasowej. A jeśli byłoby dostępne polecenie, które mogłoby zrealizować wszystkie te działania w jednym kroku? Tak się składa, że istnieje i nazywa się rsync! Narzędzie rsync jest bardzo dobrze znanym składnikiem oprogramowania GPL, napisanym przez Andrew Tridgella i Paula Mackerrasa. Jeżeli ktoś używa popularnej odmiany systemu Unix, prawdopodobnie już zainstalował to narzędzie. Jeśli nie, może zainstalować prekompilowany pakiet lub pobrać kod źródłowy z witryny http://rsync.samba.org , a następnie sam
210
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
go skompilować. Choć specjalnością narzędzia rsync jest skuteczne synchronizowanie drzew plików za pośrednictwem sieci, działa dobrze również na pojedynczym komputerze. Poniżej przedstawiono przykład ilustrujący podstawowe funkcjonowanie programu rsync. Załóżmy, że istnieje katalog /, którego zawartość ma zostać przekopiowana do innego katalogu o nazwie /. Jeśli jest dostępne polecenie cp w wersji GNU, można wykonać kopię. $ cp -a katalog_źródłowy/. katalog_docelowy/
Opcja archiwizacji (-a) powoduje, że program cp rekursywnie przetwarza drzewo plików i zachowuje ich metadane, takie jak prawa właściciela, uprawnienia i znaczniki czasu. Powyższe polecenie w razie potrzeby tworzy najpierw docelowy katalog. Ważne jest, aby użyć /., a nie /*, ponieważ w przypadku drugiego zapisu bez powiadamiania są ignorowane pliki i podkatalogi najwyższego poziomu, których nazwy rozpoczynają się od kropki. Takie pliki traktowane są jak ukryte i nie są standardowo uwzględniane w listingach katalogów. Jednak mogą być istotne dla czytelnika!
Jeśli jednak tworzy się regularne kopie zapasowe zawartości katalogu / i zapisuje je w katalogu /, uruchamianie każdorazowo programu cp nie będzie tak efektywne, ponieważ zawsze muszą być kopiowane nawet te pliki, które nie zostały zmodyfikowane (jest to większość plików). Poza tym okresowo trzeba by było usuwać katalog / i tworzyć go na nowo, w przeciwnym razie kopie zapasowe plików usuniętych z katalogu / zaczęłyby się akumulować. Na szczęście, choć program cp rozczarowuje w przypadku kopiowania często modyfikowanych plików, narzędzie rsync świetnie sobie z tym radzi. Polecenie rsync działa podobnie do polecenia cp, lecz używa bardzo inteligentnego algorytmu kopiującego jedynie zmiany. Odpowiednie polecenie rsync wyglądałoby następująco: $ rsync -a katalog_źródłowy/. katalog_docelowy/
Program rsync zwraca szczególną uwagę na obecność znaku / w argumencie, będącym katalogiem źródłowym. Narzędzie traktuje inaczej zapisy i /. Zastosowanie znaków /. jest dobrym sposobem na uniknięcie niejednoznaczności.
Prawdopodobnie Czytelnik będzie chciał dodać opcję --delete, która powoduje, że oprócz kopiowania nowych zmian są usuwane wszystkie pliki zawarte w katalogu katalog_docelowy/, a nieobecne w katalogu katalog_źródłowy/ (ponieważ przypuszczalnie zostały usunięte). W celu uzyskania szczegółowych informacji dotyczących transferu można dodać opcję -v. Poniższe polecenie to dobra metoda regularnego synchronizowania katalogu katalog_źródłowy/ z katalogiem katalog_docelowy/. $ rsync -av --delete katalog_źródłowy/. katalog_docelowy/
Choć program rsync dobry jest do synchronizowania lokalnych plików, dopiero w przypadku synchronizowania danych za pośrednictwem sieci pokazuje swoje prawdziwe możliwości. Unikatowa funkcja narzędzia rsync umożliwiająca kopiowanie jedynie zmian sprawia, że jest ono bardzo szybkie i może transparentnie działać ponad połączeniem ssh. W celu zsynchronizowania za pomocą programu rsync (przy wykorzystaniu narzędzia ssh) danych katalogu
Program rsync z m gawkam
|
211
// zdalnego komputera przyklad.abc.com z zawartością lokalnego katalogu // należy wykonać następujące polecenie: $ rsync -av --delete nazwa_uż[email protected]:/katalog_źródłowy/. /katalog_docelowy/
W tym przypadku narzędzie rsync działa w trybie pobierania. Równie dobrze może ono funkcjonować w trybie wysyłania, polegającym na transferowaniu danych z lokalnego katalogu // do zdalnego /katalog_docelowy/. $ rsync -av --delete /katalog_źródłowy/. nazwa_uż[email protected]:/katalog_docelowy/
Na koniec należy wspomnieć, że program rsync oferuje opcje --include i --exclude, które umożliwiają dokładne kontrolowanie tego, jakie mają zostać skopiowane składniki źródłowego katalogu. Jeśli z kopii zapasowej zamierza się wykluczyć określone pliki (na przykład każdy plik mający rozszerzenie .bak lub wybrane podkatalogi), opcje te mogą okazać się przydatne. W celu zapoznania się ze szczegółami i przykładami należy przejrzeć dokumentację narzędzia rsync.
Dowiązania twarde Dowiązania twarde to ważne zagadnienie związane z systemem Unix, które trzeba zrozumieć, jeśli zamierza się korzystać z tego typu dowiązań. Każdy obiekt uniksowego systemu plików, w tym katalog, dowiązanie symboliczne, potok nazwany i węzeł urządzenia, jest identyfikowany przez unikatową dodatnią liczbę całkowitą nazywaną numerem i-węzła. I-węzeł rejestruje typowe szczegóły, takie jak typ obiektu, lokalizacja jego danych, data ostatniej aktualizacji i osoba mająca uprawnienia dostępu. Jeżeli poleceniem ls generuje się listę plików, dodając opcję -i, można zobaczyć numery i-węzłów. $ ls -i foo 409736 foo
Z czego składa się plik foo? Plik ten jest złożony z i-węzła (dokładniej: numeru i-węzła o wartości 409 736) i danych. Ponadto (jest to bardzo istotne) w katalogu przechowującym plik foo znajduje się rekord dla nowego i-węzła. Rekord zawiera nazwę pliku foo, a obok niej wartość 409 736. Wpis z nazwą pliku i numerem i-węzła umieszczony w nadrzędnym katalogu tworzy dowiązanie twarde. Do najbardziej typowych plików odwołuje się tylko jedno dowiązanie twarde. Jednak możliwe jest, że do i-węzła będzie więcej niż jedno odwołanie. I-węzły przechowują również licznik dowiązań twardych wskazujących na nie. Polecenie ls -l generuje kolumnę pokazującą, ile dowiązań ma określony plik (wartość widoczna z lewej strony identyfikatora użytkownika będącego właścicielem pliku identyfikuje liczbę dowiązań twardych; w poniższym przykładowym wyniku polecenia występuje jedno dowiązanie). $ ls -l foo -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul
8 19:35 foo
W celu utworzenia dla pliku w obrębie systemu plików drugiego dowiązania należy zastosować polecenie ln. Oto przykład: $ ln foo bar $ ls -i foo bar 409736 foo 409736 bar
212
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
Dowiązania twarde podobne do powyższych mogą być tworzone tylko dla plików znajdujących się w obrębie tego samego systemu plików.
Nazwy foo i bar odwołują się teraz do tego samego pliku. Jeśli modyfikuje się plik foo, jednocześnie będzie edytowany plik bar i odwrotnie. Jeżeli zmieni się uprawnienia lub właściciela jednego z plików, będzie to również dotyczyć drugiego pliku. Nie ma możliwości stwierdzenia, która nazwa z dwóch jest pierwsza, ponieważ są równoważne. Gdy usuwa się plik, w rzeczywistości usuwa się jedynie dowiązanie do i-węzła. Operacja ta jest nazywana odłączaniem. I-węzeł jest zwalniany dopiero wtedy, gdy liczba jego dowiązań spadnie do zera (nawet jeśli to nastąpi, i-węzeł jest zwalniany wyłącznie wtedy, gdy korzystanie z niego zakończy ostatni proces; z tego powodu możliwe jest usunięcie pliku binarnego aktywnego programu). Przykładowo polecenie ls -l informuje, że plik foo ma dwa dowiązania. Jeśli usunie się plik bar, pozostanie tylko jedno dowiązanie. $ ls -l foo -rw-r--r-- 2 jnowak mkgrupa-1-d 16 Jul $ rm bar $ ls -l foo -rw-r--r-- 1 jnowak mkgrupa-1-d 16 Jul
8 19:35 foo 8 19:35 foo
Sytuacja wyglądałaby identycznie, gdyby usunięto plik foo i dla pliku bar wykonano polecenie ls -l. Jeśli teraz usunie się plik foo, liczba dowiązań spadnie do zera i system operacyjny zwolni i-węzeł o wartości 409 736. Poniżej zamieszczono podsumowanie kilku ważnych właściwości dowiązań twardych. Jeśli pliki foo i bar są dowiązaniami twardymi do tego samego i-węzła, to: • Modyfikacja pliku foo natychmiast wpłynie na plik bar i odwrotnie. • Edycja metadanych pliku foo (uprawnienia, prawo własności lub znaczniki czasu) będzie
miała wpływ na metadane pliku bar i odwrotnie. • Zawartość pliku jest przechowywana tylko raz. Polecenie ln nie zwiększa znacząco za-
potrzebowania na przestrzeń dyskową.
• Dowiązania twarde foo i bar muszą znajdować się w obrębie tego samego systemu plików.
Nie można utworzyć dowiązania twardego dla i-węzła umieszczonego w innym systemie plików, ponieważ numery i-węzłów są unikatowe tylko wewnątrz jednego systemu plików. • Zanim systemowi operacyjnemu zwolni się i-węzeł i dane, trzeba odłączyć zarówno plik
foo, jak i bar (za pomocą programu rm).
Kopie oparte na dowiązaniach twardych W poprzednim punkcie napisano, że polecenie ln foo bar tworzy drugie dowiązanie twarde o nazwie bar dla i-węzła pliku foo. Pod wieloma względami plik bar wygląda jak kopia pliku foo utworzonego w tym samym czasie. Różnice stają się istotne, gdy spróbuje się zmodyfikować jeden z plików, sprawdzić numery i-węzłów lub przestrzeń dyskową. Innymi słowy, dopóki są zabronione bezpośrednie modyfikacje, wynik wykonania poleceń cp foo bar i ln foo bar będzie dla użytkowników niemal nie do rozróżnienia. Jednak drugie polecenie nie wykorzystuje dodatkowej przestrzeni dyskowej.
Program rsync z m gawkam
|
213
Załóżmy, że planuje się regularne archiwizowanie katalogu katalog_źródłowy/. Pierwszą pełną kopię zapasową można sporządzić poleceniem rsync. $ rsync -av --delete katalog_źródłowy/. kopia_zapasowa.0/
Aby utworzyć drugą kopię, można po prostu sporządzić kolejną pełną kopię zapasową. $ mv kopia_zapasowa.0 kopia_zapasowa.1 $ rsync -av --delete katalog_źródłowy/. kopia_zapasowa.0/
Byłoby to nieefektywne, gdyby w określonym czasie zostało zmodyfikowanych tylko kilka plików katalogu katalog_źródłowy/. W związku z tym należy utworzyć drugą kopię katalogu kopia_zapasowa.0, pełniącą rolę docelowej (ponieważ są używane dowiązania twarde, nie jest zużywana dodatkowa przestrzeń dyskowa). Do sporządzania kopii zapasowych w ten sposób można użyć dwóch różnych metod. Pierwsza jest trochę prostsza do zrozumienia i tę wykorzystano w przykładzie. Druga nieznacznie wszystko usprawnia przez zastosowanie jednego polecenia. Wersja GNU programu cp oferuje opcję -l, która powoduje, że zamiast zwykłych kopii są tworzone kopie oparte na dowiązaniach twardych. Polecenie cp może nawet rekurencyjnie przetworzyć katalogi. $ mv kopia_zapasowa.0 kopia_zapasowa.1 $ cp -al kopia_zapasowa.1/. kopia_zapasowa.0/ $ rsync -av --delete katalog_źródłowy/. kopia_zapasowa.0/
Polecenie cp -al umieszczone między dwoma poleceniami archiwizującymi tworzy opartą na dowiązaniu twardym kopię najnowszej kopii zapasowej. W dalszej kolejności za pomocą programu rsync nowe zmiany wprowadzone w katalogu / są uwzględniane w katalogu kopia_zapasowa.0. Narzędzie rsync ignoruje pliki, które nie zostały zmodyfikowane. W związku z tym pozostawia nienaruszone dowiązania niezmienionych plików. Gdy program rsync musi zmodyfikować plik, najpierw odłącza oryginał, aby operacja nie miała na niego wpływu. Jak wspomniano, opcja --delete usuwa również wszystkie pliki katalogu docelowego, których nie ma już w katalogu źródłowym (w bieżącym katalogu archiwizacyjnym następuje jedynie odłączenie tych plików). Obecnie narzędzie rsync ma do wykonania wiele zadań. Decyduje, które pliki skopiować, odłącza je od katalogu docelowego, kopiuje zmodyfikowane pliki i usuwa wszelkie wymagane pliki. Przyjrzyjmy się teraz temu, jak narzędzie potrafi dobrze radzić sobie także z dowiązaniami twardymi. Program rsync oferuje nową opcję --link-dest, która zajmuje się za użytkownika dowiązaniami twardymi nawet wtedy, gdy zmieniły się tylko metadane. Zamiast oddzielnie wykonywać polecenie cp -al i uruchamiać program rsync, opcja --link-dest nakazuje mu wykonanie całego zadania, czyli skopiowanie zmian do nowego katalogu i gdy to możliwe, utworzenie dowiązań twardych dla niezmodyfikowanych plików. Proces ten jest też znacznie szybszy. $ mv kopia_zapasowa.0 kopia_zapasowa.1 $ rsync -av --delete --link-dest=../home.0 /home/. /kopie_zapasowe/home/
Warto zwrócić uwagę na względną ścieżkę ../ powiązaną z katalogiem /home.0/. Ścieżka opcji --link-dest powinna być względna w stosunku do docelowego katalogu (w tym przypadku /kopie_zapasowe/home). Dla wielu osób było to powodem nieporozumień.
214
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
Prosty przykładowy skrypt Poniższy skrypt może być uruchamiany dowolną ilość razy. Gdy uaktywni się go po raz pierwszy, utworzy pierwszą pełną kopię zapasową katalogu /home w katalogu /kopie_zapasowe/home. ¦inprogress i po ukończeniu operacji przeniesie go do katalogu /kopie_zapasowe/home.0. Po ponownym uruchomieniu skryptu narzędzie rsync utworzy opartą na dowiązaniu twardym kopię katalogu /kopie_zapasowe/home.0 w katalogu /kopie_zapasowe/home.inprogress, który następnie wykorzysta na potrzeby synchronizowania. Skrypt najpierw odłączy wszystkie zmodyfikowane pliki, po czym uaktualni je. Ostatecznie skrypt przechowuje trzy wersje kopii zapasowej. rsync -av --delete --link-dest=../home.0 /home/. /kopie_zapasowe/home.inprogress/ -d /kopie_zapasowe/home.2 ] && rm -rf /kopie_zapasowe/home.2 -d /kopie_zapasowe/home.1 ] && mv /kopie_zapasowe/home.1 /kopie_zapasowe/home.2 -d /kopie_zapasowe/home.0 ] && mv /kopie_zapasowe/home.0 /kopie_zapasowe/home.1 -d /kopie_zapasowe/home.inprogress ] && mv /kopie_zapasowe/home.inprogress /kopie_zapasowe/home.0 touch /kopie_zapasowe/home.0 $ [ [ [ [
Jest to bardzo prosty skrypt. Jeśli ktoś na poważnie zamierza wykorzystać takie rozwiązanie, do wyboru ma dwie możliwości: może zajrzeć na stronę internetową Mike’a Rubela (http://www. ¦mikerubel.org/computers/rsync_snapshots) lub zapoznać się z podrozdziałem poświęconym narzędziu rsnapshot zamieszczonym w dalszej części rozdziału. W podrozdziale przedstawiono pełne wdrożenie narzędzia rsnapshot, a także wspomniano o wspierającej je grupie użytkowników.
Odtwarzanie danych z kopii zapasowej Ponieważ kopie zapasowe tworzone w wyżej opisany sposób są po prostu tradycyjnymi uniksowymi systemami plików, istnieje tyle wariantów odtwarzania danych, ile metod kopiowania plików. Jeśli kopie zapasowe są lokalnie przechowywane (na przenośnym dysku twardym) lub dostępne za pośrednictwem sieciowego systemu plików, takiego jak NFS, można po prostu za pomocą programu cp skopiować pliki z kopii zapasowych do katalogu /home. Jeszcze lepszym rozwiązaniem będzie odtworzenie plików przy użyciu narzędzia rsync. $ rsync -av --delete /kopie_zapasowe/home.0/. /home/
W przypadku odtwarzania danych z uwagą należy stosować opcję --delete. Trzeba być pewnym, że naprawdę ma się świadomość tego, co się robi! Jeżeli kopie zapasowe są magazynowane na zdalnym komputerze dostępnym za pośrednictwem narzędzia ssh, zamiast niego można użyć programu scp lub rsync. Możliwe są również inne proste rozwiązania, takie jak umieszczanie katalogów w miejscu dostępnym dla serwera WWW.
Kwestie do rozważenia Poniżej przedstawiono kilka rzeczy godnych rozważenia, jeśli kopie zapasowe zamierza się sporządzać przy użyciu programu rsync.
Jaki ma być rozmiar każdej kopii zapasowej? Wadą metody wykorzystującej narzędzie rsync i dowiązania twarde jest to, że udostępnianie niezmodyfikowanych plików pozornie utrudnia określenie rozmiaru dowolnego katalogu archiwizacyjnego. W prosty sposób nie można udzielić odpowiedzi na typowe i rozsądne pytanie: „Które katalogi archiwizacyjne należy usunąć, aby zwolnić 100 MB przestrzeni dyskowej?”. Program rsync z m gawkam
|
215
Przestrzeń zwalniana przez usunięcie wybranego katalogu archiwizacyjnego jest równa sumie dodatkowej specjalnej przestrzeni dysku i miejsca zajmowanego przez wszystkie pliki, których wyłącznie dowiązania twarde znajdują się w tym katalogu. Używając polecenia find, można uzyskać listę takich plików. W tym przypadku polecenie przetwarza katalog /kopie_zapasowe/ ¦home.1/. $ find /kopie_zapasowe/home.1 -type f -links 1 -print
Poniższe polecenie wyświetla całkowitą przestrzeń dyskową zajmowaną przez katalog /kopie_ ¦zapasowe/home.1/. $ du -hc 'find /kopie_zapasowe/home.1 -type f -links 1 -print' | tail -n 1
Usunięcie więcej niż jednego katalogu archiwizacyjnego zwykle zwalnia więcej miejsca, niż wynosi całkowita przestrzeń dyskowa zajmowana przez poszczególne katalogi. Wynika to stąd, że w ramach operacji są też usuwane wszystkie pliki, które były współużytkowane wyłącznie przez te katalogi. Polecenie może wygenerować błędne wartości, jeśli w źródłowych danych znajdowało się mnóstwo plików bazujących na dowiązaniach twardych.
Coś na temat formatów wiadomości pocztowych Obecnie jest stosowanych kilka popularnych formatów przechowywania wiadomości pocztowych. Poczciwy format mbox przechowuje wszystkie wiadomości katalogu w jednym dużym pliku. Nowszy format maildir, rozpowszechniony przez narzędzie Qmail, umożliwia zapisywanie każdej wiadomości w postaci niewielkiego pliku. Są również wykorzystywane inne bazodanowe formaty magazynowania wiadomości pocztowych. Spośród tych formatów jak dotąd najbardziej efektywny w przypadku metody wykorzystującej narzędzie rsync i dowiązania twarde jest format maildir, ponieważ jego struktura nie zmienia większości plików (dotyczy starszych wiadomości). Jest tak też w przypadku narzędzia rsnapshot omówionego w dalszej części rozdziału. Gdy są używane kolejki wiadomości w formacie mbox, pod uwagę należy wziąć zastosowanie narzędzia rdiff-backup.
Inne przydatne opcje programu rsync Jeśli dysponuje się wolnym połączeniem sieciowym, można zdecydować się na użycie opcji --bwlimit narzędzia rsync, która powoduje, że archiwizacja nie przeciąży łącza. Opcja umożliwia określenie maksymalnej przepustowości wyrażonej w kilobajtach na sekundę. Jeżeli zastosuje się opcję --numeric-ids programu rsync, zignoruje on nazwy użytkowników, eliminując konieczność tworzenia kont użytkowników na serwerze archiwizującym.
Archiwizowanie baz danych lub innych zmieniających się dużych plików Metoda przedstawiona w niniejszym rozdziale jest przeznaczona dla niewielkich plików, które nie zmieniają się zbyt często. W przeciwnym razie (na przykład w przypadku archiwizowania regularnie modyfikowanych dużych plików, takich jak pliki bazodanowe, kolejki wiadomości formatu mbox lub pliki UML COW) metoda nie będzie efektywna z punktu widzenia wykorzystania przestrzeni dyskowej. W tego typu sytuacjach pod uwagę należy wziąć zastosowanie narzędzia rdiff-backup, które omówiono w dalszej części rozdziału. 216
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
Archiwizowanie komputerów z systemem Windows Choć program rsync współpracuje z oprogramowaniem cygwin, zgłoszono problemy związane ze znacznikami czasu, zwłaszcza podczas archiwizowania systemów plików FAT. W przeciwieństwie do systemów uniksowych, stosujących czas uniwersalny, komputery z systemem Windows tradycyjnie używają lokalnego czasu z jego zmianami na letni i innymi dziwactwami. Co najmniej część znaczników czasu plików jest tworzonych z zastosowaniem dwusekundowej dokładności. W przypadku systemu Windows pod uwagę warto wziąć ustawienie dla programu rsync opcji --modify-window o wartości 2.
Duże systemy plików i skalowanie pamięci wykorzystywanej przez narzędzie rsync Choć w ostatnich latach sytuacja się poprawiła, program rsync wciąż używa sporej ilości pamięci podczas synchronizowania dużych drzew plików. Może okazać się konieczne rozbicie zadania archiwizacyjnego na części i wykonanie ich oddzielnie. Wtedy może być konieczne ręczne usunięcie (za pomocą opcji --delete) z miejsca docelowego danych, które zostały usunięte z serwera.
Jednolitość i częściowe transfery Narzędzie rsync przyjmuje ograniczony czas działania. Gdy w czasie trwania archiwizacji plik źródłowy zostanie zmodyfikowany, może być wygenerowany błąd częściowego transferu (kod 23). Tylko pliki, które się nie zmieniły, mogą być transferowane. Program rsync wykonuje swoje zadanie na tyle, na ile jest to możliwe. Jeżeli kopie zapasowe sporządza się tylko wtedy, gdy zawartość komputera jest dość statyczna (na przykład w środku nocy w przypadku środowiska biurowego), częściowe transfery mogą nigdy nie stanowić problemu. Jeśli jednak są problemem, należy rozważyć zastosowanie opcji --partial narzędzia rsync.
Narzędzie rsnapshot rsnapshot jest narzędziem open source służącym do archiwizowania i odtwarzania, opartym na oryginalnym pomyśle Mike’a Rubela. Narzędzie zostało zaprojektowane, aby wykorzystać znakomity pomysł. Dzięki temu narzędziu rozwiązanie stworzone przez Rubela jest w większym zakresie dostępne dla użytkowników i bardziej przydatne w przypadku bardziej rozbudowanych środowisk. Wewnętrzne mechanizmy funkcjonalne narzędzia rsnapshot są takie same jak oryginalnych skryptów Mike’a Rubela, omówionych wcześniej w rozdziale. W celu zaoszczędzenia przestrzeni dyskowej program rsnapshot używa dowiązań twardych, a także narzędzia rsync, aby kopiować zmiany i w razie potrzeby usuwać dowiązania twarde. Oto podstawowe różnice występujące między narzędziem rsnapshot i oryginalnym skryptem Mike’a Rubela1: • rsnapshot napisano w języku Perl, ponieważ jest rozpowszechniony i pozwala z większą
łatwością analizować plik konfiguracyjny. 1
Część z podanych różnic już nie istnieje, ponieważ Mike cały czas aktualizował swój skrypt. Dokładniej mówiąc, nowa wersja skryptu obsługuje wiele drzew i blokowanie, a także ma interfejs zgodny z narzędziem syslog.
Narzędz e rsnapshot
|
217
Gdzie to umieszczono? Nowy wiceprezes przyszedł i poprosił nas o pomoc w rozwiązaniu problemu zaistniałego na jego komputerze PC. Gdy zacząłem usuwać problem, zauważyłem, że jego komputer był wyjątkowo wolny. Jego napęd był zapełniony w 99% i naprawdę pofragmentowany. Usunąłem zawartość kosza i przeprowadziłem defragmentację napędu. Wszystkie problemy zniknęły. I wtedy wyszło na jaw coś innego. Wiceprezes organizował sobie pracę przez umieszczanie wszystkich ważnych plików w koszu. Klawisz Delete był poręczny i przenosił rzeczy do kosza bardzo szybko (ikona kosza była jedną z trzech dostępnych na pulpicie; czyż nie jest to naprawdę praktyczne rozwiązanie?). Wiceprezes twierdził, że było to coś, czego nauczył się w wojsku. Oczywiście używany przez nas program archiwizujący nie uwzględniał zawartości kosza. — Mark • rsnapshot za pomocą jednego skryptu obsługuje wiele poziomów archiwizacji (dzienne,
tygodniowe i miesięczne kopie zapasowe).
• rsnapshot archiwizuje wiele drzew katalogowych pochodzących z wielu źródeł z możli-
wością opcjonalnego dostrajania typu używanych parametrów programu rsync. • rsnapshot obsługuje blokowanie, dzięki czemu jednocześnie nie będą wykonywane dwie
kopie zapasowe.
• rsnapshot obsługuje program syslog. • rsnapshot obsługuje skrypty wykonywane przed i po archiwizacji, które przydają się na
przykład przy tworzeniu zrzutów baz danych.
Obsługa platform W przypadku takich uniksowych platform, jak systemy Linux, FreeBSD i Solaris, narzędzie rsnapshot „czuje” się jak w domu. Jednak może też być użyte do archiwizowania danych systemów innych niż uniksowe. Narzędzie rsnapshot wymaga uruchomienia tam, gdzie program rsync może przetwarzać dowiązania twarde, czyli w systemie uniksowym. W tym przypadku do platformy uniksowej można zaliczyć system Mac OS X, choć występują pewne problemy związane z rozwidleniami zasobów i jego systemem plików HFS+, odróżniającym wielkość znaków. Na szczęście są to bardzo rzadkie problemy. Rozwidlenia zasobów nie są nigdzie tak istotne jak w systemie Mac OS X. Równie ważne były w klasycznym systemie Mac OS (należy zapoznać się z punktem rozdziału 3. poświęconym tej kwestii). Klasyczny system Mac OS nie jest w ogóle obsługiwany. Choć może być możliwe uruchomienie serwera rsync pod tym systemem i zarchiwizowanie go za pomocą narzędzia rsnapshot, nie zostaną wprowadzone w tym programie żadne zmiany mające na celu obsługę klasycznego systemu Mac OS.
Choć narzędzie rsnapshot może archiwizować komputery z systemem Windows, nie można pod nim uaktywnić serwera rsnapshot z powodu braku obsługi dowiązań twardych. Ponadto ze względu na to, że w porównaniu ze światem uniksowym uprawnienia w systemie Windows są bardzo odmienne, niemal na pewno nie będą poprawnie archiwizowane. Również znaczniki 218
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
czasu plików mogą nie być właściwie archiwizowane, ponieważ system Windows przechowuje znaczniki przy wykorzystaniu lokalnej strefy czasowej, natomiast system Unix używa do tego czasu uniwersalnego. Jednak pomimo tych niedogodności narzędzie rsnapshot jest z powodzeniem stosowane przez wiele osób do archiwizowania danych komputerów z systemem Windows. W celu uwzględnienia w kopii zapasowej uprawnień przed jej sporządzeniem można uruchomić skrypt wykonujący zrzut informacji dotyczących uprawnień plików i użytkowników. Zrzut jest umieszczany w pliku, który następnie jest dołączany do kopii zapasowej. Gdy przywróci się plik z kopii zapasowej, odpowiednie uprawnienia plików odtwarza się ręcznie lub za pomocą skryptu odwołującego się do tego pliku. Oczywiście, zanim zaufa się takiej procedurze, powinno się ją przetestować, aby mieć pewność, że zapisano odpowiednią ilość danych i skrypt poprawnie odczytuje plik! Niektóre złożone funkcje uniksowego systemu plików nie są archiwizowane, ponieważ narzędzie rsync nie obsługuje ich. Mowa o listach kontroli dostępu ACL i rozszerzonych atrybutach systemu plików. Są one rzadko stosowane i można wykorzystać to samo rozwiązanie co opisane wcześniej dla systemu Windows. Do narzędzia rsnapshot nie dołączono żadnych przydatnych w tym przypadku skryptów ze względu na dużą odmienność poszczególnych platform (z tego samego powodu sam program rsync nie obsługuje złożonych funkcji uniksowego systemu plików). Program rdiff-backup często umożliwia archiwizowanie list kontroli dostępu ACL.
Kiedy nie należy używać narzędzia rsnapshot? Nawet w przypadku najmniejszej modyfikacji pliku narzędzie rsnapshot umieszcza jego nową kopię w kopii zapasowej. Dobrze się to sprawdza, gdy doda się lub usunie plik bądź wprowadzi w nim znaczne modyfikacje. Jednak nie jest już tak wspaniale w przypadku niewielkich zmian dokonywanych w dużym pliku lub ciągłego modyfikowania pliku. W takich sytuacjach traci się wszystkie zalety dowiązań twardych (w dalszej części rozdziału omówiono program rdiffbackup). Pliki dzienników i pliki skrzynek wiadomości pocztowych formatu mbox należą do tych, w przypadku których tego typu zmiany są powszechne. Zwykle dane te stanowią jedynie znikomą część danych komputera. W związku z tym ilość straconej przestrzeni dyskowej jest dość niewielka w porównaniu z rozmiarem kopii zapasowej. Jednak w określonych przypadkach serwerów pocztowych i rejestrujących zdarzenia systemowe wyłącznie tego typu modyfikacji plików jest naprawdę dużo. W takich sytuacjach zaleca się użycie programu rdiff-backup.
Konfigurowanie narzędzia rsnapshot Pakiety narzędzia rsnapshot są dostępne dla kilku dystrybucji systemu Linux i mogą być z łatwością zainstalowane za pomocą wbudowanego menedżera pakietów. Jeśli dla używanej dystrybucji lub systemu operacyjnego nie ma dostępnego pakietu bądź zamierza się zastosować najbardziej aktualną wersję, pod następującym adresem można znaleźć plik .tar.gz: http://www.rsnapshot.org/downloads.html
Narzędz e rsnapshot
|
219
W celu zainstalowania najnowszej wersji należy najpierw rozpakować plik archiwum. $ gzip -d rsnapshot-wersja.tar.gz | tar xvf -
W dalszej kolejności należy przejść do katalogu utworzonego przez powyższe polecenie. $ cd rsnapshot-wersja
W katalogu istnieje plik z instrukcjami o nazwie INSTALL. Jednak zwykle w przypadku nowej instalacji trzeba będzie wykonać następujące polecenia: $ ./configure $ su (pojawi się prośba o podanie hasła) # make install # cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf
Dalej należy zmodyfikować plik /etc/rsnapshot.conf, aby podać narzędziu rsnapshot lokalizację kopii zapasowych, ich zawartość itp. W przykładowej konfiguracji znajduje się spora liczba instrukcji. Większość użytkowników musi zmodyfikować tylko niżej wymienione ustawienia. backup
Zawartość kopii zapasowej. snapshot_root
Lokalizacja kopii zapasowych. interval
Pora sporządzania kopii zapasowych. include i exclude
Pliki, na które narzędzie rsync zwraca uwagę. Nową konfigurację można sprawdzić, wykonując następujące polecenie: $ rsnapshot configtest
Jeśli wszystko dobrze wygląda, należy utworzyć zadania narzędzia cron, które będą automatycznie uaktywniały program rsnapshot. Zadanie można umieścić w pliku cron użytkownika root. Oto przykład: MAILTO=adres_email@przykład.com # na adres poczty elektronicznej będą wysyłane wszelkie błędy 00 00 * * * /usr/local/bin/rsnapshot daily # archiwizacja wykonywana codziennie o północy 00 22 * * 6 /usr/local/bin/rsnapshot weekly # archiwizacja wykonywana w każdą sobotę o 22 00 00 20 1 * * /usr/local/bin/rsnapshot monthly # archiwizacja wykonywana w pierwszy dzień miesiąca o 20 00
Jeśli zamierza się zarchiwizować dane z innych komputerów, należy zastosować narzędzie ssh (musi zostać zainstalowane po obu stronach połączenia) i klucze. Pod następującym adresem można znaleźć dobry opis bezpiecznej metody wykonania tej operacji: http://troy.jdmz.net/rsnapshot/ Pod poniższym adresem można przeglądać zawartość repozytorium CVS dotyczącą narzędzia rsnapshot. http://rsnapshot.cvs.sourceforge.net/rsnapshot/rsnapshot/
220
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
Społeczność użytkowników narzędzia rsnapshot To, czy oprogramowanie open source przetrwa, czy nie, zależy od poziomu wsparcia. Na szczęście narzędzie rsnapshot jest dobrze wspierane przez aktywną listę wysyłkową; użytkownicy są zachęcani do uczestniczenia w niej. Lista umożliwia zgłaszanie problemów, omawianie ich rozwiązań, ogłaszanie nowych wersji itp. Korzystając z poniższego adresu, można dołączyć do listy lub przeszukiwać jej archiwum. https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss Wiele osób zamieszcza na liście poprawki lub dodatki, z których część jest dołączana do repozytorium CVS przez niewielką grupę projektantów. Jeżeli dysponuje się dobrymi pomysłami i zamieści na liście odpowiednie poprawki, uzyskanie uprawnienia do rozszerzania repozytorium nie będzie trudne. Oczywiście każdy anonimowo może przeglądać repozytorium CVS i pobierać z niego dane. Narzędzie rsnapshot to stabilne oprogramowanie. Nie ma planów wprowadzenia większych zmian w sposobie jego funkcjonowania. Oto zmiany, których można się spodziewać w przyszłości: • Więcej dodatkowych skryptów obsługujących raportowanie. • Więcej skryptów obsługujących bazy danych. • Więcej opcji konfiguracyjnych. • Sporadyczne poprawki błędów.
Narzędzie rdiff-backup rdiff-backup jest programem napisanym w językach Python i C, który używa tego samego algorytmu sum kontrolnych co narzędzie rsync. Choć narzędzia rdiff-backup i rsync są podobne i stosują identyczny algorytm, nie dzielą żadnego kodu i muszą być instalowane oddzielnie. Podczas archiwizowania zarówno program rsnapshot, jak i rdiff-backup tworzą kopię lustrzaną źródłowego katalogu. W obu przypadkach bieżąca kopia zapasowa jest po prostu kopią źródłowego katalogu, gotową do skopiowania i sprawdzenia tak jak zwykły katalog. Oba narzędzia mogą być wykorzystywane za pośrednictwem programu ssh, działającego w trybie wysyłania lub pobierania. Najważniejsze różnice występujące między programami rsnapshot i rdiff-backup tkwią w sposobie przechowywania starszych kopii zapasowych i metadanych plików. Narzędzie rsnapshot po prostu przechowuje starsze kopie zapasowe w postaci kompletnych kopii źródłowych danych. Jak wcześniej w rozdziale wspomniano, dzięki umiejętnemu korzystaniu z dowiązań twardych kopie te są szybko tworzone i zwykle nie zajmują tyle przestrzeni dyskowej co kopie bez dowiązań. Jednak każda odmienna wersja każdego pliku zawartego w kopii zapasowej jest przechowywana jako oddzielna kopia pliku. Jeśli na przykład do pliku doda się jeden wiersz lub zmieni uprawnienia pliku, w całości zostanie dwukrotnie zapisany w kopii zapasowej. Może to być kłopotliwe zwłaszcza w przypadku plików dzienników, które dość często nieznacznie zwiększają swój rozmiar. Z kolei program rdiff-backup nie zapisuje w archiwum kompletnych kopii starszych plików. Zamiast tego przechowuje, tylko w skompresowanej postaci, różnice występujące między aktualną wersją plików a ich starszymi wersjami. Różnice te określa się anglojęzycznym terminem diff Narzędz e rd ff-backup
|
221
lub delta. W przypadku plików dzienników program rdiff-backup nie będzie utrzymywał oddzielnej kopii starszego i nieznacznie krótszego dziennika. Program zapisze w kopii zapasowej plik delta zawierający informację: „starsza wersja jest bieżącą wersją, lecz bez kilku ostatnich wierszy”. Pliki delta często są znacznie mniejsze niż cała kopia starszego pliku. Gdy plik całkowicie się zmieni, plik delta będzie miał mniej więcej taki sam rozmiar co starsza wersja. Jednak plik delta jest później kompresowany. Gdy archiwum narzędzia rdiff-backup zawiera wiele wersji pliku, program ten tworzy serię plików delta. W każdym znajdują się instrukcje dotyczące tworzenia starszej wersji na podstawie nowszej. Odtwarzając dane, program rdiff-backup rozpoczyna od aktualnej wersji i w odwrotnej kolejności stosuje pliki delta. Oprócz przechowywania starszych wersji w postaci plików delta zamiast kopii program rdiffbackup zapisuje w kopii zapasowej również skompresowane metadane wszystkich plików. Metadane są danymi powiązanymi z plikiem, które opisują jego faktyczne dane. Przykładem metadanych plików jest prawo własności, uprawnienia, czas modyfikacji i długość pliku. Metadane nie zajmują wiele miejsca, ponieważ zwykle są bardzo dobrze kompresowane. Nowsze wersje narzędzia idą jeszcze dalej i przechowują jedynie pliki delta metadanych, aby jeszcze efektywniej wykorzystać przestrzeń dyskową. Oddzielne przechowywanie metadanych kosztem określonej dodatkowej przestrzeni dyskowej daje kilka korzyści. Po pierwsze, unika się utraty danych nawet wtedy, gdy docelowy system plików nie obsługuje wszystkich funkcji źródłowego systemu plików. Przykładowo może zostać zachowane prawo właściciela nawet jeśli właściciel nie ma dostępu z prawami superużytkownika. Ponadto mogą być archiwizowane w systemie plików systemu Windows linuksowe systemy plików z dowiązaniami symbolicznymi, pliki urządzeń i listy kontroli dostępu ACL. Nie trzeba sprawdzać szczegółów dotyczących każdego systemu plików, aby wiedzieć, że proces archiwizacji zadziała. Po drugie, gdy metadane są oddzielnie przechowywane, narzędzie rdiff-backup ma mniejsze wymagania dotyczące przestrzeni dyskowej serwera archiwizującego. Podczas archiwizowania program rdiff-backup nie musi sprawdzać struktury katalogów kopii lustrzanej, żeby stwierdzić, które pliki się zmieniły. Po trzecie, metadane, takie jak sumy kontrolne SHA-1, mogą być używane do weryfikowania integralności kopii zapasowych.
Zalety Poniżej wymieniono kilka zalet wynikających z zastosowania programu rdiff-backup zamiast skryptu narzędzia rsync lub programu rsnapshot. Rozmiar kopii zapasowej Ponieważ narzędzie rdiff-backup nie zapisuje pełnych kopii starszych plików, lecz tylko w skompresowanej postaci różnice między starszymi i aktualnymi wersjami plików, zwykle kopie zapasowe zajmują mniej przestrzeni dyskowej. Łatwiejsza obsługa W przeciwieństwie do narzędzia rsync program rdiff-backup stworzono z myślą o kopiach zapasowych. Program ten ma rozsądne domyślne ustawienia (dzięki temu nie jest konieczne używanie takich opcji, jak -av, --delete, -r narzędzia ssh) i mniej dziwactw (przykładowo nie ma różnicy między łańcuchami: , / i /.).
222
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
Zachowanie wszystkich informacji W przypadku programu rsync wszystkie informacje są zapisywane w samym systemie plików. Jeśli w repozytorium kopii zapasowych Czytelnik zaloguje się jako użytkownik bez uprawnień superużytkownika (zwykle jest to dobry pomysł), narzędzie rsync nie będzie wiedziało, kto jest właścicielem wszystkich plików! Program rdiff-backup utrzymuje kopię wszystkich metadanych w oddzielnym pliku, dzięki czemu nie przepadną żadne informacje nawet wtedy, gdy nie ma się uprawnień superużytkownika lub kopię zapasową zapisze się w innego typu systemie plików. Przydatne funkcje archiwizacji Program rdiff-backup oferuje kilka różnych, przydatnych funkcji. Przykładowo narzędzie przechowuje szczegółowe dzienniki na temat tego, co się zmieniło, i dysponuje poleceniami, które je przetwarzają. Dzięki temu wiadomo, które pliki zajmują przestrzeń dyskową i powodują stratę czasu. Ponadto nowsze wersje narzędzia rdiff-backup przechowują sumy kontrolne SHA-1 wszystkich plików. W związku z tym można sprawdzić integralność kopii zapasowych. Niektóre skrypty programu rsync mają podobne funkcje. Należy zapoznać się z ich dokumentacją.
Wady Bądźmy szczerzy. Narzędzie rdiff-backup ma też wady: Szybkość Ponieważ program rdiff-backup bardziej obciąża procesor niż narzędzie rsync, jest wolniejszy od większości jego skryptów. Choć różnica w szybkości często jest niezauważalna, gdy wąskim gardłem jest sieć lub napęd dyskowy, może być znacząca w przypadku wykonywania lokalnych kopii zapasowych. Transparentność W przypadku skryptów narzędzia rsync wszystkie stare kopie zapasowe są dostępne jako kopie, dzięki czemu z łatwością można je weryfikować, odtwarzać i usuwać. Gdy stosuje się program rdiff-backup, jako rzeczywista kopia zapasowa jest widoczna tylko bieżąca kopia (starsze kopie są przechowywane w postaci skompresowanych plików delta). Wymagania Narzędzie rdiff-backup napisano w języku Python i wymaga ono biblioteki librsync. Jeśli nie używa się dystrybucji zawierającej to narzędzie (do większości z nich jest dołączone), instalacja może uwzględniać pobranie odpowiednich plików z sieci i ich zainstalowanie.
Szybki start Poniżej przedstawiono krótki, lecz kompletny przykład pokazujący, jak za pomocą narzędzia rdiff-backup archiwizować i odtwarzać katalogi. Załóżmy, że katalog przeznaczony do archiwizacji nosi nazwę i zależy nam na tym, aby katalog kopii zapasowej miał nazwę . $ rdiff-backup katalog_źródłowy katalog_docelowy
Polecenie archiwizuje katalog w katalogu . Po przyjrzeniu się zawartości katalogu okaże się, że w porównaniu z katalogiem różni się jedynie katalogiem /rdiff-backup-data, w którym znajdują Narzędz e rd ff-backup
|
223
się metadane i pliki delta. Katalog rdiff-backup-data jest uporządkowany w dość prosty sposób. Wszystkie informacje są zawarte w plikach tekstowych (być może skompresowanych za pomocą programu gzip) lub w plikach delta odczytywanych przez narzędzie rdiff. Z powodu ograniczonej objętości rozdziału nie będzie tu omawiany format danych. Gdy pierwszy raz wykona się powyższe polecenie, zostaną utworzone katalogi i /rdiff-backup-data. Przy następnych wywołaniach polecenie to stwierdzi istnienie katalogu i utworzy przyrostową kopię zapasową. Na potrzeby codziennej archiwizacji nie trzeba stosować żadnych specjalnych opcji. Przyjmijmy, że przypadkowo usunięto plik /foobar i zamierza się odtworzyć go z kopii zapasowej. Umożliwią to oba poniższe polecenia. $ cp -a katalog_docelowy/foobar katalog_źródłowy $ rdiff-backup -r now katalog_docelowy/foobar katalog_źródłowy
Pierwsze polecenie działa, ponieważ plik /foobar jest kopią lustrzaną pliku /foobar. W związku z tym do odtworzenia danych można zastosować polecenie cp lub dowolne inne narzędzie. Drugie polecenie zawiera opcję -r, która nakazuje narzędziu rdiff-backup uaktywnienie trybu odtwarzania i przywrócenie o ustalonej porze konkretnego pliku. W przykładzie użyto wartości now, co oznacza, że zostanie odtworzona najnowsza wersja pliku. Program rdiff-backup akceptuje wiele różnych formatów czasu. Załóżmy, że użytkownik zdał sobie sprawę, że tydzień wcześniej usunął ważny plik /foobar, i planuje go odtworzyć. W tym celu nie można użyć programu cp, ponieważ plik nie jest już obecny w katalogu w swojej oryginalnej postaci (w tym przypadku plik skompresowany za pomocą narzędzia gzip znajduje się w katalogu /rdiff-backup-data). Jednak polecenie z opcją -r jest skuteczne, z tym że trzeba za nią wstawić wartość 7D (siedem dni). $ rdiff-backup -r 7D katalog_docelowy/foobar katalog_źródłowy
Przyjmijmy wreszcie, że katalog staje się zbyt duży i w celu zaoszczędzenia przestrzeni dyskowej trzeba usunąć starsze kopie zapasowe. Poniższe polecenie usuwa zarchiwizowane dane mające więcej niż rok. $ rdiff-backup --remove-older-than 1Y katalog_docelowy
Podobnie jak program rsync narzędzie rdiff-backup pozwala na to, aby źródłowy lub docelowy katalog (bądź oba) znajdował się na zdalnym komputerze. Przykładowo, aby zarchiwizować lokalny katalog w katalogu komputera host.net, należy zastosować następujące polecenie: $ rdiff-backup katalog_źródłowy uż[email protected]::katalog_docelowy
Polecenie działa, dopóki narzędzie rdiff-backup jest zainstalowane na obu komputerach i host host.net może obsługiwać połączenia programu ssh. Wcześniejsze polecenia zadziałają również wtedy, gdy w miejsce wstawi się uż[email protected]::.
System Windows, system Mac OS X i przyszłość Choć narzędzie rdiff-backup zaprojektowano pod systemem Linux z myślą o systemach uniksowych, jego nowsze wersje mają funkcje, które przydadzą się użytkownikom systemów Windows i Mac OS X. Przykładowo program rdiff-backup może archiwizować w systemach plików systemu Windows systemy plików odróżniające wielkość znaków i pliki, których nazwy
224 |
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
zawierają znak :. Ponadto narzędzie rdiff-backup obsługuje rozwidlenia zasobów systemu Mac i informacje programu Finder. Narzędzie łatwo zainstalować w systemie Mac OS X, ponieważ dołączono je do dystrybucji Fink. Niestety, program rdiff-backup trochę trudniej uwzględnić w standardowej instalacji systemu Windows. Obecnie prawdopodobnie łatwiejsze będzie skorzystanie z oprogramowania cygwin. Przyszłe prace projektowe związane z narzędziem rdiff-backup mogą mieć przede wszystkim na celu zapewnienie, że nowsze funkcje, takie jak pełna zgodność z systemem Mac OS X, będą tak stabilne jak w przypadku innych systemów uniksowych. Ponadto będzie uwzględniana obsługa nowych funkcji systemów plików, które dopiero się pojawią. W celu uzyskania dodatkowych informacji na temat narzędzia rdiff-backup, w tym pełnej dokumentacji i odnośnika do listy wysyłkowej, należy zajrzeć na stronę internetową projektu oprogramowania rdiff-backup znajdującą się pod adresem http://rdiff-backup.nongnu.org. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Narzędz e rd ff-backup
|
225
226
|
Rozdz ał 7. Narzędz a open source służące do n emal c ągłej ochrony danych
CZĘŚĆ III
Komercyjne narzędzia archiwizujące
Część III składa się z dwóch rozdziałów: Rozdział 8. „Komercyjne narzędzia archiwizujące” W rozdziale opisano funkcje komercyjnych produktów. Dzięki temu Czytelnik może ocenić ich przydatność. Rozdział 9. „Urządzenia archiwizujące” W rozdziale objaśniono wiele różnego typu urządzeń archiwizujących, które są obecnie dostępne. Ponadto podano kryteria pomocne w wybraniu właściwego typu napędu archiwizującego.
ROZDZIAŁ 8.
Komercyjne narzędzia archiwizujące
Podstawowym celem książki jest pomóc osobom z mniejszymi środkami finansowymi przez pokazanie, w jaki sposób archiwizować systemy bez wydawania sporej ilości pieniędzy. Mając to na uwadze, opisałem podstawowe narzędzia archiwizujące dostępne dla systemów: Unix, Windows i Macintosh. Ponadto zostały przedstawione cztery różne narzędzia open source służące do archiwizowania i odtwarzania danych, które mogą spełnić wymagania wielu firm dotyczące ochrony danych. Osobom, których oczekiwania związane z archiwizowaniem i odtwarzaniem nie mogą być spełnione przez narzędzia open source, można zaoferować całą gamę komercyjnego oprogramowania archiwizującego. Trzeba pamiętać, że samo to, że coś jest komercyjnym produktem, nie sprawia, że jest lepsze od oprogramowania open source. Niektóre komercyjne produkty oferują mniej funkcji niż narzędzia open source zaprezentowane w książce. Jednak część komercyjnych aplikacji ma do zaoferowania znacznie więcej możliwości i może być zastosowana do rozwiązania problemów, z którymi nie radzą sobie narzędzia open source. Mam nadzieję, że objaśniając różne funkcje komercyjnych produktów archiwizujących, pomogę w podjęciu następujących decyzji: • Kiedy może być wskazane nabycie komercyjnego produktu archiwizującego? • Jaki komercyjny produkt będzie odpowiedni do wymagań?
Wybieranie komercyjnego produktu archiwizującego jest czasochłonne. Istnieje ponad 50 produktów z setkami funkcji, które zmieniają się każdego dnia. Złożoność zagadnienia i zróżnicowanie wymagań dotyczących ochrony danych sprawiają, że jeśli dwóch administratorów o takich samych umiejętnościach, pracujących w różnych firmach, przeprowadzi jednakowo zaawansowane poszukiwania produktu archiwizującego, ich wyniki będą odmienne z powodu różnic między konkretnymi wymaganiami firm. Produkt, który może nie być odpowiedni dla wszystkich firm, może okazać się idealny w przypadku jednej z nich tylko dlatego, że po prostu oferuje coś, co akurat jest przez nią wymagane, a czego nie ma inna aplikacja. Choć można wyróżnić kilka produktów, które są bliskie ideału, nie ma jednego spełniającego wszystkie oczekiwania. Oznacza to, że ani w niniejszym rozdziale, ani w całej książce nie zostanie wybrany produkt X. Powodów jest wiele, a jednym z nich jest zmienność. Rynek związany z ochroną danych zmienia się każdego dnia. Zmieniają się wymagania użytkowników dotyczące ochrony danych i to, co różne firmy robią, aby je na bieżąco spełniać. Do tego wszystkiego należy dodać wpływ konkurencji. Wiadomo o więcej niż jednym przypadku, gdy pojawiła
229
się nowa wersja mniej znanego produktu archiwizującego, która znacząco poprawiła jego sytuację na rynku. Ciągle zmieniający się kształt branży ochrony danych sprawia, że każda zamieszczona tu rekomendacja może być nieaktualna, gdy książka trafi do sprzedaży. W związku z tym w rozdziale omówiono tylko funkcje komercyjnych produktów archiwizujących1. W książce nie podjąłem próby przedstawienia podsumowania dostępnych produktów archiwizujących. Są ku temu dwa powody. Pierwszy jest taki, że zawarte tu informacje mogą być nieaktualne, gdy książka zostanie wydana. Drugi powód to obiektywizm. Skłamałbym, gdybym napisał, że równie dobrze poznałem wszystkie produkty. Z pewnością część produktów znam lepiej niż inne, dlatego uzyskałyby bardziej szczegółowy opis.
Czego szukać? Rozglądając się za produktem archiwizującym, należy sobie zadać wiele pytań. Oto one: • Czy produkt w pełni obsługuje używane platformy? • Czy produkt archiwizuje niesformatowane partycje? • Czy produkt sporządza kopie zapasowe bardzo dużych systemów plików i plików? • W jaki sposób produkt pomoże spełnić wyjątkowo rygorystyczne wymagania? • Czy produkt jednocześnie archiwizuje wielu klientów, korzystając z jednego napędu? • Czy produkt może automatycznie tworzyć dla jednego klienta wiele kopii zapasowych
naraz? • Czy produkt obsługuje dane wymagające specjalnego traktowania? • Czy produkt oferuje funkcje zarządzania magazynowanymi danymi? • Czy produkt redukuje obciążenie sieciowe? • Czy produkt obsługuje standardowy lub niestandardowy format archiwizacji? • Jak proste jest administrowanie produktem? • Jak bezpieczny jest produkt? • Jak łatwe w przypadku produktu jest odtwarzanie danych? • Jak dobrze produkt chroni katalog archiwizacji (baza danych lub indeks)? • Jak niezawodny jest produkt? • Jaki jest poziom zautomatyzowania produktu? • Czy produkt potrafi weryfikować utworzone przez siebie woluminy? • Jaka jest cena produktu? • Jaki dostawca sprzedaje produkt?
Kwestie te omówiono w dalszej części rozdziału.
1
Aby zilustrować tę uwagę, wystarczy, że wspomnę, iż kilka lat temu naprawdę spodobał mi się jeden produkt archiwizujący. Było to bardzo dobre oprogramowanie oferujące funkcje, których inne produkty w dalszym ciągu nie mają. Firma tworząca to oprogramowanie została przejęta i wtedy produkt przestał istnieć!
230
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Pełna obsługa używanych platform Jedną z najprostszych metod zawężenia listy producentów oprogramowania archiwizującego, spośród których zostanie wybrany jeden, jest stwierdzenie, czyje produkty obsługują używane platformy. Nie ma powodu, dla którego producent miałby odpowiadać na setki pytań, jeśli nie obsługuje większości platform wykorzystywanych przez zainteresowaną firmę. Idąc tym tropem, nie ma powodu, dla którego powinno się czytać setki odpowiedzi uzyskane od ponad 50 producentów. Zanim przejdzie się do konkretnych funkcji, po prostu należy stwierdzić, czyje produkty obsługują wszystkie lub większość platform wymagających archiwizacji. Kluczowe słowo w poprzednim akapicie to „większość”. Większość sklepów staje się coraz bardziej heterogeniczna: stosuje kilka odmian systemu Unix, systemy operacyjne, które przeznaczone są dla procesorów x86, i wiele różnych produktów bazodanowych. W takim sklepie zawsze znajdzie się kilka komputerów, z których część działa pod kontrolą mało popularnej wersji systemu Unix, jeden — starszej wersji systemu Windows, inny — innego systemu, a na jednym z nich dodatkowo jest zainstalowany mniej znany produkt bazodanowy nieobsługiwany przez większość komercyjnych narzędzi archiwizujących. Podczas pierwszej selekcji należy uwzględnić produkty archiwizujące większość używanych systemów operacyjnych. Ograniczając listę produktów tylko do współpracujących z każdą platformą, można wykluczyć bardzo dobre narzędzia lub wymusić wybór złego produktu. Wielu producentów może rozważyć przystosowanie swoich narzędzi do nowych systemów operacyjnych lub baz danych, jeśli potencjalny klient ich o to poprosi. Jednakże może to dodatkowo kosztować (w ostatniej fazie analizy okazuje się jednak, że produkt, który obsługiwał konkretną platformę od jakiegoś czasu, zwykle lepiej sobie radzi od oprogramowania dopiero co dostosowanego do takiej platformy). Istnieje wiele różnych systemów operacyjnych, każdy w wielu odmianach. Są to m.in.: Unix, Mac OS, Windows, NetWare i systemy przeznaczone dla serwerów przemysłowych. Większość dużych produktów współpracuje prawie z wszystkimi tymi systemami. Kiedyś było tak, że trzeba było kupić jeden produkt dla serwerów z systemem NetWare, jeden dla systemu Windows, jeden dla systemu Mac OS, jeden dla serwerów przemysłowych MVS i jeszcze jeden dla serwerów uniksowych. Obecnie część produktów obsługuje wszystkie te platformy z poziomu jednej konsoli. Jednak bardzo wielu producentów oprogramowania archiwizującego śpieszy się, aby obsługiwać wszystko, więc czasem coś zostaje pominięte. Można przytoczyć kilka przykładów. W przypadku systemu Unix zazwyczaj pomijane są specjalne pliki blokowe i znakowe, a także nazwane potoki. W przypadku systemu Windows sporadycznie jest również pomijany stan systemu i baza usługi Active Directory. Zapomina się też o rozwidleniach zasobów systemu Mac OS i usłudze katalogowej NDS firmy Novell. Trzeba się upewnić, że każdy produkt faktycznie w pełni obsługuje platformy wymienione w specyfikacji.
Czy powinno się archiwizować pliki specjalne? Jeśli produkt archiwizujący nie uwzględnia w kopii zapasowej rejestru systemu Windows, nie uzyska certyfikatu firmy Microsoft. Jednakże kilka znakomitych uniksowych pakietów archiwizujących nie umieszcza w kopii zapasowej plików specjalnych i nazwanych potoków (w systemach Unix i Linux występują specjalne typy plików). W razie utraty systemu operacyjnego typowa odpowiedź producenta brzmi: „Należy ponownie zainstalować system i nasze oprogramowanie, a następnie rozpocząć proces odtwarzania danych”. Operacja taka zajmuje zbyt wiele czasu i wiąże się z dwukrotnym wprowadzaniem mnóstwa informacji. Jeśli
Pełna obsługa używanych platform
|
231
oprogramowanie zarchiwizowało pliki specjalne, istnieje znacznie szybsza metoda przywrócenia systemu operacyjnego. Więcej informacji na ten temat można znaleźć w części IV książki. A co, gdy system udało się załadować, lecz zawartość katalogu /dev uszkodziła się? Dzięki możliwości odtworzenia plików urządzeń można zredukować liczbę godzin przestoju. Czy produkt archiwizujący naprawdę musi archiwizować tego typu pliki? Tak, musi!
Trzeba archiwizować dane — wszystkie! Komputer produkcyjny zawierał uszkodzony dysk. W efekcie utracono programy aplikacji, włącznie z bazą danych. Zwykła kopia zapasowa uwzględniała tylko dane, bez plików oprogramowania. Moi współpracownicy nie mogli znaleźć oryginalnego oprogramowania. Na szczęście w szufladzie miałem taśmą z kompletną kopią danych, którą utworzyłem jeszcze na etapie testów przed uruchomieniem komputera produkcyjnego. Korzystając z tej taśmy, mogliśmy odtworzyć oprogramowanie (ostatecznie oryginał aplikacji też został odnaleziony, skopiowany, poprawnie zapisany i skatalogowany). — Norm Eisenberg
Archiwizowanie niesformatowanych partycji W wielu środowiskach komercyjny produkt archiwizujący jest stosowany do sporządzania kopii zapasowych niesformatowanych partycji. Partycja jest sekcją dysku, która może zawierać system plików. Zwykle (choć nie zawsze) odwołując się do partycji niesformatowanej, ma się na myśli obszar dysku pozbawiony systemu plików. Taki dysk może przechowywać dane produktu bazodanowego (na przykład Oracle, Informix lub Sybase). Obszar niesformatowany może też znajdować się na początku podstawowej partycji dysku z systemem operacyjnym i przechowywać blok rozruchowy. Ponieważ większość produktów archiwizujących zaprojektowano z myślą o tworzeniu kopii zapasowych plików zlokalizowanych w obrębie systemu plików, mogą nie być w stanie archiwizować niesformatowanej partycji. Możliwość archiwizowania niesformatowanych partycji może być pomocna, gdy sporządza się kopie zapasowe stosunkowo niewielkich baz danych zlokalizowanych na tego typu partycjach. W celu zarchiwizowania większości baz danych za pomocą produktu obsługującego niesformatowane partycje wystarczy wyłączyć bazę i poinformować oprogramowanie archiwizujące, dla jakich niesformatowanych partycji ma utworzyć kopie zapasowe. Innym powodem, aby rozważyć archiwizowanie partycji niesformatowanej, jest tworzenie kopii zapasowych głównej partycji z systemem operacyjnym. Wiąże się z tym następna metoda odtwarzania podstawowego dysku bez konieczności ponownej instalacji systemu operacyjnego. Można wyróżnić dwa zasadnicze elementy dysku z systemem. Pierwszym jest sam system operacyjny znajdujący się w obrębie jednego lub większej liczby systemów plików dysku. Drugim elementem jest blok rozruchowy (w przypadku systemów uniksowych) lub główny rekord rozruchowy MBR (Master Boot Record; dotyczy komputerów z procesorami x86). Blok lub rekord informuje oprogramowanie sprzętowe komputera, gdzie ma szukać jądra systemu operacyjnego. Ten blok danych standardowo może znajdować się w pierwszym segmencie lub na podstawowej partycji dysku z systemem operacyjnym. W nowoczesnych komputerach z systemem Linux blok jest zlokalizowany na specjalnej partycji /boot. Blok znajduje się poza obrębem „normalnego” systemu plików i w związku z tym nie jest uwzględniany przez 232
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
standardowe procedury archiwizacyjne. Jeśli produkt archiwizujący potrafi utworzyć kopię zapasową niesformatowanej partycji, na której się znajduje, możliwe będzie odtworzenie jej bez ponownej instalacji systemu operacyjnego (bardziej szczegółowo zostało to omówione w części IV książki). Obecnie wiele popularnych pakietów archiwizujących obsługuje niesformatowane partycje. Jednak archiwizowanie takich partycji ma jedną wadę: niesformatowana partycja jest postrzegana jako jeden duży plik. Oznacza to, że każdorazowo, gdy archiwizuje się taką partycję, jest uwzględniana cała jej zawartość. W przypadku głównej partycji systemu operacyjnego o pojemności 100 MB nie stanowi to problemu. Jeśli ma się do czynienia z wieloterabajtowym niesformatowanym urządzeniem, taka kopia bardzo szybko może zapełnić nośnik archiwizacyjny o dużej pojemności. Niektóre produkty mogą w „inteligentny” sposób odczytać niesformatowaną partycję i sporządzić przyrostową kopię zapasową jej zawartości. Choć w czasie, gdy ta książka powstawała, była to rzadko stosowana opcja, warta jest przeanalizowania.
Archiwizowanie bardzo dużych systemów plików i plików Duże systemy plików i pliki były zaskoczeniem dla wielu produktów archiwizujących. Przez wiele lat dominowały systemy plików o rozmiarze 4 GB z plikami o maksymalnej wielkości wynoszącej 2 GB. Powodem było to, że żaden system operacyjny nie pozwalał na większe rozmiary. Wtedy pojawiły się 32- i 64-bitowe systemy, a także terabajtowy system plików. Wkrótce potem niektórzy producenci ogłosili możliwość tworzenia plików liczących wiele terabajtów. Był to poważny problem dla części wytwórców oprogramowania archiwizującego, ponieważ wiele decyzji projektowych podejmowano przy założeniu maksymalnego rozmiaru równego 4 GB. Jeśli jakiś produkt w dalszym ciągu boryka się z takim problemem, jest to niewybaczalne.
Zastanawiając się, czy określony produkt może obsługiwać duże pliki i systemy plików, pod uwagę należy wziąć kilka rzeczy. Czy producent stosuje jakiekolwiek sztywne ograniczenia, które powodują, że plik nie może mieć rozmiaru większego niż N bajtów? Czy produkt napotyka na problemy, gdy system plików lub plik ma wielkość przekraczającą pojemność woluminu? Czy producent oferuje jakąś zautomatyzowaną metodę jednoczesnego tworzenia wielu kopii zapasowych pojedynczego systemu plików bez konieczności ręcznego dzielenia przez operatora systemu plików na wiele części?
Rygorystyczne wymagania Jak wspomniano w ramce „Zmiana produktu archiwizującego na inny”, jest tylko jeden powód, dla którego powinno się brać pod uwagę zmianę produktu archiwizującego. Są to wymagania, które nie mogą być przez niego spełnione. Do wymagań tych należy zaliczyć oczekiwany czas odtwarzania, punkt odtwarzania, spójność i grupy okien archiwizacji.
Rygorystyczne wymagan a
|
233
Zmiana produktu archiwizującego na inny Nigdy nie powinno się zmieniać używanego produktu archiwizującego tylko dlatego, że sprawia problemy. Po pierwsze, problemy z dowolnym systemem archiwizacji prawie zawsze wynikają z niepoprawnej konfiguracji, złego zrozumienia czegoś, braku zdefiniowanego procesu lub nieodpowiedniej ilości sprzętu (zbyt małej lub zbyt dużej). Niemal nigdy przyczyną nie jest sam produkt. Po drugie, zmiana produktu archiwizującego na inny ma wpływ na trzy ważne czynniki związane z funkcjonowaniem firmy: koszt, ryzyko i poziom usług. Pojawia się koszt wynikający z nabycia produktu, związany z odtwarzaniem zarchiwizowanych danych, nauką obsługi nowego oprogramowania i wdrażaniem usług. Występuje ryzyko związane z utratą danych na etapie zapoznawania się z nowym produktem. Po trzecie, podczas prób stwierdzenia, jak funkcjonuje nowe oprogramowanie, będzie zauważalny spadek poziomu usług. A zatem w przypadku problemów z systemem archiwizacji produkt zmienia się tylko w ostateczności. Zanim się to zrobi, należy wynająć specjalistę od używanego produktu archiwizującego, aby mieć pewność, że działa optymalnie i korzysta się z wszelkich przydatnych dodatkowych funkcji, które mogą być pomocne w rozwiązaniu problemu. Prawdopodobnie specjalista poradzi sobie z problemem. Koszt jego pracy będzie stanowił ułamek ceny nowego produktu archiwizującego. Ponadto zwiększy się poziom wiedzy na temat obecnie stosowanego oprogramowania. A zatem istnieje tylko jeden powód, dla którego powinno się rozważyć wymianę produktu archiwizującego. Powodem tym są wymagania, które nie mogą być spełnione przez używany produkt.
Czas odtwarzania określa, jak szybko system ma zostać odtworzony. Czas ten może zawierać się w przedziale od zera sekund do wielu dni, a nawet tygodni. Ponieważ każda porcja informacji pełni funkcję biznesową, pytanie brzmi: jak długo można się obejść bez konkretnej funkcji?. Jeśli funkcja nie może być niedostępna nawet przez sekundę, czas odtwarzania wyniesie zero sekund. Jeżeli bez funkcji można sobie poradzić przez dwa tygodnie, czas odtwarzania będzie równy dwóm tygodniom. Punkt odtwarzania określa ilość danych, które mogą zostać utracone. Jeśli może przepaść zestaw danych z okresu trzech dni, tolerancja odtwarzania wynosi trzy dni. Jeżeli jednak ma się do czynienia z zamówieniami klientów składanymi w czasie rzeczywistym, być może nie można pozwolić sobie na utratę żadnych danych. Wtedy punkt odtwarzania będzie zerowy. Punkt odtwarzania może być też określony dla grupy komputerów. Jeśli zarządza się kilkoma powiązanymi ze sobą komputerami, może być niezbędne odtworzenie ich do stanu z tej samej chwili. Grupa taka jest nazywana grupą spójności. Aby spełnić taki wymóg, trzeba zarchiwizować wszystkie powiązane komputery dokładnie w tym samym czasie lub ustalić dla każdego z komputerów punkt odtwarzania o bardzo małej wartości. Określenie punktu odtwarzania dla grupy komputerów po prostu powoduje, że punkt dla każdego systemu należącego do grupy będzie równy punktowi o najmniejszej wartości powiązanemu z dowolnym komputerem grupy. Po ustaleniu czasu i punktu odtwarzania dla każdego komputera i typu awarii trzeba określić, kiedy można archiwizować system i przez jaki czas, a także w jakim stopniu podczas archiwizowania można wpłynąć na system produkcyjny. Parametry te razem są określane mianem okna archiwizacji.
234 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Po określeniu wymagań można dojść do wniosku, że są zbyt rygorystyczne. Za rygorystyczny uznaje się wymóg, który nie może zostać spełniony przez tradycyjną metodę odtwarzania bazującą na sieci lokalnej. Zwykle oznacza to, że przepustowość jest za mała, ilość danych do przesłania zbyt duża lub ilość przyznanego czasu nieodpowiednia. Zazwyczaj ma to miejsce w następujących trzech sytuacjach: Archiwizowanie danych zdalnego oddziału firmy Od dawna zdalne oddziały firmy stanowią spory problem podczas wielu sesji planowania ochrony danych. Zwykle takie oddziały są obsługiwane przez zdalne napędy taśmowe lub biblioteki taśm, które są zarządzane przez nieodpowiedni personel lub w ogóle nie są zarządzane. Ostatnio miałem do czynienia z firmą petrochemiczną, której zdalne oddziały były wyposażone w urządzenia wiertnicze umieszczone poza lądem. Można sobie wyobrazić ubaw, jaki mają pracownicy tych placówek, gdy proszą przedstawicieli firmy magazynującej dane, aby się u nich pojawili! Jednak coraz więcej osób chce poradzić sobie z powyższym problemem przez archiwizowanie danych zdalnych oddziałów za pośrednictwem sieci. W jaki sposób zarchiwizować zasoby zdalnego oddziału liczące setki gigabajtów i zlokalizowane z drugiej strony połączenia sieci rozległej? Typowy system archiwizowania i odtwarzania nie byłby w stanie spełnić żadnych oczekiwań, jeśli chodzi o rozsądne: czas odtwarzania, punkt przywracania lub okno archiwizacji. Bardzo duże aplikacje Niedawno widziałem bazę danych Oracle o pojemności 150 TB. Niech Czytelnik spróbuje zarchiwizować coś takiego! Choć może nie dysponować aplikacją z taką ilością danych, bardzo możliwe, że posiada oprogramowanie, które jest zbyt duże, aby można je było zarchiwizować i odtworzyć w akceptowalnym czasie. W czasie, gdy ta książka powstawała, z takim rozmiarem można było się spotkać raczej w przypadku pojedynczych serwerów. Wszystko o pojemności kilku terabajtów lub mniejszej może być zarchiwizowane i odtworzone w ciągu kilku godzin, co mieści się w przedziale większości czasów i punktów odtwarzania. Co jednak zrobić, gdy będzie się miało do czynienia z aplikacją o rozmiarze 10 TB i czasem odtwarzania wynoszącym godzinę? Bardzo ważne aplikacje Niektóre aplikacje są tak ważne dla firmy, że jej właściciele po prostu nie mogą zaakceptować jakiegokolwiek przestoju lub utraty danych. Jak spełnić wymóg jednominutowego czasu odtwarzania lub zerowego punktu odtwarzania, niezależnie od wielkości aplikacji? Aplikacje zaliczające się do tej kategorii są najtrudniejsze do zaprojektowania i wymagają bardzo zaawansowanych systemów ochrony danych. Przedstawione poniżej rozwiązania mogą być pomocne w spełnieniu rygorystycznych wymagań. Wymieniono je według możliwości spełniania takich wymagań. Im niżej na liście rozwiązanie zamieszczono, tym bardziej rygorystyczne wymagania może spełnić.
Archiwizowanie bez udziału sieci lokalnej Pierwsze zaawansowane rozwiązanie związane z archiwizowaniem i odtwarzaniem danych polega na przesyłaniu kopii zapasowych w obrębie sieci SAN (Storage Area Network) zamiast sieci lokalnej (stąd stwierdzenie „bez udziału sieci lokalnej”). Ponieważ w taki sposób kopie zapasowe są tworzone szybciej niż w przypadku archiwizacji bazującej na sieci lokalnej,
Rygorystyczne wymagan a
|
235
rozwiązanie to może być pomocne w uzyskaniu bardziej rygorystycznych czasów i punktów odtwarzania. Jeśli zarządza się dużym serwerem mającym problemy z uzyskaniem żądanego czasu lub punktu odtwarzania, pod uwagę można wziąć przypisanie serwerowi roli klienta procesu archiwizacji bez udziału sieci lokalnej.
Należy testować odtwarzanie kopii zapasowych W dużej firmie ubezpieczeniowej postanowiono zarchiwizować sieciowe urządzenie Filer Head przez sporządzenie kopii zapasowej udziałów zamiast wykorzystania nabytego klucza protokołu NDMP (Network Data Management Protocol) i dedykowanego napędu taśmowego. Zastosowaliśmy narzędzie wchodzące w skład zestawu zasobów dla systemu Windows, żeby podczas jego ładowania podłączyć udział. Z nieznanej przyczyny udział nie został podłączony. Ponieważ w pliku konfiguracyjnym podłączanych udziałów ustawiliśmy parametr soft, nie pojawiła się żadna uwaga lub komunikat o błędzie. Ze względu na to, że udział nie został podłączony, podczas tworzenia kopii zapasowych nie było żadnej informacji. Jeśli właściciel udziału zalogował się w systemie, udział był wtedy podłączany, a następnie odłączany w czasie wylogowywania. Tak było przez kilka miesięcy, zanim właściciel udziału uszkodził dane i poprosił o odtworzenie ich z kopii zapasowej utworzonej poprzedniej nocy. Właśnie wtedy stwierdziliśmy, że od trzech miesięcy nie było żadnej kopii zapasowej, a udział użytkownika przepadł. — Harry Tirrell
Tego typu archiwizacja wymaga, aby urządzenie archiwizujące było podłączone za pośrednictwem sieci SAN z technologią Fibre Channel lub iSCSI. W przypadku pierwszej technologii sieć SAN byłaby wyposażona w kontrolery HBA (Host Bus Adapter) i przełącznik. Z kolei sieć SAN oparta na technologii iSCSI używałaby zwykłych kontrolerów HBA ze sterownikami iSCSI (lub być może kontrolerów iSCSI HBA) i mogłaby przesyłać swoje dane w dowolnej sieci IP (jednak dobrym pomysłem jest oddzielenie tych danych od zwykłych danych sieci IP). Jak widać na rysunku 8.1, serwery archiwizacji podłączone do sieci SAN mają wirtualny fizyczny dostęp do wszystkich urządzeń peryferyjnych. Po podłączeniu urządzeń i skonfigurowaniu sieci SAN cały ruch sieciowy SCSI/Fibre Channel/iSCSI będzie przesyłany w sieci SAN. Każdy serwer będzie „myślał”, że magazyn danych będzie do niego lokalnie podłączony. Dzięki temu serwer może wykorzystać najnowsze dokonania w dziedzinie technologii archiwizujących, które umożliwiają przesyłanie kopii zapasowych w sieci SAN. Takie rozwiązanie jest znacznie szybsze (i mniej obciążające procesor) niż archiwizacja bazująca na sieci lokalnej. Gdy ludzie po raz pierwszy widzą schemat sieci SAN, nie zauważają dużej różnicy między nią i siecią lokalną LAN. Co więcej, każdego dnia granica między tymi dwoma sieciami coraz bardziej się rozmywa. W przeszłości sieć SAN wykorzystywała technologię Fibre Channel, a LAN — Ethernet i IP. Obecnie sieć SAN wyposażona w technologię iSCSI może używać protokołu IP jako mechanizmu transportowego. Wystarczy pamiętać, że sieć SAN jest zgodna z technologią SCSI, która może funkcjonować ponad technologią Fibre Channel lub IP. Jednak w dalszym ciągu ma się do czynienia z technologią SCSI.
236
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Rysunek 8.1. Podstawowa sieć SAN
Komercyjne aplikacje archiwizujące mogą dynamicznie określać, jakie serwery będą miały dostęp do poszczególnych urządzeń peryferyjnych. Przykładowo, gdy nadejdzie pora sporządzenia pełnej kopii zapasowej dla konkretnego serwera, aplikacja archiwizująca może skonfigurować router w taki sposób, że uzyska dostęp do każdego dostępnego napędu archiwizacyjnego. Oczywiście operacja taka może być też przeprowadzona w przypadku bardzo ważnego procesu odtwarzania.
Archiwizowanie bez udziału serwera W porównaniu z archiwizowaniem bazującym na sieci lokalnej wariant bez jej udziału pozwala utworzyć kopie zapasowe znacznie szybciej i przy mniejszym obciążeniu procesora. Jednak w dalszym ciągu procesor wykorzystywany jest dość znacznie. Jeśli dysponuje się bardzo dużym serwerem, nawet obniżone obciążenie procesora może przekraczać możliwości komputera, co może mieć zbyt duży wpływ na aplikacje lub wymagać zwiększenia mocy procesora. Co by było, gdyby można było zarchiwizować aplikację bez faktycznego przesyłania danych za pośrednictwem serwera używającego bazy danych? Jeśli Czytelnik jest w stanie zaakceptować rozwiązanie archiwizacyjne bardzo odmiennego typu, będzie to możliwe. Należy przyjrzeć się rysunkowi 8.2. Na samej górze rysunku widać dwa serwery bazodanowe połączone z macierzą dyskową obsługującą wiele hostów. Do macierzy jest też podłączony serwer archiwizujący. Bazy danych znajdują się na lustrzanych partycjach dużej macierzy dyskowej. W celu przeprowadzenia archiwizacji bez udziału serwera serwer archiwizujący informuje serwer bazodanowy, że musi utworzyć kopię zapasową bazy danych. Serwer bazodanowy oddziela jedną z lustrzanych partycji lub tworzy wirtualny obraz swoich woluminów, a następnie informuje serwer archiwizujący, że może rozpocząć archiwizowanie danych. Serwer archiwizujący tworzy kopię zapasową
Rygorystyczne wymagan a
|
237
Rysunek 8.2. Archiwizowanie bez udziału serwera
danych, korzystając ze ścieżki, która nie uwzględnia oryginalnego serwera bazodanowego (stąd określenie bez udziału serwera2). Oczywiście serwer archiwizujący w dalszym ciągu jest zaangażowany. Jedynie oryginalny serwer nie musi już przesyłać danych. Cała aplikacja może następnie zostać zarchiwizowana bez transferowania danych za pośrednictwem klienta, który z nich korzysta. Dane mogą podążać jedną z dwóch ścieżek: • Dane mogą zostać zarchiwizowane za pośrednictwem innego dedykowanego serwera
mającego dostęp do oddzielonej lustrzanej partycji lub obrazu. • Dane mogą być archiwizowane przy wykorzystaniu routera SAN akceptującego polecenie
X-COPY technologii SCSI. Dane są przenoszone bezpośrednio z urządzenia dyskowego na taśmę bez pośrednictwa żadnego serwera.
Jeśli archiwizowane dane znajdują się na oddzielonej lustrzanej partycji (a nie na wirtualnym obrazie), pojawia się kolejna możliwość niedostępna w przypadku tradycyjnych metod archiwizacji. Ta druga lustrzana partycja może pozostać odłączona do momentu, gdy trzeba będzie ponownie sporządzić kopię zapasową. Przed wykonaniem takiej operacji ta partycja może zostać szybko ponownie zsynchronizowana z drugą lustrzaną partycją. Dzięki pozostawieniu partycji w stanie odłączenia można natychmiast dysponować kopią zapasową całej bazy danych. Jeżeli coś stanie się z produkcyjną bazą danych, można będzie wykonać kilka poleceń i korzystając z lustrzanej partycji, ponownie uaktywnić bazę. W takiej sytuacji trzeba by jedynie odtworzyć dzienniki transakcji utworzone od czasu oddzielenia lustrzanej partycji. Bez takiej partycji w stanie oczekiwania konieczne przed odtworzeniem dzienników byłoby przywrócenie bazy danych. Takie rozwiązanie może być zastosowane w celu spełnienia rygorystycznych wymagań dotyczących czasów i punktów odtwarzania.
2
W swojej książce Using SANs and NAS próbowałem zdefiniować termin „archiwizacja bez udziału klienta” dla archiwizacji, która zamiast klienta wykorzystywała inny serwer. Jednak określenie to nigdy się nie przyjęło. Zrezygnowałem z niego. Termin „bez udziału serwera” (ang. serverless) jest standardem w branży.
238
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Rozwiązanie to ma kilka wad; przede wszystkim jest wyjątkowo złożone. Jeśli wszystko idzie dobrze, nie ma problemu. Jeżeli nie, serwer archiwizujący, serwer nośników, klient, macierz dyskowa i router SAN wygenerują dzienniki. Może upłynąć naprawdę wiele czasu, zanim stwierdzi się, dlaczego coś nie działa. Następna wada jest taka, że większość produktów archiwizujących bez udziału serwera nie oferuje tego typu operacji odtwarzania. Rozważając użycie tej metody archiwizacji, należy upewnić się, czy możliwe jest odtwarzanie bez udziału serwera. Ponadto rozwiązanie to jest bardzo kosztowne. W książce Unix Backup & Recovery bardziej obszernie omówiono archiwizowanie bez udziału serwera. Od czasu jej napisania zmieniło się wiele, począwszy od trzech technologii, które przedstawiono poniżej. Obecnie wiele osób uważa te metody za bardziej odpowiednie, żeby spełnić bardzo rygorystyczne wymagania dotyczące czasów i punktów odtwarzania.
Deduplikacyjne systemy archiwizacji Projektanci deduplikacyjnych systemów archiwizacji zadali sobie kilka pytań. Jeśli w pliku zmieniło się tylko kilka bajtów, dlaczego archiwizować cały plik? Jeżeli ten sam plik znajduje się w dwóch miejscach jednego systemu, dlaczego archiwizuje się go dwa razy? Dlaczego po prostu nie zapisuje się odwołania do drugiego pliku? Niektórzy nawet zastanawiali się, dlaczego archiwizuje się ten sam plik zlokalizowany na wielu komputerach. Czyż nie jest to strata zasobów serwerowych i sieciowych? Oczywiście odpowiedzi na te wszystkie pytania są zależne od ograniczeń tradycyjnych systemów archiwizacyjnych. Im rzadziej plik będzie archiwizowany, tym więcej taśm będzie trzeba sprawdzić, aby go odtworzyć. Jeżeli zarchiwizuje się tylko zmienione bajty pliku, w celu odtworzenia tylko jednego pliku może być wymaganych wiele taśm. Jeśli jednak zarchiwizuje się konkretny plik tylko raz, a następnie zmienione bajty wyłącznie wtedy, gdy plik zostanie zmodyfikowany, w rzeczywistości możliwe stanie się spełnienie większych wymagań dotyczących okna archiwizacji. Gdy dane zarchiwizuje się na dysku, problemy związane z taśmami stają się mniej istotne. Kopie kopii zapasowych zapisanych na dysku mogą zostać umieszczone na taśmie w dowolnej chwili, zależnie od wymagań klienta. Część produktów deduplikujących może też spełniać rygorystyczne wymagania dotyczące czasu odtwarzania przez odtwarzanie tylko tych bloków, które zmieniły się od czasu ostatniej archiwizacji pliku. Możliwości tych produktów związane z punktem odtwarzania zależą od częstotliwości archiwizowania danych. Często używa się ich do sporządzania kopii zapasowych co godzinę. Dzięki temu możliwe jest zapewnienie godzinnego punktu odtwarzania. To samo dotyczy wymagań związanych ze spójnością grupy. Deduplikacyjne systemy archiwizacji korzystają z rozwiązań podobnych do używanych przez docelowe magazyny dyskowe z funkcją deduplikacji, które omówiono w rozdziale 9. Magazyny te dokonują deduplikacji lokalnie, natomiast kompletny deduplikacyjny system archiwizacji eliminuje nadmiarowość na poziomie klienta, zmniejszając ilość danych, które muszą zostać przesłane ze zdalnego oddziału lub laptopa.
Największą zaletą produktów deduplikacyjnych z punktu widzenia użytkowników jest to, że są najbliższe temu, co jest im już znane. Interfejsy tych produktów są podobne do siebie. Często produkty te dysponują agentami bazodanowymi przypominającymi te z tradycyjnych Rygorystyczne wymagan a
|
239
aplikacji archiwizujących. Produkty deduplikacyjne mogą po prostu szybciej i częściej przeprowadzać archiwizację, a ponadto zużywają znacznie mniej dostępnej przepustowości.
Obrazy Kolejna alternatywna metoda archiwizacji to utworzenie obrazu. Najczęstszym typem obrazu jest wirtualna kopia urządzenia lub systemu plików. Prezentując użytkownikowi faktyczne dane, obraz bazuje na oryginalnym woluminie3. Taka zależność obrazu od oryginalnego woluminu jest powodem, dla którego trzeba archiwizować obrazy, aby zapewnić możliwość odtworzenia danych po wystąpieniu fizycznych awarii. Funkcję tworzenia obrazów można znaleźć w kilku miejscach, w tym w zaawansowanych systemach plików i menedżerach woluminów, macierzach magazynujących dla przedsiębiorstw, magazynach opartych na technologii NAS i oprogramowaniu archiwizującym. Obrazy mogą być pomocne w spełnieniu rygorystycznych wymagań związanych z archiwizowaniem. Przykładowo po zwykłej zmianie wskaźnika część obrazów może zapewniać czas odtwarzania wynoszący kilka sekund. W ciągu dnia można też utworzyć kilka obrazów, umożliwiając spełnienie rygorystycznego wymogu dotyczącego punktu odtwarzania. Ponieważ obrazy można utworzyć w kilka sekund, możliwe jest również spełnienie wysokich wymagań związanych z oknem archiwizacji. W ciągu kilku sekund można wygenerować stabilną wirtualną kopię zapasową bazy danych liczącej wiele terabajtów, redukując w ten sposób wpływ operacji na aplikację prawdopodobnie do zera. Później przez wiele godzin można sporządzać kopię zapasową takiego obrazu. W następnym punkcie wyjaśniono, jak znakomitym rozwiązaniem jest umożliwiająca to replikacja. Dość proste jest także tworzenie zsynchronizowanych obrazów na wielu komputerach. Oznacza to, że można też spełnić rygorystyczne wymagania dotyczące synchronizacji. W świecie obrazów interesujące jest projektowanie interfejsów API umożliwiających innym producentom obsługę obrazów. Protokół NDMP i usługa VSS Microsoftu są tego przykładami. Protokół NDMP pozwala producentom oprogramowania archiwizującego na zaplanowanie utworzenia obrazu, a także katalogowanie i odtwarzanie jego zawartości. Operacje odtwarzania są wykonywane przy użyciu tego samego interfejsu, który zastosowano by w przypadku „normalnej” archiwizacji. Jednakże proces odtwarzania jest realizowany przez magazyn danych wykorzystujący technologię obrazów. Usługa VSS umożliwia producentom oprogramowania archiwizującego z funkcją tworzenia obrazów generowanie listy zawartych w nich plików i odtwarzanie ich z poziomu karty Poprzednie wersje systemu Windows Server 2003 i nowszych. Można mieć nadzieję, że taka funkcjonalność zostanie dodana do wersji systemu Windows dla stacji roboczych, jak również będzie obsługiwana przez większą liczbę dostawców technologii NAS. Inną interesującą rzeczą związaną z projektowaniem oprogramowania z funkcją wykonywania obrazów jest tworzenie agentów bazodanowych współpracujących z obrazami. Ponieważ taki agent komunikuje się z bazą danych, baza jest „przekonana”, że jest archiwizowana, podczas gdy tak naprawdę tworzony jest obraz. Operacje przywracania czasami są zintegrowane, dzięki czemu możliwe jest wyjątkowo szybkie odtwarzanie danych kontrolowane przez aplikację bazodanową. 3
Niektórzy producenci obrazami nazywają oddzielone lustrzane partycje. Wolę posługiwać się terminem obrazu w przypadku wirtualnych kopii. Oddzieloną lustrzaną partycję nazwałbym woluminem zapewniającym ciągłość procesów biznesowych.
240 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Replikacja Replikacja polega na ciągłym kopiowaniu ze źródłowego do docelowego systemu wszystkich plików lub bloków, które zostały zmodyfikowane. Replikacja była tym, co firmy stosowały, gdy wszystko zostało całkowicie zarchiwizowane i stało się nadmiarowe. Oznacza to, że z replikacji korzystało bardzo niewiele osób. Jednak obecnie wiele osób używa replikacji jako pierwszego sposobu odtworzenia danych po wystąpieniu nieszczęśliwego zdarzenia. Replikacja sama w sobie jest dobrym rozwiązaniem archiwizacyjnym. Kopiuje wszystko, włącznie z tym, co niepożądane, na przykład wirusy i już usunięte pliki. A zatem system archiwizujący oparty na replikacji musi zapewniać dane historyczne przez sporadyczne tworzenie kopii zapasowej zreplikowanych danych docelowych lub zastosowanie obrazów. Zwykle preferowane jest wygenerowanie obrazu danych źródłowych i zreplikowanie go na systemie docelowym. Tym sposobem aplikacje bazodanowe można przygotować do archiwizacji, wykonać obraz, a następnie go zreplikować.
Systemy niemal ciągłej ochrony danych Gdy replikację połączy się z obrazami, uzyska się system niemal ciągłej ochrony danych. Ponieważ obrazy można tworzyć co godzinę (a nawet częściej w przypadku niektórych systemów), a replikacja trwa nieustannie, obrazy i replikacja są bliższe ciągłej ochronie danych niż tradycyjna archiwizacja. Z tego powodu powstało określenie „niemal ciągła ochrona danych”. Część produktów niemal ciągłej ochrony danych najpierw przeprowadza replikację, a następnie tworzy obrazy w docelowym systemie. Inne tego typu produkty generują obrazy w źródłowym systemie, po czym replikują je na docelowym systemie. Zaletą systemów niemal ciągłej ochrony danych jest to, że tworzenie obrazów zajmuje zaledwie kilka sekund; z kolei replikacja jest bardzo prostą metodą przenoszenia danych na inne urządzenie. Można też przeprowadzać kaskadową replikację, aby bez używania taśmy zapewnić wiele kopii (na przykład przechowywanych lokalnie i zdalnie). Aby następnie uzyskać na taśmie kopię zreplikowanego obrazu, wystarczy zarchiwizować jedno z docelowych urządzeń. W porównaniu z prawdziwymi produktami ciągłej ochrony danych największą wadą systemów niemal ciągłej ochrony danych jest to, że gdy spowoduje się logiczne uszkodzenie źródłowego systemu (na przykład usunięcie lub uszkodzenie pliku), zostanie to natychmiast uwzględnione w aktualnej kopii zapasowej i trzeba będzie odtwarzać plik przy użyciu najbardziej aktualnego obrazu. Prawdziwy produkt ciągłej ochrony danych byłby w stanie odtworzyć plik do momentu tuż przed jego uszkodzeniem. Inną wadą systemów niemal ciągłej ochrony danych jest to, że często wymagają zmiany używanego podstawowego systemu magazynowania na taki, który będzie z nimi zgodny. Wynika to stąd, że zwykle takie systemy bazują na macierzach dyskowych.
Systemy ciągłej ochrony danych Prawdziwy system ciągłej ochrony danych zasadniczo jest asynchronicznym systemem archiwizującym opartym na replikacji, który nie nadpisuje docelowego urządzenia najbardziej aktualnymi danymi. Taki system jest aktywny cały czas. Każdorazowo, gdy plik zostaje zmodyfikowany, w ciągu sekund lub minut jego nowe bajty są przesyłane do serwera archiwizującego. Jednak
Rygorystyczne wymagan a
|
241
w przeciwieństwie do replikacji system ciągłej ochrony danych zmiany zapisuje w dzienniku, zamiast nadpisywać docelowy system najnowszymi blokami. Dzięki temu w dowolnej chwili można cofnąć wszelkie zmiany. Różne produkty ciągłej ochrony danych na różne sposoby transferują dane do serwera archiwizacji. Część z nich natychmiast przesyła zmienione bloki, natomiast część gromadzi je i wysyła co kilka minut. Produkty te różnią się też, jeśli chodzi o odtwarzanie danych. Niektóre produkty szybko przywracają wyłącznie bloki zmienione od chwili, do której odtwarza się dane. Inne produkty odtwarzają dane w bardziej tradycyjny sposób, przywracając cały plik lub system plików. Oczywiście, pierwsza metoda odtwarzania pozwala spełnić bardziej rygorystyczne wymagania dotyczące czasów i punktów odtwarzania niż druga. System ciągłej ochrony danych ma niezauważalne okno archiwizacji, ponieważ kopiuje wyłącznie te bajty, które zmieniają się w ciągu dnia. Jeśli systemy takie obsługują wcześniej omówione przywracanie na poziomie bloków, również mogą zapewnić wyjątkowo krótkie czasy odtwarzania. Systemy te cechują się też punktami odtwarzania o nieskończenie małych wartościach. Wynika to stąd, że są w stanie przywrócić każdy plik lub system plików do dowolnej chwili. Oznacza to, że mogą spełnić każdego rodzaju wymaganie dotyczące synchronizacji, ponieważ potrafią odtworzyć 1, 10 lub 100 systemów do dowolnej chwili. Produkty ciągłej ochrony danych też archiwizują różne rzeczy. Część produktów bazujących na systemie plików umożliwia archiwizowanie i odtwarzanie dowolnych plików znajdujących się w obrębie systemu plików. Część systemów opartych na bazie danych zapewnia ciągłą ochronę tylko konkretnej bazie (na przykład serwera Exchange lub SQL Server). W przeciwieństwie do tradycyjnych produktów archiwizujących plikowe systemy ciągłej ochrony danych nie zapewniają interfejsów dla używanych aplikacji bazodanowych, bo panuje przekonanie, że nie są potrzebne. Producenci takich systemów twierdzą, że kopiują one bloki w docelowe miejsce archiwizacji w takiej samej kolejności, w jakiej bloki zostały zmodyfikowane po stronie klienta. A zatem systemy te są w stanie przywrócić pliki do dosłownie dowolnego punktu w czasie. Ponowne uruchomienie bazy danych po odtworzeniu danych za pomocą systemu ciągłej ochrony danych spowoduje, że baza znajdzie się w tym samym trybie, w którym znalazłaby się, gdyby serwer się zepsuł. Baza sprawdza pliki danych, stwierdza, co jest niespójne, wycofuje lub zatwierdza wszelkie niezbędne transakcje lub bloki, po czym uaktywnia się (nawiasem mówiąc, jeśli taki proces odtwarzania po awarii nie powiódłby się, producent bazy danych nie utrzymałby się na rynku; serwery przestają działać i takie firmy muszą być na to przygotowane). Jeżeli produkt ciągłej ochrony danych zapisze bloki dokładnie w takiej samej kolejności, w jakiej zostały zmienione, powinno być możliwe przywrócenie bazy danych do dowolnego punktu w czasie. Producenci tego typu systemów twierdzą, że jeśli z jakiegoś wyjątkowo nietypowego powodu baza danych nie może przeprowadzić odtwarzania po awarii przy użyciu obrazu sporządzonego o godzinie 12:03:57:01, należy przywrócić dane do stanu z godziny 12:03:57:00 lub 12:03:56:59. Niektóre produkty mogą nawet zaprezentować bazie danych numer jednostki logicznej lub wolumin, które może podłączyć i przetestować przed rozpoczęciem procesu odtwarzania.
242 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Albo to jest ciągła ochrona danych, albo nie! Niektórzy producenci określają swoje systemy niemal ciągłej ochrony danych mianem rozwiązań ciągłej ochrony danych z prawdziwego zdarzenia. Ma to na celu wykorzystanie dużej popularności rynku systemów ciągłej ochrony danych. Część producentów broni się, twierdząc , że ich systemy są faktycznie ciągłe, ponieważ nieustannie przeprowadzają replikację. Słyszałem, jak jeden z producentów stwierdził: „Ciągle kopiujemy wszystkie dane. My jedynie nie zatrzymujemy ich w całości!”. Przypomina mi to epizod z serialu Seinfeld dotyczący wypożyczania samochodów. „Aha, jesteś dobry w przyjmowaniu rezerwacji… Po prostu nie jesteś tak dobry w utrzymywaniu rezerwacji. Jednak utrzymywanie jest naprawdę ważną kwestią”. Tak. Producenci systemów niemal ciągłej ochrony danych cały czas replikują dane. Oznacza to, że jeśli uszkodzi się dokument, pomyłka może zostać natychmiast zreplikowana w kopii zapasowej. Najnowszy obraz będzie wtedy jedyną posiadaną kopią zapasową. Coś takiego nie jest ciągłą ochroną, a jedynie replikacją z tworzonymi obrazami, określaną też mianem niemal ciągłej ochrony danych. Prawdziwy system ciągłej ochrony danych byłby w stanie odtworzyć plik dokładnie do stanu przed jego uszkodzeniem. Producenci systemów niemal ciągłej ochrony danych chcą odciąć się od „starej” metody tworzenia kopii zapasowych i zwrócić uwagę na to, że obrazy są sporządzane w ciągu dnia, zwykle co godzinę. To jest wspaniałe, lecz po prostu nie wolno określać tego ciągłym. Nie ma znaczenia, czy obrazy są tworzone raz na godzinę, minutę, a nawet sekundę. W każdym z tych przypadków ma się do czynienia z okresem. W używanym przeze mnie słowniku terminów bliskoznacznych pojęcie okres jest antonimem ciągłości. Albo zapisuje się każdą zmianę, albo nie. Jeśli wykonuje się obrazy, nie zachowuje się każdej zmiany. Jest to zupełnie oczywiste. Nie chodzi o to, że nie jestem zwolennikiem systemów niemal ciągłej ochrony danych. Część z najfajniejszych działań związanych z ochroną danych, jakie dotąd poczyniłem, zostały zrealizowane przy wykorzystaniu obrazów i replikacji. Uważam też, że wymagania większości osób z łatwością zostałyby spełnione przez obrazy sporządzane co godzinę. Po prostu nie chcę, aby takie produkty same nadawały sobie etykietę systemów ciągłej ochrony danych. Podobnie jest w przypadku macierzy Fibre Channel nadającej sobie status technologii NAS, ponieważ jest magazynem danych podłączonym do sieci. Bez przesady!
Producent bazy danych może mieć inne zdanie na temat systemu ciągłej ochrony danych. Może uznać, że jeśli nie zastosuje się obsługiwanej przez niego metody archiwizacji, nie powinno się dzwonić w celu uzyskania pomocy, gdy coś pójdzie nie tak. Jeżeli rozważa się użycie systemu ciągłej ochrony danych do archiwizowania bazy danych, powinno się skontaktować z jej producentem, a następnie podjąć decyzję. Ponadto administratorzy baz danych muszą być przekonani do systemu ciągłej ochrony danych. Część z nich może uważać go za coś rewolucyjnego, jednak część może podchodzić do niego z przerażeniem. Jeśli pomysł zastosowania takiego systemu przypadnie nam do gustu, powinniśmy starać się przekonać do niego zarówno dostawcę bazy danych, jak i administratorów. Czasy się zmieniają. Jeszcze nie tak dawno temu firma Oracle nie obsługiwała technologii NAS i obrazów. Obecnie nie może się bez tych rozwiązań obejść.
Rygorystyczne wymagan a
| 243
Archiwizowanie danych zdalnego oddziału Rysunek 8.3 przedstawia archiwizowanie danych zdalnego oddziału firmy w jej centrali przy użyciu oprogramowania z funkcją deduplikacji albo systemu niemal ciągłej ochrony danych lub ciągłej ochrony danych. Jeśli klienty widoczne po lewej stronie są zbyt duże, żeby zostały spełnione ich wymagania dotyczące czasu trwania procesu odtwarzania przeprowadzanego z poziomu centrali firmy, dane klientów można zarchiwizować na lokalnym serwerze odtwarzającym, mającym na celu ułatwienie większych odtworzeń niespowodowanych klęskami żywiołowymi. Serwer ten replikuje następnie swoje kopie zapasowe na centralnym serwerze.
Rysunek 8.3. Archiwizowanie danych zdalnego oddziału
Jednoczesne archiwizowanie wielu klientów przy użyciu jednego napędu Obecnie są dostępne napędy archiwizujące, które mogą zapisywać dane znacznie szybciej niż wiele napędów dyskowych. Napędy archiwizujące stosują technologię Fibre Channel i duże bufory, a także czasami jednocześnie zapisują wiele strumieni danych. W efekcie sporo takich napędów może zapisywać z szybkością 100 MB/s lub wyższą. Jak wspomniano w rozdziale 9., problem występujący w przypadku większości tych napędów polega na tym, że są to strumieniowe napędy taśmowe. Oznacza to, że trzeba do nich dostarczać stały strumień danych wejściowych odpowiadający maksymalnej przepustowości urządzenia. Jeśli tak nie będzie, napęd nie będzie funkcjonował optymalnie. W efekcie uzyska się znacznie mniejszą szybkość transferu niż oferowana przez urządzenie. Oczywiście problem ten dotyczy wyłącznie strumieniowych napędów taśmowych. Nie występuje w przypadku napędów archiwizujących, które symulują napęd dyskowy, takich jak urządzenia magnetooptyczne, napędy CD i DVD i wirtualne napędy taśmowe. Wszystkie strumieniowe napędy taśmowe są tak zaprojektowane, aby zapisywały jak najbardziej efektywnie przy swojej optymalnej szybkości. Jeżeli dane są do nich dostarczane z szybkością mniejszą od optymalnej, wynik może być zaskakujący. To, co zaczyna się wtedy dziać, określa 244 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
się mianem repozycjonowania. Więcej informacji na temat tego pojęcia można znaleźć w podrozdziale „Napędy taśmowe” w rozdziale 9. Napędowi większość czasu zajmuje repozycjonowanie. W rezultacie ma mniej czasu na samo zapisywanie danych. Efekt tego jest taki, że napęd zapisuje dane z szybkością stanowiącą niewielką część maksymalnej. Kiedy do czegoś takiego dochodzi? Weźmy pod uwagę jednowątkowy proces archiwizacji realizowany na przykład za pomocą narzędzia dump lub tar. Przed osiągnięciem napędu proces taki może napotkać na wiele potencjalnych wąskich gardeł. Pierwszą przeszkodą jest sam dysk, który może nie być w stanie dostarczać danych z wystarczającą szybkością. Następną jest magistrala SCSI i komputer, do którego podłączono napęd. Magistrala może być zajęta obsługiwaniem innych żądań I/O. W efekcie wpłynie to na szybkość, z jaką dane mogą być transferowane przez magistralę. Oczywiście kolejną przeszkodą jest sieć. Jeśli jest to sieć 100 Mb, najlepsza możliwa szybkość transferu nie przekracza 10 MB/s4. W przypadku sieci gigabitowej pojedynczy serwer zazwyczaj może przesyłać dane z szybkością wynoszącą około 60 – 75 MB/s (można mieć nadzieję, że to ograniczenie wkrótce przestanie obowiązywać). Ostatnim możliwym wąskim gardłem jest komputer, do którego podłączono napęd archiwizujący. Dowolne z tych wąskich gardeł może zmniejszyć szybkość transferu danych poniżej optymalnej szybkości napędu archiwizującego. Jeśli do tego dojdzie, napęd taśmowy przerwie pobieranie strumienia danych i rozpocznie repozycjonowanie, aby dostosować się do szybkości przesyłania danych wejściowych. Gdy tak się stanie, pojawi się nowe wąskie gardło. Co można z tym zrobić? Większość komercyjnych produktów archiwizujących rozwiązuje ten problem przez zastosowanie multipleksowania. W przypadku multipleksowanej archiwizacji dane są jednocześnie wczytywane z kilku komputerów i dysków i dostarczane ze wszystkich tych lokalizacji do napędu archiwizującego. Dane z tych różnych źródeł są następnie przeplatane na woluminie. A zatem napęd archiwizujący zawsze otrzymuje strumień danych wystarczający do tego, żeby mógł zapisywać z maksymalną szybkością. Ostrożny administrator zapoznający się z funkcją multipleksowania po raz pierwszy może się zmartwić. Niektórym administratorom nie podoba się to, że ich dane są rozmieszczane na obszarze całego woluminu. Jednak takie rozwiązanie jest w rzeczywistości jedynym sposobem dostarczania danych napędowi archiwizującemu, który może odczytywać lub zapisywać z szybkościami większymi niż dysk. Właśnie z tego powodu większość komercyjnych produktów archiwizujących stosuje multipleksowanie. Różni producenci oprogramowania archiwizującego posługują się w przypadku multipleksowania odmiennymi terminami. Czasami określa się je mianem zrównoleglenia lub przeplatania.
Wadą multipleksowania jest wydłużanie czasu trwania procesów odtwarzania. W związku z tym multipleksowanie przez wielu było traktowane jak zło konieczne. Multipleksowaną archiwizację zastąpiła archiwizacja dysk-dysk-taśma, w przypadku której kopie zapasowe są najpierw umieszczane na dysku, a następnie na taśmie.
4
Dzieląc megabity przez 8, uzyska się megabajty. W związku z tym szybkość 100 Mb/s odpowiada około 12 MB/s. Jednak w rzeczywistości zwykle osiąga się transfer bliższy wartości 10 MB/s (w tym przypadku prostsze są też obliczenia matematyczne).
Jednoczesne arch w zowan e w elu kl entów przy użyc u jednego napędu
| 245
Archiwizacja dysk-dysk-taśma W obecnie spotykanych systemach archiwizacji bardzo ważną rolę odgrywa metoda polegająca na tym, że najpierw dane są zapisywane na dysku, a następnie kopiowane na taśmę. Rozwiązanie takie określa się mianem archiwizacji dysk-dysk-taśma lub D2D2T (Disk to Disk to Tape). Dopóki produkt archiwizujący pozwala na automatyczne kopiowanie danych z jednego nośnika na inny, można go wykorzystać na potrzeby archiwizacji D2D2T. Bardzo pomocna będzie jednak obsługa funkcji automatycznego powielania opartego na pojemności. Załóżmy, że dane archiwizuje się na dużej macierzy dyskowej lub w wirtualnej bibliotece taśmowej (szczegółowo omówiono ją w rozdziale 9.) i kopie zapasowe powinny pozostawać tam tak długo, jak to możliwe, zanim zostaną przeniesione na taśmę. Idealne byłoby oprogramowanie archiwizujące, które automatycznie kopiowałoby kopie zapasowe z dysku na taśmę, a następnie samoczynnie unieważniało takie kopie, aby zwolnić miejsce dla nowych kopii zapasowych. Tego typu funkcjonalność często jest nazywana powielaniem dyskowym (ang. disk staging) i zwykle dostępna tylko wtedy, gdy dane archiwizuje się w obrębie systemu plików (czyli nie przy wykorzystaniu wirtualnej biblioteki taśmowej). Produkty różnych firm projektujących oprogramowanie archiwizujące obsługują archiwizację D2D2T na kilka odmiennych sposobów. Część z tych producentów bardziej specjalizuje się w tej technologii niż pozostali. Jeśli jest się zwolennikiem archiwizacji D2D2T, zdecydowanie powinno się sprawdzić, w jakim zakresie analizowane oprogramowanie obsługuje tę technologię.
Jednoczesne archiwizowanie danych jednego klienta na wielu napędach W jaki sposób produkt archiwizujący zapisze na nośniku archiwizacyjnym kopię zapasową bardzo dużej bazy danych lub systemu? Jest to trochę inny scenariusz od przedstawionego wcześniej. Multipleksowanie umożliwia pięciu lub 10 komputerom współużytkowanie tego samego urządzenia. Dzięki temu do urządzenia archiwizującego jest dostarczany stały strumień danych i kopie zapasowe mogą być wykonywane w optymalny sposób. Z kolei sytuacja, w której pojawia się potrzeba wielostrumieniowości, dotyczy jednego komputera, który raczej nie jest w stanie zarchiwizować swoich plików na pojedynczym napędzie archiwizującym w ciągu jednej nocy. Jeśli nawet dostępny byłby napęd będący w stanie zapisywać dane z szybkością 100 MB/s, w ciągu godziny byłoby to zaledwie 720 GB, a w 8-godzinnym okresie — 5,76 TB (przy założeniu, że do urządzenia może być dostarczany strumień danych przez tak długi czas). A co będzie, gdy na komputerze znajduje się 20 TB danych? Jak postąpić, jeśli napęd jest w stanie zapisywać dane jedynie z szybkością 25 MB/s z powodu sieci, z którą się komunikuje? Jedyną metodą pozwalającą uzyskać tego rzędu szybkości jest jednoczesne zastosowanie kilku napędów (oczywiście inne kombinacje też by zadziałały, lecz wszystkie wymagają wielu symultanicznych napędów archiwizujących). Aby jednak było to możliwe, oprogramowanie archiwizujące musi być w stanie przesyłać dane z jednego komputera jednocześnie do wielu urządzeń. Choć umożliwia to wiele produktów, ważne jest, w jaki sposób. Najczęstsza metoda archiwizowania bardzo dużych baz danych lub systemów stosowana przez producentów oprogramowania archiwizującego polega na konfigurowaniu wielu definicji, z których każda stanowi podzbiór zasobów całego komputera, a następnie jednoczesnym 246 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
uaktywnianiu tych definicji. Przykładowo można utworzyć definicję archiwizacji, która tworzy kopię zapasową wszystkich danych z wyjątkiem katalogów /home1 i /home2. Może istnieć też druga definicja, archiwizująca wyłącznie katalogi /home1 i /home2. W efekcie oprogramowanie zostanie poinstruowane, żeby w tym samym czasie zastosowało obie definicje. Dzięki temu jednocześnie mogą działać dwa różne urządzenia, które są w stanie skrócić czas trwania archiwizacji nawet o połowę. Metoda taka nie jest wskazana z kilku powodów. Po pierwsze, trudno jest stwierdzić, jak podzielić partycje. Nigdy nie zrobi się tego idealnie. Jeśli nawet pewnego dnia to się uda, z czasem wszystko się zmieni. Po drugie, metoda ta wymaga utrzymywania listy dołączeń, która musi być aktualizowana każdorazowo po dodaniu nowego systemu plików. Kopie zapasowe nigdy nie powinny być definiowane w taki sposób. Jeżeli definicje muszą być rozdzielone, zawsze należy najpierw utworzyć definicję archiwizującą „wszystko z wyjątkiem czegoś”. Dzięki temu, gdy zostanie dodany nowy system plików, będzie automatycznie archiwizowany.
Cieszę się, że nikt o to nie poprosił! Używałem produktu archiwizującego, który wymagał ode mnie tworzenia oddzielnych definicji archiwizacji, gdy chciałem zapisać dane jednego komputera na wielu napędach. Host był tak pojemny, a napędy taśmowe tak powolne, że musiałem utworzyć pięć niezależnych definicji. Pierwszą była definicja uwzględniająca w kopii zapasowej wszystko z wyjątkiem katalogów od /data1 do /data8. Następnie utworzyłem kolejne cztery definicje, z których każda archiwizowała dwa systemy plików /data (w miejsce x należy wstawić wartość z przedziału od 1 do 8). Gdy administrator komputera dodał system plików /data9, został on automatycznie uwzględniony w kopii zapasowej „wszystko z wyjątkiem katalogów /data1-data8”. Gdy jednak dodano systemy plików /data10 i /data11, w ogóle nie zostały zarchiwizowane. Pewnego dnia zauważyłem, że nie mogę znaleźć żadnych danych historycznych dla systemu plików /data10. Było to niedługo po moim pamiętnym telefonie do działu obsługi technicznej, gdy poinformowałem o odkryciu własnego błędu. Gdy wykluczałem system plików /data1, w rzeczywistości nakazałem coś takiego: wykluczyć wszystkie systemy plików, których ścieżka jest zgodna z wyrażeniem regularnym /data1. Niestety, do wzorca /data1 pasuje też /data10. Przez ponad dwa miesiące dwa systemy plików nie były archiwizowane. Na szczęście nikt nie zażądał ich odtworzenia. Właśnie dlatego twierdzę, że trzeba zachować dużą ostrożność podczas wykluczania systemów plików przy użyciu wyrażeń regularnych.
Lepsza metoda polega na automatycznym tworzeniu wielu zadań przez produkt archiwizujący. Jeśli produkty coś takiego oferują, zwykle realizują to na poziomie systemów plików, tworząc dla każdego z nich zadanie. W tym przypadku wyzwaniem jest pojedynczy duży system plików. Dzięki obecnym innowacjom systemy plików mogą mieć pojemność wynoszącą kilka terabajtów. A zatem dla pojedynczego komputera trzeba zarchiwizować kilka terabajtów danych, które dodatkowo znajdują się w obrębie jednego systemu plików. Nie ma metody pozwalającej w ciągu jednej nocy zarchiwizować komputer z wieloma terabajtami danych przy wykorzystaniu jednego napędu archiwizującego. Jedynym sposobem uzyskania odpowiedniej szybkości jest jednoczesne zastosowanie kilku napędów używających czterech niezależnych kanałów. Aby jednak było to możliwe, oprogramowanie archiwizujące musi być w stanie przesyłać dane jednego systemu plików do wielu urządzeń naraz. W czasie pisania książki znane mi były tylko dwa produkty, które spełniały ten wymóg. Jednoczesne arch w zowan e danych jednego kl enta na w elu napędach
|
247
Dane wymagające specjalnego traktowania Wszystkie komercyjne produkty mogą archiwizować dane normalnych systemów plików. Jednak istnieje mnóstwo danych, które nie znajdują się w obrębie zwykłego systemu plików. Część danych wchodzi w skład systemu plików, mimo to przed zarchiwizowaniem wymaga specjalnego traktowania. Należy sprawdzić, w jaki sposób analizowany produkt przetwarza dane. Można wyróżnić następujące warianty: Systemy plików podłączane za pośrednictwem sieci Czasami konieczne jest zarchiwizowanie danych znajdujących się na dysku podłączanym z poziomu innego komputera. Dane wymagające do archiwizacji niestandardowego skryptu Określonego typu dane są czymś pośrednim między danymi zwykłego systemu plików i bazy danych. Jeśli takie dane zostały utworzone przez specjalne narzędzie, trzeba będzie je wyłączyć przed rozpoczęciem archiwizacji. Dane relacyjnej bazy danych Choć niektóre dane relacyjnego systemu bazodanowego mogą być archiwizowane przy użyciu skryptu startowego lub wyłączającego, obecnie dostępna jest znacznie lepsza metoda tworzenia kopii zapasowych danych większości komercyjnych produktów bazodanowych. W poniższych punktach zostały omówione te trzy warianty.
Systemy plików podłączane za pośrednictwem sieci Dlaczego ktokolwiek chciałby archiwizować dane za pośrednictwem protokołu NFS? W niemal każdym sklepie można znaleźć klienta nieobsługiwanego przez komercyjne oprogramowanie archiwizujące. Być może przyczyną tego jest starszy system operacyjny, który nie jest już wspierany. Być może producenci oprogramowania nie są przekonani do tego, że system ten ma wystarczający udział w rynku (trzeba pamiętać, że tacy producenci nie obsługują określonego systemu za darmo). Co dobrego przyniesie dostosowanie oprogramowania na platformę, z której nikt nie korzysta? Jednym z rozwiązań pozwalających zarchiwizować takiego klienta jest podłączenie jego systemów plików za pośrednictwem protokołu NFS do serwera archiwizującego. Tak, zastosowanie tego protokołu może okazać się mało przyjemnym sposobem tworzenia kopii zapasowych danych. Tak, występują problemy z odtwarzaniem za pośrednictwem protokołu NFS. Jednak mówi się, że lepsze to niż nic. Protokołowi NFS towarzyszy system plików CIFS Microsoftu, który korzysta z protokołu SMB. Protokół ten działa podobnie do protokołu NFS. Serwer archiwizujący, który obsługuje protokół NFS za pośrednictwem sieci, może podłączyć dyski CIFS i zarchiwizować je (jeden z problemów związanych z tą metodą polega na tym, że dyski muszą zostać podłączone do serwera z systemem Windows, w przeciwnym razie nie będzie możliwe zarchiwizowanie lub odtworzenie list kontroli dostępu ACL; jednak przynajmniej będzie się dysponować danymi). Następny problem dotyczący podłączanych systemów plików NFS i CIFS: czy oprogramowanie archiwizujące może je wykluczyć. Można sobie wyobrazić, co by się stało w większości środowisk z systemem Windows, gdyby program archiwizujący zaczął tworzyć kopie zapasowe dla wszystkich partycji CIFS! Zwykle unika się czegoś takiego przez wykluczenie wszystkich 248 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
punktów podłączenia systemów plików NFS i CIFS. Jednak niektóre produkty potrafią selektywnie archiwizować partycje NFS i CIFS. Część programów umożliwia skonfigurowanie klienta w taki sposób, że zostaną zarchiwizowane wszystkie jego partycje CIFS i NFS podłączone za pośrednictwem sieci.
Niestandardowe skrypty użytkownika W pewnym okresie niestandardowe skrypty użytkownika były jedyną dostępną opcją archiwizowania baz danych. Produkt archiwizujący uruchamiałby specjalny program napisany przez administratora, który wyłączałby bazę danych. W dalszej kolejności oprogramowanie archiwizowałoby pliki lub niesformatowane partycje z bazą danych. Na końcu produkt ponownie uruchamiałby bazę danych. Zależnie od jej rozmiaru i wymagań dotyczących czasu jej aktywności taka metoda tworzenia jej kopii zapasowych w przypadku określonych środowisk w dalszym ciągu może być warta uwagi. Obecnie niestandardowe skrypty użytkownika są używane w przypadku określonego typu danych, których nie można w pełni zakwalifikować jako bazodanowych, lecz są na tyle dynamiczne, że wymagają specjalnego przetwarzania. Można stosować narzędzie, które cały czas monitoruje sieć i wyniki przechowuje w kilku powiązanych ze sobą plikach. Ponieważ pliki te muszą być archiwizowane w jednym czasie, w czasie trwania procesu narzędzie nie może być aktywne. Można to osiągnąć za pomocą niestandardowego skryptu.
Bazy danych Kilka lat temu żadne komercyjne narzędzie nie archiwizowało bezpośrednio bazy danych. Najlepsze, co można było zrobić, to wyłączyć bazę przy użyciu wcześniej omówionego niestandardowego skryptu. Jednak obecnie bazy danych są tak duże, że w przypadku wielu środowisk taka opcja nie wchodzi już w grę. Wszyscy więksi producenci baz danych udostępnili interfejsy API (Application Programming Interface), które mogą być użyte przez komercyjne narzędzia archiwizujące do sporządzania kopii zapasowych bazy danych. Interfejsy te mają cztery wspólne cechy: • Potrafią przekazywać strumień danych zewnętrznemu narzędziu, takiemu jak komercyjny
produkt archiwizujący (niektóre mogą też we własnym zakresie tworzyć kopie zapasowe).
• Mogą przesyłać strumień danych zewnętrznemu narzędziu, gdy baza danych jest aktywna. • Mogą zapewnić wiele jednoczesnych wątków pochodzących z tej samej bazy danych. • Po skonfigurowaniu mogą być wywoływane z poziomu komercyjnego produktu archiwi-
zującego lub interfejsu bazodanowego (przykładowo można zalogować się na serwerze bazodanowym jako jego administrator i wykonać polecenie, które automatycznie uaktywni sesję dla komercyjnego narzędzia archiwizującego). Można również wykonać polecenie narzędzia archiwizującego i nakazać mu uaktywnienie oprogramowania bazodanowego. Producentowi oprogramowania archiwizującego trzeba zadać następujące pytanie: „Do jakich baz danych dostosowano narzędzie?”. Jeśli nawet obecnie nie korzysta się z żadnego produktu bazodanowego, liczba baz archiwizowanych przez konkretne narzędzie pokazuje poziom zaangażowania jego producenta w segment oprogramowania dla przedsiębiorstw.
Dane wymagające specjalnego traktowan a
| 249
Ponadto należy wspomnieć, że część innych interfejsów nie korzysta z interfejsów API dostarczonych przez producentów baz danych. Co więcej, niektórzy producenci komercyjnych narzędzi archiwizujących we własnym zakresie napisali interfejsy dla systemów bazodanowych, które też nie używają interfejsów API utworzonych przez firmy projektujące bazy danych. Preferowaną metodą powinno być zastosowanie interfejsu API producenta bazy danych. Procesy archiwizowania i odtwarzania realizowane przy wykorzystaniu innej metody zwykle nie są obsługiwane przez twórcę oprogramowania bazodanowego.
Funkcje zarządzania magazynem danych Kolejnym ważnym pojęciem jest zarządzanie magazynem danych. Tak jak część osób uważa, że termin internet został stworzony kilka lat temu, tak wiele ludzi myśli, że zarządzanie magazynem danych jest nowym zagadnieniem. W rzeczywistości pojawiło się w czasach komputerów przemysłowych, gdy nośnik taśmowy 3480 kosztował znacznie mniej niż dysk. Stało się konieczne przenoszenie ważnych i nieużywanych danych z kosztownych dysków na tańszy nośnik taśmowy 3480 (jest to jeden ze sposobów zarządzania dostępnym magazynem danych; stąd też określenie zarządzanie magazynem danych). Ponieważ z czasem dyski SCSI bardzo potaniały, w środowiskach uniksowych po prostu umieszczano kolejne dyski, gdy zwiększyło się zapotrzebowanie na przestrzeń dyskową. Niestety, myślenie w stylu „dysk jest tani” spowodowało, że użytkownicy tworzyli znacznie większe pliki niż kiedykolwiek wcześniej. Jednak w ciągu kilku ostatnich lat menedżerowie działów informatycznych zaczęli się dość mocno frustrować z powodu ilości pieniędzy wydawanych na dyski. Byli przekonani, że niezauważenie można przenieść określoną liczbę plików z dysku na wolniejszy nośnik magazynujący. Wiara ta spowodowała zapotrzebowanie na zarządzanie magazynami danych w środowiskach uniksowych. Jednak czym jest zarządzanie magazynem danych? W niniejszym podrozdziale omówiono trzy podstawowe pojęcia dotyczące zarządzania magazynem danych, które mają związek z kopiami zapasowymi. Oto one: • archiwa, • technologia HSM (Hierarchical Storage Management), • technologia ILM (Information Lifecycle Management).
Archiwa Archiwa zaprojektowano na potrzeby logicznego pobierania informacji, czyli uzyskiwania danych pogrupowanych w logiczny sposób. Przykładowo za pomocą archiwów można magazynować następujące dane referencyjne: • rysunki CAD, listy części i inne informacje dotyczące produktu, który kiedyś był wytwarzany
przez firmę;
• wszystkie informacje związane z dawnym klientem; • wszystkie dane dotyczące zamkniętego projektu, konta lub sprawy sądowej; • zwroty podatku, zapisy księgowe lub inne rekordy z określonego roku.
Innymi słowy, informacje, które można logicznie pogrupować, mogą być archiwizowane i magazynowane. Dzięki temu firma, korzystając z takiego logicznego grupowania, ma możliwość pobrania danych. Gdy produkt nie jest już wytwarzany, sprawa zostanie zamknięta lub rok 250
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
podatkowy się zakończy, stosowne informacje związane ze zdarzeniem lub pozycją po prostu będą zajmować przestrzeń dyskową. Choć z jakiegoś powodu może okazać się konieczne ponowne odwołanie się do tych informacji, nie warto pozostawiać ich w obrębie kosztownego magazynu danych. W związku z tym należy je zarchiwizować i usunąć z podstawowego magazynu. Logiczne magazynowanie aktywnych danych jest drugim oczywistym zastosowaniem archiwów. Załóżmy, że stwierdzono, iż z projektu produktu usunięto krytyczny element zabezpieczający. Bardzo ważne byłoby sprawdzenie każdej wersji specyfikacji wraz z informacjami, kto wprowadził zmiany. Można też wspomnieć o częstej praktyce elektronicznej identyfikacji systemów pocztowych. Można sobie wyobrazić żądania identyfikujące pochodzące od kogoś z zarządu, kto został oskarżony o nękanie lub dyskryminację, handlowca posądzonego o obietnicę wpływów finansowych lub firmę oskarżoną o zmowę z konkurencją. Tego typu oskarżenia mogą skutkować elektronicznymi żądaniami identyfikacyjnymi, które mogą mieć na celu uzyskanie następujących informacji: • wszystkie wiadomości pocztowe wysłane w zeszłym roku przez pracownika A do pracow-
ników: B, C i D; • wszystkie wiadomości pocztowe i wiadomości komunikatorów napisane w ciągu ostatnich
trzech lat przez wszystkich handlowców do każdego klienta i zawierające słowa takie, jak „obietnica”, „gwarancja”, „przyrzeczenie”, „zapewnienie” lub „poręczenie”; • wszystkie wiadomości pocztowe pozostawione przez firmę i skierowane do domen: X, Y i Z
lub pod określone adresy e-mail. Używanie programu archiwizującego do tworzenia plików archiwum nie jest dobrym pomysłem, ponieważ próba znalezienia w kopiach zapasowych konkretnych informacji będzie się wiązała z kosztami i stratą czasu. Choć butelka soku winogronowego pozostawiona na półce wystarczająco długo sfermentuje, nikt nie nazwie tego winem. Podobnie możliwe jest pobranie danych ze starych kopii zapasowych, lecz nikt nie powinien nazywać ich archiwami. Mówiąc wprost, kopie zapasowe są kiepskimi archiwami.
Kopie zapasowe są kiepskimi archiwami Najczęstsza metoda utrzymywania archiwów danych polega na przechowywaniu kopii zapasowych przez długi okres. Najpierw są sporządzane cotygodniowe lub comiesięczne pełne kopie zapasowe, które następnie składowane są przez okres od roku do 50 lat, zależnie od wymagań firmy. Nie ma gorszego sposobu tworzenia archiwów danych. Z zastosowaniem kopii zapasowych w roli archiwów związanych jest wiele trudności. Najbardziej typowym przeznaczeniem kopii zapasowych w roli archiwów jest pobieranie danych referencyjnych. Zakłada się, że jeśli ktoś poprosi o części produktu ABC (lub dowolny inny składnik danych referencyjnych), odpowiednie pliki będzie można po prostu odtworzyć z komputera, na którym się znajdowały. Pierwszym problemem związanym z takim scenariuszem jest to, że trzeba pamiętać, gdzie pliki były kilka lat temu. Choć produkty archiwizujące, a nawet niektóre urządzenia archiwizujące, zaczynają oferować pełnotekstowe przeszukiwanie zawartości wszystkich kopii zapasowych, nadal istnieć będą problemy przedstawione w poniższym akapicie.
Funkcje zarządzan a magazynem danych
|
251
Jeśli nawet można zapamiętać pierwotną lokalizację plików, liczba systemów operacyjnych lub wersji aplikacji, które pojawiły się i zniknęły w międzyczasie, może spowodować, że cały wysiłek pójdzie na marne. Aby odtworzyć pliki zarchiwizowane pięć lat temu dla komputera Apollo, trzeba najpierw dysponować hostem o takiej nazwie. Ktoś musi dodatkowo zająć się wszelkimi kwestiami związanymi z uwierzytelnianiem między serwerem archiwizującym i nowym komputerem Apollo, ponieważ nie jest to ten sam host Apollo, który zarchiwizowano pięć lat temu. Zależnie od oprogramowania archiwizującego i systemu operacyjnego nowy host Apollo może też wymagać tych samych wersji systemu i aplikacji, które działały pięć lat temu na starym komputerze Apollo. W przeciwnym razie mogą wystąpić niezgodności w odtwarzanym systemie plików lub bazie danych.
Realizacja elektronicznych żądań identyfikacyjnych Kopie zapasowe są również wykorzystywane do realizowania elektronicznych żądań identyfikacyjnych, które mogą być jeszcze większym wyzwaniem. W ramach przykładu posłużmy się najbardziej typowym elektronicznym żądaniem identyfikacyjnym dotyczącym wiadomości pocztowych zgodnych z określonym wzorcem i wysłanych przez serwer Exchange (mogą to też być inne systemy pocztowe, takie jak Lotus Notes i SMTP). Z zastosowaniem kopii zapasowych w celu obsługi takiego żądania związane są dwa spore problemy. Pierwszy polega na tym, że niemożliwe jest uzyskanie wszystkich wiadomości pocztowych wysłanych lub otrzymanych przez konkretną osobę. Możliwe jest jedynie odtworzenie wiadomości, które znajdowały się na serwerze Exchange w chwili sporządzania kopii zapasowych. Jeśli żądanie identyfikacyjne dotyczy wiadomości pocztowej, którą ktoś wysłał, skasował, a następnie usunął z katalogu Elementy usunięte, taka wiadomość nie da się odzyskać tygodnie, miesiące lub lata później, bo nie została uwzględniona w nocnej kopii zapasowej. A zatem technicznie nie byłoby możliwe zrealizowanie żądania identyfikacyjnego z wykorzystaniem kopii zapasowych. Oznacza to, że nawet pomimo najlepszych starań w celu skutecznej obsługi żądania identyfikacyjnego powód może stwierdzić, że nie przedstawiono wystarczającego dowodu. Drugim problemem związanym z używaniem kopii zapasowych do obsługi elektronicznego żądania identyfikacyjnego jest bardzo duża trudność przeprowadzenia procesu odtwarzania wiadomości pocztowych z okresu kilku miesięcy lub lat. Dla przykładu przyjmijmy, że firma raz w tygodniu wykonuje pełne kopie zapasowe serwera Exchange i ze względu na zachowanie kompatybilności przechowuje je przez siedem lat. Jeżeli firma otrzymałaby elektroniczne żądanie identyfikacyjne dotyczące wiadomości pocztowych z ostatnich siedmiu lat, w celu jego spełnienia musiałaby przeprowadzić wiele operacji odtwarzania zawartości całego serwera Exchange. Pierwszym krokiem byłoby odtworzenie danych serwera Exchange na alternatywnym serwerze przy użyciu kopii zapasowej z ostatniego tygodnia. W dalszej kolejności trzeba by było przesłać do serwera Exchange zapytanie wyszukujące żądane wiadomości pocztowe i zapisujące je w pliku .PST. Dalej konieczne byłoby odtworzenie serwera Exchange przy wykorzystaniu kopii zapasowej sprzed dwóch tygodni, ponowne wykonanie zapytania i utworzenie następnego pliku .PST. W sumie trzeba by było przeprowadzić 364 razy operację przywracania całego serwera Exchange (siedem lat pomnożone przez 52 tygodnie). Niemal każdy krok tego procesu musiałby być wykonywany ręcznie. Choć nie jest to niemożliwe, proces odtwarzania pochłonąłby ogromną ilość czasu i pieniędzy. Powoda w procesie cywilnym lub rząd nie będzie interesować, jakie koszty poniesie pozwany. Firma może otrzymać nakaz sądowy wymagający od niej przekazania wiadomości pocztowych, niezależnie od kosztów. Choć dobry prawnik może znaleźć argumenty za niewykonaniem nakazu, druga strona procesu może podobnie postąpić. Czy naprawdę warto ryzykować? 252
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Inne obawy związane z kopiami zapasowymi Kopie zapasowe są też wyjątkowo nieefektywną metodą przechowywania archiwów. System tworzący archiwa sprawdza, czy dysponuje tylko jedną czy dwoma kopiami określonej wersji pliku, natomiast system sporządzający kopie zapasowe zwykle nie postępuje w ten sposób. Jeśli firma korzysta z tygodniowych pełnych kopii zapasowych jako archiwów (lub tworzy „archiwa” za pomocą produktu archiwizującego, lecz bez usuwania oryginalnych plików) i przechowuje je przez siedem lat, w sumie na taśmie będą zapisane 364 kopie wielu plików, nawet wtedy, gdy pliki te nigdy nie zostały zmodyfikowane. Coś takiego prowadzi do marnotrawienia niesamowitej pojemności nośników. Kolejnym argumentem przemawiającym za tym, żeby kopii zapasowych nie używać w roli archiwów, jest liczba zmian formatów archiwizacyjnych i formatów taśm dokonanych przez firmę w ciągu wielu lat. Niemal każda firma stosująca kopie zapasowe jako archiwa ma taśmy i kopie zapasowe w kilku starszych formatach, które musi nadal obsługiwać w związku z archiwami. Choć metodą wymagającą mnóstwa kopiowania można skonwertować starsze formaty taśm, konwersja starszych formatów archiwizacyjnych jest zupełnie inną sprawą. Większość osób decyduje się na utrzymywanie zarówno starych formatów taśm, jak i formatów archiwizacyjnych, mając nadzieję, że nigdy nie będą musiały ich odczytywać.
Prawdziwe archiwa Najważniejszą cechą systemu tworzącego archiwa jest to, że powinien zapewnić umieszczenie w nich metadanych wystarczających do tego, aby umożliwić pobranie informacji w logiczny sposób. Przykładowo metadane mogą uwzględniać autora lub jednostkę biznesową, która stworzyła pozycję (może być nią dowolna część archiwalnych danych, taka jak plik, rekord bazy danych lub wiadomość pocztowa). Metadane mogą również zawierać projekt, do którego dodano pozycję lub jakieś inne logiczne pogrupowanie. System archiwizujący pocztę elektroniczną uwzględniałby to, kto wysłał i odebrał wiadomość, jej temat i wszystkie inne odpowiednie metadane. System tworzący archiwa może importować do swojej bazy danych pełny tekst pozycji, umożliwiając pełnotekstowe przeszukiwanie archiwów. Może to być przydatne zwłaszcza wtedy, gdy obsługiwanych jest wiele formatów. Szczególnie wartościowa może okazać się możliwość pełnotekstowego przeszukiwania wszystkich wiadomości pocztowych, dokumentów Worda, plików PDF itp. Inną ważną cechą systemów tworzących archiwa jest zdolność przechowywania wstępnie ustalonej liczby kopii pozycji, dla której sporządzono archiwa. Firma może później zdecydować, ile kopii chciałaby zachować. Jeśli na przykład firma magazynuje swoje archiwa na komputerze chronionym przy użyciu technologii RAID, może postanowić, że jedna kopia będzie na dysku, a druga na przenośnym nośniku taśmowym lub optycznym.
Dwa typy systemów tworzących archiwa Systemy służące do sporządzania archiwów mniej więcej można zaliczyć do dwóch kategorii w zależności od metody magazynowania danych. W pierwszej grupie znajdują się tradycyjne systemy współpracujące z używanym pakietem oprogramowania archiwizującego. Tego typu system umożliwia utworzenie archiwum wybranej grupy plików, dodanie do niego niektórych metadanych (na przykład opisu produktu XYZ), a następnie usunięcie tych plików z kopii zapasowych. Dobrą rzeczą jest to, że system pozwala na dołączenie metadanych i może zredukować liczbę kopii w archiwum przez usunięcie zduplikowanych plików zawartych w kopii Funkcje zarządzan a magazynem danych
|
253
zapasowej, dla których utworzono archiwum. Zła wiadomość jest taka, że jeśli zamierza się przeszukiwać archiwa przy użyciu różnego typu metadanych (właściciel, przedział czasu itp.), może być konieczne utworzenie wielu archiwów. Podstawowym zastosowaniem tego typu archiwum jest oszczędność miejsca przez usuwanie plików powiązanych z projektami lub jednostkami, które nie są już aktywne. Druga i zarazem nowsza kategoria systemów tworzących archiwa jest potwierdzeniem tego, że z różnych powodów może okazać się konieczne pobranie dowolnej pozycji archiwum i w związku z tym mogą być wymagane różne metadane. Aby możliwa była obsługa wielu typów operacji pobierania, ważne jest, aby tylko raz zapisać faktyczną pozycję archiwum, lecz jednocześnie umieścić wszystkie jej metadane w bazie danych, którą można przeszukiwać. Tego typu system zapewnia, że określona pozycja archiwum może być w nim umieszczona nie w celu zaoszczędzenia miejsca, lecz żeby można było ją przeszukiwać w logiczny sposób. A zatem, w przeciwieństwie do poprzedników przechowujących jedynie kopie danych referencyjnych, nowsze systemy tworzące archiwa zapisują dodatkową kopię danych, pozostawiając oryginalne dane na swoim miejscu. Jak wspomniano, jeden z problemów dotyczących używania kopii zapasowych w roli archiwów jest taki, że nie uwzględniają one wszystkich plików lub wiadomości pocztowych. Kopie zawierają jedynie te pozycje, które były dostępne podczas archiwizacji danych. Część nowszych systemów tworzących archiwa rozwiązuje ten problem przez automatyczne archiwizowanie danych. Przykładowo każda wysłana lub otrzymana wiadomość pocztowa jest przechwytywana przez system. Każdorazowo po zapisaniu pliku jego aktualna wersja jest przekazywana systemowi. Następną zaletą nowszych systemów sporządzających archiwa jest wykorzystywanie przez nie rozwiązań dotyczących przechowywania jednego egzemplarza. Systemy te magazynują tylko jedną kopię pliku lub wiadomości pocztowej, niezależnie od tego, kto ją wysłał lub odebrał (oczywiście system rejestruje, kto jest adresatem lub nadawcą wiadomości). Jeśli plik zostanie następnie zmodyfikowany i ponownie zapisany lub treść wiadomości zmieni się i wiadomość zostanie ponownie wysłana, aplikacja obsługująca archiwa zapamięta w nowej wersji pliku lub wiadomości jedynie zmienione bajty. Technologia przechowywania jednego egzemplarza pozwala zaoszczędzić wiele przestrzeni dyskowej. Jeśli chodzi o problemy związane z formatem w przypadku stosowania kopii zapasowych w roli archiwów, wiele systemów tworzących archiwa w dalszym ciągu boryka się z nimi. Wiele osób nadal przechowuje archiwa na taśmie. Wraz z upływem czasu mogą one zmienić używane oprogramowanie obsługujące archiwa. A zatem problemy te mogą pozostać nawet w przypadku archiwów. Nowsze systemy tworzące archiwa pełnią też rolę systemu hierarchicznego zarządzania magazynowaniem, automatycznie usuwając duże, a także starsze pliki i wiadomości pocztowe oraz zastępując je w niezauważalny sposób mniejszymi obiektami, które samoczynnie pobierają odpowiednią zawartość, gdy pojawi się na nią zapotrzebowanie. Jest to jeden z podstawowych elementów, które mają zachęcić firmy do zakupu oprogramowania obsługującego archiwa wiadomości pocztowych. Oprócz tego, że można spełniać elektroniczne żądania identyfikacyjne, można zaoszczędzić mnóstwo miejsca przez tworzenie archiwów nadmiarowych i archiwów zbędnych wiadomości pocztowych i załączników.
254 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Badania pokazują, że ponad 90% przestrzeni typowego magazynu poczty elektronicznej jest zajętych przez załączniki. Jeśli, jak w przypadku wielu serwerów pocztowych (i grup magazynujących Exchange), można przechowywać tylko jedną kopię załącznika i zastąpić ją mniejszym obiektem, uzyska się ogromne oszczędności przestrzeni dyskowej. Jeżeli do tego doda się bloki różnicowe delta, oszczędności mogą być jeszcze większe. Choć serwer Exchange w obrębie grupy magazynującej stosuje przechowywanie pojedynczego egzemplarza, nie stosuje już tego w przypadku wielu takich grup lub serwerów. Załóżmy, że wysłano wiadomość pocztową do czterech osób, z których dwie należą do tej samej grupy magazynującej jednego serwera, jedna do innej grupy tego samego serwera, a jedna została przypisana do zupełnie innego serwera. Serwer Exchange zapisałby jedną kopię wiadomości pocztowej w grupie magazynującej pierwszych dwóch użytkowników, jedną w grupie trzeciego użytkownika i jedną na drugim serwerze czwartego użytkownika. Wyżej opisane oprogramowanie obsługujące archiwa pobrałoby wszystkie trzy kopie i jedną z nich zapisało na serwerze archiwów, a następnie w miejsce kopii wiadomości wstawiło mniejszy obiekt, tak aby dowolny użytkownik wymagający wiadomości mógł ją automatycznie pobrać z archiwum.
Jeśli firma zatrudnia więcej niż jednego pracownika, nie będzie trudne uzasadnienie potrzeby tworzenia archiwów. Jeżeli w roli archiwów stosuje się kopie zapasowe, można mieć naprawdę spory problem, gdy otrzyma się elektroniczne żądanie identyfikacyjne. Być może już teraz powinno się przyjrzeć produktowi tworzącemu archiwa poczty elektronicznej lub oprogramowaniu zarządzającemu treścią przeznaczonemu dla przedsiębiorstw.
Hierarchiczne zarządzanie magazynowaniem Drugim podstawowym zagadnieniem związanym z zarządzaniem magazynowaniem jest technologia HSM (Hierarchical Storage Management). Technologia HSM oraz archiwa to jakby dwa konie różnej maści. Choć tworzenie archiwów umożliwia komuś usunięcie plików z dysku, gdy zostaną umieszczone w archiwum, nie jest to główny cel tego procesu. Podstawowym celem archiwów jest ułatwienie lokalizacji tych plików po upłynięciu wielu lat, gdy użytkownik nie będzie pamiętał, na jakim komputerze pliki pierwotnie się znajdowały. Głównym przeznaczeniem technologii HSM jest automatyczne monitorowanie systemów plików w celu szukania plików spełniających określone kryteria, takie jak nieprzeglądanie zawartości pliku przez długi czas. W prawdziwym systemie hierarchicznym proces ten angażowałby kolejne tańsze typy nośników. Przykładowo plik może być przenoszony z bardzo szybkiego systemu o dużej dostępności na starsze dyski bez mirroringu. W dalszej kolejności plik może zostać przetransferowany na dyski optyczne i ostatecznie na taśmę. Każdy z tych poziomów jest tańszy od poprzedniego, lecz cechuje się też dłuższym czasem dostępu. Gdy plik zostanie przeniesiony lub poddany „migracji” do tańszego poziomu, system HSM umieści w jego miejsce mniejszy plik zastępczy o identycznej nazwie co nazwa oryginalnego pliku. Jeśli ktoś spróbuje uzyskać dostęp do zastępczego pliku, automatycznie przez system HSM zostanie pobrany oryginalny plik. Choć operacja ta będzie niezauważalna dla końcowego użytkownika, czas uzyskiwania dostępu do pliku zostanie wydłużony (niektóre bardzo szybkie systemy mogą skrócić ten czas na tyle, że zwykły użytkownik niczego nie zauważy).
Funkcje zarządzan a magazynem danych
|
255
Weźmy pod uwagę środowisko CAD (Computer Aided Development). Choć inżynierowie mogą tworzyć nowe rysunki każdego dnia, może im zależeć też na zatrzymywaniu starych rysunków na potrzeby odwoływania się. Załóżmy, że ktoś po pięciu latach zada takie oto pytanie: „Jakie części wchodziły w skład produktu XYZ?”. Bez systemu HSM rysunki powiązane z tym produktem pozostawałyby na dysku całe lata, po prostu zajmując miejsce. Jeśli inżynier sporządzający rysunek dba o wykorzystywaną przez siebie przestrzeń dyskową, może skontaktować się z administratorem i poprosić go o umieszczenie w archiwum swoich plików (jednak większość użytkowników nie przejmuje się problemami administratora związanymi z przestrzenią dyskową). System HSM aktywnie monitorowałby katalog z rysunkami CAD i stwierdził, że zawarta w nim grupa rysunków nie była sprawdzana przez ponad rok. Gdyby to nastąpiło, system przeniósłby rysunki na mniej kosztowny nośnik danych bez wykonywania żadnej operacji przez inżyniera. Gdyby ostatecznie inżynier potrzebował pliku rysunku, musiałby jedynie otworzyć go w aplikacji CAD. Plik zostałby automatycznie pobrany. Operacja taka spowodowałaby, że inżynier mógłby stwierdzić, iż tego dnia komputer działa wolniej. Jeśli inżynier miałby wiedzę na temat systemu HSM, mógłby pomyśleć: „Aha, plik musiał zostać przeniesiony”. Dopóki plik będzie dostępny, prawdopodobnie inżynier nie będzie w ogóle myślał o systemie HSM. W przypadku takiego systemu pojawia się potrzeba edukowania użytkowników, którzy muszą wiedzieć, że ich pliki są przenoszone. W przeciwnym razie będą kontaktować się z działem pomocy zawsze, gdy nastąpi opóźnienie podczas pobierania plików. System HSM powinien być wdrażany powoli i metodycznie przy znacznym wsparciu kogoś, kto już wcześniej gdzieś zainstalował taki system. Nierealistyczne zasady migracji i niewłaściwe edukowanie użytkowników mogą być zgubne dla systemu HSM. Zwykli użytkownicy żądali od wielu administratorów systemów usunięcia lub wyłączenia systemu HSM. Taki system może działać, lecz bardzo wiele osób miało do czynienia ze źle skonfigurowanymi systemami HSM, dlatego też zyskały one bardzo złą reputację. Decydując się na zastosowanie systemu HSM, trzeba postępować bardzo ostrożnie.
Zarządzanie cyklem życia informacji ILM (Information Lifecycle Management) jest bardziej pojęciem niż technologią. Systemy HSM i tworzące archiwa zwykle zakładają, że z upływem czasu pliki stają się mniej wartościowe, a system ILM stwierdza, że różne dane mają z czasem inną wartość. Wartość danych może kilkakrotnie wzrastać lub spadać. Najlepszym przykładem wzorca rozpoznawalnego przez system ILM jest eksploracja danych na potrzeby firmy petrochemicznej. Takim firmom ciągłe poszukiwania ropy zajmują lata. W końcu uzyskują informacje, że złoża ropy występują w określonym miejscu. Na etapie przygotowań do uzyskania pozwoleń na odwierty dane są bardzo wartościowe. Gdy firma czeka na zgodę, wartość danych spada. Po otrzymaniu pozwolenia wartość danych znów się zwiększa. Gdy firma rozpoczyna odwierty, lepiej, żeby dane nie przepadły, ponieważ może ją to kosztować miliony dolarów. Po wydobyciu całej ropy ze złoża nagle dane ponownie nie są ważne. Dane są magazynowane przez nieokreślony czas. W pewnym momencie ktoś postanawia zaskarżyć firmę o to, że dokonała odwiertów w złym miejscu. I w ten sposób okazuje się, że dane znów stają się istotne, włącznie z pozwoleniami, rejestrami odwiertów itp.
256
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Choć jest to skrajny przykład, ilustruje ważne zagadnienie związane z technologią ILM, czyli cykl życia posiadanych danych. Należy dowiedzieć się od dostawcy oprogramowania archiwizującego, jak może pomóc w zarządzaniu tym cyklem.
Zmniejszone obciążenie sieci Jedną z najlepszych metod tworzenia kopii zapasowych jest instalacja całkowicie niezależnej sieci obsługującej ruch związany z archiwizowaniem. Jednak wiele osób nie dysponuje funduszami niezbędnymi do utworzenia takiej sieci. W związku z tym muszą zwracać uwagę na to, w jaki sposób system archiwizujący wpływa na sieć, z której korzysta. Można wymienić kilka różnych rzeczy, które produkty archiwizujące robią, żeby zminimalizować swój wpływ na sieć, niezależnie od tego, czy jest to prywatny segment sieciowy przeznaczony na potrzeby archiwizacji czy korporacyjna sieć szkieletowa.
Ruch sieciowy związany z archiwizowaniem należy zatrzymać na poziomie podsieci Jednym z najlepszych sposobów redukowania przez produkt archiwizujący ilości danych przesyłanych między sieciami jest umieszczenie urządzeń archiwizujących na poziomie podsieci. Z zatrzymania ruchu generowanego przez archiwizowanie w obrębie lokalnej podsieci wynikają dwie korzyści. Po pierwsze, ruch taki jest dystrybuowany, dzięki czemu żadna pojedyncza podsieć nie przyjmuje go w całości. A zatem ogólny wpływ archiwizacji na użytkownika wewnętrznej sieci (próbującego również korzystać z sieci korporacyjnej) jest zmniejszony. Po drugie, ogólna przepustowość systemu archiwizującego będzie mogła być skalowana, gdy sieć powiększy się o nowe podsieci. Przyjrzyjmy się rysunkowi 8.4. Widocznych jest na nim sześć różnych podsieci (100.10 – 100.15), z których każda jest obsługiwana za pomocą przełącznika 100 Mb/s (nie został pokazany). Każdy przełącznik jest podłączony do routera obsługującego też podsieć 100.1, w której znajduje się serwer archiwizujący. Typowy sieciowy system archiwizujący powoduje przepływ danych w sposób zilustrowany przez ścieżkę danych widoczną po lewej stronie rysunku. Ścieżka danych reprezentowana przez linię kropkowaną identyfikuje dane transferowane w podsieci 100.10, a następnie, za pośrednictwem routera, do serwera archiwizującego zlokalizowanego w podsieci 100.1. Jeśli w ten sposób dane są archiwizowane w obrębie wszystkich sześciu podsieci, całkowita przepustowość nie może przekraczać szybkości podsieci 100.1 lub routera, ponieważ cały ruch sieciowy musi do niego trafić. W efekcie system archiwizujący nigdy nie dostarczy do napędu archiwizującego optymalnej ilości danych. Jeśli jednak oprogramowanie archiwizujące obsługuje zdalne urządzenia, ruch sieciowy związany z tworzeniem kopii zapasowych można zatrzymać na poziomie podsieci, co przedstawiono w prawej części rysunku 8.4. Nawet bez wykorzystywania technologii przełączania system archiwizujący może w tym przypadku osiągnąć ogólną przepustowość wynoszącą 6 MB/s zamiast 1 MB/s.
Zmn ejszone obc ążen e s ec
|
257
Rysunek 8.4. Ścieżki archiwizowania danych w sieci
Zastosowanie kompresji po stronie klienta W celu zmniejszenia obciążenia sieci produkty archiwizujące mogą wykonywać kompresję po stronie klienta. Oznacza to, że pliki są kompresowane po stronie klienta, zanim zostaną wysłane za pośrednictwem sieci. Choć operacja bardzo obciąża procesor, w znaczącym stopniu można zredukować ilość danych przesyłanych w sieci. Jeżeli procesory komputerów są szybkie, natomiast sieć wolna, w ten sposób można poprawić ogólną przepustowość archiwizacji i skrócić całkowity czas jej trwania. Zastosowanie kompresji po stronie klienta może też wydłużyć proces odtwarzania. To, w jakim stopniu, zależy od konkretnego produktu i specyfiki archiwizowanych systemów. Przed użyciem kompresji należy przeprowadzić testy, aby przekonać się, jak wpływa ona na wydajność procesu odtwarzania. Może się okazać, że gra nie jest warta świeczki.
Zastosowanie dławienia Kolejna funkcja rzadko spotykana w produktach archiwizujących to dławienie. Może pomóc zredukować wpływ archiwizowania na ogólne obciążenie sieci. Niektóre produkty umożliwiają administratorowi dławienie klienta archiwizacji, czyli określenie liczby megabitów, które w ciągu sekundy mogą zostać wysłane przez klienta do sieci. Dzięki temu nawet w przypadku sieci 100 Mb system archiwizujący użyłby jedynie wcześniej narzuconej wartości procentowej całkowitej przepustowości. Oczywiście, w ten sposób wydłuży się tworzenie kopii zapasowych, lecz osoby próbujące skorzystać z sieci na pewno docenią taki zabieg.
258
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Sieci SAN Sieci SAN, przedstawione na rysunku 8.5, oferują kilka zalet, gdy zostaną zastosowane razem z systemem archiwizującym. Sieć SAN ma następujące cechy: • Zapewnia skalowalne urządzenia magazynujące, które mogą być współużytkowane nie-
zależnie od platformy. • Przyspiesza przenoszenie danych, pozwalając na zmianę konfiguracji magazynowania
w rozproszonym lub scentralizowanym środowisku o dużej dostępności. • Obsługuje wyższe poziomy przepustowości operacji wejścia-wyjścia. • Umożliwia lepszą wydajność procesów archiwizowania i odtwarzania. • Przyczynia się do lepszej komunikacji między hostami, co wynika z odciążenia sieci lokalnej
od ruchu związanego z dostępem do magazynów danych. • Poprawia poziom współużytkowania w przedsiębiorstwie zarówno urządzeń magazynują-
cych, jak i archiwizujących.
Rysunek 8.5. Podłączanie dowolnego typu urządzenia peryferyjnego za pośrednictwem sieci SAN
Jeśli spojrzeć na technologię SAN z punktu widzenia branży związanej z archiwizowaniem i odtwarzaniem danych, prezentuje ona najlepszą metodę redukcji obciążenia sieciowego. Hosty podłączone do sieci SAN mogą sporządzać kopie zapasowe bez udziału sieci lokalnej (należy zapoznać się z punktem „Archiwizowanie bez udziału sieci lokalnej” zamieszczonym wcześniej w rozdziale), korzystając z najnowszych rozwiązań zastosowanych w procesorach i zmniejszonego zużycia pamięci. Sieć SAN umożliwia to wszystko i jednocześnie pozwala
Zmn ejszone obc ążen e s ec
|
259
w maksymalnym stopniu wykorzystywać biblioteki taśmowe. Jeśli zarządza się dużym środowiskiem (zwłaszcza wtedy, gdy są w nim bardzo duże serwery), zdecydowanie powinno się poszukać aplikacji archiwizujących obsługujących wykonywanie kopii zapasowych bez udziału sieci lokalnej.
Obsługa standardowego lub niestandardowego formatu archiwizacji Niestandardowy format archiwizacji jest formatem odczytywanym tylko przez konkretne komercyjne narzędzie archiwizujące5. Kopie zapasowe zapisane w nietypowym formacie nie mogą być odczytywane przez wbudowane narzędzia archiwizujące, takie jak tar, cpio i dump. Część produktów archiwizujących używa niestandardowego formatu, który jest publikowany lub za darmo udostępniany. Choć kopie zapasowe tworzone przez takie produkty nie są odczytywane przez wbudowane narzędzia, teoretycznie programista może napisać aplikację, która byłaby w stanie odczytać takie kopie. Niektóre produkty archiwizujące są całkowicie zastrzeżone. W rzeczywistości część produktów jest tak bardzo chroniona, że nawet same nie potrafią przeczytać woluminu, jeśli jego indeksy utraciły ważność lub zostały usunięte. Standardowy format archiwizacyjny byłby czytelny dla standardowego narzędzia. W przypadku formatów archiwizacji można wyróżnić dwie szkoły. Są osoby, które uważają, że zastosowanie zastrzeżonych lub niestandardowych formatów archiwizacyjnych jest niebezpieczne. Jeśli woluminy kopii zapasowych nie mogą być odczytane przez wbudowane narzędzia, co należy zrobić, gdy komercyjny produkt archiwizujący przestanie działać? Takie osoby wolą do archiwizowania danych używać narzędzi bazujących na standardowych formatach archiwizacji (na przykład cpio lub tar). Narzędzia te zapewniają poczucie bezpieczeństwa, które po prostu nie jest możliwe, gdy korzysta się z nietypowego formatu archiwizacyjnego. Firmy często zmieniają produkty archiwizujące. Gdy to tego dochodzi, stare woluminy nie są czytelne dla nowego produktu. Jeśli jednak woluminy mogą być odczytane przez standardowe narzędzia, w dalszym ciągu dane można odtworzyć za ich pomocą. W takim przypadku częstym rozwiązaniem jest zatrzymywanie aktywnego starego systemu archiwizującego tylko na potrzeby przywracania danych. Producenci znajdują się po obu stronach debaty. Poniżej postarałem się jak najlepiej przedstawić argumenty każdej ze stron. Czytelnik musi sam zdecydować, które bardziej do niego przemawiają.
Niektórzy twierdzą, że stare formaty archiwizacyjne są po prostu stare. Spełniły swoją rolę, lecz teraz nadeszła pora na zastosowanie bardziej zaawansowanych narzędzi. Z wbudowanymi narzędziami są związane dwa problemy. Pierwszy jest taki, że zawsze się zmieniają. Program dump bazuje na konkretnym systemie plików. Różne jego wersje nie są ze sobą zgodne. Z kolei narzędzia tar i cpio z czasem zmieniły swoje formaty i nie zawsze są kompatybilne w przypadku różnych systemów operacyjnych (narzędzie ntbackup nie zmieniło się od wielu lat). Drugi problem polega na tym, że wbudowane narzędzia mają znaczne ograniczenia, takie jak długość 5
Termin niestandardowy jest bardziej właściwy od terminu zastrzeżony, ponieważ ten drugi wskazuje na to, że nie ma możliwości zapoznania się z formatem.
260
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
ścieżek i brak możliwości obsługi otwartych plików. Jednak najpoważniejszym ograniczeniem jest niezdolność generowania lub odbierania wielu strumieni archiwizowanych danych. Jedno z wcześniej omówionych narzędzi utworzonych w ramach projektu open source, o nazwie Bacula, ma własny, niestandardowy format.
Standardowe formaty archiwizacyjne Doświadczeni administratorzy systemów opanowali umiejętność obsługi takich programów, jak ditto, dump, ntbackup, tar i cpio. Ta „zażyłość” po prostu nie będzie możliwa w przypadku unikatowego formatu. Część osób jest poirytowana tym, że komercyjne narzędzia pojawiają się i następnie znikają. Było nawet kilka takich produktów, które zmieniły własne formaty i w efekcie stare woluminy stały się nieczytelne dla nowej wersji oprogramowania! Oznacza to, że zasadne są obawy związane z niestandardowymi i zastrzeżonymi formatami. Ponieważ przez ograniczenie się do wbudowanych narzędzi znacznie zmniejsza się liczbę dostępnych produktów, przed ich użyciem trzeba mieć pewność, że właściwie sprawdziło się ich ograniczenia. Poniżej omówiono ograniczenia każdego z narzędzi wbudowanych.
Narzędzie dump Polecenie dump stanowi część dystrybucji Berkeley i jako takie nie zawsze jest obecne w niektórych klasycznych systemach System V Release 4 (oczywiście to mnie w pierwszej chwili zaskoczyło!). Narzędzie dump archiwizuje dane za pośrednictwem niesformatowanego urządzenia, a nie systemu plików. W związku z tym musi znać strukturę archiwizowanego systemu plików. Oznacza to, że każdy nowy typ systemu plików wymaga nowej wersji programu dump. Ponadto kopia zapasowa jednego z typów systemów plików sporządzona za pomocą narzędzia dump niekoniecznie będzie czytelna dla programu restore obsługującego system plików innego typu. Przez lata pojawiło się kilka nowych typów systemów plików. Każdy nowy system plików zwykle dysponuje własną wersją narzędzia dump. Wiele nowszych wersji nie jest zgodnych ze starszymi wersjami (należy zapoznać się z punktem „Różne wersje narzędzia dump” z rozdziału 3.). Część nowych typów systemów plików nie jest w ogóle wyposażona w tradycyjne narzędzie dump. Oprogramowanie archiwizujące nie powinno bazować na wbudowanym narzędziu, które jest inne w przypadku każdego systemu plików. Woluminy z kopiami zapasowymi na różnych platformach nie są zgodne; zgodności brakuje nawet w obrębie poszczególnych platform (przykładem są programy (efs)dump i xfsdump systemu SGI). Poza tym narzędzie dump nie zawsze jest dostępne.
Narzędzia: tar, ditto i cpio W przeciwieństwie do programu dump, narzędzia tar i cpio uzyskują dostęp do plików za pośrednictwem systemu plików, czyli tak jak użytkownik. Ponieważ nie są one zależne od systemu plików, z czasem zmieniają się znacznie mniej niż program dump. Być może to jest największą zaletą narzędzi: ditto, tar i cpio. Jednak dla każdej platformy istnieją różne wersje tych programów i nie wszystkie są ze sobą kompatybilne. Godne uwagi jest to, że większość komercyjnych produktów archiwizujących zapisujących kopie w formacie zgodnym z narzędziem tar Obsługa standardowego lub n estandardowego formatu arch w zacj
|
261
lub cpio w rzeczywistości nie używa polecenia tar lub cpio. Dysponują własnym poleceniem zapisującym kopie zapasowe w formacie odczytywanym przez narzędzie tar lub cpio (tak jest w przypadku programu ditto). Dzięki temu komercyjny produkt może obejść ograniczenia narzędzi tar i cpio, takie jak maksymalna długość ścieżki wynosząca 255 (cpio) i 100 (tar) znaków. Część tych ograniczeń eliminuje też wersja GNU programu tar, którą omówiono w rozdziale 3.
Niestandardowe formaty archiwizacyjne Jak wspomniano, istnieją dwa obozy: zwolenników produktów archiwizujących, które używają standardowych formatów, i zwolenników narzędzi, które ich nie używają. Dodatkowo produkty niekorzystające ze standardowego formatu powinny zostać podzielone na dwie grupy: udostępniające swój format i nie. Teoretycznie programista znający format woluminu może napisać program, który go odczyta. Większość produktów dość silnie jest zależna od bazy danych rejestrującej położenie w obrębie woluminu każdego pliku lub jego fragmentu. Jeśli baza się uszkodzi lub przepadnie, w ogóle może nie być możliwe odczytanie woluminu. Trzeba przeczytać podpunkt „Rozpoznawanie zawartości” w rozdziale 9.
Czy należy zastosować produkt mający niestandardowy format archiwizacyjny? Przed nabyciem takiego produktu trzeba zadać kilka pytań. Czy format woluminu jest całkowicie zastrzeżony? Czy istnieje dokument opisujący sposób zapisania tego formatu? Czy jest dostępne niezależne narzędzie umożliwiające odczytanie woluminów nawet wtedy, gdy przepadnie katalog? Czy jeśli po utworzeniu woluminu produkt nie miał informacji o jego zawartości, będzie mógł ponownie odczytać wolumin i zidentyfikować zestawy plików zapisane na woluminie? Niektóre programy archiwizujące używające niestandardowych formatów są wyposażone w niezależne narzędzie, które odczytuje wolumin bez pomocy bazy danych kopii zapasowych, zapewniając w zasadzie takie same funkcje co wbudowane polecenie. Choć jest to coś pięknego, trudniej to uzyskać, niż można sobie wyobrazić.
Co się stało z formatem SIDF? Część Czytelników być może pamięta format SIDF (System Independent Data Format), który po raz pierwszy zaproponowano w 1993 r. jako międzynarodowy format wymiennych woluminów. Format ten w ograniczonym zakresie był wykorzystywany przez niewielką liczbę produktów archiwizujących. Jeżeli produkt całkowicie obsługiwał format, nie tylko był w stanie tworzyć woluminy zupełnie niezależne od platformy, ale również możliwe do odczytania przez inne aplikacje archiwizujące. Format SIDF ledwie zyskał aprobatę. Odpowiedź na każde pytanie dotyczące statusu tego formatu można uzyskać pod adresem http://www.sidf.org.
Praktyczny test Załóżmy, że dysponuje się zestawem woluminów zapisanych w formacie narzędzia tar, które były rejestrowane przez używane oprogramowanie archiwizujące. Jeśli aplikacja nie funkcjonuje poprawnie, jak można się dowiedzieć, co znajduje się na setkach, a nawet tysiącach posiadanych woluminów kopii zapasowych? Przyjmuję, że możliwe jest wykonanie polecenia tar tvf 262
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
dla wszystkich woluminów i utworzenie własnego „minikatalogu”. Nie jest to łatwe zadanie. Załóżmy, że zapisano około 500 taśm. Odczytanie ich wszystkich zajęłoby ponad miesiąc. Tyle czasu byłoby potrzebne tylko do uzyskania tabeli zawartości woluminów na tych taśmach. Znacznie lepszym rozwiązaniem będzie poszukanie systemu archiwizującego, któremu się ufa. Należy dowiedzieć się, jak sprawdzać bazę danych pod kątem niespójności. Operację taką należy powtarzać każdego dnia. Jeśli zostaną znalezione jakiekolwiek niespójności, których nie będzie można usunąć, bazę danych należy przywrócić do stanu przed uszkodzeniem. Jeżeli oprogramowanie archiwizujące pozwala na to, można mu nakazać ponowne odczytanie wszelkich woluminów zapisanych od tamtego czasu.
Łatwość administrowania Jeśli ktoś zarządza dość dużym systemem archiwizującym, cały czas są wykonywane niżej omówione czynności. Jak prosto jest je wykonać za pomocą produktu, którego użycie się rozważa? Wykonywanie duplikatów woluminów na potrzeby przechowywania na zewnątrz firmy Czynność ta umożliwia administratorowi sporządzanie kopii woluminów i przesyłanie ich poza obręb firmy (właściwie lepszą metodą jest składowanie na zewnątrz firmy oryginałów; przeprowadzanie na co dzień operacji odtwarzania przy użyciu kopii jest nieustannym weryfikowaniem procesu kopiowania; niestety, wiele produktów nie umożliwia tworzenia kopii w ten sposób). Poprawnie operację taką wykonuje się przez skopiowanie woluminu na wolumin, a nie przez utworzenie kolejnej kopii zapasowej. Skopiowany wolumin powinien mieć własną tożsamość, aby mógł być zlokalizowany w katalogu (starsze metody kopiowania woluminów pozwalały uzyskać dwie kopie dokładnie tego samego woluminu; drugi wolumin w rzeczywistości nigdy nie istniał w bazie danych produktu, był po prostu kolejną kopią pierwszego woluminu; to samo dotyczy niektórych wirtualnych bibliotek taśmowych replikujących swoje dane). Część produktów pozwala również administratorowi określić położenie kopii woluminów, tak aby wiedział, które z nich są przechowywane w firmie, a które poza nią. Tym sposobem oprogramowanie nie zapyta o wolumin, o którym wie, że znajduje się na zewnątrz firmy, a ponadto dysponuje innym woluminem z tymi samymi danymi, przechowywanym lokalnie. Kopiowanie wybranych kopii zapasowych Z kopiowaniem woluminów jest związana niedogodność. Zależnie od poziomu zmienności danych i ślepego losu każdej nocy system może zapełnić cały wolumin lub nie. Jeśli kopie są codziennie tworzone i wysyłane poza obręb firmy, co się stanie z woluminem w połowie wypełnionym? Jeżeli wolumin zostanie skopiowany i wysłany na zewnątrz firmy, oprogramowanie nie może kontynuować zapisu na oryginalnym woluminie nawet pomimo tego, że jest dostępne na nim wolne miejsce. Jeśli byłoby inaczej, oprogramowanie musiałoby ponownie skopiować cały wolumin. Czy nie byłoby lepiej, gdyby aplikacja wiedziała, jak skopiować kopie zapasowe z zeszłej nocy, niezależnie od tego, na których woluminach by się znalazły? Właśnie coś takiego umożliwia kopiowanie wybranych kopii zapasowych. Oznacza to, że można powiedzieć: „Pobierz wszystkie pliki zarchiwizowane ostatniej nocy (kopie zapasowe) i umieść je na woluminach, które zostaną wysłane poza obręb firmy”. Zależnie od złożoności oprogramowania kopie zapasowe z zeszłej nocy mogą mieć różną postać, na przykład 100-megabajtowych porcji zapisanych na 20 woluminach. Funkcja powielania kopii
Łatwość adm n strowan a
|
263
zapasowych może tych 20 oddzielnych kopii umieścić na jednym woluminie o pojemności 2000 MB (2 GB). Operacja taka zostałaby wykonana po zakończeniu archiwizacji danych, a związane z nimi obciążenie byłoby lokalne względem systemu archiwizującego. W związku z tym nie miałoby to wpływu na inne procesory, sieć lub użytkowników. Jednoczesne kopiowanie kopii zapasowych Zupełnie nową funkcją, która zaczęła się już rozpowszechniać, jest możliwość kopiowania kopii zapasowej podczas jej tworzenia. Jeśli wszystko poprawnie skonfigurowano i oprogramowanie działa zgodnie z oczekiwaniami, właściwie kopie można sporządzać w czasie nieprzekraczającym czasu tworzenia pierwszej kopii zapasowej. Lepsze produkty umożliwią użycie dwóch woluminów archiwizacyjnych o różnych pojemnościach, dzięki czemu dopuszczalne będą różnice dotyczące kompresji i typów nośników (być może będzie się chciało umieścić lokalnie przechowywane kopie zapasowe na nośniku jednego typu, a kopie przeznaczone do magazynowania poza firmą — na nośniku innego rodzaju). Konsolidowanie kopii zapasowych hosta Przydatną funkcją niektórych programów archiwizujących jest możliwość konsolidowania wszystkich kopii zapasowych określonego hosta na jednym woluminie lub niewielkim zestawie woluminów. Dzięki temu znacznie łatwiej można przygotować się na nieszczęśliwe zdarzenia. Konsolidowanie woluminów zawierających niewielką ilość danych Jest to funkcja pozwalająca efektywnie wykorzystać pojemność woluminu. Na skutek różnych czasów ważności kopii zapasowych może pojawić się duży zestaw woluminów, z których każdy będzie przechowywał zaledwie kilkaset megabajtów nadal przydatnych danych. Funkcja konsolidująca woluminy łączy kopie zapasowe z wszystkich lub części używanych woluminów, umieszczając je na jednym woluminie. Dzięki temu źródłowe woluminy mogą być ponownie wykorzystane. Identyfikowanie systemu plików lub bazy danych Czy produkt automatycznie zidentyfikuje wszystkie systemy plików i napędy, czy trzeba będzie zrobić to ręcznie? Druga z opcji wymaga ciągłego aktualizowania listy systemów plików przeznaczonych do archiwizowania, co nie jest niczym dobrym. Ponadto należy się upewnić, czy produkt umożliwia automatyczną identyfikację w przypadku każdej bazy danych. Z pewnością nie będzie przyjemna konieczność zarządzania listą baz danych SQL Server, które mają zostać zarchiwizowane. Wykluczanie plików Zawsze znajdą się pliki, które powinny zostać wyłączone z kopii zapasowych: tymczasowe pliki internetowe, pliki katalogu /tmp, pliki kolejki wydruku, pliki zrzutów pamięci itp. Typy plików, które muszą być wykluczone, zmieniają się w przypadku każdej organizacji. Trzeba mieć świadomość, że różne produkty stosują odmienne metody wyłączania plików. Typy interfejsów Większość produktów oferuje interfejsy graficzne (zgodne z systemem Windows, językami Java i HTML, a także środowiskami Motif i Curses) i (lub) tekstowe trybu wiersza poleceń. Tylko kilka aplikacji ma wbudowane interfejsy kompatybilne z systemem Mac. Trzeba się upewnić, że produkt dysponuje interfejsem odpowiednim dla używanego środowiska (powinienem również zwrócić uwagę na istotną rolę opcjonalnego interfejsu trybu tekstowego w przypadku niemal każdego środowiska; nie można zawsze liczyć na dostępność graficznego interfejsu podczas przywracania po awarii, ponadto może być konieczne wykonanie operacji za pośrednictwem zdalnego połączenia). 264 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Powiadamianie W jaki sposób zespół administrujący powinien zostać powiadomiony, gdy archiwizacja nie powiedzie się lub będzie wymagać interwencji? Można wyróżnić kilka metod. Najczęstsza polega na użyciu poczty elektronicznej. Niektórzy producenci umożliwiają nawet określanie różnych odbiorców różnego typu wiadomości pocztowych. Reszta producentów pozwala na pisanie niestandardowych programów pełniących rolę interfejsów, które w razie potrzeby wysyłają raporty. Część aplikacji archiwizujących może nawet wysyłać strony alfa, gdy jest dostępny modem. Być może najbardziej zaawansowaną metodą powiadamiania jest zastosowanie pułapek protokołu SNMP (Simple Network Management Protocol), który pierwotnie został zaprojektowany z myślą o sprzęcie sieciowym, tak aby routery różnych producentów mogły się ze sobą komunikować. Protokół SNMP został rozbudowany o obsługę każdego typu monitorowania sieci. Właśnie na tym protokole bazuje większość komercyjnych narzędzi monitorujących sieć. Instalowanie Większość instalacji serwerowych jest dość mocno zautomatyzowana. Prawdziwym problemem jest instalacja oprogramowania po stronie klienta. Zazwyczaj stosuje się dwie metody takiej instalacji: ręczną lub automatyczną. W przypadku pierwszej z nich najpierw trzeba umieścić na komputerze pliki oprogramowania klienta. W tym celu można użyć narzędzia: ftp, nfs lub CIFS, a następnie uruchomić program instalacyjny. W określonych okolicznościach niektóre produkty mogą całkowicie zautomatyzować instalację po stronie klienta. Aktualizowanie Choć produkt jest instalowany raz, będzie aktualizowany raz lub dwa razy w roku. W związku z tym łatwość aktualizacji jest następną ważną kwestią, którą należy wziąć pod uwagę. Proces aktualizacji może być przeprowadzany ręcznie lub automatycznie. Jednak niektóre produkty (po zainstalowaniu) potrafią automatycznie wykonać aktualizację. Ponieważ aktualizowanie oprogramowania na setkach klientów jest najtrudniejszym, a do tego powtarzalnym zadaniem, taka możliwość jest dość przydatna.
Bezpieczeństwo W przeszłości kopie zapasowe i procedury bezpieczeństwa miały prawie zupełnie odmienne cele. Pliki uniksowe .rhosts, znane z problemów z bezpieczeństwem, były absolutnie konieczne do uzyskania dowolnego typu automatyzacji procesu archiwizowania danych. Na szczęście większość nowoczesnych produktów archiwizujących poradziła sobie z tym. Poniżej wymieniono kilka kwestii związanych z bezpieczeństwem, które warto rozważyć. Komunikacja z demonem lub usługą Każdy przyzwoity produkt będzie oferował bezpieczną metodę komunikacji z klientem. Nie będą wymagane niebezpieczne rozwiązania komunikacyjne, takie jak oparte na narzędziu rsh. Uwierzytelnianie komputera W jaki sposób serwer i klient weryfikują własną tożsamość? Czy po prostu stosują w tym celu nazwy hostów i adresy IP? W przypadku takiej metody bardzo łatwo o zafałszowania, dlatego powinno się jej unikać. Inna metoda polega na użyciu hasła superużytkownika klienta. Wymaga to, aby administrator odpowiedzialny za archiwizację znał takie hasło Bezp eczeństwo
|
265
dla każdego klienta. Nie jest to dobry pomysł. Część systemów archiwizujących wykorzystuje zaawansowane hasła jednorazowe, które są bardzo trudne do złamania. Trzeba sprawdzić, jak używane oprogramowanie archiwizujące uwierzytelnia komputery. Uwierzytelnianie użytkownika W jaki sposób oprogramowanie archiwizujące uwierzytelnia administratorów systemu lub osoby, które zamierzają przeprowadzić proces odtwarzania na poziomie użytkownika? Czy ma własną bazę danych? Czy jest zintegrowane z usługą Active Directory lub NIS? Autoryzowanie oparte na rolach Czy po uwierzytelnieniu użytkownik ma pełne możliwości lub może przydzielać określone zadania wybranym osobom? Byłoby dobrze, gdyby osoba odpowiedzialna za monitorowanie kopii zapasowych nie była tą samą, która je sporządza. Przydatne byłoby również ograniczenie liczby osób, które mogą usuwać lub nadpisywać kopie zapasowe. Szyfrowanie Pod adresem http://www.privacyrights.org jest utrzymywana lista przypadków naruszenia prywatności. W czasie pisania książki znajdował się na niej tuzin naruszeń związanych z taśmami. Na takie incydenty zwraca się dużą uwagę i coraz więcej osób żąda szyfrowania danych, które można zapewnić na jeden z trzech sposobów. Dane mogą być szyfrowane w obrębie oryginalnego systemu plików. Mogą też być szyfrowane przez oprogramowanie archiwizujące podczas transferowania do serwera. Trzecia metoda polega na szyfrowaniu danych na poziomie sprzętowym. Jeśli rozważa się szyfrowanie przez oprogramowanie archiwizujące, trzeba w tej sprawie skontaktować się z producentem aplikacji.
Łatwość odtwarzania Często cytuję mojego dawnego współpracownika: „Nikogo nie interesuje to, czy możesz archiwizować dane, lecz to, czy możesz je odtworzyć6”. Łatwość przywracania danych i szybkość przeprowadzania tego procesu to kwestie często pomijane podczas sprawdzania produktów archiwizujących. Wiele drobnych czynników może sprawić, że operacje odtwarzania będą bardzo proste lub niemożliwe. Niezależność od platformy Jest to bardzo istotna kwestia. Niektórzy producenci przysporzyli sobie kłopotów przez zapewnianie, że każdy wolumin utworzony przez dowolną wersję ich oprogramowania może być odczytany przez każdą inną wersję, niezależnie od tego, na jakiej platformie wolumin sporządzono. Jeśli używane oprogramowanie spełnia ten wymóg i klient zostanie zniszczony, jego dane będzie można odtworzyć nawet wtedy, gdy zastosuje się wersję narzędzia innego typu. Jeżeli woluminy nie są niezależne od platformy, administrator może być zmuszony do utrzymywania działającego komputera z każdą wersją systemu operacyjnego tylko na potrzeby odtwarzania danych7. Rzeczywista niezależność od platformy znacznie ułatwia wykonywanie regularnych operacji odtwarzania. 6
Wyrazy uznania za to dla Rona Rodrigueza. Zastępowanie go na stanowisku „chłopaka od kopii zapasowych” było moją pierwszą pracą związaną z archiwizowaniem. Nie mam pojęcia, ile razy Ron to powiedział, lecz myślę, że dotarło to do mnie.
7
Można mi zaufać, że tak jest, bo sam się o tym przekonałem! Znane jest mi jedno miejsce, w którym w dalszym ciągu znajduje się jeden lub dwa komputery AT&T 3b2 z systemem SVr3, ponieważ wszystkie stare kopie zapasowe narzędzia cpio utworzone przy wykorzystaniu napędów QIC nie są czytelne dla innych platform.
266
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Równoległe odtwarzanie Może to być bardzo wygodna funkcja. Gdy odtwarza się duży katalog lub system plików, jego kopie zapasowe mogą zostać umieszczone na kilku woluminach. Niektóre produkty są w stanie jednocześnie odczytać wszystkie te woluminy, dzięki czemu odtwarzanie danych trwa krócej od ich archiwizowania. Analizując tę funkcjonalność, powinno się też sprawdzić, czy woluminy mogą być ładowane w dowolnej kolejności. Proces odtwarzania przeprowadzany przez użytkownika W niektórych środowiskach znajdują się zaawansowani użytkownicy, którzy lubią mieć możliwość odtwarzania danych we własnym zakresie. Jeśli tak jest w przypadku zarządzanego środowiska, ta funkcja okaże się przydatna. Osoby, które nie chcą, aby użytkownicy mogli sami odtwarzać dane, będą zainteresowane tym, czy funkcję tę można wyłączyć. Odtwarzanie danych w innej lokalizacji Jest to bardzo ważna kwestia. Czasami trzeba odtworzyć plik, który pierwotnie znajdował się na innym komputerze. Dane można odtworzyć na innym hoście lub w innym katalogu. Niektóre produkty nie pozwalają na coś takiego. Przywracanie komputera od podstaw Proces przywracania komputera od podstaw nie wymaga nawet dostępności funkcjonującego systemu operacyjnego (więcej na ten temat można znaleźć w części piątej książki). Proces można przyrównać do świętego Graala archiwizacji. Umożliwia on odtworzenie zawartości całego komputera „z niczego”. Obecnie kilka produktów oferuje proces przywracania komputera od podstaw dla jednej lub więcej platform. Wiele wersji Również ta kwestia jest bardzo istotna. Mnóstwo produktów archiwizujących nie tylko rejestruje najnowszą wersję zarchiwizowanego pliku, ale też wszystkie jego wersje znajdujące się na woluminach kopii zapasowych. Czasami konieczne jest odtworzenie pliku do stanu sprzed czterech dni. Rejestrowanie usuwanych plików Może to być zaskoczeniem dla wielu osób. Załóżmy, że istnieje system plików, który trochę się zmienia. Codziennie są dodawane i usuwane pliki (dobrym przykładem będą tu archiwizowane dzienniki powtórzeń bazy danych Oracle; każdego dnia mogą być dodawane lub usuwane setki plików). Gdy zażąda się od oprogramowania archiwizującego odtworzenia takiego systemu plików, można oczekiwać, że zostanie przywrócony do wczorajszej postaci. Niestety, wiele produktów odtworzy wszystkie pliki, które wchodziły w skład tego systemu plików! Aby oprogramowanie mogło „zauważyć”, że plik został usunięty, i nie odtwarzało go, jeśli użytkownik tego nie zażąda, musi ono przeprowadzić dodatkowe działania. Brak rejestrowania usuwanych plików może bardzo utrudnić odtwarzanie niektórych systemów plików. Opcje nadpisywania Czy kiedykolwiek Czytelnikowi zdarzyło się otrzymać telefon od użytkownika informującego, że utracił połowę zawartości swojego katalogu domowego, ponieważ przypadkowo wykonał polecenie rm -r *? Użytkownik ten nie będzie chciał, żeby program odtwarzający dane nadpisał resztę zawartości katalogu. Dobrym sposobem uchronienia się przed tym będzie nakazanie oprogramowaniu archiwizującemu, aby odtworzyło wszystkie pliki katalogu, z wyjątkiem tych, które są nowsze od zawartych w kopii zapasowej. Istnieje kilka
Łatwość odtwarzan a
|
267
innych opcji nadpisywania, takich jak nadpisywanie bezwarunkowe, nadpisywanie wymagające potwierdzenia i nienadpisywanie dokładnie tego samego pliku.
Ochrona indeksu kopii zapasowych Baza danych, katalog lub indeks kopii zapasowych rejestruje, jakie pliki zostały zarchiwizowane na poszczególnych woluminach. Ponieważ system archiwizujący nie może niczego odtworzyć bez takiego indeksu, w zarządzanym środowisku staje się on najważniejszą pojedynczą bazą danych. Indeks ten stanowi też pojedynczy punkt awarii w przypadku dowolnego systemu archiwizującego. Jak wspomniano, jeśli nawet wolumin zapisano przy użyciu formatu odczytywanego przez wbudowane narzędzie, nadal potrzebny jest indeks, żeby wiedzieć, co się na woluminie znajduje. Choć indeks kopii zapasowych jest największym wynalazkiem od czasów zastosowania etykiet woluminów, gdy coś z nim okaże się nie tak, nie będzie można mówić o szczęściu. Choć indeksy kopii zapasowych zazwyczaj są zlokalizowane na centralnym serwerze archiwizującym, mogą być też rozmieszczone na czymś, co czasami określa się mianem serwerów nośników lub urządzeń (serwer nośników lub serwer urządzeń jest serwerem, który może dysponować sprzętem archiwizującym). Jedno z pierwszych pytań, które można zadać, brzmi: „Jaki rozmiar będzie miał indeks?”. Typowa odpowiedź brzmi: „Od 0,5 do 1 procenta rozmiaru archiwizowanych danych”. Odpowiedź taka jest wyjątkowo myląca, całkowicie niepoprawna i zupełnie niestosowna. Całkowity rozmiar archiwizowanych danych absolutnie nie ma nic wspólnego z pojemnością bazy danych (indeksem). Niech powtórzę to jeszcze raz.
Postąpiłem zgodnie z procedurą Miałem do czynienia z firmą z branży rozrywkowej, która obsługiwała około 10 000 automatów do gier i archiwizowała je przy użyciu komercyjnego oprogramowania archiwizującego. Z powodu znanego i nieusuwalnego problemu z oprogramowaniem sprzętowym kart Fibre Channel biblioteki magazynującej dane sporadycznie zdarzało jej się „gubić” napęd i uszkadzać bazę danych. Mniej więcej w początkowej fazie realizowania projektu ktoś utworzył dokument, który szczegółowo opisywał sposób usunięcia tego błędu przez odinstalowanie i ponowną instalację oprogramowania archiwizującego. Niestety, pracownicy firmy pominęli krok polegający na zapisaniu kopii katalogu. Zanim to zauważono, w pierwszym roku funkcjonowania centrum danych procedura została przeprowadzona dwukrotnie. Na szczęście niezbędne operacje odtworzenia danych można było przeprowadzić przy użyciu kopii zapasowej zapisanej na dysku i wykonanej bez pomocy komercyjnego oprogramowania archiwizującego. — Brian Sakovitch
Całkowity rozmiar archiwizowanych danych absolutnie nie ma nic wspólnego z pojemnością bazy danych (indeksem). O rozmiarze bazy decyduje liczba archiwizowanych plików, a nie ich wielkość.
268 |
Rozdz ał 8. Komercyjne narzędz a arch w zujące
Dla każdego archiwizowanego pliku w indeksie jest tworzony rekord. Będzie on tego samego rozmiaru niezależnie od wielkości pliku, który zarchiwizowano8. W związku z tym właściwe pytanie brzmi: „Ile bajtów doda do indeksu każdy nowy plik podczas archiwizowania go po raz pierwszy, a ile przy kolejnych archiwizacjach uwzględniających plik w przyrostowych kopiach zapasowych?”. Liczba bajtów może zostać pomnożona przez liczbę archiwizowanych plików. W ten sposób uzyska się rozmiar indeksu, jaki może być po sporządzeniu jednej pełnej kopii zapasowej. Otrzymaną wartość należy pomnożyć przez liczbę pełnych kopii, które system musi przechowywać. Zakładając w przybliżeniu, że w ciągu dnia dane zmieniają się w przedziale od dwóch do pięciu procent9, należy oszacować, jak bardzo zwiększy się indeks po utworzeniu każdej kolejnej przyrostowej kopii zapasowej. Uzyskaną wartość należy pomnożyć przez liczbę przyrostowych kopii zapasowych, które system musi przechowywać. Wynik należy dodać do końcowej wartości uzyskanej dla pełnych kopii zapasowych, a następnie sumę pomnożyć przez dwa. Otrzymana wartość będzie naprawdę realistycznym, choć nieznacznie przesadzonym oszacowaniem rozmiaru, który może osiągnąć indeks kopii zapasowych. Zwiększanie się rozmiaru indeksu jest sporym problemem. Niezależnie od formatu bazodanowego używanego przez firmę jeden z plików indeksu może osiągnąć rozmiar przekraczający limity obowiązujące dla systemu plików. Jeśli do tego dojdzie, indeks od razu może się uszkodzić. Produkt archiwizujący powinien oferować jakąś metodę radzenia sobie z tym problemem. Ponadto cały indeks może uzyskać wielkość nieobsługiwaną przez największy system plików. W związku z tym powinno być możliwe rozmieszczanie danych na wielu systemach plików. Tak jak woluminy powinny być niezależne od platformy, tak też powinno być w przypadku indeksu kopii zapasowych. Powinno być możliwe odtworzenie indeksu na dowolnym komputerze, na którym funkcjonuje oprogramowanie serwerowe, a także ciągłe korzystanie z tego indeksu. Aby to było możliwe, indeks musi być całkowicie niezależny od platformy. Część produktów spełnia ten wymóg, a część nie. Choć niektóre produkty nie są niezależne od platformy, zapewniają narzędzie umożliwiające przeniesienie indeksu na inne platformy. Jednym z najlepszych testów potwierdzających to jest próba odtworzenia na serwerze z systemem Windows indeksu kopii zapasowych utworzonego na serwerze uniksowym. Zanim podejmie się decyzję o zakupie komercyjnego produktu archiwizującego, należy sprawdzić jego procedurę odtwarzania indeksu. Część produktów może przywrócić indeks w jednym kroku, część wymaga liczby kroków zajmujących 20 stron opisu. Gdy już nabędzie się produkt, należy ponownie przetestować procedurę. Później należy ją sprawdzać regularnie, aby nigdy nie być zmuszonym do wypowiadania takich oto słów: „Mój cały świat właśnie runął w gruzach, włącznie z serwerem archiwizującym. Co ja teraz mam począć?”. Pomocnych będzie też kilka pomniejszych, lecz wartościowych funkcji. Pierwsza z nich umożliwia zmianę nazwy klienta wewnątrz indeksu. Jeśli nazwa hosta archiwizowanego klienta zmieni się i produkt archiwizujący nie będzie obsługiwał tej funkcji, możliwe będą tylko dwa warianty. Pierwszym wariantem jest zrezygnowanie z wszystkich dotychczasowych danych 8
Niektóre produkty używają rekordu o zmiennej długości. W związku z tym coś takiego jak długość ścieżki może nieznacznie wpływać na rozmiar rekordu. Jednak w dalszym ciągu wielkość pliku nie ma na rekord żadnego wpływu.
9
Choć w rzeczywistości jest to znaczna zmienność danych, w przypadku większości środowisk nie są dostępne żadne informacje na temat liczby plików, które są modyfikowane każdego dnia. Jeśli nawet firmy monitorują swoje oprogramowanie archiwizujące, większość raportów informuje jedynie o pojemności zarchiwizowanych danych, a nie o liczbie plików.
Ochrona ndeksu kop zapasowych
|
269
archiwizacyjnych sporządzonych dla takiego hosta, drugim — zapłacenie za kolejną licencję, która pozwoli oprogramowaniu rozpoznać nową nazwę hosta jako nazwę nowego klienta. Druga z bardzo przydatnych funkcji, postrzegana przez niektórych jako zasadnicza, pozwala ponownie wczytać zawartość woluminu do indeksu. Załóżmy, że istnieje wolumin, który pominięto i który obecnie jest całkowicie nieuwzględniany przez indeks. Co będzie, jeśli jedyna kopia wymaganego pliku znajduje się na tym woluminie? Co się stanie, gdy nie wiadomo, czy plik jest zlokalizowany na tym woluminie? Część produktów potrafi odtwarzać dane bez konieczności ponownego wczytywania całego woluminu, a część może wczytać zawartość woluminu bezpośrednio do indeksu, sprawiając, że wolumin wygląda na dopiero zarchiwizowany. Niektóre produkty w ogóle nie są w stanie ponownie odczytać takiego woluminu! Czynnikiem decydującym o tym, czy produkt umożliwia wczytanie takiego woluminu, jest to, czy producent zapisuje kopię indeksu na woluminie. Choć jest to dodatkowa operacja, myślę, że jest warta zachodu. Nowy fragment indeksu dodany do niego po wykonaniu każdej kolejnej kopii zapasowej jest umieszczany na woluminie. Dzięki temu ponowne wczytanie woluminu staje się znacznie prostsze. Choć możliwe jest ponowne wczytanie woluminu kopii zapasowych bez zapisywania na nim indeksu, wszystko staje się łatwiejsze, gdy indeks znajduje się na woluminie. Ważności indeksu kopii zapasowych i znajomości zasad jego działania nie można przecenić. Indeks jest krwiobiegiem każdego systemu archiwizującego i powinien być traktowany jak złoto.
Niezawodność Z komputerami archiwizującymi dzieją się okropne rzeczy. Ponownie się uruchamiają i są odłączane od zasilania. Napędy archiwizujące zawieszają się, biblioteki blokują, sieci stają się niedostępne. Niezawodność produktu może być określona przez to, jak dobrze radzi sobie z tego typu problemami. Czy produkt może przekierować wykonywanie kopii zapasowych z uszkodzonego napędu archiwizującego na dobry? Czy w ogóle produkt zauważy, że napęd lub proces zawiesił się? Czy produkt będzie w stanie poradzić sobie z tym, że podczas trwania procesu archiwizowania danych klienta nastąpiło jego ponowne uruchomienie? Czy taki klient ponownie uruchamiający się w środku procesu archiwizowania spowoduje uszkodzenie indeksu kopii zapasowych? Są to bardzo ważne kwestie. Sprawy kiedyś źle się potoczą i gdy to nastąpi, trzeba mieć pewność, że z kopiami zapasowymi nic się nie stało. Jeśli produkt archiwizujący potrafi przekierowywać archiwizację po wystąpieniu awarii, ponawiać archiwizowanie otwartych plików i jeszcze raz tworzyć uszkodzone kopie zapasowe, najgorsze, co może się przydarzyć, to naprawdę długi raport na początek następnego dnia w pracy.
Automatyzacja Obecnie dostępnych jest kilka bardzo fajnych bibliotek taśmowych i optycznych. Są między innymi wyposażone w obsługę kodów kreskowych, funkcje automatycznego czyszczenia, zasilacze wymieniane w czasie pracy i wymienne napędy. Jak dobrze używany produkt archiwizujący wykorzystuje te funkcje? Jedną z największych zalet wynikających z zastosowania nowoczesnej biblioteki nośników jest możliwość użycia woluminów identyfikowanych przez kody kreskowe. Po umieszczeniu w bibliotece 20 woluminów należy oprogramowaniu archi270
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
wizującemu nakazać odczytanie ich kodów kreskowych i nadanie woluminom elektronicznych etykiet zgodnych z zawartością kodów. Bez wątpienia takie rozwiązanie bije na głowę trwający pół godziny proces etykietowania polegający na ciągłym umieszczaniu 20 woluminów w napędach archiwizujących i wyciąganiu ich z nich!
Historie z gatunku grozy związane z indeksem kopii zapasowych Większość zdarzeń wywołujących dreszcze, które mi się przytrafiły, były spowodowane problemami z indeksem kopii zapasowych. Moje pierwsze negatywne doświadczenie było związane z archiwizowaniem dużego serwera NFS, który służył do przechowywania stron domowych serwerów WWW rozbudowanej usługi sieciowej. Na serwerze znajdowały się ponad trzy miliony niewielkich plików, które wygenerowały tak duży indeks, że często się uszkadzał. Nawet po umieszczeniu indeksu na wielu serwerach podrzędnych jego rozmiar był powodem regularnych uszkodzeń. Jakby tego było mało, często uszkodzenia stwierdzaliśmy dopiero kilka dni później, gdy produkt archiwizujący zachowywał się nietypowo. Ponieważ byliśmy na tyle niemądrzy, żeby przechowywać zawartość indeksu kopii zapasowych tylko z okresu dwóch dni, nie byliśmy w stanie przywrócić stabilnego indeksu. Ostatecznie skończyło się na tym, że codziennie w plikach ASCII zapisywaliśmy zawartość indeksu, a następnie archiwizowaliśmy te pliki przy użyciu innego serwera i regularnych harmonogramów retencji. Inna równie przerażająca historia zdarzyła się w tej samej firmie. Starając się utrzymać niewielki rozmiar indeksu, przechowywaliśmy jego zawartość powiązaną z kopiami zapasowymi utworzonymi tylko w ostatnich dwóch tygodniach (nawet pomimo tego, że dane na woluminie archiwizacyjnym były przechowywane przez dwa miesiące). Miałem do czynienia z użytkownikiem, który wielokrotnie usuwał dane po zakończeniu ich przetwarzania. Dwa i pół tygodnia później stwierdził, że tak naprawdę te dane są mu nadal potrzebne. Ponieważ rekordów dla plików z tymi danymi nie było już w indeksie, trzeba było ponownie wczytać każdy wolumin, który mógł zawierać dane. Jedna z operacji odtwarzania wymagała ode mnie ponownego odczytania ponad 40 taśm DLT 4000 (za pomocą zmieniarki obsługującej jednocześnie tylko 28 taśm), gdy w tym samym czasie nadal próbowałem sporządzać standardowe kopie zapasowe. Wczytanie taśm zajęło mi ponad trzy dni. Nawet pomimo tego nie byłem w stanie odzyskać wszystkich danych użytkownika. Na szczęście nie straciłem pracy, ponieważ dane nie były uważane za bardzo ważne. — Bryce Wade
Weryfikowanie woluminów Inną często ignorowaną funkcją oprogramowania chroniącego dane jest możliwość weryfikowania utworzonych kopii zapasowych. Można by przytoczyć wiele przerażających opowieści ludzi, którzy przez miesiące lub lata sporządzali kopie zapasowe, przyjmując, że będą po prostu świetnie działały. Gdy jednak trzeba było odczytać woluminy archiwizacyjne, okazywało się, że oprogramowanie archiwizujące poinformowało o braku możliwości wykonania takiej operacji. Jedynym sposobem zabezpieczenia się przed czymś takim jest regularne sprawdzanie nośników z kopiami zapasowymi. Można wyróżnić kilka typów weryfikacji:
Weryf kowan e wolum nów
|
271
Odczytanie części woluminu i porównanie jej Przynajmniej jeden duży producent preferuje tę metodę weryfikowania. Jeśli uaktywni się funkcję sprawdzającą nośnik, nastąpi przejście do końca woluminu i odczytanie jednego lub dwóch plików. Funkcja porównuje zawartość plików z tym, co według niej powinno w nich być. Oczywiście jest to najniższy poziom weryfikacji. Porównanie tabeli zawartości indeksu W porównaniu z pierwszym typem weryfikacji ta metoda idzie krok dalej. Jej działanie odpowiada wykonaniu polecenia tar tvf. Metoda nie sprawdza zawartości pliku, a jedynie to, czy oprogramowanie archiwizujące jest w stanie wczytać nagłówek pliku. Porównanie zawartości kopii zapasowej z zawartością systemu plików Tego typu weryfikacja jest powszechna w przypadku tanich aplikacji archiwizujących przeznaczonych dla komputerów PC. Oprogramowanie po prostu przygląda się sporządzonej przez siebie kopii zapasowej konkretnego systemu plików, a następnie jej zawartość porównuje z rzeczywistą zawartością systemu plików. Niektóre pakiety oprogramowania wykonujące taką operację automatycznie archiwizują wszelkie pliki, które różnią się od tego, co jest w kopii zapasowej, lub te, których w ogóle w niej nie ma. Tego typu weryfikacja jest bardzo trudna, ponieważ większość systemów nieustannie się zmienia. Porównanie sumy kontrolnej z indeksem Niektóre produkty archiwizujące zapisują sumę kontrolną dla każdego archiwizowanego pliku. Dzięki temu są w stanie odczytać wolumin archiwizacyjny i porównać sumę kontrolną pliku z sumą kontrolną zarejestrowaną w indeksie dla tego pliku. W ten sposób zyskuje się pewność, że plik zapisany na woluminie będzie można odczytać, gdy okaże się to konieczne.
Weryfikować, weryfikować i jeszcze raz weryfikować! W celu archiwizowania serwerów plików i baz danych stosowaliśmy komercyjne oprogramowanie. Pewnego dnia klient dysponujący wieloma milionami dolarów chciał odzyskać pliki, które zostały zarchiwizowane około półtora roku wcześniej. Znaleźliśmy taśmy i spróbowaliśmy przeprowadzić proces odtwarzania. Nic z tego. Spróbowaliśmy użyć innych taśm. Nic z tego. Został zwolniony administrator systemu i jego przełożony. Firma straciła klienta i została zaskarżona. Choć zasadnicza przyczyna nie została nigdy zidentyfikowana, pracownicy firmy na pewno nigdy nie podjęli próby zweryfikowania sporządzonych kopii zapasowych. — Eugene Lee
Koszt Choć aspekt cenowy oprogramowania archiwizującego jest zbyt złożony, aby go tu szczegółowo przedstawiać, wystarczy stwierdzić, że istnieje kilka elementów, które mogą mieć wpływ na całkowity koszt, zależnie od firmy sprzedającej produkt. Oto one: • liczba klientów, które mają być archiwizowane; • liczba napędów archiwizujących, które będą używane;
272
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
• typ napędów archiwizujących, które zamierza się stosować (bardzo szybkie urządzenia
często kosztują więcej); • liczba bibliotek, a także oferowanych przez nie napędów i gniazd; • wielkość komputerów (określana mocą procesorów); • wymagana szybkość procesu archiwizacji; • liczba posiadanych serwerów bazodanowych; • liczba zarządzanych baz danych różnego typu; • liczba innych klientów, które wymagają specjalnego traktowania (na przykład MVS, Back
Office), i nietypowych interfejsów; • typ oczekiwanej obsługi (24/7, 8/5 itp.).
Dostawca Jest mnóstwo ważnych informacji, które trzeba uzyskać na temat firmy, od której planuje się nabyć tak kluczowy produkt jak oprogramowanie archiwizujące. Od jakiego czasu firma oferuje rozwiązania archiwizacyjne? Jakiego rodzaju zasoby są przeznaczone na rozwój produktu? Jakiego typu obsługę produkt zapewnia? Czy firma jest otwarta na sugestie dotyczące swojego produktu? Należy poszukać co najmniej jednej organizacji wymienionej w referencjach i skontaktować się z jej pracownikami. Trzeba wiedzieć, że dla firm bardzo trudne jest uzyskanie referencji. Wielu klientów nie chce być podawanych w referencjach tylko z powodów politycznych i prawnych. Trzeba w tym przypadku być elastycznym. Nie należy oczekiwać, że sprzedawca przedstawi w referencjach organizację, która dysponuje środowiskiem identycznym jak nasze. Jeśli otrzyma się dane organizacji podanej w referencjach, trzeba postarać się nawiązać z nią kontakt. Sprzedawcy przede wszystkim uskarżają się na to, że usilnie starają się zdobyć referencje, a później klient nawet nie pofatyguje się, żeby do takiej organizacji zadzwonić.
Na etapie wybierania produktu archiwizującego również internet okaże się wspaniałym źródłem informacji. W archiwach Usenetu (http://www.google.com/groups) należy poszukać nazwy produktu. Należy znaleźć personalia osób, które dobrze i źle wypowiadają się na temat produktu, a następnie wysłać do nich wiadomość pocztową. Ponadto, korzystając z dostępnych wyszukiwarek internetowych, należy przeprowadzić ogólne poszukiwania. Naprawdę dobry produkt będzie miał referencje zamieszczone na stronach internetowych konsultantów. Z kolei naprawdę zły produkt może nawet spowodować, że powstaną witryny WWW o takich adresach, jak http://www.tenproduktarchiwizacyjnyjestdoniczego.com. Wszystko należy czytać z dystansem i mieć świadomość, że z każdym twórcą dowolnego produktu będzie związana jakaś grupa osób, które nie darzą go sympatią i wybierają inne oprogramowanie. Niektórzy klienci mieli do czynienia z trzema produktami archiwizującymi i szukają czwartego.
Dostawca
|
273
Końcowe wnioski Wybieranie komercyjnego narzędzia archiwizującego jest trudne. Trudniejsze jest jedynie napisanie takiego oprogramowania. Należy poświęcić odpowiednią ilość czasu, aby zrobić to dobrze. Podczas podejmowania decyzji należy śmiało korzystać z profesjonalnej pomocy, ponieważ ma się do czynienia z ciągle poruszającym się celem. Ponadto nie należy zbyt szybko odrzucać funkcji, które uzna się za zbędne. Dodam, że w pewnym momencie mogą okazać się potrzebne. Nigdy nie wiadomo, do jakich rozmiarów powiększy się zarządzane środowisko. Przykładowo moje pierwsze komercyjne oprogramowanie archiwizujące było skonfigurowane pod kątem obsługi około 20 komputerów przechowujących w sumie 200 GB danych. W ciągu dwóch lat liczba komputerów zwiększyła się do 250, a rozmiar danych — do kilku terabajtów. W tym czasie zastosowaliśmy kilka różnych typów systemów operacyjnych i baz danych. Po prostu nigdy nie wiadomo, jak duże lub jak bardzo złożone stanie się administrowane środowisko. Jeśli jednak zwyczajnie poszuka się rozwiązania archiwizacyjnego przeznaczonego dla niewielkiego środowiska i uzyska pewność, że nigdy nie zwiększy się znacząco, bez obaw będzie można zignorować pytania dotyczące funkcji dla bardzo dużych środowisk (jeżeli zarządza się małym środowiskiem, być może lepsze okaże się jedno z narzędzi open source przedstawionych wcześniej w książce). Życzę Czytelnikowi jak najlepszych wyników poszukiwania produktu spełniającego postawione wymagania. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
274
|
Rozdz ał 8. Komercyjne narzędz a arch w zujące
ROZDZIAŁ 9.
Urządzenia archiwizujące
Jak zdecydować, jakiego typu napęd archiwizujący kupić? Istnieją napędy duże i małe, szybkie i wolne, reagujące dynamicznie i powoli, a także napędy taśmowe, optyczne, dyskowe działające jak napędy dyskowe, dyskowe emulujące napędy i biblioteki taśmowe, a także docelowe magazyny dyskowe z funkcją deduplikacji danych. Decyzja taka zwykle jest prostsza do podjęcia, niż może się wydawać. Z pewnością jest łatwiejsza niż decyzja dotycząca zakupu produktu archiwizującego. Można wyróżnić tylko osiem krytycznych czynników mających wpływ na decyzję. W niniejszym rozdziale szczegółowo omówiono każdy z nich, a także zawarto informacje, które pomogą stwierdzić, który napęd archiwizujący będzie odpowiedni. Zaprezentowano też ofertę wybranych producentów, jednak tego typu informacje, ze względu na ich zmienną naturę, nie zostały przedstawione zbyt obszernie. W rozdziale zawarto też typowe pytania dotyczące sprzętu archiwizującego, a dokładniej: kompresji, gęstości, czyszczenia i korzystania z nośników. Mam nadzieję, że rozdział pozwoli Czytelnikowi uzyskać odpowiedzi na pytania związane z archiwizowaniem i pomoże w jak najlepszym wykorzystaniu sprzętu archiwizującego. Jak w przypadku innych partii książki, należy zwrócić uwagę na użycie w tym rozdziale terminu napęd archiwizujący. Z większym prawdopodobieństwem niż kiedykolwiek wcześniej może się okazać, że używany napęd archiwizujący nie jest taśmowy. Może to być napęd dyskowy działający jak napęd dyskowy z prawdziwego zdarzenia, jak napęd dyskowy emulujący napęd taśmowy lub bibliotekę taśmową bądź jak określonego typu napęd optyczny.
Czynniki decyzyjne Jak wspomniano, występuje tylko osiem czynników, które należy uwzględnić podczas podejmowania decyzji dotyczącej kupna napędu archiwizującego. Są to: niezawodność, cykl roboczy, prędkość transferu, elastyczność, czas dostępu do danych, pojemność, przenośność i cena. Trzeba rozważyć każdy z tych czynników i zdecydować, które są najważniejsze dla nas i danych. Przykładowo w przypadku środowiska z bazą danych o pojemności 6 TB najbardziej istotna może być niezawodność, na drugim miejscu znajdzie się pewnie prędkość transferu, a na końcu — koszt. Z kolei gdy zarządza się środowiskiem, w którym będzie wykorzystywany określonego typu system HSM, najpierw trzeba zadbać o niezawodność, następnie o czas dostępu do danych, a na końcu o prędkość transferu. Przyjrzyjmy się wszystkim tym czynnikom.
275
Niezawodność W każdym punkcie napraw urządzeń elektronicznych można usłyszeć, że ruchome części psują się. Jeśli mechanizm przeznaczony do naprawy liczy 25 układów scalonych i jeden element obrotowy, zawsze w pierwszej kolejności zostanie sprawdzony ten element. Zła wiadomość jest taka, że napędy archiwizujące, a zwłaszcza taśmowe, mają więcej ruchomych części niż jakikolwiek inny komponent sprzętowy komputera. Oznacza to, że statystycznie rzecz biorąc, w przypadku napędu archiwizującego szansa wystąpienia mechanicznej usterki jest znacznie większa niż szansa uszkodzenia procesora. Tanie taśmy mogą powodować utratę danych. W związku z tym nie należy takich kupować!
Regularnie psujące się napędy wpływają na dostępność systemu, ponieważ wymiana niektórych napędów wymaga uprzedniego wyłączenia komputera. Niestety, zwykle ma miejsce to, że na liście priorytetów wymiana uszkodzonych napędów znajduje się na bardzo odległej pozycji. Zepsuty napęd może oczekiwać na wymianę kilka dni, a nawet tygodni, niezależnie od tego, że zamienne urządzenie jest natychmiast dostępne (wynika to stąd, że czasami wymiana napędów wymaga wyłączenia komputera). A zatem jeśli napędy zbyt często się psują, może to mieć znaczący wpływ na ogólną integralność systemu archiwizującego. Chodzi o to, że napędy mogą psuć się tak często, że duża operacja archiwizowania lub odtwarzania nie miałaby do dyspozycji wystarczającej liczby napędów do tego, aby została zakończona w rozsądnym czasie. Właśnie z tego powodu niezawodność napędu jest tak ważna przy wyborze typu napędu archiwizującego. Producenci napędów posługują się parametrem MTBF (Mean-Time-Between-Failure), czyli średnim czasem międzyawaryjnym. Reprezentuje on poziom niezawodności napędów. Niestety, wartości parametru MTBF zwykle są wyznaczane w sztucznych środowiskach, które próbują symulować tysiące godzin eksploatacji (jak w inny sposób ustalić parametr MTBF o wartości 30 000 godzin, gdy napęd znajduje się na rynku dopiero od sześciu miesięcy? Przecież 30 000 godzin to niemal trzy i pół roku). Najlepszym źródłem informacji na temat niezawodności różnych napędów jest internet. Za pomocą kilku różnych wyszukiwarek należy poszukać dyskusji poświęconych interesującemu nas napędowi archiwizacyjnemu. Wyszukiwarka Google zdecydowanie się przyda. W jej archiwach należy poszukać różnych zwrotów, które mogą ułatwić lokalizację takich dyskusji (na przykład o napędzie DLT, LTO-4 lub T10000). Jeżeli nie znajdzie się żadnej dyskusji, należy wysłać wiadomość i poczekać na odpowiedź (najbardziej przydatna grupa dyskusyjna Usenet ma adres comp.arch.storage; czy Czytelnik pamięta, co to takiego Usenet?). Po znalezieniu grupy dyskusyjnej powinno się zrobić coś nie do pomyślenia, czyli… porozmawiać z innymi osobami. Przed zakupem nowego typu napędu archiwizującego warto skontaktować się z co najmniej pięcioma firmami, które z niego korzystają. Choć przenośność nośnika jest ważną cechą napędów taśmowych, wymaga od nich, aby były rozwiązaniami otwartymi. Kurz i inne zanieczyszczenia dostają się do napędu każdorazowo, gdy otworzy się pokrywę w celu wsunięcia lub wyjęcia taśmy. Poza tym zanieczyszczenia są zgubne dla każdego mechanizmu. Dla porównania: napędy dyskowe są zamkniętymi urządzeniami. Nośnik nigdy nie jest oddzielany od napędu. Do urządzenia nie ma prawa dostać się nawet powietrze. Jest to główny powód, dla którego napędy dyskowe są z założenia bardziej niezawodne od napędów taśmowych i coraz częściej wykorzystywane w roli napędów archiwizujących. 276
|
Rozdz ał 9. Urządzen a arch w zujące
Chwile zwątpienia Kilka razy ocaliła mnie metoda przywracania „na początku przekręć”. Mowa o sytuacji, gdy przytrafi się dysk twardy, który nie wydaje się właściwie obracać, i trzymając go w ręku, szybko przekręci się nadgarstkiem. W magiczny sposób dysk zaczyna się obracać z normalną prędkością i działa przez krótką chwilę. — Brian O’Neill
Kolejnym powodem większej niezawodności napędów dyskowych w porównaniu z taśmowymi jest to, że w przypadku tych pierwszych można zastosować technologię RAID w celu zmniejszenia ryzyka spowodowania poważnych szkód przez pojedynczy nośnik. Używając taśmowego lub optycznego napędu, wykonuje się kopię zapasową, a następnie umieszcza ją na półce, mając nadzieję, że nic się nie stanie w tym czasie z bitami danych. Tak naprawdę nigdy nie wiadomo, czy jakaś kopia jest dobra, dopóki nie użyje się jej do odtworzenia danych. W przypadku dysku chronionego przez technologię RAID cały czas można monitorować stan nośnika. Jeśli dowolny z napędów dyskowych zacznie zachowywać się podejrzanie (lub zupełnie się zepsuje), wystarczy go wymienić i nakazać macierzy RAID odtworzenie jego zawartości. Żadnych utraconych danych, żadnych uszkodzonych kopii zapasowych, a jedynie niewielki nakład pracy.
Cykl roboczy Porównując parametr MTBF dla różnych napędów, nie należy zapomnieć o sprawdzeniu cyklu roboczego, dla którego urządzenie zaprojektowano. Cykl roboczy napędu archiwizującego określa procentową wartość czasu, który urządzenie spędza na odczytywaniu, zapisywaniu i sprawdzaniu danych. Jeśli na przykład wybrany napęd działa przez sześć godzin dziennie, jego cykl roboczy wynosi 25%. Jeżeli urządzenie pracowałoby nieustannie, miałoby cykl roboczy równy 100%. Każdy napęd ma ustalony cykl roboczy. Przykładowo napędy dyskowe Fibre Channel i SCSI zwykle są projektowane pod kątem zastosowań wymagających cyklu roboczego wynoszącego 100%. Napędy dyskowe ATA cechują się krótszymi cyklami roboczymi. Właśnie z tego powodu napędy dyskowe Fibre Channel i SCSI często są obecne w zastosowaniach bazujących na dużej pojemności, takich jak serwery bazodanowe lub bardzo obciążone serwery plikowe. Napędy dyskowe ATA w przeszłości były używane w komputerach PC i laptopach, które mają znacznie mniejsze wymagania dotyczące napędów dyskowych. Nawet obecnie, gdy takie napędy są wykorzystywane w dużych macierzach magazynujących dane i wirtualnych bibliotekach taśmowych, tego typu systemy zwykle służą do składowania danych referencyjnych. Systemy obsługujące kopie zapasowe, archiwa i obrazy tworzą dane referencyjne. Choć codziennie sporządza się kopie zapasowe, przeciętna kopia jest rzadko używana lub wcale. To samo dotyczy prawdziwych systemów obsługujących archiwa i obrazy. Jeżeli na przykład firma tworzy obraz dla każdej umowy z klientem, każda umowa jest zapisywana raz i tylko sporadycznie używana (lub wcale). Napędy taśmowe też mają wyznaczony cykl roboczy. Napędy taśmowe serwerów przemysłowych zwykle są projektowane z uwzględnieniem 100-procentowego cyklu roboczego, natomiast urządzenia przeznaczone dla segmentów rynku systemów otwartych oferują krótsze
Czynn k decyzyjne
|
277
cykle robocze. Wynika to stąd, że serwery przemysłowe zazwyczaj używają swoich podsystemów taśmowych w roli dodatkowego systemu magazynowania, natomiast systemy otwarte zwykle stosują napędy taśmowe wyłącznie do archiwizowania danych. Serwery przemysłowe nieustannie odczytują z taśmy i zapisują na niej dane produkcyjne. A zatem ich napędy taśmowe muszą być przygotowane na ciągłą pracę. Biblioteki taśmowe serwerów przemysłowych są oceniane liczbą operacji wymiany, które są w stanie przeprowadzić w ciągu godziny. Dla porównania: większość aplikacji archiwizujących otwartych systemów używa ich napędów taśmowych przez mniej niż połowę dnia. Właśnie z tego powodu napędy taśmowe zaprojektowane dla tego typu systemów zwykle mają znacznie krótsze cykle robocze. Ważne jest, aby nabyć napęd taśmowy z cyklem roboczym dopasowanym do używanej aplikacji. W przeciwnym razie znacząco może wzrosnąć koszt lub zmniejszyć się niezawodność napędu archiwizującego. Jeśli kupi się napęd z 40-procentowym cyklem i będzie się go cały czas używać, można jedynie oczekiwać, że urządzenie zepsuje się znacznie szybciej, niż wskazuje na to wartość parametru MTBF. Jeżeli dysponuje się aplikacją wymagającą 40-procentowego cyklu roboczego i nabędzie się napęd przewidziany dla 100-procentowego cyklu, należy mieć świadomość, że wyda się trzy razy więcej w zamian za taką samą prędkość i pojemność (czasami parametry te będą nawet gorsze)! Producent napędu ze 100-procentowym cyklem może twierdzić, że jest bardziej niezawodny, co jest prawdą. Jeśli taki napęd zostanie wykorzystany w środowisku wymagającym 100-procentowego cyklu roboczego, będzie bardziej niezawodny od urządzenia mającego 40-procentowy cykl i użytego w tym samym środowisku. Jednak napęd taśmowy przewidziany dla 40-procentowego cyklu roboczego i zastosowany w środowisku wymagającym 40-procentowego cyklu (na przykład do tworzenia tradycyjnych kopii zapasowych) powinien być dokładnie tak samo niezawodny jak napęd ze 100-procentowym cyklem.
Prędkość transferu Prędkość transferu jest kolejną bardzo istotną kwestią podczas wybierania napędu archiwizującego. Jak szybko napęd może odczytywać i zapisywać dane? Oczywiście, analizując różne napędy, trzeba porównać ich własne prędkości transferu, czyli prędkości bez zastosowanej kompresji. Często trudno to zrobić, ponieważ wiele napędów podaje jedynie prędkość z kompresją. Zwykle producent napędu umieszcza obok prędkości notkę, która mówi coś takiego: „Dla wartości przyjęto współczynnik kompresji 2:1. Rzeczywista prędkość transferu zmienia się zależnie od stopnia kompresji danych”. Powodem tego jest to, że producenci ustalają różne współczynniki kompresji. Niektórzy producenci uznali za typowy współczynnik kompresji 5:1. Choć prawdą jest, że różne algorytmy kompresji dają odmienne wyniki, bardzo trudno zweryfikować, czy producent słusznie podał wyższą kompresję. Aby mieć pewność, że wartości są porównywalne, zawsze należy posługiwać się własnymi prędkościami transferu. Część producentów nie używa terminu własna prędkość transferu. Mogą oni stosować określenie prędkość transferu między głowicą i taśmą, które wskazuje, jak szybko głowica zapisująca może zapisywać dane na taśmie. Prędkość ta nie zmienia się wraz z kompresją. Jeśli dane zostaną skompresowane przed wysłaniem do głowicy zapisującej, wzrośnie rzeczywista przepustowość napędu, lecz prędkość transferu między głowicą i taśmą nie zmieni się. Przyglądając się specyfikacji napędu, należy spróbować odszukać słowo sustained (średnia). Średnie prędkości transferu pozwalają przeprowadzać najbardziej wiarygodne porównania napędów. Niektóre napędy podają maksymalne i synchroniczne prędkości, które są osiągane
278
|
Rozdz ał 9. Urządzen a arch w zujące
tylko sporadycznie (zależnie od konkretnego zastosowania można zdecydować się również na porównywanie tych dwóch prędkości transferu; jednak trzeba mieć pewność, że się wie, co się robi). Należy pamiętać, aby wszystko wyrażać w tych samych jednostkach. Niektóre napędy podają wartości w gigabajtach lub megabajtach na godzinę. Aby megabajty na godzinę zamienić na megabajty na sekundę, wystarczy podzielić wartość przez 3600, czyli liczbę sekund w godzinie. Jeśli są to gigabajty na godzinę, megabajty na sekundę otrzyma się po podzieleniu wartości przez 3 686 400 (3600*1024).
Elastyczność Napęd archiwizujący może być elastyczny na dwa sposoby — może dobrze obsługiwać różne prędkości transferu i może służyć do różnych celów. Generalnie rzecz biorąc, napędy taśmowe i optyczne nie są zbyt elastyczne, natomiast napędy dyskowe są dość elastyczne. Zajmijmy się tym dokładniej.
Napędy taśmowe — niezbyt elastyczne Napędy taśmowe zwykle nie reagują dobrze na różne prędkości przesyłu i mogą być używane tylko do jednego celu. Zazwyczaj na jeden serwer archiwizujący trzeba będzie przeznaczyć co najmniej jeden napęd taśmowy. Do napędów taśmowych dane muszą być dostarczane strumieniowo. Oznacza to, że aby dobrze działać w sposób ciągły, zwykle muszą otrzymywać strumień danych z szybkością bliską maksymalnej przepustowości urządzenia. Jeśli strumień danych będzie przesyłany wolniej, napędy taśmowe mogą zapisywać z prędkością mniejszą niż prędkość wejściowego strumienia danych, a także częściej się psuć. Bardziej szczegółowo zagadnienie to omówiono w dalszej części rozdziału, w podrozdziale „Napędy taśmowe”. Choć może to zabrzmieć niemądrze, napędy taśmowe naprawdę potrafią wykonywać tylko dwie rzeczy: sekwencyjnie zapisywać i odczytywać dane. Oznacza to, że mogą być użyte tylko w przypadku aplikacji, które wiedzą, jak odczytywać dane z napędów taśmowych i zapisywać je na nich. Inaczej mówiąc, są to aplikacje tworzące kopie zapasowe i archiwa. Ponadto, jeśli zadań archiwizacyjnych jest pięć, potrzebnych będzie pięć napędów taśmowych. Owszem, wiele komercyjnych produktów archiwizujących zadania przesłane do jednego serwera archiwizującego może przeplatać na pojedynczym napędzie. Jednak nie będzie to możliwe, gdy zadania zostaną przekazane wielu serwerom archiwizującym. Wiele tego typu serwerów często potrafi współużytkować napędy, pod warunkiem że są „pewne” tego, iż w jednym czasie dwa serwery nie będą chciały zapisać danych na tym samym napędzie. Jednakże serwery archiwizujące nie są w stanie jednocześnie odczytywać i zapisywać danych na tym samym napędzie taśmowym.
Napędy optyczne — trochę bardziej elastyczne Napędy optyczne są bardziej elastyczne od napędów taśmowych, lecz nie w takim stopniu jak napędy dyskowe. Z łatwością radzą sobie z danymi wejściowymi dostarczanymi z różną prędkością. Jednak podobnie do napędów taśmowych napędy optyczne mają skłonność do jednozadaniowości.
Czynn k decyzyjne
|
279
Napędy optyczne są urządzeniami o dostępie losowym, co oznacza, że nie dotyczą ich problemy napędów taśmowych związane ze strumieniowym dostarczaniem danych. Ogólnie rzecz biorąc, napędy optyczne potrafią obsługiwać dowolne prędkości przesyłu danych, które nie przekraczają ich własnej przepustowości. W czasie pisania książki żaden napęd optyczny nie oferował kompresji sprzętowej. W związku z tym własna przepustowość jest równa efektywnej przepustowości napędów optycznych. Ponieważ napędy optyczne zachowują się bardziej jak napędy dyskowe niż taśmowe, zwykle mogą być podłączane jako system plików. Oznacza to, że w tym przypadku nie występuje problem z jednozadaniowością charakterystyczny dla napędów taśmowych. Wiele aplikacji może jednocześnie odczytywać i zapisywać dane na tym samym napędzie optycznym, tak jak ma to miejsce w przypadku dowolnego podłączonego systemu plików. Korzystając z ogólnego oprogramowania obsługującego systemy plików, można również umożliwić wielu serwerom jednoczesne odczytywanie i zapisywanie danych na napędzie optycznym. Można sprawić, że napędy optyczne będą równie elastyczne, co dyskowe. Przykładowo ktoś może napisać sterowniki, które spowodują, że napęd optyczny będzie przypominał taśmowy. Gdy była pisana ta książka, nikt tego jeszcze nie zrobił.
Napędy dyskowe — bardzo elastyczne Napędy dyskowe naprawdę zwyciężają w kategorii elastyczności. Mogą przyjąć dane przesyłane z dowolną prędkością, nawet przekraczającą ich własną przepustowość (gdy stosuje się technologię RAID). Napędy te potrafią emulować niemal każdy typ urządzenia archiwizującego, a także dowolną liczbę tych urządzeń. Oprócz możliwości obsługi wolniejszych transferów danych napędy dyskowe mogą być paskowane w ramach macierzy RAID, tak aby radziły sobie z bardzo wysokimi prędkościami przesyłu danych wejściowych. Zależnie od potrzeb pojedyncza macierz RAID może w ciągu sekundy obsłużyć zarówno setki megabajtów, jak też transfer danych z prędkością 1 kb/s. Dzięki sterownikom wirtualizacji dyski mogą też emulować inne rzeczy. Macierz RAID to w rzeczywistości kilka dysków emulujących jeden duży. Oprogramowanie wirtualnych taśm umożliwia dyskom emulowanie napędów taśmowych. Oprogramowanie takie powoduje, że użytkownik widzi macierz dyskową, a serwer archiwizujący — napęd lub bibliotekę taśmową. Rozwiązanie to nosi nazwę wirtualnej biblioteki taśmowej. Napędy dyskowe mogą emulować mnóstwo napędów taśmowych. Oprogramowanie wirtualnych taśm umożliwia pojedynczej macierzy dyskowej emulowanie dowolnej liczby napędów lub bibliotek taśmowych. Dzięki temu kilka serwerów z łatwością może współużytkować ten sam zasób bez potrzeby stosowania czegoś takiego, jak ogólne oprogramowanie obsługujące systemy plików. W przeciwieństwie do prawdziwych napędów taśmowych, wystarczy wcisnąć przycisk, aby uzyskać kolejne wirtualne napędy taśmowe. Ciekawostka związana z elastycznością napędów dyskowych: jeśli używane oprogramowanie archiwizujące obsługuje multipleksowanie i zastosuje się je podczas archiwizowania danych na wirtualnym napędzie taśmowym, napęd pozwoli zmniejszyć efekty uboczne multipleksowania dzięki znacznie szybszemu działaniu w porównaniu z normalnym napędem taśmowym.
280 |
Rozdz ał 9. Urządzen a arch w zujące
Zwykle multipleksowanie nie będzie wymagane w przypadku wirtualnego napędu taśmowego. Powodem używania multipleksowania dla napędu taśmowego było to, że wymagał strumieniowego dostarczania danych. Nie jest to konieczne, gdy korzysta się z wirtualnego napędu taśmowego. Jednakże w przypadku niektórych wirtualnych bibliotek taśmowych i pakietów oprogramowania archiwizującego występują problemy z licencjami, które mogą uzasadnić zastosowanie multipleksowania. Celem tej uwagi jest podkreślenie tego, że jeśli dla wirtualnej taśmy użyje się multipleksowania, może ono nie mieć takiego wpływu na wydajność procesu odtwarzania jak w przypadku fizycznego napędu taśmowego.
Załóżmy, że oprogramowanie archiwizujące wykonało multipleksowanie kilku kopii zapasowych na jednej taśmie i użytkownik żąda odtworzenia zawartości tylko jednej z tych kopii. W takiej sytuacji oprogramowanie odczytuje wszystkie zmultipleksowane kopie zapasowe, a następnie wszystkie niepotrzebne dane umieszcza w odpowiednim koszu. Jeśli napęd taśmowy może działać tylko z prędkością 50 MB/s, oznacza to, że znaczna część tej przepustowości (75% przy multipleksowaniu o wartości 4) jest przeznaczana na odczytywanie odrzucanych danych. Co by jednak było, gdyby dysponowano „napędem taśmowym”, który mógłby odczytywać dane z prędkością 150 MB/s? Jeżeli odrzucono by 75% tej przepustowości, w dalszym ciągu dostępne byłoby 37,5 MB/s, czyli dość przyzwoita prędkość transferu. Prawdą jest, że interfejs wirtualnego napędu taśmowego jest po prostu interfejsem napędu dyskowego. Ostatecznie dane nadal znajdują się na dysku, co stwarza kilka możliwości, bardziej szczegółowo omówionych w dalszej części rozdziału. Spośród nich należy wymienić deduplikację, replikację, rozpoznawanie zawartości i wtórną prezentację.
Czas dostępu do danych Prędkość transferu nie zawsze jest najważniejszym czynnikiem decyzyjnym (to coraz częściej jedna z ostatnich rzeczy, które biorę pod uwagę). Oczywiście dysponując szybszym napędem, łatwiej można archiwizować i odtwarzać duże ilości danych. Jednak wiele żądań odtworzenia dotyczy jednego pliku lub niewielkiej grupy plików. Zależnie od zarządzanego środowiska może to stanowić 99% wszystkich operacji odtwarzania. Ponadto wiele dużych procesów odtwarzania wymaga załadowania od kilku do kilku tysięcy taśm (wiem o jednym takim procesie, podczas którego załadowano 20 000 taśm). To, co najbardziej liczy się w przypadku takich operacji, to czas dostępu do danych. Ile czasu zajmie załadowanie woluminu, zlokalizowanie jego odpowiedniego fragmentu i rozpoczęcie odczytywania danych? Strumieniowe napędy taśmowe zwykle wolniej reagują, dlatego mają znacznie dłuższy czas dostępu do danych. Zwycięzcami w kategorii czasu dostępu do danych swego czasu były napędy optyczne. W przypadku tego typu napędów najgorszy czas dostępu do danych zwykle wynosi około 12 sekund, z uwzględnieniem pięciu sekund na automatyczną zmianę nośnika. Jeśli odtwarzany plik znajduje się na już załadowanym nośniku, czas dostępu do danych nie przekracza sekundy. Jednak obecnie nowym triumfatorem w tej kategorii jest napęd dyskowy. Trudno pobić urządzenie mające czasy dostępu wyrażane w nanosekundach, nawet wtedy, gdy napęd dyskowy emuluje napęd taśmowy. Ile czasu zajmie przewinięcie, wyciągnięcie lub załadowanie wirtualnej taśmy? Ze względu na sposób funkcjonowania systemy HSM zwracają największą uwagę na czas dostępu do danych. Nieużywany plik jest automatycznie przenoszony z dysku na tańszy nośnik danych. Użytkownik nie wie, że coś takiego ma miejsce, i ostatecznie może spróbować skorzystać z pliku. System HSM stwierdzi, że plik jest potrzebny, i automatycznie pobierze
Czynn k decyzyjne
|
281
go z nośnika archiwizacyjnego. Użytkownik zauważy jedynie opóźnienie w dostępie do pliku. Jeżeli opóźnienie wyniesie 12 sekund lub mniej, użytkownik może nawet niczego nie zauważyć. Załóżmy jednak, że plik umieszczono na napędzie taśmowym, którego czas dostępu do danych wynosi dwie minuty. Typowy użytkownik w tym czasie zadzwoni do działu pomocy technicznej lub ponownie uruchomi komputer. Właśnie z tego powodu systemy HSM powinny stosować napęd optyczny lub jeden z nowszych napędów taśmowych, które zaprojektowano z myślą o zapewnieniu bardzo krótkich czasów dostępu do danych. W środowiskach z systemem HSM obsługującym wyjątkowo duże pojemności istotne jest też to, ile czasu zajmuje przewijanie i wyciąganie woluminu. Gdy czas dostępu do danych zsumuje się z czasem transferu danych, a także czasem przewijania i wyciągania woluminu, uzyska się coś, co określa się mianem czasu cyklu. Jeśli czas cyklu dla konkretnego napędu taśmowego wynosi dwie minuty, system HSM w ciągu godziny dla jednego napędu może obsłużyć 30 żądań dotyczących przeniesienia pliku. 8-napędowa automatyczna zmieniarka byłaby w stanie zwiększyć do 240 liczbę plików przenoszonych w ciągu godziny. Dla porównania: przeciętny nośnik optyczny ma czas cyklu nieprzekraczający 30 sekund. Oznacza to, że 8-napędowa automatyczna zmieniarka używająca takich nośników może w ciągu godziny obsłużyć maksymalnie 1000 żądań migracji pliku. Z dużą rozwagą należy oceniać ważność czasu dostępu do danych w przypadku środowiska, którym się zarządza.
Pojemność Dawniej pojemność była najważniejszą kwestią podczas wybierania napędu archiwizującego. Nadal tak jest w przypadku wielu środowisk pozbawionych automatyzacji. Jeśli pełna kopia zapasowa całego komputera może zmieścić się na jednym woluminie, nie trzeba się martwić wymianą woluminów w środku nocy. Jednak stosując automatyczną zmieniarkę, można w znacznym stopniu zmniejszyć znaczenie pojemności woluminu. W rzeczywistości przez zapisanie danych na wielu mniejszych woluminach można przyspieszyć proces odtwarzania przeprowadzany za pomocą dostępnego obecnie oprogramowania archiwizującego. Z kolei używanie napędu o niewystarczającej pojemności ma wpływ na ogólną prędkość transferu. Załóżmy, że archiwizowane dane zapisuje się na woluminie 100 GB z prędkością transferu wynoszącą 100 MB/s i czasem cyklu równym cztery minuty. Z taką prędkością cały wolumin można zapełnić w czasie nieznacznie przekraczającym 16 minut. Konieczna byłaby wymiana woluminów, która zajęłaby cztery minuty. Oznacza to, że zarchiwizowanie 100 GB danych zajęłoby 20 minut. Ogólna efektywna przepustowość spadłaby zatem ze 100 MB/s do 80 MB/s. Przyjmijmy, że w automatycznej zmieniarce byłby zestaw ośmiu takich napędów. Dla 8-godzinnego okresu ogólna przepustowość spadłaby z 29 TB do 23 TB, co daje różnicę wynoszącą 6 TB. Jeśli jednak wolumin miałby pojemność 500 GB, tracona przepustowość transferu danych spadłaby do około 1 TB ze względu na mniejszą liczbę operacji wymiany woluminów. Trzeba też pamiętać, że większa pojemność zwykle oznacza dłuższy czas dostępu do danych, zwłaszcza w przypadku napędów taśmowych (oczywiście więcej czasu zajmie osiągnięcie środka taśmy liczącej 660 niż 330 metrów). Choć niektóre napędy taśmowe redukują czas dostępu przez podłączanie punktu środkowego, to nawet jeśli rozpocznie się w środku taśmy, nadal do końca taśmy jest daleka droga. Następną kwestią związaną z pojemnością, którą należy rozważyć, jest przeznaczenie napędu. Czy planuje się używać oprogramowania archiwizującego, które w sposób ciągły zapisuje dane na każdym woluminie do momentu jego zapełnienia, czy może zamierza się utworzyć 282
|
Rozdz ał 9. Urządzen a arch w zujące
wiele małych kopii zapasowych na pojedynczym woluminie? Załóżmy, że regularnie na taśmę eksportuje się zawartość bazy danych, a następnie przekazuje ją partnerowi, który importuje dane do swojej bazy. Czy naprawdę potrzeba taśmy 400 GB, aby wyeksportować bazę danych o pojemności 500 MB? Każda operacja eksportowania będzie wymagać kosztownej taśmy 400 GB. Ekonomicznie najbardziej efektywnym rozwiązaniem byłoby użycie w tym celu tańszej i mniej pojemnej taśmy lub nośnika optycznego.
Przenośność Odkąd pojawiły się wirtualne taśmy, trzeba brać je pod uwagę. Oczywiście napędy taśmowe i optyczne są przenośne, co jest uważane za jedną z ich głównych zalet. W czasie pisania tej książki zaczęły być również dostępne przenośne kasety wirtualnych taśm. Jednak dla większości kaset wirtualnych taśm i dysków nie są oferowane wymienne nośniki. Wielu klientów zaczyna pytać, czy w ich przypadku nadal istotna jest możliwość przenoszenia. Powód, dla którego większość osób wymaga przenośności, jest taki, że chcą mieć możliwość przesyłania swoich taśm do zewnętrznego dostawcy usług magazynowania. Co będzie, jeśli można to osiągnąć bez przemieszczania taśmy w inne miejsce? Czy w dalszym ciągu nośnik musi być wymienialny? Pytanie takie należy sobie zadać podczas analizowania funkcji replikacji docelowych magazynów dyskowych, omówionych w dalszej części rozdziału.
Koszt Bardziej niezawodne i elastyczne napędy zapisujące więcej danych z większą prędkością i oferujące krótszy czas dostępu do danych zwykle kosztują więcej. Atrakcyjną cenę za niezawodny i szybki napęd będzie można uzyskać jedynie wtedy, gdy jego producent próbuje zaistnieć na rynku zdominowanym przez inną firmę. Oczywiście w takim przypadku ryzykuje się tym, że napęd nie utrzyma się na rynku (przez lata było kilku takich przegranych wojowników). Następnym czynnikiem cenowym, który należy uwzględnić, jest możliwość wielokrotnego użycia nośnika. Istnieje kilka technologii WORM (write-once-read-many), które nie pozwalają na ponowne zapisanie nośnika. Tego typu nośniki mają konkretne przeznaczenie, takie jak tworzenie ładowalnych dysków CD lub archiwów bez możliwości modyfikowania. Niezależnie od tego podczas określania całkowitego kosztu eksploatacji powinno się wziąć pod uwagę to, czy nośnik można wielokrotnie wykorzystywać. Kolejną rzeczą, którą powinno się rozważyć, jest koszt związany z zarządzaniem systemem archiwizującym. Jeśli używa się napędów taśmowych, trzeba przeprowadzić znacznie więcej działań mających związek z projektowaniem i administrowaniem systemem, aby zapewnić, że będzie zapisywał dane na taśmie w sposób optymalnie wykorzystujący napędy taśmowe. Jeżeli stosuje się napęd dyskowy, takie działania są prawie nieobecne, dzięki czemu w znaczącym stopniu redukuje się całkowity koszt eksploatacji. Podczas porównywania kosztu różnych typów nośników danych trzeba rozpatrzyć wszystkie czynniki cenowe. Szczególnie jest to istotne w przypadku analizowania kosztu lokalnego systemu magazynowania, ponieważ prawdopodobnie nie będzie to niezależny napęd taśmowy. Najprawdopodobniej zastosuje się bibliotekę taśmową lub optyczną bądź określonego typu urządzenie dyskowe. Nie wolno popełnić błędu polegającego na porównywaniu wyłącznie ceny nośnika. Taśma zawsze będzie górą. Trzeba pamiętać, że gdy chodzi o lokalny system
Czynn k decyzyjne
| 283
magazynowania, nośnik stanie się bezużyteczny bez obsługującej go biblioteki taśmowej lub optycznej. Najpierw należy stwierdzić, jaka pojemność magazynowania będzie wymagana. W tym celu należy określić liczbę pełnych i przyrostowych kopii zapasowych, które będą przechowywane przez lokalny system. Załóżmy, że okazało się, iż potrzebny jest lokalny system magazynowania o pojemności 200 TB. W dalszej kolejności należy porównać koszt kompletnej biblioteki taśmowej 200 TB, kompletnej biblioteki optycznej 200 TB i systemu dyskowego o identycznej pojemności. Kompletna biblioteka taśmowa lub optyczna zawiera wszystkie wymagane napędy taśmowe lub optyczne, gniazda i liczbę taśm lub dysków wystarczającą do wypełnienia gniazd. Z kolei kompletny system dyskowy jest wyposażony we wszystkie potrzebne dyski, a także w oprogramowanie lub sprzęt obsługujące macierz RAID lub wirtualizację, niezbędne do zapewnienia działania systemu zgodnie z oczekiwaniami użytkownika (oczywiście pod uwagę trzeba wziąć różnice między systemem dyskowym i taśmowym dotyczące zasilania). Porównując takie rzeczy, można być zaskoczonym wartościami, zwłaszcza wtedy, gdy uwzględni się funkcje deduplikacji danych systemów dyskowych.
Podsumowanie Choć kilka napędów można zaliczyć do kategorii „jeszcze im trochę brakuje”, większość urządzeń znakomicie spełnia jedno lub więcej z ośmiu wymienionych istotnych kryteriów. W przeszłości „specjalnością” napędów taśmowych było optymalizowanie kosztu archiwizowania danych. Jednak funkcja deduplikacji systemów dyskowych zmienia to. Różne napędy taśmowe są lepsze od innych pod względem czasu dostępu do danych, prędkości transferu i elastyczności. Oczywiście nośnik optyczny zapewnia krótszy czas dostępu do danych, lecz w porównaniu z nośnikiem taśmowym oferuje zdecydowanie mniejszą pojemność przy wyższej cenie. Napędy dyskowe mogą być droższe od napędów taśmowych lub optycznych. Napędy dyskowe wiodą prym w przypadku każdego innego czynnika decyzyjnego. Podejmując decyzję, trzeba samemu stwierdzić, które czynniki są najważniejsze.
Zastosowanie sprzętu archiwizującego Ludzie zadają różne pytania dotyczące użycia sprzętu archiwizującego. Mam nadzieję, że niniejszy podrozdział ułatwi znalezienie odpowiedzi na kilka najczęstszych.
Kompresja W celu zaoszczędzenia miejsca dane przed zapisaniem na napędzie mogą być skompresowane. Można wyróżnić dwie metody kompresji: programową i sprzętową. Kompresja programowa polega na kompresowaniu przez oprogramowanie danych przed wysłaniem ich do napędu. Gdy korzysta się z kompresji sprzętowej, dane bez kompresji są przekazywane do napędu, po czym specjalizowany układ urządzenia dokonuje kompresji. Rysunek 9.1 próbuje zilustrować ścieżki pokonywane w przypadku tych dwóch różnych typów kompresji. Oczywiście kompresja programowa wymaga większego obciążenia procesora hosta niż kompresja sprzętowa. Z użyciem procesora zwykle wiąże się jedna zaleta, mianowicie zmniejsza się liczba danych transferowanych w sieci. Z kolei kompresja sprzętowa wszystko przyspiesza. Specjalizowany układ może kompresować dane z prędkością liniową. Ponieważ kompresja ta zmniejsza ilość danych zapisywanych na taśmie i robi to z prędkością liniową, w rzeczywistości 284 |
Rozdz ał 9. Urządzen a arch w zujące
Rysunek 9.1. Ścieżki danych w przypadku kompresji programowej i sprzętowej
zwiększa przepustowość napędu. A zatem jeśli dysponuje się napędem taśmowym zapisującym dane z prędkością 120 MB/s i dostarczane dane mogą być skompresowane w stosunku 2:1, napęd może przyjmować dane z prędkością 240 MB/s. Napęd kompresuje strumień danych wejściowych pobieranych z szybkością 240 MB/s i generuje dane wyjściowe o rozmiarze o połowę mniejszym, zapisując je na taśmie. Jeśli dane wejściowe można skompresować w stosunku 3:1, napęd będzie w stanie odbierać je z prędkością 360 MB/s i generować trzykrotnie mniejsze dane wynikowe przeznaczone do zapisu na taśmie. Osiągany poziom kompresji w dużej mierze zależy od współczynnika kompresji danych. Określonego typu dane kompresują się lepiej od innych. Przykładowo dane tekstowe kompresują się bardzo dobrze. Niektóre typy formatów obrazów (np. TIFF) są już skompresowane i nie mogą być dodatkowo kompresowane. Jeżeli archiwizuje się system plików zawierający jedynie pliki TIFF, prawdopodobnie nie uzyska się prędkości większej niż własna prędkość napędu. Jeśli jednak tworzy się kopię zapasową systemu plików składającego się wyłącznie z plików dzienników, można osiągnąć prędkości transferu, które znacznie przekraczają podawane prędkości napędu (większość tych wartości określa się przy założeniu współczynnika kompresji 2:1).
Porównanie gęstości i kompresji Gęstość i kompresja często są ze sobą mylone. Jak wspomniałem, kompresja sprzętowa używa algorytmów kompresujących dane przed wysłaniem ich do głowicy zapisującej. Sposób zapisywania danych przez głowicę napędu właściwie się nie zmienia. Z kolei gęstość określa, jak gęsto dane są fizycznie zapisywane na taśmie. Gęstość jest wyrażana w bitach na cal (b/cal). Gęstość zapisu decyduje o tym, że nowsze generacje napędów taśmowych osiągają wyższą przepustowość i pojemność, nawet w przypadku tej samej taśmy. Jeśli napęd obraca taśmę z taką samą prędkością, lecz dodatkowo umieszcza na niej bity w bardziej zwarty sposób, może szybciej zapisywać dane i zmieścić ich więcej na nośniku.
Jak często powinno się wymieniać nośnik? Trwałość nośnika jest określana przez producentów liczbą przejść. Za przejście uważa się minięcie nośnika przez głowicę zapisującą. Ma to miejsce każdorazowo podczas odczytywania lub zapisywania danych na taśmie, a także wtedy, gdy taśma podlega retencji. Większość producentów nośników danych podaje, że konkretny nośnik może wytrzymać kilka tysięcy przejść. Jeśli do napędu taśmowego dostarczano by optymalny strumień danych i raz w tygodniu wykonywano po jednej operacji archiwizacji i odtwarzania, osiągnięcie 2000 przejść zajęłoby prawie 20 lat. Ważne jest, aby zdać sobie sprawę z ważności roli, jaką w tym przypadku odgrywa zjawisko pucowania (ang. shoe-shining). Jeżeli napęd taśmowy wykonuje taką czynność, Zastosowan e sprzętu arch w zującego
| 285
każdorazowe przesunięcie fragmentu taśmy pod głowicą do przodu i do tyłu jest traktowane jak przejście. A zatem jeśli napęd często „pucuje”, jedna archiwizacja może spowodować 20 przejść dla każdej sekcji nośnika, zmniejszając jego trwałość z 20 lat do roku. To, ile razy ponownie wykorzysta się nośnik, powinno być zależne od zarządzanego środowiska. Nie byłoby to zbyt w porządku, gdybym zalecał wyrzucenie nośnika zaledwie po kilku użyciach. Również nie mógłbym namawiać do tego, aby nośnika w ogóle nie wymieniać. Jestem przekonany, że w przypadku wymieniania nośników powinno się zastosować metodę „poczekania i podjęcia następnie decyzji”. Regularnie należy testować operacje archiwizacji i odtwarzania dla posiadanych nośników. Dla losowo wybranych woluminów należy podjąć próbę odtworzenia z nich plików. Wolumin należy wymienić od razu, gdy wykazuje najmniejsze oznaki problemów. Jeśli zauważy się, że cała partia taśm jest wyjątkowo zła, być może powinno się przeprowadzić więcej testów, aby stwierdzić, czy problem się rozszerza. Jeżeli przegląda się dzienniki archiwizacji, sporadycznie można napotkać błędy operacji wejścia-wyjścia wygenerowane podczas zapisu danych na określonej taśmie. Taka taśma też powinna zostać wymieniona.
Uważne korzystanie z kaset Obecnie dostępne nośniki archiwizacyjne są znacznie bardziej wytrzymałe niż dawniej (pamiętam, jak przypadkowo upuściłem na podłogę 9-ścieżkową taśmę i obserwowałem, jak rozwija się na sporej powierzchni). Jednak w dalszym ciągu trzeba traktować nośniki z troską. Taśmy powinny tak być przechowywane, żeby rowek był u góry, a osie szpuli równolegle do ziemi (jeśli byłaby to kaseta magnetofonowa i ołówek umieszczono by w otworze szpuli naciągającej, zamiast pionu ołówek wskazywałby poziom; czy Czytelnik wie, czym jest kaseta magnetofonowa?). W ten sposób zapobiega się owijaniu taśmy wokół szpuli spowodowanemu działaniem siły grawitacji. Jeśli przypadkowo upuści się taśmę, należy ją podnieść i wstrząsnąć nią. Jeżeli usłyszy się szelest, taśmę należy wyrzucić. Wewnątrz kasety znajdują się delikatne mechanizmy umożliwiające wyciąganie taśmy. Upuszczenie taśmy może spowodować wyskoczenie z podstawy jednej ze sprężyn. Jeśli następnie taśmę umieści się w napędzie, zostanie ona rozwinięta, lecz nie będzie możliwe jej wciągnięcie. W takiej sytuacji jedynym rozwiązaniem będzie demontaż napędu.
Troszczenie się o napęd Napęd należy czyścić zgodnie z zaleceniami producenta. Tak wiele problemów można uniknąć dzięki temu prostemu zabiegowi konserwacyjnemu! Należy przeczytać instrukcję obsługi dołączoną do konkretnego modelu napędu i postępować zgodnie z podanymi w niej wytycznymi. Cóż jeszcze mogę dodać? Trzeba również pamiętać o tym, że w przypadku konieczności naprawy urządzenia kontakt z wieloma producentami staje się wyjątkowo mało przyjemny, jeśli idealnie nie przestrzegano harmonogramu konserwacji sprzętu. Warto zauważyć, że niektórzy producenci napędów chcą, żeby je czyścić tylko wtedy, gdy tego wymagają. Tego typu napędy są projektowane z myślą o automatycznym czyszczeniu i mogą zostać zanieczyszczone tylko w przypadku niekorzystnych okoliczności. Napędy takie powiadamiają użytkownika, gdy muszą zostać wyczyszczone. Czyszczenie ich częściej, niż jest to wymagane, może skrócić ich trwałość.
286
|
Rozdz ał 9. Urządzen a arch w zujące
Prawie lokalne i zewnętrzne magazynowanie danych Dwa terminy, z którymi można się spotkać podczas podejmowania decyzji dotyczącej zakupu sprzętu archiwizującego, to prawie lokalne (ang. nearline) i zewnętrzne magazynowanie. Drugi termin przychodzi zwykle na myśl, gdy rozważa się tworzenie kopii zapasowych. Zewnętrzną kopią zapasową nazywa się drugą kopię danych lokalnych. Kopia taka nie ma pełnić roli podstawowej kopii danych, jeśli oczywiście nie trzeba jej użyć do odtwarzania danych. Prawie lokalna kopia zapasowa jest zupełnie czymś innym. „Prawie lokalna” wskazuje, że plik jest bliski statusu bycia lokalnym. Oznacza to, że taki plik jest przechowywany w zautomatyzowanej bibliotece na tańszym nośniku archiwizującym. Choć uzyskanie dostępu do danych może zająć kilka sekund, a nawet minutę, operacja może być przeprowadzona automatycznie. System HSM wymaga niemal lokalnego magazynowania danych.
Napędy taśmowe W niniejszym podrozdziale zamieszczono kilka pomocnych informacji na temat napędów taśmowych.
Do napędów taśmowych musi być dostarczany stały strumień danych Nowsze napędy taśmowe zwykle nie reagują dobrze na różne prędkości transferu danych. Oznacza to, że jeśli napęd zaprojektowano tak, aby odczytywał lub zapisywał dane z prędkością 120 MB/s, zazwyczaj będzie dobrze działać tylko wtedy, gdy operacja odczytu lub zapisu będzie wykonywana właśnie z taką prędkością (jest kilka wyjątków, które omówiono w dalszej części rozdziału, w punkcie „Napędy taśmowe obsługujące zmienne prędkości”). Obecnie większość napędów taśmowych potrafi właściwie zapisywać dane tylko z własną prędkością nominalną. Jeżeli do napędu wysyła się dane z prędkością 120 MB/s, będzie je zapisywał z taką prędkością. Jeśli jednak temu samemu napędowi dostarcza się dane z prędkością 60 MB/s, 50% czasu zajmie mu zapisywanie z prędkością 120 MB/s, a pozostałe 50% — przygotowywanie się do zapisu z taką prędkością. Mechanizm działania wygląda następująco. Po rozpoczęciu przesyłania danych do napędu najpierw trafiają one do bufora urządzenia. Napęd taśmowy wprawia mechanizmy w ruch obrotowy, przygotowując się do zapisu na taśmie z prędkością 120 MB/s (jeśli używa się napędu o takiej szybkości) danych pobieranych z bufora. Po zapełnieniu bufora napęd rozpoczyna czytać z niego dane i zapisywać je na taśmie. Jeżeli do napędu jest dostarczany stały strumień danych, bufor będzie zapełniany nowymi danymi z prędkością równą prędkości opróżniania bufora z danych zapisanych na taśmie. Jeśli jednak bufor nie jest zapełniany w tempie jego opróżniania, w pewnym momencie napęd taśmowy stwierdzi, że bufor nie jest pełny. Oczywiście taśma nadal będzie przesuwana, ponieważ jest to niezbędne do zapisu danych. Jednak w tym przypadku nie będzie więcej danych do zapisania. W związku z tym napęd musi się zatrzymać, przewinąć taśmę do miejsca, w którym przerwany został zapis, a następnie poczekać na ponowne wypełnienie bufora danymi. Operacja ta jest nazywana repozycjonowaniem. Każda taka operacja zajmuje określony czas, niekiedy jest to nawet kilka sekund. Gdy bufor ponownie się zapełnia, napęd znów przesuwa taśmę i bufor jest opróżniany. Napędy taśmowe
|
287
Jeśli bufor cały czas jest wypełniony danymi i napęd taśmowy nie musi przeprowadzać repozycjonowania, mówi się, że do urządzenia jest dostarczany stały strumień danych. Jeżeli dane transferuje się z szybkością mniejszą od własnej prędkości napędu, urządzenie dokona repozycjonowania. Gdy przesyła się strumień danych z prędkością mniejszą od własnej prędkości napędu, ale do niej zbliżoną, repozycjonowanie będzie zachodzić sporadycznie. Im większa różnica między prędkością przesyłania danych i prędkością własną urządzenia, tym częstsze będzie repozycjonowanie. Jeśli napęd notorycznie wykonuje taką operację, taśma cały czas jest przesuwana w tę i z powrotem pod głowicą odczytująco-zapisującą. Można to przyrównać do ruchów szmatą wykonywanych przez pucybuta. Z tego też powodu zjawisko to nazwano pucowaniem. Zwykle więcej czasu zajmuje repozycjonowanie taśmy niż opróżnienie bufora. W związku z tym, gdy rozpoczyna się repozycjonowanie, nie ma znaczenia, jak szybko można opróżnić bufor. Napęd musi zakończyć repozycjonowanie, zanim ponownie zacznie zapis danych i opróżnianie bufora. W tym czasie bufor może być pełny, lecz wcale nie jest opróżniany. Oznacza to, że gdy napęd przygotowuje się do opróżnienia bufora, musi przekazać informację nakazującą wstrzymanie transferu danych wejściowych. Im częściej ma to miejsce, tym gorzej napęd radzi sobie z prędkością przesyłania danych wejściowych. Właśnie z tego powodu napęd taśmowy, który nie przyjmuje danych ze stałą prędkością, może zapisywać dane z szybkością mniejszą od szybkości danych wejściowych. Napęd większość czasu spędza na repozycjonowaniu, a resztę na zapisie danych.
Kompresja utrudnia dostarczanie do napędów stałego strumienia danych Choć podczas porównywania różnych napędów archiwizujących nie powinno się używać prędkości przy zastosowanej kompresji, ważne jest, aby zrozumieć, jaką rolę kompresja odgrywa podczas określania rzeczywistej przepustowości. Jak wspomniano wcześniej w rozdziale, wiele osób nie uświadamia sobie tego, że kompresja zwiększa efektywną przepustowość napędu w takim samym stopniu jak efektywną pojemność magazynowania. W poprzednim punkcie wspomniano, że aby napęd taśmowy o prędkości 120 MB/s optymalnie działał, dane muszą być do niego dostarczane właśnie z taką prędkością. Prędkość taką określa się mianem docelowej przepustowości. Jeśli jednak dane przesyłane do napędu o prędkości 120 MB/s są kompresowane w stosunku 2:1, w rzeczywistości efektywna docelowa przepustowość wynosi 240 MB/s. Napęd działa płynnie tylko wtedy, gdy zapisuje dane z szybkością bliską lub równą swojej efektywnej docelowej przepustowości. Konieczne jest określenie efektywnej docelowej przepustowości napędów używanych w zarządzanym środowisku. W tym celu trzeba stwierdzić, jaki faktycznie uzyskuje się współczynnik kompresji, a następnie pomnożyć go przez efektywną przepustowość napędu (na przykład 120 MB/s), aby uzyskać rzeczywistą przepustowość (na przykład 240 MB/s). W celu wyznaczenia współczynnika kompresji trzeba stwierdzić, ile danych jest zapisywanych na pełnych taśmach. Większość produktów archiwizujących zapisuje dane na taśmie do momentu osiągnięcia znacznika identyfikującego fizyczny koniec taśmy. Oznacza to, że jeśli podzieli się średnią pojemność pełnej taśmy przez jej własną pojemność, otrzyma się faktyczny średni współczynnik kompresji. Jeśli na przykład własna pojemność taśm wynosi 400 GB i na każdej z nich można średnio zmieścić 600 GB danych, średni współczynnik kompresji wyniesie 1,5:1. A zatem napęd taśmowy o prędkości 120 MB/s faktycznie może działać z prędkością 180 MB/s. 288 |
Rozdz ał 9. Urządzen a arch w zujące
Napędy taśmowe obsługujące zmienne prędkości W poprzednim punkcie pokazano, jak napędy taśmowe niezbyt dobrze radzą sobie ze zmieniającymi się prędkościami transferu danych, ponieważ mogą je zapisywać tylko z jedną prędkością. Jak wspomniano, wynika to z konieczności bardzo szybkiego przemieszczania głowicy zapisującej w poprzek nośnika w celu uzyskania wysokiego stosunku sygnału do szumu. Producenci napędów taśmowych mieli dość ciągłego słuchania narzekań na kiepską obsługę różnych prędkości przesyłu i poważnie martwili się tym, że problem ten narastał, w miarę jak oferowali coraz szybsze urządzenia. Im szybsze napędy, tym trudniej dostarczać do nich stały strumień danych i większe ryzyko wystąpienia zjawiska „pucowania”. Jednak natura rynku wymagała od producentów dostarczania coraz szybszych napędów taśmowych. W związku z tym kilku wiodących producentów zaczęło zdawać sobie sprawę z tego, że jeśli zaoferują szybszy napęd, który będzie mógł też działać wolniej, będą dysponowali naprawdę czymś wyjątkowym. A zatem obecnie część napędów potrafi obniżyć swoją prędkość, aby poradzić sobie z mniejszymi szybkościami transferu danych. W czasie pisania książki były dostępne napędy będące w stanie działać z prędkością o połowę mniejszą od swojej własnej prędkości przesyłu. Inaczej mówiąc, napęd o prędkości 100 MB/s może też działać z prędkością 50 MB/s bez „pucowania”. Niektórzy producenci twierdzą, że zmienna prędkość napędów taśmowych sprawia, że zjawisko „pucowania” staje się przeszłością. Absolutnie nie jest to prawdą.
Napędy taśmowe obsługujące zmienne prędkości nadal mogą padać ofiarą zjawiska „pucowania”. Weźmy pod uwagę napęd taśmowy o własnej prędkości 120 MB/s. Dane są kompresowane w stosunku 1,5:1, dzięki czemu napęd działa z prędkością 180 MB/s. Napęd taśmowy ze zmienną prędkością transferu zwykle może zmniejszyć własną szybkość o 50%, dzięki czemu przykładowy napęd po zastosowaniu kompresji działałby z prędkością 90 MB/s. Jeśli dane będzie się dostarczać z prędkością mniejszą niż 90 MB/s, strumień danych nie będzie stały. Zamiast tego wystąpi zjawisko „pucowania”.
Napędy taśmowe z zapisem liniowym i ukośnym są inne Ogólnie przyjęło się, że napędy taśmowe z zapisem ukośnym są mniej podatne od napędów z zapisem liniowym na zmniejszanie prędkości przesyłu danych wejściowych. Omówienie różnic występujących między tymi dwoma technologiami będzie pomocne w wyjaśnieniu, dlaczego tak jest. Świetnym sposobem, aby pokazać różnice między zapisem liniowym i ukośnym, jest analiza magnetowidu bez technologii Hi-Fi. Urządzenie to właściwie zawiera oba rozwiązania i jego budowa ilustruje ważną kwestię. Czy Czytelnik pamięta magnetowidy, które były pozbawione technologii Hi-Fi? Czy kiedykolwiek Czytelnikowi zdarzyło się nagrać i oglądać film na magnetowidzie bez technologii Hi-Fi z włączonym ustawieniem EP (Extended Play)? Jeśli tak, dźwięk musiał być okropny.
Napędy taśmowe
| 289
Użyta analogia byłaby lepsza 5 – 10 lat temu, gdy nie wszystkie magnetowidy były Hi-Fi. Być może część użytkowników będzie musiała zapytać rodziców, czym był magnetowid bez technologii Hi-Fi. Jeśli Czytelnik nigdy nie miał takiego urządzenia, po prostu musi mi zaufać. Nagrywanie filmu z włączonym ustawieniem EP powodowało, że dźwięk był fatalny!
Jeśli ten sam film nagra się z ustawieniem EP na magnetowidzie Hi-Fi, dźwięk będzie znakomity. Czy kiedykolwiek Czytelnik zastanawiał się, dlaczego tak jest? Przyjrzyjmy się rysunkowi 9.2. Taśma magnetowidowa jest wyciągana z kasety i owijana dookoła bębna nagrywającego. Jak widać na rysunku 9.3, bęben jest lekko nachylony i po boku ma głowice zapisujące (prostokąt nachylony pod kątem widoczny na rysunku 9.3 reprezentuje bęben z jego obrotowymi głowicami zapisującymi). Gdy taśma powoli jest owijana dookoła bębna, ukośnie rozmieszczone głowice zapisujące diagonalnie rejestrują „paski” danych wideo na taśmie (zostało to pokazane w dolnej części rysunku 9.3). Choć taśma bardzo wolno przemieszcza się wokół bębna, ten obraca się bardzo szybko. Oznacza to, że głowice zapisujące znajdujące się na krawędzi bębna bardzo szybko przesuwają się w poprzek taśmy, dzięki czemu uzyskuje się dobrej jakości sygnał wideo.
Rysunek 9.2. Ścieżka pokonywana przez taśmę magnetowidu
Rysunek 9.3. Zapis ukośny 290
|
Rozdz ał 9. Urządzen a arch w zujące
Bęben obraca się z prędkością 1800 obr./min lub 30 obr./s. Z każdej strony bębna jest jedna głowica. Oznacza to, że głowice zapisujące rejestrują pasek danych na taśmie 60 razy na sekundę. Każdy z tych pasków zawiera połowę międzyliniowej ramki wideo. Wzdłuż krawędzi taśmy jest też zapisywany sygnał, który synchronizuje taśmę z obracającymi się głowicami zapisującymi. Magnetowid składa ramki do postaci normalnego obrazu wideo. W przypadku magnetowidu bez technologii Hi-Fi taśma mija również stałą głowicę audio, która wzdłuż krawędzi taśmy zapisuje liniowy sygnał audio. Bardzo podobnie jest to realizowane przez odtwarzacz kasetowy. Stała głowica zapisująca audio jest widoczna na rysunku 9.3. Choć ze względu na zachowanie zgodności wstecz magnetowid Hi-Fi ma taką samą stałą głowicę, jest też wyposażony w głowice audio umieszczone na obracającym się bębnie. Oznacza to, że urządzenie zapisuje ścieżki dźwiękowe jako ukośne paski położone obok pasków danych wideo (rysunek 9.4). Głowice zapisujące audio magnetowidu Hi-Fi przesuwają się w poprzek taśmy z dużą prędkością, niezależnie od tego, czy nagrywa się w trybie EP czy standardowym SP. Właśnie z tego powodu magnetowid Hi-Fi może nagrywać dobrej jakości sygnał audio, niezależnie od prędkości, z jaką taśma obraca się dookoła bębna.
Rysunek 9.4. Fragment taśmy magnetowidowej
W efekcie uzyskuje się taśmę wideo przedstawioną na rysunku 9.4. Ścieżki wideo są zapisywane jako paski ułożone ukośnie w stosunku do taśmy. W przypadku magnetowidu bez technologii Hi-Fi ścieżka audio jest wolno zapisywana w sposób liniowy w dolnej części taśmy, gdy ta przechodzi przez stałą głowicę zapisującą. Magnetowid Hi-Fi podobnie rejestruje dźwięk, lecz dodatkowo zapisuje go w krótkich ukośnych paskach położonych równolegle do ścieżek wideo. Trzeba pamiętać, że w magnetowidzie bez technologii Hi-Fi głowice wideo przemieszczają się bardzo szybko w poprzek taśmy, natomiast głowice audio — nie. W efekcie uzyskuje się dobrej jakości sygnał wideo, lecz kiepski sygnał audio. Gdy jednak dźwięk rejestruje magnetowid Hi-Fi, zapisuje go tak jak obraz, czyli w postaci krótkich pasków ukośnie rozmieszczonych na taśmie. Dzięki temu otrzymuje się wysokiej jakości sygnały audio i wideo. To pokazuje, że aby na taśmie można było zapisać wysokiej jakości sygnał, głowica zapisująca musi być bardzo szybko przesuwana w poprzek nośnika. Jest to ważne, ponieważ w przypadku napędu z danymi jakość sygnału jest wszystkim. Szczegółowe omówienie zasad działania magnetowidów wyjaśnia również różnice między technologiami liniowego i ukośnego zapisu. Napędy z zapisem ukośnym rejestrują dane tak jak magnetowidy obraz wideo, przez owijanie taśmy dookoła obracającego się bębna z dołączonymi głowicami zapisującymi. Napędy z zapisem liniowym szybko przesuwają taśmę przez stałą głowicę zapisującą. Przyjrzyjmy się bardziej dokładnie tym dwóm typom napędów.
Napędy taśmowe
|
291
Jak widać na rysunku 9.3, napęd z zapisem ukośnym wyciąga taśmę z kasety i owija ją dookoła bębna obracającego się pod niewielkim kątem nachylenia. Z boku bębna znajdują się głowice zapisujące, które na taśmie umieszczają ukośne paski. Dzięki temu taśma może powoli owijać się wokół obracającego się bębna, a głowice zapisujące mogą bardzo szybko przemieszczać się w poprzek powierzchni taśmy. W dokładnie taki sam sposób magnetowid rejestruje sygnał wideo. Wadą takiego urządzenia jest to, że taśma nieustannie musi być owinięta dookoła obracającego się bębna. Zwolennicy technologii zapisu liniowego twierdzą, że coś takiego powoduje nadmierne naprężenie taśmy. Producenci urządzeń z zapisem ukośnym głoszą, że zmienili sposób, w jaki taśma jest owijana wewnątrz napędu — w efekcie jest zmniejszone naprężenie taśmy. Technologia zapisu ukośnego jest wykorzystywana w kilku napędach, takich jak 8 mm, AIT, DAT/DDS, DTF, DTS i SAIT. Napęd taśmowy używający technologii zapisu liniowego bardzo szybko przesuwa taśmę w poprzek stałej głowicy zapisującej. Jak Czytelnik pamięta z lekcji poświęconej magnetowidom, głowica zapisująca musi bardzo szybko przemieszczać się w poprzek taśmy. Ponieważ głowica zapisująca jest nieruchoma, wymaga przesuwania taśmy z bardzo dużą prędkością, rzędu setek centymetrów na sekundę. Napęd LTO (Linear Tape Open) jest jednym z popularnych urządzeń korzystających z technologii zapisu liniowego. Na rysunku 9.5 pokazano ścieżkę pokonywaną przez taśmę takiego napędu.
Rysunek 9.5. Technologia zapisu liniowego
Większość nowszych napędów taśmowych, włącznie z urządzeniami LTO, używa rozszerzonej technologii zapisu liniowego nazywanej liniowym zapisem serpentynowym. Napęd korzystający z tej metody zapisu rejestruje kilka pasków danych w poprzek taśmy od jednej krawędzi do drugiej. Głowica następnie nieznacznie przesuwa się w górę lub w dół, zapisując kilka kolejnych pasków w odwrotnym kierunku. Zależnie od modelu napędu proces ten może zostać kilkakrotnie powtórzony, zanim zostanie wykorzystana cała powierzchnia nadająca się do zapisu. Technologia zapisu liniowego jest też stosowana w kilku napędach taśmowych, takich jak DLT, LTO i wszystkie produkowane przez firmy IBM i Sun (w czasie, gdy ta książka była pisana). 292
|
Rozdz ał 9. Urządzen a arch w zujące
Gdy Czytelnik zrozumie różnice między tymi dwoma technologiami, zapewne zauważy, dlaczego wiele osób twierdzi, że napędy z zapisem ukośnym mogą być bardziej narażone na zjawisko „pucowania” niż napędy z zapisem liniowym. Pierwsze przesuwają taśmę bardzo powoli, natomiast drugie — bardzo szybko. Napęd z zapisem liniowym, mający pusty bufor, przewinie kilkaset centymetrów taśmy, zanim „uświadomi” sobie, że w buforze nic nie ma, i rozpocznie repozycjonowanie. Jednak w przypadku napędu z zapisem ukośnym taśma nie jest przesuwana tak szybko, dlatego urządzenie nie przewinie jej wiele, gdy stwierdzi, że musi wykonać tę operację. Nie będzie konieczne przewinięcie sporej ilości taśmy w celu cofnięcia się do miejsca, od którego napęd może ponownie rozpocząć zapis. Choć trochę czasu zajmie synchronizacja z sygnałem zlokalizowanym w dolnej części taśmy, który synchronizuje głowice z ukośnymi paskami danych zapisanymi na taśmie, prawdopodobnie wszystko będzie trwało krócej niż w przypadku napędu z zapisem liniowym.
Zasobniki kontra kasety Choć wiele osób używa terminu „zasobnik” (ang. cartridge) w odniesieniu do dowolnego typu taśmy, w rzeczywistości zasobnikami są 1-szpulowe taśmy takich napędów, jak DLT, LTO i SAIT. Z kolei kaseta taśmy zawiera dwie szpule, tak jak w przypadku napędów AIT i DDS. Celem omawiania tej kwestii jest objaśnienie podstawowej różnicy między sposobem działania tych dwóch typów taśm. 1-szpulowy zasobnik nie ma szpuli odbiorczej. Szpula ta znajduje się wewnątrz napędu. Oznacza to, że w przypadku 1-szpulowych zasobników cała taśma jest wyciągana z zasobnika i owijana dookoła wewnętrznej szpuli odbiorczej napędu. Z kolei w przypadku kasety taśma pozostaje w jej obrębie. Choć większość technologii wysuwa określoną ilość taśmy z kasety, jej reszta pozostaje wewnątrz kasety. Można wyróżnić kilka rozwiązań, które mogą używać kasety bez zupełnego wyciągania taśmy poza jej obręb.
Trzeba było ratować pakiet Dostawca usług archiwizacji obsługujący zdalne wykonywanie kopii zapasowych kilku klientów zaplanował odbiory taśm nie w centrum danych, lecz w centrali. Taśmy były przewożone między centrami danych i centralą z tyłu pojazdu transportowego operatora archiwizacji. Czasami w rozgrzanym samochodzie leżały przez kilka godzin. — Kevin Suttle
Typy napędów taśmowych średniej klasy W tym punkcie w skrócie wyjaśniono, co w branży jest nazywane napędami taśmowymi średniej klasy. Takie urządzenie zwykle jest czymś, co przez użytkownika domowego zostałoby uznane za kosztowne, lecz wcale nie jest wysokiej jakości specjalistycznym napędem taśmowym, takim jak napędy spotykane w czarnych skrzynkach samolotów. Cena napędów taśmowych omówionych w niniejszym punkcie obecnie waha się w przedziale od niecałych trzech tysięcy do dziesiątek tysięcy złotych.
Napędy taśmowe
|
293
Nie wymieniono tu pojemności przedstawionych napędów, ponieważ bardzo często się zmieniają. Informacje te z łatwością można znaleźć w internecie.
Dołączone przeze mnie informacje są bardzo ogólne i często nieaktualne. Mają głównie na celu pomóc w odróżnieniu różnych typów napędów. W miarę możliwości napędy wymieniono w kolejności alfabetycznej, tak więc żaden z napędów nie został jakoś szczególnie wyróżniony. Część zaprezentowanych napędów dopiero pojawiła się na rynku, niektórych w czasie pisania książki nie było jeszcze w sprzedaży. Niektóre napędy omówione w niniejszym rozdziale nie są produkowane. Rozważam usunięcie ich w przyszłości z książki. Jednakże klient naprawdę dbający o budżet po prostu mógł nabyć jeden z tych napędów w sklepie z używanymi rzeczami. Opisałem te napędy z myślą o takich właśnie osobach.
3480 (już nieprodukowany) Rodzina napędów IBM 3840 nie jest dostępna od jakiegoś czasu. Urządzenia te używają półcalowego zasobnika 3480. W skład rodziny wchodzą napędy: 3480, 3490 i 3490E. Choć obecnie napędy te są wytwarzane przez kilku producentów, początkowo były produkowane dla serwerów IBM. Spośród napędów montowanych w obecnie sprzedawanych systemach otwartych urządzenia z rodziny 3840 mogą się pochwalić najdłuższym stażem, decydującym o poziomie ich niezawodności i stabilności. Choć w porównaniu z innymi napędami taśmowymi urządzenia te są raczej wolne i mało pojemne, cechują się dość krótkim czasem ładowania i dostępu do danych.
3590 Napęd taśmowy IBM 3590 był następcą urządzeń z rodziny 3480. Oferował większe pojemności i szybkość. Napęd używa własnego typu nośnika, którym jest półcalowy zasobnik 3590.
3592 Urządzenie IBM 3592 miało zastąpić napęd 3590. Napęd 3592 korzysta z własnego półcalowego zasobnika 3592 i w porównaniu z konkurencją oferuje wyższe prędkości transferu danych, a także większe pojemności. W rzeczywistości istnieją dwa typy nośnika 3592. Pierwszy jest tańszy, drugi zapewnia krótszy czas dostępu do danych.
TS1120 Napęd IBM TS1120 używa nośnika 3592 i oferuje wyjątkowo wysokie prędkości przesyłu danych i bardzo duże pojemności.
Napęd 3570 (inaczej zwany Magstar MP) Zasobnik napędu IBM 3570 ma trapezoidalny kształt, zupełnie inny niż niemal każdy z dostępnych zasobników. Był to pierwszy napęd taśmowy średniej klasy, który mógł podłączać punkt środkowy. Napęd ten również nie wysuwa zasobnika (rozwiązanie zastosowane w tym napędzie przypomina mi poczciwą kasetę z taśmą; czy Czytelnik pamięta, jak bolce były umiesz294 |
Rozdz ał 9. Urządzen a arch w zujące
czane w otworach taśmy, a następnie wałki przewijały taśmę bez wyciągania jej z kasety? Mechanizm ten jest podobny do zastosowanego w przypadku zasobnika 3570). Choć taśma ma stosunkowo niewielką prędkość transferu, nie jest to najważniejszy parametr w przypadku rynku, z myślą o którym zasobnik 3570 zaprojektowano. Jest to potencjalne rozwiązanie dla niemal lokalnego magazynowania danych, ponieważ całkowity czas dostępu do danych nie przekracza 30 sekund, czyli niewiele więcej od osiągów napędów optycznych dostępnych w sprzedaży, gdy napęd 3570 pojawił się na rynku.
Napędy 8 mm (8x0x; już nieprodukowane) Choć początkowo ta rodzina napędów była wytwarzana wyłącznie przez firmę Exabyte, ostatecznie inni producenci też je wytwarzali (nie dotyczy to napędów AIT i Mammoth, które omówiono oddzielnie). Pierwszy napęd z tej rodziny miał oznaczenie 8200, kolejne — 8500 i 8505. Urządzenia te nie mają się czym pochwalić, jeśli chodzi o niezawodność. Bardziej wtajemniczone osoby stwierdzą, że jest to spowodowane mechanizmami napędów, tymi samymi, które zastosowano w kamkorderach Sony 8 mm. Chwilowo oba urządzenia były nawet wytwarzane na tej samej linii montażowej. Napędy te tak bardzo przypominały kamkordery, że w tamtych czasach w roli taśm archiwizacyjnych używano zwykłych taśm wideo. Choć byliśmy wściekli na wydział odpowiedzialny za tanie zakupy, takie taśmy naprawdę dobrze się sprawowały.
Napędy 9840 Ta linia napędów firm Sun i StorageTek używa półcalowego zasobnika 9840 i obejmuje takie urządzenia, jak 9840A, 9840B i 9840C. Na pierwszy rzut oka można stwierdzić, że w porównaniu z innymi napędami wymienionymi w tym rozdziale urządzenia te mają mniejsze pojemności i przepustowości, a przy tym kosztują więcej. Powody są dwa. Pierwszy jest taki, że podobnie do napędów IBM 3xx0 urządzenia te zostały zaprojektowane dla serwerów przemysłowych i z myślą o 100-procentowym cyklu roboczym. Drugi powód jest taki, że napędy 9840 cechują się bardzo krótkimi czasami dostępu do danych. Jeśli szuka się napędu taśmowego ze 100-procentowym cyklem roboczym i bardzo szybko reagującego, urządzenie 9840 będzie w sam raz.
Napędy 9940 Napędy 9940 też są wytwarzane przez firmy Sun i StorageTek i wykorzystują półcalowy zasobnik 9940. Oferują większą pojemność i przepustowość od urządzeń 9840 poprzedniej generacji.
Napędy T10000 Następna generacja napędów firm Sun i StorageTek używa półcalowego zasobnika 10000, który w porównaniu z rodziną 9940 oferuje większą pojemność i przepustowość.
Napęd AIT Napęd AIT to efekt próby całkowitego przebudowania przez firmę Sony napędu 8 mm. Taśmy napędów AIT mieszczą się w 3,5-calowej obudowie o obniżonej o połowę wysokości. Choć taśmy mają szerokość 8 mm, na tym podobieństwo z napędami 8xx0 się kończy. Firma Sony Napędy taśmowe
|
295
zaprojektowała nowy typ nośnika AME (Advanced Metal Evaporative) z myślą tylko o napędzie AIT. Nośnik składa się z naparowanej metalowej warstwy nagrywającej pokrytej warstwą ochronną i substancją poślizgową. Twierdzono, że ten nowy typ nośnika w porównaniu ze standardową taśmą magnetyczną oferuje znakomite możliwości zapisu i retencji magnetycznej. Taśma zawiera również pamięć EEPROM nazywaną MIC (Memory In Cassette). W pamięci tej są przechowywane dane historyczne na temat taśmy. Choć teoretycznie pamięć może być wykorzystana do podziału taśmy na wiele logicznych woluminów, żaden z producentów nie skorzystał z tej możliwości. Napęd AIT nie może czytać tradycyjnych taśm 8 mm. Napęd ten wprowadzono do sprzedaży, zapewniając o lepszej pojemności i przepustowości przy dość niskiej cenie; zaprojektowano go z myślą o rywalizowaniu z segmentem napędów DLT.
Napęd DDS Stworzony przez firmę HP napęd DDS (Digital Data Storage) zapożyczył format od urządzeń DAT. Gwoli ścisłości, nie jest poprawne nazywanie napędu DDS urządzeniem DAT (Digital Audio Tape), ponieważ skrót ten odnosi się do cyfrowej taśmy audio. Wiele osób (i niektórzy producenci) w dalszym ciągu napędy DDS określa mianem napędów DAT, mimo że to mniej więcej tak, jakby napęd 8 mm nazwać kamkorderem. Bardzo niewiele osób zwróci uwagę na tę typową pomyłkę. Prawdopodobnie łatwiej byłoby sprawić, żeby ludzie przestali mówić „numer PIN”. Napędy DDS to jedne z najtańszych i najwolniejszych urządzeń obecnych na rynku systemów otwartych. Są również dość popularne, ponieważ przez długi czas w sprzedaży były dostępne tylko napędy DDS średniej klasy w cenie nieprzekraczającej 3000 zł.
Napędy DLT (już nieprodukowane) Napędy DLT (Digital Linear Tape) zostały zaprojektowane przez firmę Digital Corp. i bazowały na urządzeniach z serii TK-50 i TK-70. Firma zachowała ten sam podstawowy format nośnika i zmodyfikowała napęd, który go używał (pierwsze napędy DLT był w stanie odczytać stare taśmy TK). Dwa lata później firma ulepszyła projekt i zaproponowała napęd DLT 2000 oferujący pojemność dwukrotnie większą i przepustowość o 60% wyższą od osiągów najbardziej konkurencyjnego urządzenia. Jedyny problem z napędem DLT 2000 był taki, że nikt poza firmą Digital nie instalował go w swoich komputerach. W 1994 r. firma Digital postanowiła sprzedać technologię napędu firmie Quantum Technology, producentowi dysków twardych. A reszta, jak to się mówi, jest historią. Napędy DLT na dość długi czas zdominowały segment rynku urządzeń magazynujących średniej klasy.
Napędy DLT-S (inaczej zwane Super DLT) Firma Quantum ulepszyła oryginalny napęd DLT i wprowadziła go do sprzedaży pod nazwą Super DLT. Pierwsze takie urządzenia mogły odczytywać starsze nośniki DLT. Dało im to znaczną przewagę nad każdym innym konkurencyjnym napędem, ponieważ większość firm dysponowała ogromną liczbą taśm DLT z zapisanymi starymi kopiami zapasowymi. Ponieważ napęd Super DLT w rzeczywistości używał zupełnie innej głowicy odczytująco-zapisującej, firma Quantum osiągnęła zgodność wstecz, stosując oddzielną głowicę czytającą starszy nośnik. Obecnie firma Quantum urządzenia z tej serii nazywa DLT-S.
296
|
Rozdz ał 9. Urządzen a arch w zujące
Napędy DLT-V (inaczej zwane Value DLT) Niektórzy przedsiębiorcy uznali, że w dalszym ciągu istnieje zapotrzebowanie na tanie napędy DLT. W efekcie firma Quantum udzieliła licencji na technologię DLT firmie Benchmark, która rozpoczęła produkcję urządzeń z serii DLT. Choć w porównaniu z urządzeniami Super DLT firmy Quantum napędy te oferowały mniejsze pojemności i przepustowości, były tańsze. Ponieważ urządzenia firmy Benchmark odniosły sukces, firma Quantum przejęła ją i obecnie sprzedaje jej napędy w ramach serii DLT lub DLT-V.
Napęd DTF Napędem tym firma Sony zapoczątkowała swoją obecność na rynku bardzo szybkich urządzeń o dużej pojemności. Napędy te oferują znaczną pojemność i przepustowość, a ich nośnik pod względem rozmiaru plasuje się między taśmą napędu LTO i taśmą magnetowidową. Zwykle napędów DTF nie spotka się nigdzie poza biblioteką taśmową firmy Sony. Większość bibliotek obsługuje nośniki o podobnym rozmiarze, takie jak 4 mm, 8 mm i półcalowe, ponieważ z łatwością można urządzenia te przekonfigurować przez zwykłą wymianę napędów i taśm. Niestety, powoduje to, że ze względu na swoją obudowę nośnik DTF nie jest obsługiwany przez te biblioteki.
Napęd LMS NCTP Napęd LMS (Laser Magnetic Storage) NCTP został zaprojektowany przez Phillipsa, a później sprzedany firmie Plasmon. Napęd ten może odczytywać lub zapisywać dane na taśmie zasobników 3480 i 3490E. Chociaż napęd nie zyskał dużego uznania wśród innych producentów zautomatyzowanych magazynów danych, oferuje przyzwoite przepustowości i pojemności. Firma Plasmon oferuje własną serię bibliotek taśmowych używających tego napędu (nośnik LMS ma podobny problem związany z rozmiarem co nośnik DTF).
Napędy LTO Napędy LTO (Linear Tape Open) są produktem LTO Consortium, stworzonego przez firmy: HP, IBM i Quantum. Obecnie urządzenia te cieszą się największą popularnością spośród napędów taśmowych średniej klasy. Niektórym chyba podoba się to, że napędy te są wytwarzane przez wiele firm, inaczej niż napędy DLT firmy Quantum. Konkurencja sprawiła, że każdy członek konsorcjum dokonał wszelkich starań, żeby jego wersja napędu LTO była najlepsza. Jednocześnie zagwarantowano, że napęd LTO jednego z członków konsorcjum jest w stanie czytać taśmy innego. Wszystko trafiło do firmy Quantum. LTO Consortium, zainicjowane przez firmy: HP, IBM i Seagate, miało za zadanie podjąć rywalizację z firmą Quantum produkującą napędy DLT. Seagate utworzył spółkę Certance w celu wytwarzania urządzeń z serii LTO, a następnie Quantum przejął firmę Certance. Obecnie Quantum jest jednym z członków konsorcjum, które miało na celu rywalizować z nim. Ponadto w 2006 r. Quantum przejął jedynego groźnego konkurenta dla swoich bibliotek taśmowych, który nie należał do żadnego większego producenta sprzętu. IBM ma własne biblioteki taśmowe, a do firmy Sun należy to, co nazywano StorageTek. Jedynym pozostałym dużym rywalem była firma ADIC, która obecnie należy do firmy Quantum.
Napędy taśmowe
|
297
Napędy LTO, wykorzystujące półcalowe zasobniki, oferują bardzo wysokie prędkości transferu i duże pojemności przy dość umiarkowanej cenie (wciąż jednak niemałej). Większość napędów LTO cechuje się zmienną prędkością w pewnym zakresie i możliwością obniżenia jej w przybliżeniu o połowę w celu obsługi niewielkich prędkości danych wejściowych.
Napęd Mammoth (już nieprodukowany) Napęd Mammoth był próbą zdobycia przez firmę Exabyte udziału w rynku napędów. Firma otrzymywała od swoich klientów zażalenia dotyczące oryginalnej taśmy 8 mm, lecz nie była skora do tego, aby zupełnie zrezygnować z tego formatu. Firma była przekonana, że wadliwość oryginalnych napędów była spowodowana tańszymi komponentami wytwarzanymi na linii montażowej kamkorderów. W związku z tym firma postanowiła niezależnie produkować własny mechanizm. Powiększyła obudowę, aby części miały większą przestrzeń, a także zmodernizowała kilka kluczowych elementów projektu. W efekcie uzyskano kompletnie przebudowane urządzenie, w którym wymieniono wszystko, począwszy od grubości metalu, a skończywszy na innego rodzaju materiale zastosowanym w rolkach napędowych. Napędy Mammoth oferowały znacznie większe pojemności i przepustowości niż oryginalne napędy 8 mm. Firma Exabyte sprzedała sporo tych urządzeń. Jednak ostatecznie na skutek braku zapotrzebowania wycofała napędy Mammoth ze sprzedaży.
Napędy MLR 1-3 Tak jak napęd DLT był zmodyfikowaną wersją napędu TK 70, tak napędy MLR są zupełnie nowymi urządzeniami opartymi na napędzie QIC. Choć napędy MLR oferują przeciętne pojemności i prędkości, nie zyskały ogólnej akceptacji wśród producentów zautomatyzowanych magazynów danych lub dostawców centrów danych.
VXA Technologia VXA, opracowana przez firmę Ecrix, została kupiona przez firmę Exabyte. Napędy VXA stanowią opcję dla osób szukających tanich napędów taśmowych z przyzwoitą pojemnością i wydajnością. Za technologią VXA przemawia wiele bardzo silnych argumentów, jeśli chodzi o pewność danych zapisanych na taśmach VXA, w tym raporty osób, które były w stanie odczytać swoje taśmy po tym, jak dotknęła je prawdziwa katastrofa. Choć firma Exabyte oferuje kilka bibliotek taśmowych używających napędów VXA, nie zostały one zastosowane przez większych producentów zautomatyzowanych magazynów danych. Prawdopodobnie również to jest spowodowane różnicami w rozmiarze taśm.
Napędy optyczne Napędy optyczne wypełniają lukę między tanimi taśmami a dyskami cechującymi się dużą przepustowością i elastycznością. Napędy optyczne wiodą prym w takich obszarach, jak niezawodność, elastyczność, cykl roboczy, wymienność i czas dostępu do danych. Wyzwaniem dla nich jest przepustowość, pojemność i cena. Napędy optyczne zapewniają poziom wymienności charakterystyczny dla taśmy, lecz ich pojemności i przepustowości zwykle wypadają gorzej od osiągów napędów taśmowych. W porównaniu z urządzeniami taśmowymi największa przewaga napędów optycznych tkwi w bardzo
298 |
Rozdz ał 9. Urządzen a arch w zujące
krótkich czasach dostępu do danych i długoterminowej niezawodności. Choć obecnie tanie dyski z łatwością wygrywają w kategorii czasu dostępu do danych, większość systemów dyskowych nie jest projektowana pod kątem przenośności. A zatem systemy optyczne są oczywistą opcją w przypadku środowisk wymagających bardzo krótkiego czasu dostępu do danych i dobrej przenośności. Ponadto, jeśli wymaga się pewnego magazynowania danych przez długi czas, napędy optyczne będą oczywistym faworytem (niektóre systemy dyskowe nawet podejmują rywalizację w tej kategorii, lecz wiele osób nie do końca jest do tego przekonanych; zobaczymy, co będzie dalej). Jeżeli potrzebny jest przenośny nośnik z losowym dostępem, który przez długi czas potrafi w pewny sposób przechowywać dane, napędy optyczne będą trudne do pobicia. Jeśli pod uwagę weźmie się długoterminową retencję, okaże się, że nie wszystkie nośniki optyczne są tworzone w taki sam sposób. W związku z tym należy dokonać analizy.
Niniejszy podrozdział podzielono na dwie części. W pierwszej przedstawiono metody zapisu, w drugiej — formaty nośników optycznych. Metoda zapisu to sposób, w jaki dane są fizycznie reprezentowane na dysku. Z kolei format zapisu odnosi się do typu napędu, który może go używać. Przykładowo najbardziej typową metodą zapisu jest metoda zmiennofazowa. Korzysta z niej kilka formatów zapisu, takich jak CD-RW, DVD-RW, DVD-RAM i DVD+RW.
Metody zapisu optycznego Dla większości osób jest zrozumiałe, że tradycyjne napędy dyskowe zapisują dane cyfrowe (binarne) przez polaryzację obszarów dysku. W przypadku tradycyjnych metod zapisu optycznego dziury zawarte w obszarze dysku reprezentują dane binarne. Patrząc z perspektywy czasu, obszarem była płaska powierzchnia dysku, a dziurami rowki wypalone w obrębie obszaru. Gdy laser czyta dysk, dziury nie odbijają tyle światła co obszar. Jest to wykorzystywane podczas translacji do postaci danych binarnych. Wiele nowszych technologii zapisu w rzeczywistości nie generuje dziur. Obszar jest wykonany z materiału czułego na lasery o dużej mocy. Gdy laser zostaje skierowany na powierzchnię, zmienia jej własności refleksyjne, tak że wydaje się dziurą w obszarze (choć w rzeczywistości nie są to dziury, w dalszym ciągu używa się tego terminu). Magnetooptyczna metoda zapisu jest hybrydą technologii zapisu magnetycznego i optycznego. Dane binarne są reprezentowane przez przegrupowane cząstki magnetyczne, tak jak w przypadku tradycyjnego dysku lub napędu taśmowego. Laser jest używany podczas sesji nagrywania, a także podczas odczytu (więcej na ten temat zamieszczono w dalszej części rozdziału).
Magnetooptyczna metoda zapisu W przypadku magnetooptycznej metody zapisu (w skrócie MO) magnetyczna warstwa jest ogrzewana przez laser, który ułatwia polaryzację. Dane są następnie zapisywane przy użyciu tradycyjnych metod zapisu magnetycznego. Różnica jest jednak taka, że nagrzana powierzchnia zapisywana umożliwia precyzyjne kontrolowanie namagnesowanych obszarów. Gdy warstwa zapisywana ochłodzi się, jest mniej podatna na degradację magnetyczną. Dysk MO jest wymazywany przez przejście lasera o dużej mocy i zapisanie na dysku samych zer. Choć ta dwuetapowa operacja zwykle wymaga dwóch przejść, niektóre napędy MO dysponują instrukcjami pozwalającymi wykonać ją w jednym przejściu. Napędy MO oferują pojemności z przedziału Napędy optyczne
|
299
od kilkuset megabajtów do 9,1 gigabajta. Tradycyjnie nośnik MO trwale jest umieszczony w zasobniku przypominającym dyskietkę 3,5-calową (czy Czytelnik pamięta dyskietki?), tyle że dużo większą. W czasie gdy dyski CD miały pojemność wynoszącą tylko kilkaset megabajtów, a tanie nagrywarki DVD nie istniały, napędy MO oferowały pierwszą przystępną „optyczną” metodę zapisu dużych ilości danych. Choć w rzeczywistości był to zapis magnetyczny, umożliwiał przechowywanie danych przez dłuższy czas niż w przypadku tradycyjnych metod magnetycznego zapisu, ponieważ nośnik musiał zostać nagrzany, aby zmienić swoje własności magnetyczne. W efekcie na kilka ładnych lat świat archiwizacji został zdominowany przez napędy MO. Jednak wszystko się zmieniło, gdy pojawiła się zmiennofazowa metoda zapisu.
Zmiennofazowa metoda zapisu Zapis zmiennofazowy jest jedyną prawdziwą metodą zapisu optycznego porównywaną z metodą MO, będącą połączeniem zapisu optycznego i magnetycznego. Dyski zapisane przy użyciu tej metody zawierają specjalną warstwę zapisywalną, która po ogrzaniu przez laser zmienia swój stan z krystalicznego na amorficzny. Właśnie z tego powodu metodę nazywa się zmiennofazową. Stan amorficzny to mniejsze odbicie światła od krystalicznego. Obszary dysku będące w stanie amorficznym podczas odczytywania danych są identyfikowane jako dziury. Przy usuwaniu danych laser o dużej mocy przywraca dla całego dysku stan krystaliczny. W czasie pisania książki zmiennofazowa metoda zapisu była stosowana we wszystkich napędach jednorazowego i wielokrotnego zapisu, takich jak CD, DVD i UDO. W porównaniu z magnetooptyczną metodą zapisu zmiennofazowa metoda zapisu ma kilka zalet. Pierwszą z nich jest to, że dysk może być wymazany w jednym przejściu. Druga zaleta jest taka, że natura zapisu laserowego pozwala na użycie laserów o coraz mniejszej średnicy i jednocześnie o większej mocy. W przypadku dysków CD i DVD początkowo stosowano dziury o średnicach wynoszących odpowiednio 780 i 630 nm. Obecnie niebieskie lasery wykorzystywane przez napędy UDO mają średnicę zaledwie 405 nm. Niewielka średnica laserów pozwala na zapis gęściej upakowanych ścieżek bitów, dzięki czemu na dysku mieści się więcej danych. Gdy to połączy się z laserami o większej mocy, które mogą czytać i zapisywać wiele warstw, stanie się zrozumiałe, dlaczego przy tej samej średnicy dysku uzyskano wzrost pojemności z 650 MB do 30 GB. W rezultacie urządzenia wykorzystujące zmiennofazową metodę zapisu obecnie naprawdę zdominowały rynek.
Metoda zapisu barwionego polimeru Ta metoda zapisu została zaadaptowana przez niewielu producentów. Używa specjalnego nośnika, który po ogrzaniu tworzy bąbelki. Obszary z bąbelkami inaczej odbijają światło niż obszary bez bąbelków i podczas odczytywania przez laser są identyfikowane jako dziury. Gdy laser o podwyższonej mocy przywraca nośnik do pierwotnego stanu, dane są usuwane.
Metody jednokrotnego zapisu WORM Nieznaczne modyfikacje wcześniej omówionych metod zapisu pozwoliły uzyskać metody WORM (Write-Once-Read-Many); dzięki nim tworzone jest archiwum, którego nie można usunąć, zmienić lub nadpisać. Kilka firm używa tych metod do sporządzania archiwów, które mogą posłużyć jako dowód przeszłych zdarzeń, ponieważ można potwierdzić, że się nie zmieniły.
300 |
Rozdz ał 9. Urządzen a arch w zujące
Nośniki: CD-R, DVD-R, DVD+R i UDO używają wariantu zmiennofazowej metody zapisu, aby tworzyć dyski WORM. Istnieją też odmiany metody zapisu MO umożliwiające uzyskiwanie dysków WORM. Dostępna jest nawet taśma WORM. Aby zapis WORM był możliwy, nośnik musi zostać tak zaprojektowany, żeby można go było tylko raz zmodyfikować. Przykładowo popularna ablacyjna metoda zapisu korzysta ze stopu telluru jako warstwy zapisywanej. Stop ten ma wystarczająco niski punkt topnienia, żeby laser o dużej mocy mógł w nim wypalić faktyczne dziury. Gdy dziury zostaną wykonane na dysku, nie będzie można ich usunąć.
Formaty zapisu optycznego Poniżej dokonano przeglądu formatów optycznych jednokrotnego i wielokrotnego zapisu. Formaty omówiono zdecydowanie ogólnie, ponieważ ich szczegóły zmieniają się bardzo często.
Formaty zapisu dysków CD Dyski CD jednokrotnego i wielokrotnego zapisu są dość popularne. Mają niewielką pojemność (około 700 MB) i stosunkowo małą prędkość transferu (od 1 do 2 MB/s). Jednak obecnie dyski CD można wszędzie odczytać. W związku z tym przynajmniej przydają się do przenoszenia danych. Są dwa typy nagrywarek CD — oto jak działają: CD-R Nagrywarki CD-R używają jednej z metod zapisu WORM, aby utworzyć dyski CD tylko do odczytu, które mogą być odczytane przez zwykły odtwarzacz CD-ROM lub CD Audio. Dzięki temu format CD-R jest bardzo popularny. Nagrywarki CD-R zazwyczaj służą do tworzenia trwałych archiwów lub ładowalnych dysków CD-R. CD-RW Nagrywarki CD-RW stosują zmiennofazową metodę zapisu do tworzenia dysków CD, które w razie potrzeby mogą być nadpisywane. Dyski CD-RW mogą być odczytywane tylko przez napędy CD-ROM typu MultiRead. Większość napędów CD-RW umożliwia zapisywanie dysków CD-R, które mogą być odczytane przez starsze napędy CD-ROM. W porównaniu z formatem CD-R największą słabością formatu CD-RW jest jego prędkość.
Formaty zapisu dysków DVD Zależnie od tego, kogo się zapyta, uzyska się jedno z dwóch rozwinięć skrótu DVD: Digital Versatile Disk lub Digital Video Disk. W ciągu ostatnich lat format DVD zyskał sporą popularność — nie bez powodu. Ponadto mnóstwo producentów zautomatyzowanych magazynów danych oferuje biblioteki z dyskami DVD wielokrotnego zapisu. Różne zapisywalne formaty mają pojemności z przedziału od 2,6 do 4,7 GB dla jednej strony dysku, co w przypadku dwuwarstwowej lub dwustronnej płyty DVD w sumie daje pojemność 9,4 GB. Prędkość transferu (od 5 do 20 MB/s) w dalszym ciągu jest bardzo niewielka, gdy porówna się ją z osiągami nowoczesnych napędów taśmowych. Jednak większość zapisywalnych formatów DVD obsługuje losowy dostęp, dzięki czemu zapewnia bardzo krótki czas dostępu do danych. Kiedyś użytkownik musiał z rozwagą wybierać format zapisu danych, który miał być używany przez długi okres. Istnieją dwa formaty jednokrotnego zapisu (DVD-R i DVD+R) i trzy wielokrotnego (DVD-RW, DVD+RW i DVD-RAM). Jednak obecnie większość nagrywarek DVD potrafi odczytywać lub zapisywać dowolny z pięciu wymienionych konkurencyjnych formatów.
Napędy optyczne
|
301
Niżej opisane formaty DVD są sponsorowane przez dwie różne grupy: DVD Forum (http://www. ¦dvdforum.org) i DVD+RW Alliance (http://www.dvdrw.com). Pierwsza grupa pierwotnie zrzeszała producentów urządzeń DVD, lecz ich napędy i nośniki nie są już mniej ani bardziej oficjalne od zapewnianych przez grupę DVD+RW Alliance. Napędy mające w nazwie znak minusa (DVD-RAM, DVD-R i DVD-RW) są powiązane z organizacją DVD Forum, a napędy z plusem w nazwie (DVD+R i DVD+RW) — z organizacją DVD+RW Alliance. DVD-RAM DVD-RAM (DVD Random-Access Memory) był pierwszym łatwo dostępnym i tanim formatem DVD wielokrotnego zapisu, używającym zmiennofazowej metody zapisu, tak jak format CD-RW. Format DVD-RAM jest prawdopodobnie najmniej popularny spośród tego typu formatów, być może na skutek braku zgodności ze zwykłymi napędami DVD. DVD-R DVD-R (DVD-Recordable) jest jedynym formatem DVD, który stosuje metodę zapisu barwionego polimeru. Napędy DVD-R używają nośnika WORM, który może być zapisany tylko raz. Wielkim plusem formatu DVD-R jest to, że dyski tworzone przez napędy DVD-R mogą być z łatwością odczytane za pomocą dowolnego innego napędu DVD. Wynika to stąd, że dyski DVD-R są identyczne jak „normalne” dyski DVD. DVD-RW DVD-RW (DVD-Rewritable) jest drugim formatem wielokrotnego zapisu wspieranym przez organizację DVD Forum i używającym zmiennofazowej metody zapisu. Format ten jest też odczytywany przez większość napędów DVD-ROM, lecz nie zawsze przez zwykłe odtwarzacze DVD. Choć format DVD-RW jest droższy od formatu DVD-RAM, nie ma jego wad. DVD+R DVD+R (DVD-Recordable) jest najnowszym formatem DVD jednokrotnego zapisu, zaproponowanym przez takie firmy, jak Sony, HP, Ricoh, Yamaha i Phillips. Format korzysta ze zmiennofazowej metody zapisu i pozwala utworzyć dysk o dostępie sekwencyjnym lub losowym. DVD+RW DVD+RW (DVD-Rewritable) jest najnowszym formatem DVD wielokrotnego zapisu, zaproponowanym przez takie firmy, jak Sony, HP, Ricoh, Yamaha i Phillips. Również ten format stosuje zmiennofazową metodę zapisu i pozwala utworzyć dysk o dostępie sekwencyjnym lub losowym. W książce Unix Backup & Recovery zamieszczono zestawienie zgodności różnych formatów DVD. Jednakże na podstawie przeczytanych porównań i własnego doświadczenia twierdzę, że opinia Czytelnika w tym zakresie będzie się znacząco różnić. Ogólnie mówiąc, format DVD-R jest najbardziej kompatybilny z różnymi odtwarzaczami. Wiem, że właśnie na dysku DVD-R muszę zapisać dane, aby mieć pewność, że inna osoba odczyta je. Były osoby, które powiedziały mi, że właściwie nie miały do czynienia z żadnymi problemami z niezgodnością, które mi się przytrafiły. Właśnie z tego powodu napisałem wyżej, że opinia Czytelnika będzie zupełnie odmienna od mojej. Aby się o tym przekonać, należy przeprowadzić odpowiednie testy.
Magnetooptyczny format zapisu Napędy MO używają magnetooptycznej metody zapisu i są łatwo dostępne u kilku producentów. Istnieje też bogata seria zautomatyzowanych bibliotek obsługujących napędy i nośniki MO. Taki poziom automatyzacji w połączeniu z niskim kosztem sprawił, że napędy MO stały 302
|
Rozdz ał 9. Urządzen a arch w zujące
się odpowiednią propozycją dla środowisk z niemal lokalnym magazynowaniem danych. Słabe strony napędów MO, takie jak ograniczona pojemność (9,1 GB) i wielokrotny zapis z wieloma przejściami, sprawiły, że użytkownicy zaczęli szukać czegoś innego. W czasie pisania książki okazało się, że formaty DVD i UDO zyskały pod tym względem znaczącą przewagę.
Format zapisu UDO Dysk formatu UDO (Ultra Density Optical) jest 5,25-calowym nośnikiem optycznym wielokrotnego zapisu zaprojektowanym przez firmę Plasmon. Napędy UDO obsługują też nośniki WORM. W czasie pisania książki dysk formatu UDO mieścił 30 GB, używając niebieskiego lasera i zmiennofazowej metody zapisu. Przygotowywane są dyski o pojemności 60 i 120 GB. Choć napędy UDO przypominają napędy CD i DVD zaprojektowane dla typowych użytkowników, stworzono je z myślą o centrach danych. W związku z tym w napędach UDO zastosowano droższe i większe komponenty niż w przypadku urządzeń dla zwykłych odbiorców. Napędy UDO używają 8-warstwowego dysku, który ma czterokrotnie większą liczbę warstw niż typowy dysk DVD.
Zautomatyzowany sprzęt archiwizujący Do tej pory w rozdziale omówiono tylko napędy taśmowe i optyczne. Jednakże obecnie istniejące środowiska wymagają coraz większej automatyzacji, ponieważ bazy danych, systemy plików i serwery stają się coraz większe i bardziej złożone. Wydanie kilku tysięcy złotych na określonego typu system zautomatyzowanego zarządzania woluminami może zmniejszyć zapotrzebowanie na ręczną interwencję, dzięki czemu znacząco można poprawić poziom spójności systemu archiwizującego. Zautomatyzowany system zmniejsza frustrację administratora dzięki obsłudze najbardziej typowego (i nudnego) zadania związanego z kopiami zapasowymi, czyli wymiany woluminów. Zasadniczo można wyróżnić trzy typy zautomatyzowanego sprzętu archiwizującego. Niektórzy mogą używać zamiennie trzech poniższych terminów. Na potrzeby niniejszego rozdziału terminy te są stosowane zgodnie z ich definicją. Warstwowy magazyn Wiele osób zaczęło swoją przygodę z zautomatyzowanymi urządzeniami właśnie od warstwowego magazynu, którego nazwa jest związana z przeznaczeniem przewidzianym przez projektantów. Choć w pierwszych modelach tych urządzeń taśmy były układane warstwowo, wiele obecnie używanych magazynów warstwowych ma taśmy ustawiane obok siebie. Tradycyjnie warstwowy magazyn jest urządzeniem o sekwencyjnym dostępie do danych. Oznacza to, że gdy wyjmie się taśmę 1, automatycznie zostanie załadowana taśma 2. Jeśli w magazynie jest 10 taśm i wyciągnie się taśmę 10, zostanie załadowana taśma 1. Prawdziwemu warstwowemu magazynowi nie można nakazać załadowania taśmy 5 (taka możliwość jest określana mianem dostępu losowego). To użytkownik musi wiedzieć, jaka taśma znajduje się w napędzie, aby określić liczbę operacji wyjęcia niezbędnych do załadowania taśmy 5. Warstwowe magazyny zwykle mają od czterech do 12 gniazd i jeden lub dwa napędy. Ponieważ wiele produktów reklamowanych jako warstwowe magazyny obsługuje dostęp losowy, linia podziału nie jest już tak wyraźna. Jednak aby produkt został zakwalifikowany jako warstwowy magazyn, musi obsługiwać operację dostępu sekwencyjnego. Umożliwia Zautomatyzowany sprzęt arch w zujący
| 303
to administratorowi łatwe korzystanie ze skryptów powłoki kontrolujących warstwowy magazyn. Jeśli nabędzie się komercyjny produkt archiwizujący lub zastosuje narzędzie open source mogące zarządzać biblioteką taśmową, można przełączyć warstwowy magazyn w tryb dostępu losowego, umożliwiając kontrolowanie go przez oprogramowanie archiwizujące (administrowanie zautomatyzowanym sprzętem archiwizującym prawie zawsze jest w takim oprogramowaniu dodatkowo płatną opcją). Biblioteka Choć ta kategoria zautomatyzowanego sprzętu archiwizującego jest nazywana na wiele sposobów, najczęściej stosowane terminy to „biblioteka” i „automatyczna zmieniarka”. Każdy z tych terminów oznacza adresowalną grupę woluminów, które mogą być automatycznie załadowane przy wykorzystaniu unikatowych adresów. Oznacza to, że każde gniazdo i napęd biblioteki otrzymuje konkretny adres lokalizacji. Przykładowo pierwsze gniazdo może mieć adres 0000, a pierwszy napęd — 1000. Gdy oprogramowanie archiwizujące, które kontroluje bibliotekę, nakaże jej umieszczenie taśmy z gniazda 1 w napędzie 1, w rzeczywistości wyda polecenie „przenieś wolumin z lokalizacji 0000 do lokalizacji 1000”. Podstawowa różnica między biblioteką i warstwowym magazynem polega na tym, że biblioteka może działać tylko w trybie dostępu losowego. Obecnie dostępne biblioteki zaczynają zapożyczać rozwiązania spotykane wyłącznie w silosach, takie jak importowanie lub eksportowanie portów, czytniki kodów kreskowych, wizualne wyświetlacze i porty ethernetowe (na potrzeby funkcji monitorowania protokołu SNMP). Biblioteki mogą liczyć od 12 do 1000 lub więcej gniazd. Największe biblioteki oferują nawet porty przesyłowe, które umożliwiają jednej bibliotece przekazanie taśm innej bibliotece (zwykle jest to standardowa funkcja silosów). Niektóre biblioteki mogą być rozbudowywane o dodatkowe szafy, które w rzeczywistości stają się częścią podstawowej obudowy. Ścieżka robota jest rozszerzana o kolejną szafę. Silos Ponieważ wiele bibliotek oferuje obecnie funkcje, które były dostępne wyłącznie w silosach, linia podziału między tymi dwoma urządzeniami zamazała się. Głównym elementem odróżniającym je było to, że wiele hostów z różnymi aplikacjami archiwizującymi można było podłączyć do tego samego silosa. Jednak obecnie biblioteki oferują podobne rozwiązanie, określane mianem partycjonowania. A zatem wiele osób po prostu używa terminu silos w odniesieniu do naprawdę dużej biblioteki taśmowej. Trudno to wyeliminować. Inny sposób podziału różnego typu zautomatyzowanego sprzętu archiwizującego bazuje na tym, jakie są możliwości rozbudowy tych urządzeń (jeśli w ogóle są). Zautomatyzowane urządzenia archiwizujące można w tym przypadku zaliczyć do następujących trzech kategorii: Nierozszerzalne Tego typu biblioteki nie mogą być rozbudowane poza ich podstawową konfigurację. Choć w przypadku mniejszych systemów jest to najczęstsza sytuacja, istnieje też mnóstwo dużych bibliotek, których nie można rozbudowywać. Podłączalne Podłączalna biblioteka taśmowa może być rozbudowana przez połączenie z drugą. Choć każda biblioteka ma własnego niezależnego robota, wszystkie mają możliwość współużytkowania nośników przy użyciu portów przesyłowych. Wielką zaletą tego rozwiązania jest to, że można odłączać różne biblioteki i później niezależnie z nich korzystać.
304 |
Rozdz ał 9. Urządzen a arch w zujące
Rozszerzalne Rozszerzalna biblioteka pozwala na zwiększanie pojemności bez dodawania dodatkowej automatyki. W celu obsługi dołączonej pojemności istniejący robot jest po prostu rozszerzany. Dużą zaletą tego typu bibliotek jest to, że w razie potrzeby można zwiększyć pojemność o dokładną wartość.
Docelowe magazyny dyskowe Jak wspomniano w punkcie „Do napędów taśmowych musi być dostarczany stały strumień danych” w tym rozdziale, poprawne dostarczanie napędowi strumienia danych zwiększa zarówno jego przepustowość, jak i niezawodność. Taktyka związana z przesyłaniem do napędów strumienia danych stosowana przez większość produktów archiwizujących polegała na jednoczesnym wysyłaniu wielu zadań archiwizacyjnych do tego samego napędu taśmowego. Rozwiązanie to jest nazywane multipleksowaniem lub przeplataniem. Choć ułatwia ono archiwizowanie, może mieć negatywny wpływ na proces odtwarzania zawartości pojedynczej kopii zapasowej. Oprogramowanie archiwizujące wczytuje całą taśmę i ignoruje dane, których nie potrzebuje. Kilka produktów archiwizujących rozwiązuje problem ze strumieniowaniem danych, stosując powielanie dyskowe, w przypadku którego kopie zapasowe przed zapisaniem na taśmie są umieszczane na dysku. Aby przyspieszyć procesy archiwizacji i odtwarzania, powinno się nabyć na tyle duży dysk, żeby był w stanie przechowywać wszystkie lokalne kopie zapasowe. Wraz z pojawieniem się tańszych macierzy opartych na dyskach ATA i SATA wielu producentów oprogramowania archiwizującego zaczęło dodawać do niego funkcję powielania dyskowego, dzięki czemu znacznie więcej osób może skorzystać z dyskowych kopii zapasowych bez konieczności rezygnowania z tradycyjnej architektury archiwizacji. Obecnie typowe stało się rozszerzanie biblioteki taśmowej o określonego typu dysk. Jedynym problemem jest wybór metody; powinny w tym pomóc poniższe akapity. Tradycyjny system archiwizujący widoczny na rysunku 9.6 może być rozszerzony o dysk. Pierwsze dwa warianty określa się mianem dysk-jako-dysk, ponieważ w ich przypadku napędy dyskowe zachowują się jak napędy dyskowe. Nie emulują napędu taśmowego. W konfiguracji sieci SAN typu dysk-jako-dysk (rysunek 9.7) za jej pośrednictwem macierz dyskowa jest połączona z jednym lub większą liczbą serwerów archiwizujących. Do każdego serwera jest przydzielony wolumin dyskowy. Każdy serwer archiwizujący zwykle na tym woluminie umieszcza system plików, a następnie do tego systemu są przesyłane kopie zapasowe (choć niektóre pakiety oprogramowania archiwizującego mogą zapisywać kopie zapasowe bezpośrednio na niesformatowanym woluminie, większość tak nie postępuje). W konfiguracji rozwiązania NAS typu dyskjako-dysk (rysunek 9.8) dysk znajduje się za urządzeniem Filer Head, które współużytkuje systemy plików za pośrednictwem protokołu NFS lub CIFS. Kopie zapasowe są umieszczane na tych systemach plików. Dwie następne opcje wykorzystują wirtualne biblioteki taśmowe, w których systemy dyskowe są umieszczane za urządzeniem z aktywnym oprogramowaniem umożliwiającym macierzy dyskowej emulowanie jednej lub więcej bibliotek taśmowych. Rysunek 9.9 ilustruje niezależne wirtualne biblioteki taśmowe, które znajdują się obok fizycznej biblioteki taśmowej i emulują kolejną tego typu bibliotekę. Jeśli ma być możliwe przechowywanie kopii zapasowych poza firmą, po zarchiwizowaniu danych na niezależnej wirtualnej bibliotece trzeba użyć serwera archiwizującego do skopiowania ich na fizyczną taśmę. Zintegrowana
Docelowe magazyny dyskowe
| 305
Rysunek 9.6. Tradycyjna architektura archiwizacji
Rysunek 9.7. Sieć SAN typu dysk-jako-dysk
Rysunek 9.8. Rozwiązanie NAS typu dysk-jako-dysk
Rysunek 9.9. Niezależna wirtualna biblioteka taśmowa
306
|
Rozdz ał 9. Urządzen a arch w zujące
wirtualna biblioteka taśmowa (rysunek 9.10) jest zlokalizowana między fizyczną biblioteką taśmową i serwerem archiwizującym. Jej zadaniem jest emulowanie fizycznej biblioteki. Serwer archiwizujący zapisuje kopie zapasowe na zintegrowanej bibliotece, która następnie kopiuje zawartość wirtualnych taśm na prawdziwe bez pośrednictwa serwera. Zasobnik wirtualnej taśmy jest interesującą hybrydą wirtualnej i fizycznej taśmy.
Rysunek 9.10. Zintegrowana wirtualna biblioteka taśmowa
Docelowe magazyny danych typu dysk-jako-dysk Gdy oprogramowanie archiwizujące zapisuje kopie zapasowe w systemie typu dysk-jako-dysk, wie, że ma do czynienia z dyskiem, i zwykle tworzy plik w obrębie systemu plików. Jak wspomniano, niektóre aplikacje archiwizujące są w stanie umieszczać kopie zapasowe bezpośrednio na niesformatowanym urządzeniu dyskowym. Jednak jest to rzadka sytuacja.
Zalety docelowych magazynów danych typu dysk-jako-dysk W porównaniu z większością wirtualnych bibliotek taśmowych największą zaletą takich magazynów danych jest ich cena. W przypadku większości systemów typu dysk-jako-dysk koszt gigabajta danych jest niższy niż w przypadku wirtualnych bibliotek taśmowych, ponieważ nie płaci się za drogie oprogramowanie obsługujące takie biblioteki. Niektórzy uzyskują nawet większe oszczędności przez wykorzystanie w roli docelowego magazynu danych typu dysk-jako-dysk starej i wycofanej z użycia macierzy dyskowej. Oczywiście takie macierze często nie mają ważnych umów serwisowych, które powinno się odnowić, jeśli urządzenie planuje się zastosować w systemie produkcyjnym. Ponieważ umowy serwisowe dla starszego sprzętu mogą być dość kosztowne, trzeba pamiętać o porównaniu kosztu przywrócenia kontraktu z kosztem nowego systemu z już dołączoną umową. Następną zaletą docelowych magazynów zarchiwizowanych danych typu dysk-jako-dysk jest to, że większość firm tworzących oprogramowanie archiwizujące obecnie nie każe sobie płacić za zapisywanie na nich kopii zapasowych. W podpunkcie poświęconym wadom zostanie wyjaśnione, jak to się zmienia. Ostatnią zaletą docelowych magazynów danych typu dysk-jako-dysk jest ich elastyczność, która może mieć znaczenie, gdy planuje się przejście z tradycyjnej architektury archiwizacji. Jeśli na przykład zamierza się zastosować system archiwizujący z deduplikacją albo system ciągłej lub niemal ciągłej ochrony danych, będzie wymagany docelowy magazyn typu dyskjako-dysk. Ponieważ te zaawansowane komercyjne opcje ochrony danych wykraczają poza zakres książki, poniżej zamieszczono kilka bardzo zwięzłych definicji. System archiwizujący Docelowe magazyny dyskowe
|
307
z deduplikacją próbuje wyeliminować nadmiarowe bloki danych na poziomie klienta i transmituje do serwera archiwizującego tylko nowe unikatowe bloki danych. System niemal ciągłej ochrony danych używa replikacji i bardzo często tworzonych obrazów, aby wygenerować wiele punktów w czasie, do których można przywrócić dane. Prawdziwy system ciągłej ochrony danych archiwizuje każdy blok zmodyfikowanych danych i przechowuje go w ciągłym dzienniku umożliwiającym odtworzenie danych do stanu z dowolnej chwili. Więcej na temat tych systemów archiwizujących można znaleźć w rozdziale 8.
Wady docelowych magazynów typu dysk-jako-dysk W czasie pisania tej książki większość oprogramowania archiwizującego nie wymagała dodatkowych licencji na umieszczanie kopii zapasowych na docelowych magazynach typu dyskjako-dysk. Jednak to się szybko zmienia. Firmy tworzące aplikacje archiwizujące zaczynają pobierać opłaty za to, co dotąd było darmowe, i ta tendencja utrzyma się. Producenci oprogramowania archiwizującego uzasadniają to posunięcie tym, że do swoich aplikacji dołączają dodatkowe funkcje. Następna wada urządzeń archiwizujących typu dysk-jako-dysk jest związana z naturą systemów plików. Pliki są zapisywane, otwierane, modyfikowane i przechowywane ponownie w tym samym miejscu. Często nowy plik nie mieści się w miejscu, gdzie był wcześniej, dlatego w części jest zapisywany w oryginalnej lokalizacji, a w części w jakimś innym miejscu dysku. W efekcie dochodzi do fragmentacji. Im więcej plików się dodaje, usuwa i ponownie dodaje, tym system plików staje się bardziej pofragmentowany. Sposób używania dysku przez system archiwizujący spowoduje z czasem znaczną fragmentację, która zmniejszy wydajność (dalej zostanie wyjaśnione, dlaczego wirtualnych bibliotek taśmowych nie dotyczy to ograniczenie). Kolejnym mankamentem związanym z docelowymi magazynami typu dysk-jako-dysk jest to, że część produktów nie archiwizuje danych na systemach plików tak dobrze jak na taśmach. Przykładowo oprogramowanie archiwizujące dokładnie wie, co zrobić, gdy taśma zostanie zapełniona, lecz nie zawsze jest tak w przypadku wypełnienia systemu plików. Niektóre produkty archiwizujące wymagają od użytkownika umieszczenia kopii zapasowych typu dysk-jakodysk na pojedynczym systemie plików. Gdy taki system plików zostanie wypełniony, wszystkie następne archiwizacje nie powiodą się, nawet jeśli będzie dostępny inny system plików z odpowiednią pojemnością. Innym problemem związanym z docelowymi magazynami typu dysk-jako-dysk jest to, jak tworzyć kopie zapasowe na potrzeby przechowywania na zewnątrz. Choć najlepszym rozwiązaniem jest skopiowanie oryginalnej kopii zapasowej na taśmę, a następnie przewiezienie jej w inne miejsce, większość osób nie postępuje w ten sposób. Po prostu wyciągają z napędu oryginalną taśmę i przesyłają poza obręb firmy. Ponieważ nie można tego zrobić w przypadku macierzy dyskowej, trzeba nauczyć się kopiowania na taśmę danych zarchiwizowanych na dysku, a także automatyzowania tej operacji. Automatyzowanie procesu może być wyjątkowo proste lub bardzo trudne, zależnie od używanego produktu archiwizującego, i może wymagać zakupu dodatkowego oprogramowania od dostawcy usług archiwizacji. Niezależnie od metody przenoszenia danych z dysku na taśmę trzeba pamiętać, że dane są teraz przenoszone dwukrotnie, a nie tylko raz (gdy wyjmowano z napędu oryginalną taśmę). W związku z przenoszeniem danych po raz drugi trzeba wygospodarować dodatkowy czas.
308 |
Rozdz ał 9. Urządzen a arch w zujące
Warto przeczytać podpunkt „Jak wyciąga się wirtualne taśmy?” zamieszczony w dalszej części rozdziału, aby sprawdzić, czy w przypadku wirtualnych bibliotek taśmowych występuje ten sam problem.
Ostatnią wadą docelowych magazynów typu dysk-jako-dysk jest brak kompresji sprzętowej. Może ona zwiększyć prędkość i pojemność urządzenia archiwizującego nawet o 100%. Niektóre produkty typu dysk-jako-dysk obsługują deduplikację, która nie powinna być mylona z kompresją. Więcej na temat deduplikacji można znaleźć w dalszej części rozdziału, w punkcie „Funkcje dyskowe godne uwagi”.
Docelowe magazyny typu dysk-jako-dysk sieci SAN Docelowy magazyn typu dysk-jako-dysk sieci SAN (rysunek 9.7) jest po prostu macierzą dyskową podłączoną do sieci SAN i jednego lub większej liczby serwerów archiwizujących. Serwer archiwizujący umieszcza system plików w macierzy i zapisuje na nim dane. Oczywiście przewagą docelowego magazynu typu dysk-jako-dysk sieci SAN nad docelowym magazynem typu dysk-jako-dysk rozwiązania NAS jest znakomita wydajność operacji zapisu, typowa dla zaawansowanej macierzy dyskowej SAN (w przypadku technologii NAS jest stosowany magazyn plików oparty na protokole IP). Gdy jednak w roli docelowego magazynu kopii zapasowych zastosuje się macierz dyskową, na dodatkowy magazyn danych przerzuci się wszystkie problemy konfiguracyjne podstawowego magazynu. Wszystkie czynności związane z przydzielaniem dysków do grup RAID, grup RAID — do serwerów, a woluminów — do systemów plików muszą teraz być wykonane na zapleczu systemu archiwizującego. Problem ten pogłębia się, gdy zarządza się wieloma serwerami archiwizującymi. Jeśli używa się biblioteki taśmowej lub wirtualnej biblioteki taśmowej, większość aplikacji archiwizujących będzie umiała współużytkować takie urządzenia. Jeżeli jednak korzysta się z docelowego magazynu dysk-jako-dysk sieci SAN z wieloma serwerami archiwizującymi, zwykle trzeba będzie zdecydować, jak duży musi być wolumin każdego serwera i w jaki sposób każdemu z nich przydzieli się odpowiednią ilość miejsca (niektóre aplikacje archiwizujące są w stanie dynamicznie współużytkować dysk; taka możliwość eliminuje wiele problemów konfiguracyjnych).
Docelowe magazyny typu dysk-jako-dysk technologii NAS Docelowy magazyn typu dysk-jako-dysk technologii NAS (rysunek 9.8) eliminuje wiele problemów konfiguracyjnych obecnych w przypadku docelowego magazynu typu dysk-jako-dysk sieci SAN. Osiąga się to przez umieszczenie dysków za urządzeniem NAS Head obsługującym klienty i uzyskanie ogromnego woluminu, który może być współużytkowany za pośrednictwem protokołu NFS lub CIFS. Ogólnie mówiąc, takie systemy są łatwiejsze do utrzymania niż tradycyjne macierze dyskowe. Jednak należy pamiętać, że prostsza administracja generuje dodatkowy koszt. Zarówno urządzenie Filer Head, jak i jego system operacyjny zwiększają koszt systemu. Jego wydajność jest ograniczana przez przepustowość urządzenia Filer Head. Jednak, zależnie od rozmiaru kopii zapasowych, wydajność może nie stanowić problemu. Jeżeli zarządza się siecią NAS z wieloma innymi urządzeniami Filer Head, zastosowanie docelowego magazynu typu dysk-jako-dysk będzie czymś idealnym, zwłaszcza wtedy, gdy zamierza się sprawdzić system niemal ciągłej ochrony danych.
Docelowe magazyny dyskowe
| 309
Klastry systemów plików w roli docelowych magazynów danych Klastry systemów plików mogą wyeliminować kilka wad docelowych magazynów danych typu dysk-jako-dysk. Ułatwiają konfigurowanie przez brak wymogu użycia woluminu dla każdego serwera archiwizującego. Nie występuje w tym przypadku ograniczenie jednego urządzenia Filer Head występujące w typowym systemie NAS. W czasie, gdy ta książka była pisana, klaster systemów plików nadal przez wielu był uważany za zbyt nową technologię. Choć często rozwiązuje ona mnóstwo problemów, ma też ograniczenia, które dla systemów archiwizujących mogą być przyczyną innych problemów. Przykładowo część klastrów oferuje bardzo dobrą wydajność w przypadku setek jednoczesnych strumieni danych, lecz kiepską dla dowolnego wybranego strumienia. Klastrowe systemy plików są też zwykle droższe od innych omawianych tu opcji. Jeśli ograniczenia zostaną wyeliminowane, być może kiedyś klastrowe systemy plików będą opcją godną uwagi.
Dysk-jako-taśma — wirtualne biblioteki taśmowe Wirtualne biblioteki taśmowe stanowią alternatywę dla docelowych magazynów danych typu dysk-jako-dysk. Są też nazywane jednostkami dysk-jako-taśma, ponieważ są macierzami dyskowymi emulującymi taśmę. Wiele osób jest przekonanych, że oprogramowanie obsługujące wirtualne biblioteki taśmowe jest czymś, za co trzeba dodatkowo zapłacić (wcześniej płaci się za macierz dyskową). Ponadto nie są pewne, czy i dlaczego powinny to zrobić. Niniejszy punkt powinien pomóc w wyjaśnieniu tej kwestii. Najpierw zostaną przedstawione zalety i wady wszystkich wirtualnych bibliotek taśmowych, a następnie wyjaśniona różnica między niezależnymi i zintegrowanymi wirtualnymi bibliotekami taśmowymi, a także omówione zalety i wady obu typów urządzeń. Na końcu punktu opisano funkcje, które powinno się rozważyć podczas podejmowania decyzji, jaki typ wirtualnej biblioteki taśmowej kupić.
Zalety wirtualnych bibliotek taśmowych W porównaniu z docelowym magazynem typu dysk-jako-dysk podstawową zaletą wirtualnej biblioteki taśmowej jest łatwość zarządzania i lepsza wydajność. Jak wspomniano w poprzednim punkcie, docelowy magazyn typu dysk-jako-dysk wymaga przeprowadzenia wszystkich typowych czynności konfiguracyjnych charakterystycznych dla standardowych współużytkowanych macierzy przechowujących dane. W przypadku wirtualnej biblioteki taśmowej informuje się ją, ile ma być emulowanych wirtualnych napędów taśmowych i zasobników. Na tym kończy się etap konfiguracji. Oprogramowanie wirtualnej biblioteki taśmowej automatycznie zajmuje się całą konfiguracją, przydzielając każdemu wirtualnemu zasobnikowi odpowiednią przestrzeń dyskową i dynamicznie udzielając dostępu do takiego zasobnika każdemu serwerowi archiwizującemu, który tego wymaga. Nie wszystkie wirtualne biblioteki taśmowe w tym samym stopniu eliminują czynności konfiguracyjne. Jest to ważna kwestia, którą należy uwzględnić podczas analizowania wirtualnej biblioteki taśmowej.
Następną istotną zaletą wirtualnych bibliotek taśmowych jest łatwość, z jaką mogą być współużytkowane przez wiele serwerów i aplikacji. Jeśli z wirtualnej biblioteki taśmowej musi korzystać wiele serwerów archiwizujących z tym samym oprogramowaniem, można zastosować
310
|
Rozdz ał 9. Urządzen a arch w zujące
wbudowaną funkcję współużytkowania biblioteki, w którą jest już wyposażona większość komercyjnych produktów archiwizujących. Jeżeli wirtualną bibliotekę taśmową trzeba udostępnić wielu serwerom, które nie obsługują dynamicznego współużytkowania (tak jak w przypadku narzędzia open source lub stosowania wielu produktów niepotrafiących ze sobą współpracować), można po prostu przeprowadzić partycjonowanie biblioteki na wiele mniejszych bibliotek, przypisać określoną liczbę wirtualnych zasobników do każdej biblioteki i skojarzyć każdą z innym serwerem archiwizującym. Można też tak postąpić, gdy nie chce się używać oprogramowania współużytkującego bibliotekę oferowanego przez producenta aplikacji archiwizacyjnych, a jedynie przydzielić każdemu serwerowi archiwizującemu własne napędy taśmowe. Oba warianty są znacznie prostsze do zrealizowania od tego, co jest wymagane do współużytkowania docelowego magazynu danych typu dysk-jako-dysk przez wiele serwerów archiwizujących. Aby zrozumieć korzyści ze stosowania wirtualnych bibliotek taśmowych związane z wydajnością, trzeba najpierw zastanowić się, jak aplikacje archiwizujące zapisują dane na taśmie. Gdy taka aplikacja zaczyna zapisywać dane na taśmie, zwykle kontynuuje tę operację do momentu osiągnięcia fizycznego końca taśmy. Dane zostaną umieszczone na taśmie nawet wtedy, gdy część wcześniej zapisanych danych utraciła już ważność. Gdy aplikacja osiąga fizyczny koniec taśmy, uznaje ją za zapełnioną. Większość aplikacji archiwizujących pozostawia wszystko na taśmie, dopóki każda zapisana na niej kopia zapasowa nie utraci ważności. Gdy to nastąpi, aplikacje zapisują dane od początku taśmy. Niektóre aplikacje archiwizujące czekają, aż określona procentowa część kopii zapasowych zapisanych na taśmie utraci ważność, a następnie odzyskują miejsce na taśmie przez przeniesienie wszystkich ważnych kopii na drugą taśmę. W dalszej kolejności pierwsza taśma traci ważność i w konsekwencji jest nadpisywana. Chodzi o to, że nie są nadpisywane fragmenty taśmy; taśmy po prostu nie pozwalają na to. Aplikacje archiwizujące zapisują dane w obrębie systemu plików w bardzo odmienny sposób. Informują system operacyjny, że zamierzają utworzyć konkretną nazwę pliku, a następnie rozpoczynają zapisywanie w tym pliku danych. Każda kopia zapasowa ma własny plik. Gdy plik traci ważność, jest usuwany. Aplikacja archiwizująca nie ma żadnych informacji na temat tego, jak w rzeczywistości dane są zapisywane na dysku. Oczywiście bez udziału użytkownika bajty każdego pliku są umieszczane na całym dysku, a taka fragmentacja powoduje spadek wydajności. Wirtualne biblioteki taśmowe traktują dysk jak taśmę. Urządzenia te „wiedzą”, że są wykorzystywane do tworzenia kopii zapasowych i archiwów, a także dysponują informacjami na temat ich działania. Dzięki temu wirtualne biblioteki taśmowe eliminują fragmentację, zapisując kopie zapasowe w ciągłych obszarach dysku. Bloki przypisane do konkretnej taśmy pozostają z nią związane, dopóki aplikacja archiwizująca nie rozpocznie nadpisywania tej taśmy. Gdy to nastąpi, wirtualna biblioteka taśmowa będzie mogła ponownie rozpocząć zapisywanie danych w ciągłych obszarach dysku, tak jak ma to miejsce w przypadku zapisu na taśmie. Niektórzy producenci wirtualnych bibliotek taśmowych zarządzają nawet woluminami RAID, co daje pewność, że określona grupa RAID jest powiązana tylko z jedną wirtualną taśmą. Można sobie wyobrazić, jak dobrze działa dysk, jeśli w danej chwili wykonuje operację odczytu lub zapisu tylko dla jednej aplikacji, która zawsze odczytuje lub zapisuje dane w ciągłych obszarach dysku. Następną kluczową kwestią związaną z wydajnością jest zastosowanie klastrów w niektórych wirtualnych bibliotekach taśmowych. Choć klastrowe systemy plików nadal są wyjątkiem, a nie regułą, inaczej jest w przypadku wirtualnych bibliotek taśmowych. Kilka z nich oferuje wiele modułów przenoszących dane, z których każdy zwiększa pojemność i przepustowość. Docelowe magazyny dyskowe
|
311
Zastosowanie klastrowania razem z niestandardowym sposobem zapisywania danych na dysku powinno wyjaśniać, dlaczego najszybsze systemy plików zapisują setki megabajtów na sekundę, a najszybsze wirtualne biblioteki taśmowe — nawet tysiące. Wirtualne biblioteki taśmowe mają też inne zalety. Z jednym wyjątkiem (omówionym w poniższym podpunkcie) oprogramowanie archiwizujące, a także operatorzy kopii zapasowych i administratorzy, mogą korzystać z wszystkich dostępnych technologii, procesów i procedur, gdy dane są archiwizowane za pomocą wirtualnej biblioteki taśmowej. Oznacza to, że wszystko działa tak, jak gdyby zastosowano fizyczną bibliotekę taśmową. Nie jest tak w przypadku docelowych magazynów danych typu dysk-jako-dysk, przy których oprogramowanie archiwizujące może zachowywać się różnie. Część wirtualnych bibliotek taśmowych obsługuje również kompresję, co pozwala zmieścić na tej samej przestrzeni dysku większą liczbę kopii zapasowych (nie powinno to być mylone z deduplikacją, omówioną w dalszej części rozdziału). Niezależnie od tego, czy zapłaci się za funkcję kompresowania oferowaną przez wirtualną bibliotekę taśmową i będzie się z niej korzystać, czy nie, funkcja ta będzie bazować na typie posiadanej wirtualnej biblioteki i sposobie używania jej. Niestety, wiele takich bibliotek stosuje kompresję programową, która oszczędza miejsce, lecz powoduje znaczący spadek wydajności, nawet do 50%. Jeśli szybkość procesu archiwizowania jest zmniejszana przez szybkość klientów i (lub) sieci, można nie zauważyć tego spadku wydajności. Jednak prawdopodobnie będzie to widoczne w przypadku wykonywania kopii zapasowych w sieci lokalnej lub bez jej udziału, ponieważ w tych wariantach szybkość procesu archiwizowania zwykle jest ograniczana przez urządzenie archiwizujące. Niektórzy producenci wirtualnych bibliotek taśmowych zapewniają kompresję sprzętową, która nie ma wpływu na wydajność (osiągnęli to przez zastosowanie identycznego układu jak w napędach taśmowych).
Wady wirtualnych bibliotek taśmowych Pierwszą wadą wirtualnych bibliotek taśmowych, wskazywaną przez wiele osób, jest koszt. Ludzie są przekonani, że jeśli macierz dyskowa kosztuje X, macierz mająca przypominać wirtualną bibliotekę taśmową będzie mieć cenę X + Y. Dość dziwne jest to, że koszt docelowych magazynów danych typu dysk-jako-dysk w przybliżeniu zawiera się w tym samym przedziale cenowym co koszt wirtualnych bibliotek taśmowych. Oznacza to przede wszystkim, że niezbyt sprawiedliwe jest stwierdzenie, że wirtualne biblioteki zawsze kosztują więcej niż docelowe magazyny typu dysk-jako-dysk. Poniesiony wydatek będzie zależny od typu wirtualnej biblioteki taśmowej i docelowego magazynu typu dysk-jako-dysk używanego w porównaniu. W przypadku większości bibliotek stosuje się wycenianie na podstawie pojemności. Oznacza to, że cenę wyraża się w przeliczeniu na gigabajt. W czasie, gdy ta książka była pisana, najdroższa wirtualna biblioteka taśmowa kosztowała trzykrotnie więcej od najtańszej biblioteki. W związku z tym warto sprawdzić wiele ofert. Jeśli wirtualna biblioteka taśmowa obsługuje deduplikację danych, może być jeszcze tańsza. Następną kwestią związaną z kosztem wirtualnych bibliotek taśmowych jest cena licencji na oprogramowanie archiwizujące. Jeżeli nabędzie się wirtualną bibliotekę taśmową, która „znajdzie” się obok posiadanej biblioteki taśmowej, prawdopodobnie trzeba będzie kupić dodatkową licencję dla biblioteki taśmowej, która w rzeczywistości nie istnieje. Oczywiście zwiększy to koszt wirtualnej biblioteki taśmowej. Faktyczna kwota do wydania będzie zależeć od tego, ile zapłaci się za licencje na oprogramowanie archiwizujące dla fizycznych i (lub) wirtualnych bibliotek taśmowych. Część produktów archiwizujących ma jedną licencję dla 312
|
Rozdz ał 9. Urządzen a arch w zujące
wszystkich bibliotek taśmowych, a część pobiera opłatę od liczby gniazd lub napędów. Niektóre wirtualne biblioteki taśmowe są wyceniane na podstawie pojemności. A zatem podejmując decyzję o sposobie konfiguracji wirtualnej biblioteki taśmowej, należy sprawdzić, jak producent używanego oprogramowania archiwizującego obciąża opłatami w związku z fizycznymi i wirtualnymi bibliotekami taśmowymi. Porównując wirtualne biblioteki taśmowe z docelowymi magazynami typu dysk-jako-dysk, trzeba pamiętać, że producenci oprogramowania archiwizującego zaczęli również pobierać opłaty za używanie tych drugich.
Jak wyciąga się wirtualne taśmy? Odpowiedź na to pytanie zależy od tego, czy zakupiono niezależną (rysunek 9.9) czy zintegrowaną wirtualną bibliotekę taśmową (rysunek 9.10). Jak wcześniej wspomniano, podstawową zaletą wirtualnych bibliotek taśmowych jest to, że nie wymagają wprowadzania żadnych zmian w istniejącym procesie archiwizacji lub konfiguracji. Wyjątkiem jest sytuacja, gdy nie kopiowano taśm z kopiami zapasowymi i nie wysyłano ich poza obręb firmy. Choć nie jest to najlepsza z praktyk, w przypadku wielu środowisk wyciąga się oryginalne taśmy i przekazuje na zewnątrz. Świetnie się to sprawdza w przypadku fizycznej biblioteki taśmowej, lecz nie wirtualnej. W związku z tym firmy, które wyjmują z napędów oryginalne taśmy i chcą korzystać z wirtualnej biblioteki, zwykle muszą zrobić jedną z dwóch rzeczy: nauczyć się kopiowania taśm lub używać zintegrowanej wirtualnej biblioteki taśmowej. To, który z tych dwóch wariantów zostanie uznany za najlepszy w konkretnym środowisku, będzie zależeć od preferencji osoby zarządzającej nim. Niektórzy twierdzą, że metoda kopiowania z taśmy na taśmę przy wykorzystaniu niezależnych wirtualnych bibliotek taśmowych jest jedynym właściwym sposobem zapisywania fizycznych taśm danymi z wirtualnych taśm. Dzięki tej metodzie oprogramowanie archiwizujące może kontrolować proces kopiowania, integrując go z normalnymi procedurami raportowania. Jednak z metodą tą są związane dwa wyzwania. Pierwszym jest skala trudności automatyzacji procesu, zależna od używanego oprogramowania archiwizującego. W przypadku niektórych aplikacji może być po prostu konieczne przeczytanie nowej sekcji dokumentacji i postępowanie zgodnie z wytycznymi. Inne produkty archiwizujące mogą wymagać nabycia dodatkowej licencji. Część tych produktów żąda utworzenia skryptu obsługującego proces. Trzeba będzie określić poziom trudności dla zarządzanego środowiska. Drugie wyzwanie polega na tym, że w przypadku wielu środowisk w ciągu dnia brakuje czasu i zasobów systemowych, aby odpowiednio szybko można było kopiować taśmy z kopiami zapasowymi. Wiele firm może spełnić jedynie takie wymogi, aby na czas przygotować kopie zapasowe do odbioru przez dostawcę usług magazynowania danych. Oczywiście, jeśli już wiadomo, jak kopiować taśmy z kopiami zapasowymi, i dysponuje się pozwalającymi na to zasobami, powyższy mankament nie stanowi problemu. Jeżeli wyzwania towarzyszące kopiowaniu zawartości wirtualnych taśm na fizyczne nie dają spokoju, można zastanowić się nad zastosowaniem zintegrowanej wirtualnej biblioteki taśmowej. Ponieważ z tego typu biblioteką jest związanych mnóstwo obaw i wątpliwości, z uwagą należy zapoznać się z zasadami jej działania. Zintegrowana wirtualna biblioteka taśmowa znajduje się między serwerem archiwizującym i fizyczną biblioteką taśmową. Biblioteka taka inwentaryzuje fizyczną bibliotekę i jej zawartość reprezentuje jako swoje wirtualne taśmy. Jeśli na przykład w fizycznej bibliotece znajduje się taśma X01007, w wirtualnej bibliotece pojawi się wirtualna taśma X01007. Oprogramowanie archiwizujące będzie następnie zapisywać kopie na tej taśmie. W określonym momencie, ustalanym przez użytkownika, zawartość wirtualnej taśmy X01007 jest kopiowana na fizyczną taśmę X01007. Gdy oprogramowanie nakaże Docelowe magazyny dyskowe
|
313
wirtualnej bibliotece wyjęcie wirtualnej taśmy X01007, fizyczna taśma o tym samym oznaczeniu pojawi się w gnieździe fizycznej biblioteki. Godne uwagi jest to, że fizyczna taśma wygląda dokładnie tak, jak gdyby oprogramowanie zarchiwizowało dane bezpośrednio na niej. Aplikacja jest „przekonana”, że kopię zapasową umieściła na fizycznej taśmie X01007 i wysunęła ją. Ostatecznie faktycznie tak się stało. Używając kodu kreskowego podobnego do etykiety X01007, można utrzymać spójność między menedżerem nośników oprogramowania archiwizującego a fizycznymi taśmami. Trzeba jednak pamiętać, że metoda ta nie da dwóch kopii taśmy. Wirtualna kopia taśmy jest usuwana po udanym utworzeniu fizycznej kopii. Niektóre zintegrowane wirtualne biblioteki taśmowe umożliwiają stosowanie taśm z kodami kreskowymi, które nie są zgodne z kodami fizycznych taśm. Nie wolno tak robić! Oprogramowanie archiwizujące poprosi o jedną taśmę i trzeba będzie uzyskać od wirtualnej biblioteki informację pozwalającą stwierdzić, jaka w rzeczywistości jest to taśma.
Z opisaną powyżej metodą jest też związanych kilka wyzwań. Pierwsze dotyczy tego, co się stanie, gdy nie powiedzie się kopiowanie zawartości wirtualnej taśmy na fizyczną. Jeśli powodem jest to, że rzeczywista taśma jest wadliwa, trzeba ją usunąć, umieścić jej kod kreskowy na nowej taśmie, a następnie tę taśmę załadować w fizycznej bibliotece i nakazać wirtualnej bibliotece ponowienie operacji kopiowania (oczywiście jest to możliwe tylko wtedy, gdy kody kreskowe są wymienne). Jeżeli coś takiego zdarza się sporadycznie, można to traktować jako drobną niedogodność. Jeśli jednak ma to miejsce codziennie, może być powodem sporego poirytowania. Ważne jest również, aby mieć świadomość, że cały proces przebiega bez udziału oprogramowania archiwizującego. Oznacza to, że jeśli coś stanie się z kopią taśmy, wirtualna biblioteka będzie musiała powiadomić użytkownika o problemie. Oczywiście wiąże się to z użyciem kolejnego interfejsu raportowania, co przez niektórych zostanie uznane za mankament. Następne potencjalne wyzwanie: co będzie, gdy wirtualna biblioteka umieści na taśmie więcej danych, niż może zmieścić się na prawdziwej taśmie. Nie będzie możliwe utworzenie fizycznej kopii takiej taśmy. Aby do tego nie doszło, producenci zintegrowanych wirtualnych bibliotek taśmowych dbają o to, żeby kopie nie osiągały standardowego końca fizycznej taśmy. Firmy wytwarzające niezależne wirtualne biblioteki przypominają, że coś takiego zwiększa liczbę taśm, które trzeba kupić i obsługiwać, a tym samym koszty. Trzeba pamiętać, że jeśli nabyto zintegrowaną wirtualną bibliotekę i postanowiono nie korzystać z jej funkcji kopiowania taśm, może pełnić rolę niezależnej biblioteki. W czasie, gdy ta książka była pisana, niektórzy producenci wirtualnych bibliotek taśmowych współpracowali z wybranymi dostawcami niezależnego oprogramowania, aby umożliwić im kontrolowanie procesu kopiowania i jednocześnie pozwolić użytkownikowi na wykorzystanie funkcji zintegrowanej wirtualnej biblioteki taśmowej. Efektem tej współpracy może być połączenie ze sobą najlepszych elementów światów niezależnych i zintegrowanych wirtualnych bibliotek taśmowych.
Funkcje dyskowe godne uwagi W niniejszym punkcie omówiono kilka podstawowych funkcji, którym należy się przyjrzeć przed zakupem docelowego magazynu dyskowego. Ponieważ większość zaawansowanych funkcji jest projektowana przez producentów wirtualnych bibliotek taśmowych, przeważnie dotyczą one wyłącznie tych urządzeń.
314
|
Rozdz ał 9. Urządzen a arch w zujące
Pakiety Ponieważ to, co sprzedają producenci wirtualnych bibliotek taśmowych i rozwiązań NAS, jest przede wszystkim oprogramowaniem uruchamianym na określonego typu hostach lub urządzeniach, przyjrzyjmy się temu, w jakiej postaci tego typu systemy są oferowane. Część producentów wirtualnych bibliotek taśmowych i rozwiązań NAS to firmy wyłącznie programistyczne. Oznacza to, że można od nich kupić wyłącznie oprogramowanie, które współpracuje z procesorem i dyskiem należącymi do użytkownika. Niektórzy z tych producentów sprzedają urządzenia pełniące rolę interfejsu między klientami a wirtualną biblioteką taśmową lub magazynem danych NAS. Choć używa się ich oprogramowania i urządzenia interfejsowego, dysk zapewnia się we własnym zakresie. Część producentów preferuje sprzedaż oprogramowania dla całego rozwiązania obejmującego urządzenie interfejsowe, dysk i inne elementy. Producenci wyłącznie oprogramowania i urządzenia interfejsowego oczywiście umożliwiają wykorzystanie istniejącej macierzy, dzięki czemu można zmniejszyć koszty. Choć dostawcy kompleksowych rozwiązań są drożsi, w ich przypadku występuje najmniej problemów z integrowaniem.
Deduplikacja Prawdopodobnie jedną z najważniejszych kwestii do rozważenia jest dostępność funkcji deduplikacji. Jest to raczej intensywny proces, który sprawdza każdy blok danych dostarczanych do urządzenia i próbuje stwierdzić, czy określony blok pojawił się już wcześniej. Jeśli nie, blok jest magazynowany. W przeciwnym razie blok jest odrzucany i zapisywane jest tylko odwołanie do niego. Oto oczywiste przykłady duplikacji danych, które zostałyby wykryte przez proces deduplikacji i zapisane tylko raz: • Ten sam plik archiwizowany z pięciu różnych serwerów. • Cotygodniowe wykonywanie pełnej kopii zapasowej w sytuacji, gdy zmieniło się tylko
5% danych (95% byłoby zduplikowanymi blokami z zeszłego tygodnia).
• Sporządzanie każdego dnia pełnej kopii zapasowej bazy danych, która nie pozwala wyko-
nywać przyrostowych kopii zapasowych (większość danych byłaby powielonymi blokami z poprzedniego dnia). • Tworzenie przyrostowych kopii zapasowych dla plików codziennie zmieniających się, takich
jak plik arkusza kalkulacyjnego aktualizowanego każdego dnia. W przypadku zastosowania deduplikacji byłyby przechowywane wyłącznie zmiany wprowadzone każdego dnia. Rozważmy typowe centrum danych z kombinacją danych bazy i systemu plików, dla którego co tydzień jest sporządzana pełna kopia zapasowa, a codziennie — kopia przyrostowa. Przeciętny system deduplikacji może zredukować ilość miejsca zajmowanego przez kopie zapasowe dwadzieścia (współczynnik deduplikacji 20:1) lub więcej razy. Systemy wykonujące pełne miesięczne kopie zapasowe oferują mniejszy współczynnik deduplikacji. W dokumentacji producenta można spotkać się ze znacznie wyższymi wartościami współczynnika. Nie wolno popełnić błędu polegającego na porównywaniu dwóch dostawców na podstawie podawanych przez nich współczynników deduplikacji. Choć niektórzy producenci mogą być lepsi od innych pod względem eliminowania nadmiarowości danych, istotne jest to, jak dobrze przetwarza dane algorytm konkretnej firmy. Używając własnych danych, trzeba określić wydajność i współczynnik deduplikacji dla każdego systemu.
Docelowe magazyny dyskowe
|
315
Replikacja Jeśli każdorazowo podczas wykonywania kopii zapasowej są zapisywane wyłącznie nowe unikatowe bloki, następną godną uwagi funkcją jest replikacja, lub kaskadowanie (taki zamienny termin czasami jest stosowany w świecie wirtualnych bibliotek taśmowych). Funkcja umożliwia replikowanie na innym urządzeniu kopii zapasowych znajdujących się na urządzeniu dyskowym. Trzeba pamiętać, że bez deduplikacji danych (została omówiona wcześniej) replikowana będzie cała kopia zapasowa. Ponadto należy mieć świadomość tego, że większość kopii zapasowych to nie są kopie wykonywane na poziomie bloków. Nawet przyrostowe kopie zapasowe zajmują w przybliżeniu od jednego do pięciu procent rozmiaru archiwizowanych danych. Oznacza to, że każdej nocy trzeba będzie replikować od jednego do pięciu procent zasobów centrum danych, co w przypadku wielu środowisk jest znacznym przedsięwzięciem. A zatem jeśli używane urządzenie nie obsługuje deduplikacji, zastosowanie replikacji może być możliwe tylko w obrębie kampusu. Trzeba też wiedzieć, że kopie zapasowe umieszczone na drugim urządzeniu nie będą uważane przez oprogramowanie archiwizujące za duplikaty, ponieważ będą miały one identyczne kody kreskowe lub nazwy plików co oryginalne taśmy. To, jak wykorzysta się te taśmy w przypadku nieszczęśliwego zdarzenia lub braku zasilania, będzie zależne od posiadanego oprogramowania archiwizującego. Może być konieczne replikowanie katalogu kopii zapasowych i zainstalowanie kolejnego serwera archiwizującego w nowej lokalizacji. Jeśli stary serwer archiwizujący nadal jest aktywny, może być możliwe poinformowanie go, że podstawowa biblioteka taśmowa po prostu została przeniesiona w nowe miejsce. Zanim do tego dojdzie, trzeba mieć pewność, że się wie, jak postępować.
Rozpoznawanie zawartości Docelowy magazyn dyskowy z funkcją rozpoznawania zawartości analizuje formaty przesyłanych do niego kopii zapasowych i w razie możliwości ekstrapoluje z nich oryginalne dane. W uproszczonej wersji tego rozwiązania byłaby pobierana kopia zapasowa utworzona przez narzędzie tar, a następnie z niej byłyby wyodrębniane pliki. Jeżeli system rozpoznawania zawartości robiłby tylko tyle, nie oferowałby żadnych nowych możliwości. Jeśli jednak docelowy magazyn dyskowy może zamieniać kopie zapasowe na archiwizowane pliki, może też być w stanie robić coś jeszcze — coś, co określa się mianem wtórnej prezentacji. Produkty oferujące rozpoznawanie zawartości zwykle obsługują jedynie od trzech do pięciu komercyjnych produktów archiwizujących i mogą nie współpracować z narzędziami open source lub takimi, które mają niewielki udział w rynku.
Wtórna prezentacja Jeżeli docelowy magazyn dyskowy dysponuje funkcją rozpoznawania zawartości i ekstrapoluje oryginalne dane z kopii zapasowych, potencjalnie może wykonać kilka interesujących rzeczy przez wtórną prezentację danych użytkownikowi. Część produktów udostępnia dane za pomocą witryny internetowej z drzewem katalogowym, część zaś — korzystając z punktów podłączeń protokołu NFS lub CIFS. W każdym przypadku można uzyskać dostęp do wszystkich wersji pliku, które zostały zarchiwizowane na odpowiednim urządzeniu. Po znalezieniu pliku wystarczy przeciągnąć go i upuścić na pulpicie. Nie trzeba uczyć się obsługi żadnego graficznego interfejsu użytkownika ani też instalować aplikacji. Wystarczy użyć znanych już narzędzi.
316
|
Rozdz ał 9. Urządzen a arch w zujące
Funkcja wtórnej prezentacji wyznacza nowy rozdział w tradycyjnej archiwizacji przez zaoferowanie kolejnej metody dostępu do kopii zapasowych. Zbyt długo pliki i bazy danych archiwizowało się przy użyciu formatów, które do wyodrębnienia wymagały zastosowania oprogramowania archiwizującego. Taka sytuacja utrzymywała się na tyle długo, że właściwie dość trudno sobie wyobrazić nowe możliwości oferowane przez wtórną prezentację. Poniżej zamieszczono krótką listę ułatwiającą zorientowanie się w zaletach wtórnej prezentacji. • Rozwiązanie oferujące wyszukiwanie pełnotekstowe może być zastosowane bezpośrednio
dla kopii zapasowych. Dzięki temu w trybie pełnotekstowym mogą być przeszukiwane wszystkie wciąż zarchiwizowane pliki.
• Jeśli używa się wielu produktów archiwizujących, użytkownicy i administratorzy mogą
korzystać z jednej metody odtwarzania danych.
• Można sobie wyobrazić, jak proste byłyby dla końcowych użytkowników operacje odtwa-
rzania danych, gdyby po prostu można było wskazać je za pomocą punktu podłączenia, takiego jak \\serwer_archiwizujący\nazwa_klienta\data.
• Jeżeli urządzenie dyskowe umożliwia podłączenie kopii zapasowej w trybie odczytu-zapisu,
mogłaby ona pełnić rolę produkcyjnego systemu plików, który stał się niedostępny.
• A jakby tak funkcję wtórnej prezentacji można było wykorzystać do przejścia na inny pro-
dukt archiwizujący?
Ostatnie dwa punkty listy zasługują na trochę więcej niż tylko jedno zdanie. Załóżmy, że można podłączyć kopię zapasową jako wolumin z możliwością odczytu i zapisu. Produkcyjna baza danych mogłaby podłączyć taki wolumin, jeśli uszkodziłby się podstawowy wolumin. Wszelkie zmiany byłyby zapisywane i mogłyby zostać skopiowane na podstawowy system po przywróceniu jego woluminu. Ostatni punkt listy, w którym wspomniano o zmianie używanego produktu archiwizującego, też jest dość istotny. Każdy, kto przez jakiś czas sporządza kopie zapasowe, miał do czynienia z sytuacją, w której stosował produkt archiwizujący XYZ i w końcu chciał z niego zrezygnować. Być może produkt nie jest już dostępny lub jego producent nie ulepszył go w takim stopniu jak konkurencja. Dawniej przejście z jednego produktu archiwizującego na inny wymagało, aby pozostawić aktywną starą aplikację tak długo, jak długo trzeba było odtwarzać dane ze starszych kopii zapasowych.
Czy dyski mają być odłączane od zasilania? Krótka odpowiedź brzmi: nie. Gdy projektuje się dyski z myślą o długoterminowym przechowywaniu danych, nie bierze się pod uwagę tego, czy będą odłączane od zasilania. Jeśli zapyta się producenta dysków, jak długo można pozostawiać napęd bez zasilania, prawdopodobnie usłyszy się, że takich praktyk nie śledzi. Z założenia napędy dyskowe mają być włączone. A zatem pojawia się pytanie: czy przenośne napędy dyskowe są odpowiednim nośnikiem do przechowywania kopii zapasowych poza obrębem firmy? Większość producentów sprzedających takie urządzenia sugeruje, żeby używać ich tylko na potrzeby „cyklicznych” kopii zapasowych magazynowanych przez krótki okres, wynoszący kilka tygodni lub miesięcy. Jeden z producentów twierdzi, że wewnątrz pojedynczego dysku stosuje coś analogicznego do technologii RAID, aby wyeliminować problemy z uszkadzaniem poszczególnych obszarów dysku. Producent ten na tym samym dysku zapisuje bity parzystości, żeby umożliwić odtworzenie danych utraconych na skutek uszkodzenia obszarów dysku. Czas pokaże, czy rozwiązanie to się sprawdzi.
Docelowe magazyny dyskowe
|
317
Co by było, gdyby dane zostały zarchiwizowane na produkcie z funkcją rozpoznawania zawartości? Nie byłoby już konieczne dalsze używanie starej aplikacji archiwizującej, aby dało się odtworzyć dane z jej kopii zapasowych. Jedną z opcji byłoby pozostawienie starych kopii zapasowych w ich formacie i po prostu odtwarzanie z nich danych za pośrednictwem witryny internetowej lub systemu plików. Następną opcją byłoby podłączenie starych kopii zapasowych do nowego serwera archiwizującego i zarchiwizowanie ich danych w nowym formacie. Wystarczy pomyśleć, jaką to daje elastyczność.
Stertowanie Niektóre zintegrowane wirtualne biblioteki taśmowe oferują dodatkową funkcję nazywaną stertowaniem (ang. stacking). Funkcja ta, zapożyczona z wirtualnych systemów taśmowych serwerów przemysłowych, kopiuje zawartość wielu wirtualnych taśm na jedną fizyczną. Coś takiego miało sens w przypadku serwerów przemysłowych, których aplikacje nie były w stanie dołączać danych do istniejących na taśmie. Wirtualny system taśmowy udostępnia aplikacji setki niewielkich wirtualnych taśm, a następnie zapisuje je kolejno (stertuje) na jednej fizycznej taśmie, dając oszczędności na nośnikach wynoszące dziesiątki tysięcy złotych. Wartość tej funkcji w przypadku większości środowisk z systemami otwartymi jest mocno kwestionowana, ponieważ każdy przyzwoity produkt archiwizujący może dołączać dane do taśmy aż do jej zapełnienia. Trzeba mieć świadomość, że użycie funkcji stertowania powoduje przerwanie relacji między menedżerem nośników aplikacji archiwizującej i fizyczną taśmą. Ponadto trzeba wiedzieć, że część produktów obsługujących tę funkcję musi odczytać całą stertowaną taśmę, aby wczytać tylko jedną z wirtualnych taśm zapisanych na tej taśmie. W związku z tym powinno się korzystać z tej funkcji tylko wtedy, gdy uzyskuje się identyczne korzyści jak w przypadku środowiska z serwerami przemysłowymi.
Powiadamianie Ważne jest również, aby zwrócić uwagę na to, jakiego typu powiadamianie jest obsługiwane przez urządzenie dyskowe, zwłaszcza wtedy, gdy rozważa się zastosowanie zintegrowanej wirtualnej biblioteki taśmowej1. Część takich bibliotek obsługuje pułapki SNMP i powiadamianie za pośrednictwem poczty elektronicznej, część wymaga od użytkownika zalogowania się na stronie internetowej w celu zapoznania się z wszelkimi problemami.
Dysk-jako-taśma — zasobniki wirtualnych taśm Inna obecnie stosowana metoda emulowania taśmy przez dysk polega na użyciu zasobników wirtualnych taśm. Po umieszczeniu w bibliotece taśmowej zasobniki te pod każdym względem mają przypominać taśmę, z uwzględnieniem wymienności. Jednak w rzeczywistości zasobniki te są dyskiem. W czasie pisania książki było to zupełnie nowe rozwiązanie, które może się przyjąć lub nie. Obecnie można wyróżnić trzy typy zasobników wirtualnych taśm. W przypadku pierwszego typu zasobników macierz dysków jest umieszczona w kanistrze większym od standardowej taśmy, lecz obsługiwanym przez określony model biblioteki taśmowej. Biblioteka wsuwa zasobnik wirtualnej taśmy do wirtualnego napędu i wyciąga go z niego, 1
Zintegrowana wirtualna biblioteka taśmowa kopiuje zawartość wirtualnej taśmy na fizyczną bez wiedzy serwera archiwizującego. Jeśli coś pójdzie nie tak, jedyne powiadomienie zostanie przekazane przez bibliotekę. A zatem funkcje powiadamiania są znacznie ważniejsze w przypadku zintegrowanych wirtualnych bibliotek taśmowych.
318
|
Rozdz ał 9. Urządzen a arch w zujące
a następnie z powrotem umieszcza w gnieździe umożliwiającym zabranie zasobnika tak jak każdego innego. Zaletą tego rozwiązania jest to, że zasobnik wirtualnej taśmy jest chroniony przez technologię RAID. Z kolei wadą jest to, że rozmiar zasobnika jest obsługiwany tylko przez jednego producenta bibliotek taśmowych. W przypadku drugiego typu zasobników pojedynczy napęd, podobny do stosowanych w laptopach, jest umieszczany w zasobniku, który wygląda dokładnie jak zasobnik LTO i używa specjalnie zaprojektowanego wirtualnego napędu taśm akceptującego tylko ten zasobnik. Jeśli taki zasobnik wirtualnej taśmy umieści się w prawdziwym napędzie LTO, napęd wysunie go. Podobnie będzie w odwrotnym przypadku. Zarówno napęd, jak i zasobnik mają taki sam rozmiar co napęd i zasobnik LTO. W związku z tym mogą być zintegrowane z biblioteką dowolnego producenta obsługującego format LTO. Oczywiście zasobnik wirtualnej taśmy jest w takim samym stopniu chroniony przez technologię RAID co zasobnik innej taśmy. Choć koszt tego typu zasobnika wirtualnej taśmy jest wyższy od fizycznej taśmy, oferuje on korzyści z posiadania dysku i taśmy w jednym wymiennym zasobniku. Trzeci typ zasobnika jest promowany przez kilka firm, które nie uznały, że potrzebne jest zaprojektowanie zasobnika mającego taki sam kształt co istniejąca taśma. A zatem tego typu zasobniki prawdopodobnie będą ograniczone wyłącznie do niezależnego stosowania. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Docelowe magazyny dyskowe
|
319
320
|
Rozdz ał 9. Urządzen a arch w zujące
CZĘŚĆ IV
Przywracanie komputera od podstaw
Część IV składa się z następujących pięciu rozdziałów: Rozdział 10. „Przywracanie od podstaw komputera z systemem Solaris” W rozdziale wyjaśniono, jak za pomocą narzędzia Flash Archive firmy Sun przywrócić komputer od podstaw. Rozdział 11. „Systemy Linux i Windows” W rozdziale zamieszczono kilka procedur i narzędzi, które mogą być użyte do przywrócenia od podstaw komputerów z systemami Linux i Windows. Rozdział 12. „Przywracanie od podstaw komputera z systemem HP-UX” Rozdział omawia narzędzia make_net_recovery i make_tape_recovery, które obecnie są dołączone do systemu HP-UX, aby możliwe było przywrócenie komputera od podstaw. Rozdział 13. „Przywracanie od podstaw komputera z systemem AIX” W rozdziale przedstawiono program mksysb systemu AIX, który prawdopodobnie jest jednym z najstarszych i najlepiej znanych narzędzi przeznaczonych do przywracania komputera od podstaw. Rozdział 14. „Przywracanie od podstaw komputera z systemem Mac OS X” W rozdziale wyjaśniono, w jaki sposób przywrócić od podstaw komputer z systemem Mac OS X.
ROZDZIAŁ 10.
Przywracanie od podstaw komputera z systemem Solaris
Flash Archive jest elastycznym, przenośnym i prostym w użyciu narzędziem umożliwiającym przeprowadzenie instalacji, powielania i przywracania od podstaw komputerów z systemem Solaris. Dokumentacja stworzona przez firmę Sun prezentuje ten produkt przede wszystkim jako narzędzie służące do powielania i instalowania. Jednak ze względu na to, że można utworzyć obraz działającego systemu operacyjnego, a następnie użyć go podczas procesu inicjalizowania nowego komputera do przeprowadzenia na nim „instalacji” systemu, narzędzie Flash Archive idealnie nadaje się do przywracania komputera od podstaw. Właśnie na tym zastosowaniu koncentruje się niniejszy rozdział. Ponieważ narzędzie działa bardzo podobnie do programu mksysb systemu AIX, można je z nim porównywać. Narzędzie Flash Archive eliminuje wszystkie ograniczenia programu ufsrestore systemu Solaris, który wymagał, aby wszystkie komputery były wyposażone w taki sam sprzęt i jądro, a ponadto w celu umożliwienia przywrócenia komputera od podstaw żądał zdefiniowania drzewa urządzeń. Narzędzie Flash Archive jest dostępne dla systemu Solaris 8 i jego nowszych wersji. Jest w pełni obsługiwane przez wszystkie serwery firmy Sun zarówno z 32-, jak i 64-bitowym jądrem. W tworzeniu tego rozdziału brał udział Aaron Gersztoff. Przez ponad 10 lat Aaron był zawodowo związany z ochroną danych przedsiębiorstw i przywracaniem po awarii. Aaron jest zagorzałym fanem baseballa, który lubi odwiedzać stadion każdej drużyny najważniejszych lig.
Zastosowanie narzędzia Flash Archive W poniższych punktach wyjaśniono, jak narzędzie Flash Archive może być użyte do przywrócenia komputera od podstaw. Zamieszczono również listę pytań, które należy wziąć pod uwagę podczas konfigurowania narzędzia Flash Archive.
Ogólne informacje na temat archiwizowania i odtwarzania Ten punkt zawiera krótki przegląd podstawowego procesu archiwizowania i odtwarzania systemu operacyjnego Solaris za pomocą narzędzia Flash Archive. 323
Tworzenie kopii zapasowej 1. Wykonując polecenie flar create, na dysku (na przykład podłączonym przy użyciu usługi NFS) lub taśmie należy utworzyć obraz.
2. Jeśli obraz narzędzia Flash Archive zapisze się na dysku, za pomocą polecenia dd obraz ten można też umieścić na taśmie.
Choć na podstawie takiego obrazu można utworzyć startowy dysk CD lub DVD, w rozdziale nie omówiono tego zagadnienia.
Odtwarzanie 1. Jeśli planuje się odtwarzanie danych z taśmy, w napędzie taśmowym lokalnym względem przywracanego komputera należy umieścić taśmę z obrazem narzędzia Flash Archive.
2. Korzystając z instalacyjnego dysku CD systemu Solaris lub sieci, należy załadować przywracany komputer.
3. Standardowy proces ładowania systemu należy kontynuować do momentu pojawienia się panelu Specify Media.
4. Zależnie od lokalizacji obrazu narzędzia Flash Archive należy wybrać pozycję Network File System lub Local Tape.
5. Po wybraniu obrazu, za pomocą którego przeprowadzi się proces odtwarzania, należy udzielić odpowiedzi na serię pytań.
Jeśli ustawi się odtwarzanie bez interakcji, kroki od 3. do 5. zostaną automatycznie wykonane (przy wykorzystaniu plików konfiguracyjnych).
Wstępne kwestie do rozważenia Jest wiele rzeczy, które trzeba uwzględnić przed zastosowaniem narzędzia Flash Archive. Niniejszy punkt pomoże Czytelnikowi wybrać na podstawie postawionych wymagań najlepszą metodę archiwizowania i odtwarzania.
Wymagania systemowe Narzędzie Flash Archive ma następujące minimalne wymagania systemowe: • system operacyjny Solaris 8 (HW 04/01) lub nowszy, • przestrzeń dyskowa wystarczająca do zapisania obrazu narzędzia Flash Archive lub ob-
sługiwany napęd taśmowy podłączony do komputera lokalnie lub zdalnie.
Należy przetestować proces przywracania za pomocą obrazu narzędzia Flash Archive, zanim naprawdę konieczne będzie jego wykonanie. Z pewnością Czytelnik nie będzie zadowolony, gdy stwierdzi, że nowy system nie jest obsługiwany lub wybrana metoda przywracania nie działa.
324 |
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
Podczas odtwarzania przy użyciu istniejącego obrazu komputer z systemem firmy Sun musi być wyposażony w napęd CD lub DVD i ładowalny dysk CD lub DVD z systemem operacyjnym Solaris lub mieć dostęp do sieciowego serwera rozruchowego z systemem Solaris, który obsługuje instalacje przy wykorzystaniu obrazów narzędzia Flash Archive. Użyta wersja systemu Solaris powinna być taka sama jak wersja tego systemu zainstalowana na źródłowym komputerze lub nowsza. Przykładowo w przypadku przywracania serwera z systemem Solaris 9 (HW 09/05) do załadowania komputera powinno się użyć dysku CD lub DVD tej wersji systemu lub nowszej (choć ważność tego wymagania zmienia się w zależności od wersji systemu operacyjnego, w celu uniknięcia problemów usilnie namawiam do zastosowania dysku tej samej lub nowszej wersji systemu). Jeśli operację odtwarzania zamierza się wykonać na odmiennym sprzęcie, archiwizowany komputer powinien zawierać całą dystrybucję systemu Solaris z uwzględnieniem obsługi OEM (SUNWCXALL). Jeżeli na komputerze z innymi peryferiami lub odmienną architekturą (na przykład z magistralą Sbus zamiast PCI) przywraca się ograniczoną dystrybucję systemu Solaris, mogą być nieobecne wymagane sterowniki i w efekcie proces odtwarzania nie powiedzie się. Jeśli odtwarzanie planuje się wykonać przy wykorzystaniu identycznego sprzętu, powyższy wymóg nie obowiązuje.
Częstość wykonywania kopii zapasowej Indywidualne wymagania Czytelnika determinują to, jak często będą tworzone obrazy narzędzia Flash Archive. Jeśli używa się ich wyłącznie na potrzeby przywracania komputera od podstaw, zdecydowanie nowy obraz trzeba utworzyć każdorazowo, gdy na serwerze wprowadzi się zmianę, która ma być uwzględniona podczas przywracania od podstaw. Jednak większość użytkowników korzystających z obrazów narzędzia Flash Archive automatyzuje operację regularnego ich sporządzania. Dzięki temu zapewnia się, że obrazy systemowe zawsze są aktualne.
Archiwizować na dysku czy na taśmie? Obrazy narzędzia Flash Archive mogą być zapisywane bezpośrednio na dysku lub taśmie. Trzeba wybrać ten wariant, który lepiej spełnia stawiane wymagania. Dużą rolę podczas decydowania, czy użyć taśmy czy dysku, odgrywa sposób, w jaki planuje się wykorzystywać obrazy. Jeśli na przykład obrazy narzędzia Flash Archive są tworzone wyłącznie z myślą o procesie przywracania komputera od podstaw przeprowadzanym poza firmą, można uznać, że właściwe będzie środowisko bazujące tylko na taśmach. W większości środowisk stosuje się kombinację taśmy i dysku. Polega to na zapisywaniu na dysku obrazu narzędzia Flash Archive, a następnie okresowemu kopiowaniu obrazu na taśmę. Dzięki temu kopię obrazu można wysłać poza obręb firmy w celu odtworzenia po awarii, pozostawiając jednocześnie obraz na miejscu na potrzeby lokalnego przywracania serwera. Firmy mogą też zdecydować się na wdrożenie serwera obrazów narzędzia Flash Archive. W tym przypadku obrazy są magazynowane na centralnym serwerze i z niego pobierane podczas odtwarzania. Wielu administratorów systemu korzysta również z istniejących serwerów inicjalizujących Jumpstart, aby przechowywać obrazy narzędzia Flash Archive (Jumpstart jest narzędziem firmy Sun upraszczającym instalację systemu Solaris). W ten sposób w tym samym miejscu zapewnia się inicjalizację komputera za pośrednictwem sieci i dostępność obrazu dającego możliwość przeprowadzenia procesu przywracania. W każdym przypadku do serwera może być podłączony jeden lub więcej napędów taśmowych w celu zaoferowania prostej metody tworzenia przenośnych kopii obrazu na potrzeby magazynowania na zewnątrz firmy. Zastosowan e narzędz a Flash Arch ve
|
325
Jeżeli rozważa się zastosowanie dysku, trzeba pamiętać, że wymagana jest przestrzeń dyskowa wystarczająca do przechowywania obrazów narzędzia Flash Archive. Zależnie od opcji wybranych w czasie tworzenia obrazu jego rozmiar zwykle stanowi od 75 do 100% wielkości systemów plików zawartych w obrazie.
Odtwarzać z taśmy czy z dysku? Obraz narzędzia Flash Archive może być użyty lokalnie do przywrócenia systemu operacyjnego Solaris serwera, który miał awarię. W tym przypadku taśma lub zasób podłączony za pomocą usługi NFS zapewniają znakomite źródło odtwarzanych danych. Jeśli pozwala na to sprzęt i zasoby sieciowe, zaleca się, aby obrazy były magazynowane na dysku i odtwarzane za pośrednictwem punktu podłączenia NFS. Ogólnie rzecz biorąc, metoda ta wymaga mniejszej ilości lokalnie podłączonego sprzętu (przydatne podczas przywracania wielu serwerów) i zazwyczaj oferuje szybkość większą niż w przypadku taśmy. Obraz narzędzia Flash Archive może też posłużyć do odtworzenia komputera znajdującego się poza obrębem firmy (na przykład gdy dojdzie do jakiegoś nieszczęśliwego wydarzenia). W tym przypadku wybrana firma może postanowić, że najlepszą opcją jest przywrócenie krytycznych serwerów bezpośrednio z taśmy. Zależnie od kilku czynników (liczba serwerów do przywrócenia, dostępność sprzętu itp.) inne firmy mogą zdecydować się na odtworzenie zawartości wszystkich obrazów na dysk, a następnie przeprowadzenie faktycznych operacji przywracania przy wykorzystaniu punktu podłączenia NFS. Następna opcja warta wspomnienia polega na użyciu powielania w połączeniu z obrazami narzędzia Flash Archive w celu wdrażania nowych serwerów. Opcja ta umożliwia użytkownikom przeprowadzanie na serwerach standardowej i niezależnej sprzętowo instalacji, znacznie szybciej, niż gdyby system Solaris musiał być instalowany oddzielnie na każdym komputerze. Ponieważ tematem tego rozdziału jest przywracanie komputera od podstaw, metoda ta nie zostanie omówiona.
Odtwarzanie interaktywne czy nie? Wybierając sposób tworzenia obrazu narzędzia Flash Archive, trzeba najpierw zdecydować, czy ma być możliwe przeprowadzenie interaktywnego procesu odtwarzania, czy nie. Choć interaktywne odtwarzanie prawie w ogóle nie wymaga wstępnej konfiguracji, w czasie jego wykonywania trzeba podać więcej danych wejściowych. Ponadto z procesem tym może się wiązać znacznie większa liczba czynności wykonywanych po ukończeniu odtwarzania. Co prawda nieinteraktywna metoda odtwarzania wymaga więcej działań konfiguracyjnych, lecz w czasie przeprowadzania procesu (gdy czas zwykle jest bardzo istotny) trzeba wprowadzić niewielką ilość danych wejściowych, lub nawet nie trzeba wprowadzać żadnych danych. Obie metody odtwarzania są uważane na dopuszczalne. Jednak ze względu na to, że zazwyczaj czas odgrywa największą rolę, gdy serwer jest niedostępny, większość administratorów systemu uznaje, że szkoda czasu na tworzenie plików i skryptów z myślą o nieinteraktywnej metodzie odtwarzania.
Inne ograniczenia środowiska Wiele organizacji używa stref zdemilitaryzowanych i innych narzędzi sieciowych, żeby ograniczyć dostęp do środowiska produkcyjnego z określonych komputerów. Jeśli tak jest w przypadku firmy, z którą jest związany Czytelnik, pod uwagę powinien wziąć wpływ takich rozwiązań na wdrożenie obrazów narzędzia Flash Archive. 326
|
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
Zaleca się, aby infrastruktura obrazów narzędzia Flash Archive istniejąca w strefie zdemilitaryzowanej powielała to, co jest dostępne w środowisku produkcyjnym. Wymagana infrastruktura obejmuje na przykład napędy taśmowe, serwery NFS i serwery archiwizujące. Jeżeli nie są dostępne zasoby powielające infrastrukturę środowiska produkcyjnego, trzeba dysponować sprawdzonym i niezawodnym procesem archiwizowania i odtwarzania serwerów w strefie zdemilitaryzowanej.
Przygotowanie do interaktywnego odtwarzania Najprostszym sposobem, aby zacząć korzystać z obrazów narzędzia Flash Archive, jest utworzenie kopii zapasowych na potrzeby procesu interaktywnego odtwarzania. Choć wymaga to większej ilości pracy podczas przywracania, w zaledwie kilka minut będzie się dysponować kopią zapasową umożliwiającą inicjalizację. W dalszej części rozdziału wyjaśniono, jak taką metodę archiwizowania przenieść na następny poziom przez odtwarzanie bez interakcji.
Tworzenie obrazów narzędzia Flash Archive Uzyskanie solidnego, powtarzalnego i sprawdzonego procesu archiwizacji jest kluczem do tego, aby mieć możliwość odtworzenia danych, gdy pojawi się taka potrzeba. W tym punkcie opisano kroki niezbędne do utworzenia obrazu narzędzia Flash Archive, począwszy od określenia systemów plików, które zostaną dołączone, a skończywszy na procesie tworzenia taśmy (w razie potrzeby).
Wybieranie systemów plików przeznaczonych do archiwizacji Choć w obrazie narzędzia Flash Archive można umieścić dowolny system plików, zwykle do przywrócenia komputera z systemem Solaris są wymagane jedynie systemy plików z danymi systemu operacyjnego. Dane odtwarzane z systemów plików, których nie utworzono podczas przywracania, prawdopodobnie zostaną umieszczone w obrębie głównego systemu plików. Może to mieć poważne konsekwencje, zwłaszcza wtedy, gdy całkowita pojemność danych do odtworzenia przekracza rozmiar głównego systemu plików. Jeśli planuje się przeprowadzić nieinteraktywny proces odtwarzania i w kopii zapasowej postanowi uwzględnić wszystkie systemy plików bez danych systemu operacyjnego, systemy te będzie trzeba wymienić w pliku profile, aby zostały utworzone przed rozpoczęciem przywracania (konfiguracja nieinteraktywnego odtwarzania została omówiona w dalszej części rozdziału).
Zastosowanie polecenia flar create Polecenie flar create systemu Solaris tworzy obrazy narzędzia Flash Archive. Proces może być realizowany przy użyciu skryptu i narzędzia harmonogramującego, takiego jak cron, lub ręcznie. Jeżeli ręcznie wykona się polecenie flar create i zamierza się przeprowadzić proces nieinteraktywnego odtwarzania, ze względu na wstępne wymagania operacji tworzenia taśmy obraz powinien zostać umieszczony na dysku, a następnie skopiowany na taśmę. Dokumentacja programu flar zawiera aktualną składnię i opis jego obsługi. Poniżej wymieniono opcje stosowane w przykładach. Przygotowan e do nteraktywnego odtwarzan a
|
327
create
Opcja nakazuje programowi flar utworzenie archiwum. info
Gdy nie podało się żadnych dodatkowych znaczników, opcja ta sprawdza archiwum i wyświetla znalezione w nim informacje podsumowujące. Jeśli użyje się znacznika -l, opcja info wygeneruje listę plików zawartych w archiwum (opcje create i info wzajemnie się wykluczają). -c
Opcja nakazuje programowi flar skompresowanie archiwum podczas jego zapisywania. -n
Opcja pozwala nadać archiwum nazwę, która jest przechowywana wewnątrz niego. Później można skorzystać z tej nazwy, gdy okaże się, że nazwa pliku nie jest zbyt przydatna. nazwa_pliku lub urządzenie_taśmowe
Łańcuchy pozwalają przekazać programowi flar nazwę pliku lub urządzenia taśmowego, na którym zostanie wykonany zapis.
Poniżej zaprezentowano przykład polecenia flar create wykonanego w systemie Solaris 9. W tym przypadku program flar kompresuje archiwum (opcja -c), nadaje mu nazwę sun2.flar (-n sun2.flar) i w roli nazwy pliku kopii zapasowej również używa nazwy sun2.flar. # flar create -c -n sun2.flar sun2.flar Full Flash Checking integrity... Integrity OK. Running precreation scripts... Precreation scripts done. Determing the size of the archive... 3949130 blocks The archive will be approximately 1.01GB. Creating the archive... 3949130 blocks Archive creation complete. # echo $? 0
Warto zauważyć, że po utworzeniu archiwum sprawdzono zwracany kod, wykonując polecenie echo $?. Zwracanie przez system Solaris kodu jest podstawową metodą określania wyniku polecenia flar create. Kod o wartości 0 wskazuje na udane zakończenie operacji, natomiast każda inna wartość oznacza niepowodzenie. Po uzyskaniu po wykonaniu polecenia flar create kodu 0 można zastosować polecenia flar info i flar info -l, aby upewnić się, że powiódł się proces tworzenia obrazu. Jeśli kod zwrócony przez polecenie flar create lub wynik polecenia flar info wskazuje na problem, archiwum powinno zostać uznane za podejrzane. W poniższym przykładzie pokazano wynik wykonania polecenia flar info nazwa_obrazu. # flar info sun2.flar archive_id=c80af5b0c18ef7a9375e124c07f56875 files_archived_method=cpio creation_date=20060211192433 creation_master=sun2 creation_name=sun2.flar creation_node=sun2
328
|
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
creation_hardware_class=sun4m creation_platform=SUNW,SPARCstation-5 creation_processor=sparc creation_release=5.9 creation_os_name=SunOS creation_os_version=Generic_118558-11 files_compressed_method=compress files_archived_size=470522936 content_architectures=sun4m type=FULL
Oprócz wyświetlenia ogólnych informacji na temat obrazu narzędzia Flash Archive można uzyskać listę plików zawartych w obrazie. Umożliwia to polecenie flar info -l nazwa_obrazu. # flar info -l sun2.flar lost+found export export/home0 export/home0/lost+found export/home0/rules export/home0/rules.ok export/home0/sysidcfg export/home0/standard.profile ~list truncated~ platform/sun4u/kernel/drv/sparcv9 platform/sun4u/kernel/drv/sparcv9/scmi2c
Tworzenie taśmy z obrazem narzędzia Flash Archive Po utworzeniu obrazu na dysku można zapisać go na taśmie, aby przeprowadzić proces przywracania komputera od podstaw. W tym celu trzeba skorzystać z polecenia dd. # mt -f /dev/rmt/0n rewind # dd if=sun2.flar of=/dev/rmt/0n obs=1024000
Tworząc taśmę z obrazem, należy skorzystać z napędu taśmowego, który używa sterowników systemu operacyjnego Solaris i nie stosuje niestandardowych wpisów pliku /kernel/drv/st.conf. Użycie takich wpisów może spowodować problemy niezauważalne podczas odtwarzania.
Proces przywracania komputera od podstaw przy użyciu obrazu narzędzia Flash Archive Gdy już utworzono obraz narzędzia Flash Archive, można go wykorzystać do interaktywnego odtwarzania komputera z systemem Solaris. W tym celu należy wykonać następujące kroki:
1. Najpierw należy sprawdzić, czy system jest załadowany i widoczny jest wiersz interpretera poleceń ok>.
2. Jeśli nie ma się pewności, czy są dostępne urządzenia związane z inicjalizowaniem i odtwarzaniem, należy przeprowadzić test przez wykonanie poniższego polecenia. ok> probe-scsi-all
Powinna zostać wyświetlona lista lokalnie podłączonych urządzeń. Trzeba zadbać o to, aby na liście przynajmniej pojawił się lokalny dysk rozruchowy, napęd CD lub DVD (jeśli jest potrzebny) i odpowiednie napędy taśmowe SCSI.
Przygotowan e do nteraktywnego odtwarzan a
|
329
3. Jeżeli planuje się odtwarzanie danych z taśmy, należy umieścić ją w lokalnym napędzie taśmowym.
4. W dalszej kolejności należy załadować system. a. Jeśli system ładuje się z dysku CD, w odpowiednim napędzie komputera przeznaczonego do odtworzenia należy umieścić instalacyjny dysk CD systemu Solaris, a następnie w wierszu poleceń ok> wykonać polecenie boot cdrom. b. Jeżeli skonfigurowano sieciowy serwer rozruchowy, korzystając z polecenia boot net -install, można też dokonać inicjalizacji komputera za pośrednictwem sieci.
5. Komputer jest uruchamiany, a następnie pojawiają się pytania standardowej instalacji systemu Solaris. Po wyświetleniu okna Specify Media należy wybrać opcję 5 (odtwarzanie z lokalnej taśmy) lub 2 (odtwarzanie z punktu podłączenia NFS).
a. Jeśli wybierze się taśmę, pojawi się prośba o podanie nazwy urządzenia taśmowego i pliku znajdującego się na taśmie, w którym umieszczono obraz. Trzeba pamiętać, że 0 identyfikuje pierwszy plik na taśmie. b. Jeżeli użytkownik postanowi skorzystać z punktu podłączenia NFS, zostanie poproszony o nazwę serwera NFS i udział udostępniający obrazy narzędzia Flash Archive. Następnie powinien wybrać jeden z obrazów.
6. W dalszej kolejności pojawi się prośba o podanie nazwy dysku, na którym mają być odtworzone dane, a także określenie sposobu partycjonowania dysku. Udzielane odpowiedzi należy dostosować do zarządzanego środowiska.
7. Po wykonaniu powyższych kroków proces odtwarzania powinien zostać automatycznie ukończony, a następnie nastąpi ponowne uruchomienie komputera.
Przykład procesu interaktywnego przywracania W poniższym przykładzie jest przywracana zawartość obrazu zapisanego na taśmie. Jeśli obrazy znajdują się na dysku, zamiast opcji 5 należy wybrać opcję 2. Please specify the media from which you will install the Solaris Operating Environment. Media: 1. 2. 3. 4. 5.
CD/DVD Network File System HTTP (Flash archive only) FTP (Flash archive only) Local Tape (Flash archive only) Media [1]: 5
Please specify the local tape device and the position on the tape where the Flash archive is located. To select a different media, enter B to go Back. Tape Device or B [/dev/rmt/0] /dev/rmt/0n Tape Position or B [1] 0 You selected the following Flash archives for initial install: Tape /dev/rmt/0n
330
|
0
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
Press Return to continue or enter D to deselect all archives: To select additional Flash archives, please specify the media where the archives are located. Media: 1. 2. 3. 4. 5. 6.
CD/DVD Network File System HTTP FTP Local Tape None - Archive Selection Complete
Jeśli istnieją archiwa zawierające dodatkowe systemy plików, można je określić na tym etapie. Media [6]: The system is being initialized, please wait... Select which disks you want to lay out the file systems on. Available Disks: Disk Size c0t0d0 4000 MB Enter 'y' to layout file systems on the specified disk. This will erase all existing data on the disk. Enter 'n' to leave the disk unmodified. Enter 'e' to leave the remaining disks unmodified and continue with install. Layout file systems on disk c0t0d0 (bootdisk) (y/n) [y]? y At least one of the disks selected for installing Solaris software has file systems or unnamed slices that you can choose to preserve. Do you want to preserve existing data? Enter y to preserve data or n to skip data preservation. [n] The Solaris Installer is determining size requirements based on your choices, please wait... \ File System operations: 1. 2. 3. 4.
Print the current partition table Modify a disk's partition table Return to beginning Done
Select the number corresponding to a file system operation, 'Return to beginning' to change selections, or 'Done' to proceed with the install [4]: 1 Disk Name c0t0d0
Slice Name
Size(Mb)
/ swap
2000 514
File System operations: 1. 2. 3. 4.
Print the current partition table Modify a disk's partition table Return to beginning Done
Przygotowan e do nteraktywnego odtwarzan a
|
331
Select the number corresponding to a file system operation, 'Return to beginning' to change selections, or 'Done' to proceed with the install [4]: 4 The following items will be installed: Tape /dev/rmt/0n 0 Root Device: c0t0d0 File Systems: c0t0d0s1 / 2000 MB c0t0d0s1 swap 514 MB Enter 'y' to accept these values and start the installation, or 'n' to return to disk selection to make changes (y/n): y Installing... Extracting archive(s) Enter 'y' to accept these values and start the installation, or 'n' to return to disk selection to make changes (y/n): y Installing... (Note: The progress meter may not move during the extraction.) Extracting archive(s) |-1%----------------25%----------------50%----------------75%----------------100%| ...usunięte wiersze... Feb 18 09:19:45 rpcbind: rpcbind terminating on signal. syncing file systems... done rebooting... Resetting ...
Proces przywracania danych z obrazu został ukończony. Po ponownym uruchomieniu komputera można kontynuować określanie informacji systemowych, takich jak nazwa węzła i parametry sieciowe.
Przygotowanie nieinteraktywnego procesu odtwarzania Choć definiowanie nieinteraktywnego procesu odtwarzania wiąże się z większym nakładem pracy, jego przeprowadzenie będzie znacząco ułatwione. Oprócz możliwości przywracania bez wymogu interakcji ma on następujące funkcje: • Możliwość wykonywania zadań przed rozpoczęciem instalacji i konfigurowania zmiennych
przed zainicjowaniem procesu odtwarzania w przypadku komputerów z różnym sprzętem. • Możliwość wykonywania zadań po zakończeniu instalacji i przed ponownym uruchomie-
niem komputera finalizującym proces. Te zadania to instalacja oprogramowania, modyfikowanie procesu ładowania itp.
Pliki konfiguracyjne nieinteraktywnego procesu odtwarzania Narzędzie Jumpstart od wielu lat jest wykorzystywane do automatyzowania instalacji systemu Solaris. Po części narzędzie Flash Archive używa tej samej technologii co Jumpstart. Przykładowo narzędzie stosuje pliki: profile, rules i sysidcfg, aby zapewnić możliwość przeprowadzenia nieinteraktywnego procesu odtwarzania przy użyciu obrazu narzędzia Flash Archive. A zatem
332
|
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
na etapie przygotowania do nieinteraktywnego odtwarzania oprócz tego obrazu trzeba utworzyć wymienione pliki. W dalszej kolejności trzeba zadbać o to, żeby właścicielem każdego z tych plików był superużytkownik, a ponadto dla plików były ustawione uprawnienia 644.
Plik profile Plik profile określa systemy plików przeznaczone do archiwizacji, miejsce docelowe kopii zapasowych i metodę instalacji używaną podczas procesu przywracania. Nazwa profilu może być dowolna, pod warunkiem że podano ją w pliku rules. Profile mogą być statyczne lub tworzone dynamicznie za pomocą skryptu inicjującego. Profile drugiego typu są nazywane profilami pochodnymi. Poniżej przedstawiono przykład profilu statycznego, w którym znajduje się kilka wierszy parametrów z podanymi wartościami oddzielonymi spacjami. Tworząc profil statyczny, trzeba się upewnić, że jego właścicielem jest superużytkownik, a ponadto że dla pliku profilu ustawiono uprawnienia 644. Poniższe parametry powinny być uwzględnione w każdym profilu tworzonym z myślą o zastosowaniu go razem z obrazem narzędzia Flash Archive. install_type
W celu identyfikacji procesu przywracania opartego na obrazie powinno się użyć wartości flash_install (należy pamiętać, że profile są stosowane także na potrzeby innych programów, takich jak narzędzie Jumpstart). archive_location
Parametr umożliwia określenie lokalizacji danych pobieranych przez proces nieinteraktywnego odtwarzania. Jako wartość parametru można wstawić local_tape nazwa_urządzenia nr_pliku lub nfs serwer_nfs:/ścieżka/plik_obrazu. partitioning
Ponieważ dane są odtwarzane z obrazu narzędzia Flash Archive, należy samemu przeprowadzić partycjonowanie, tak aby można było utworzyć systemy plików zgodne z takim procesem przywracania, a także ogólnym planem odzyskiwania danych. Używając parametru explicit, należy zastosować słowo kluczowe filesys, żeby określić dostępną przestrzeń dyskową i przeprowadzić jej partycjonowanie. filesys
Należy określić jeden lub więcej wierszy z nazwami partycji systemów plików (z uwzględnieniem partycji swap). Każdy wiersz musi zawierać słowa kluczowe filesys nazwa_dysku rozmiar punkt_podłączenia. install_type flash_install archive_location local_tape partitioning explicit filesys c0t0d0s0 7000 / filesys c0t0d0s1 2000 swap
/dev/rmt/0n 1
W przykładzie przedstawiono istniejący profil statyczny kopiowany na taśmę. W czasie przywracania skrypt inicjujący może dynamicznie utworzyć profil pochodny lub niestandardowy. Skrypt ten zapewnia zwiększoną elastyczność podczas odtwarzania komputerów o różnej konfiguracji sprzętowej. Spośród przykładów takiej elastyczności należy wymienić testowanie urządzeń komputera, proszenie użytkownika o dane przy wybieraniu i partycjonowaniu dysków, a także określanie napędu taśmowego, który zostanie użyty.
Przygotowan e n e nteraktywnego procesu odtwarzan a
|
333
Poniżej zamieszczono prosty skrypt inicjujący, który tworzy profil pochodny przypominający profil statyczny pokazany w dalszej części rozdziału. Podobnie do profilu skrypt może być dowolnie nazwany (nazwa skryptu po prostu musi być podana w pliku rules). #!/bin/sh echo "install_type flash_install" echo "archive_location local_tape echo "partitioning explicit" echo "filesys c0t0d0s0 7000 echo "filesys c0t0d0s1 2000
> ${SI_PROFILE} /dev/rmt/0n 1" >> ${SI_PROFILE} >> ${SI_PROFILE} / " >> ${SI_PROFILE} swap" >> ${SI_PROFILE}
Tworząc skrypt inicjujący, trzeba zastosować widoczną wyżej zmienną ${SI_PROFILE}.
Jest to bardzo prosty skrypt i jego tworzenie zdaje się nie mieć sensu, ponieważ generuje profil dokładnie taki jak profil statyczny zaprezentowany w przykładzie. Jednakże wystarczy trochę kreatywnych działań, żeby skrypt inicjujący zamienić w bardzo przydatne narzędzie, które będzie mogło testować urządzenia komputera, sprawdzać minimalne pojemności dysków i żądać od użytkownika wartości dla nieznanych zmiennych. Przykładowo skrypt może wyświetlić listę napędów taśmowych i poprosić użytkownika o wybranie jednego z nich. Więcej informacji na temat tworzenia skryptu inicjującego można znaleźć w dokumentacji poświęconej przywracaniu danych przy użyciu obrazu narzędzia Flash Archive.
Plik rules Plik rules określa, jaki profil, skrypty inicjujące i finalizujące są stosowane podczas procesu odtwarzania. Plik rules.ok jest tworzony automatycznie po wykonaniu polecenia check dla pliku rules. Struktura pliku wygląda następująco: [słowo_kluczowe] [wartość_słowa_kluczowego] [skrypt_finalizujący]
[skrypt_inicjujący]
[profil]
Oto przykład: any
-
-
standard
-
W przykładzie każdy komputer powinien użyć standardowego profilu do skonfigurowania przywróconego systemu (nie są stosowane skrypty inicjujące lub finalizujące). Pliki rules narzędzia Jumpstart mogą być znacznie bardziej złożone i oferować większe możliwości. Choć plik rules wymaga tylko jednej reguły, można określić wiele reguł konfigurujących komputery, opartych na konfiguracji, architekturze itp.
Plik sysidcfg Plik sysidcfg zawiera informacje służące do konfigurowania komputera podczas procesu odtwarzania. Choć nie pokazano tego w poniższym przykładzie, w pliku sysidcfg można również umieścić szyfrowane hasło superużytkownika (z punktu widzenia bezpieczeństwa zwykle nie jest to zalecane). Dodatkowe informacje na temat tej opcji można znaleźć w dokumentacji Solaris Installation. Poniżej przedstawiono przykład pliku sysidcfg. Słowa kluczowe i ich znaczenia są dość zrozumiałe.
334 |
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
system_locale=C timezone=US/Pacific network_interface=primary {hostname=sun2 default_route=192.168.1.253 ip_address=192.168.1.34 netmask=255.255.255.0 protocol_ipv6=no} security_policy=NONE name_service=NONE timeserver=localhost
Po utworzeniu plików konfiguracyjnych można je zintegrować z obrazem narzędzia Flash Archive sporządzonym wcześniej w tym rozdziale, w podrozdziale „Przygotowanie do interaktywnego odtwarzania”.
Umieszczanie na taśmie obrazu nieinteraktywnego procesu odtwarzania Po utworzeniu obrazu można przygotować taśmę, która zostanie zastosowana w celu przywrócenia komputera od podstaw. Poniższe kroki tworzą na dysku obraz narzędzia Flash Archive, a następnie kopiują go na taśmę.
1. Należy utworzyć pliki: sysidcfg, rules i profile (lub plik skryptu inicjującego). 2. W celu wygenerowania pliku rules.ok dla pliku rules należy uruchomić program check. 3. Za pomocą polecenia flar create (należy zajrzeć do wcześniejszego podrozdziału „Przygotowanie do interaktywnego odtwarzania”) należy zapisać obraz na dysku.
Jeśli skrypt sprawdzający nie znajduje się na lokalnym serwerze, może być uruchomiony lub skopiowany z dysku CD lub DVD systemu Solaris.
4. Przy użyciu programu tar należy zapisać na taśmie pliki: sysidcfg, rules, rules.ok i profile (lub plik skryptu inicjującego).
5. Za pomocą narzędzia dd należy przenieść obraz na taśmę. Alternatywnie można wykonać
kroki od 1. do 4., a następnie, wykonując polecenie flar create, utworzyć obraz narzędzia Flash Archive bezpośrednio na taśmie.
Oto przykład wykonania powyższej procedury, począwszy od kroku 4.: # a a a a #
tar cvf /dev/rmt/0n rules rules.ok sysidcfg standard.profile rules 1 tape blocks rules.ok 1 tape blocks sysidcfg 1 tape blocks standard.profile 1 tape blocks dd if=sun2.flar of=/dev/rmt/0n obs=1024000
Zapisywanie na dysku obrazu nieinteraktywnego procesu odtwarzania Jeśli zamierza się przeprowadzić nieinteraktywny proces odtwarzania przy wykorzystaniu punktu podłączenia NFS, powinno się dysponować poprawnie skonfigurowanym serwerem sieciowym z systemem Solaris i dokonać inicjalizacji komputera za pomocą polecenia boot net Przygotowan e n e nteraktywnego procesu odtwarzan a
|
335
- install. W tym przypadku sposób skonfigurowania konkretnego środowiska decyduje
o miejscu, w którym powinny być przechowywane pliki konfiguracyjne serwera (profile, rules i sysidcfg).
Choć możliwe jest przeprowadzenie instalacji i inicjalizacji za pomocą dostosowanego dysku CD lub DVD systemu Solaris, który odtwarza dane za pośrednictwem sieci przy użyciu istniejącego serwera Jumpstart, tego rozwiązania nie omówiono szczegółowo w rozdziale. Aby przeprowadzić nieinteraktywne odtwarzanie, należy wykonać następujące kroki:
1. Najpierw należy sprawdzić, czy system jest załadowany i widoczny jest wiersz interpretera poleceń ok>.
2. Wykonując poniższe polecenie, należy sprawdzić, czy są dostępne urządzenia związane z inicjalizowaniem i odzyskiwaniem. ok> probe-scsi-all
Powinna zostać wyświetlona lista lokalnie podłączonych urządzeń. Trzeba zadbać o to, aby na liście przynajmniej pojawił się lokalny dysk rozruchowy, napęd CD lub DVD (jeśli jest potrzebny) i odpowiednie napędy taśmowe SCSI.
3. Jeżeli planuje się odtwarzanie danych z taśmy, należy umieścić ją w lokalnym napędzie taśmowym.
W przykładowym pliku profile zastosowano jeden napęd taśmowy (/dev/rmt/0n) podłączony do serwera. Jeśli napęd taśmowy na stałe określono w pliku profile, w procedurze tej trzeba zastosować to samo urządzenie. W celu uniknięcia tego wymogu należy skorzystać ze skryptu inicjującego, który w czasie procesu odtwarzania dynamicznie utworzy profil.
4. W dalszej kolejności należy załadować system. a. Jeśli dane odtwarza się z taśmy, w odpowiednim napędzie komputera przeznaczonego do przywrócenia należy umieścić instalacyjny dysk CD systemu Solaris, a następnie w wierszu poleceń ok> wykonać następujące polecenie: boot cdrom - install tape=/dev/rmt/0n
System jest uruchamiany i rozpoczyna się proces instalacji. System jest ładowany z dysku CD lub DVD, a następnie szuka na taśmie wymaganych plików. Jeśli je znajdzie, zostaną wykonane wszelkie skrypty wymagane przed operacją przywracania, po czym rozpocznie się wyodrębnianie zawartości obrazu. Pobrane pliki: rules.ok, profile i sysidcfg służą do konfigurowania serwera. b. Jeżeli dane odtwarza się z punktu podłączenia NFS, trzeba dysponować skonfigurowanym sieciowym serwerem rozruchowym i wykonując polecenie boot net - install, za pośrednictwem sieci przeprowadzić inicjalizację komputera. System szuka sieciowego serwera rozruchowego, aby zapewnić lokalizację wymaganych plików konfiguracyjnych i obrazu narzędzia Flash Archive. Oto informacje wyświetlone podczas wykonywania nieinteraktywnego procesu odtwarzania: ok boot cdrom - install tape=/dev/rmt/0n Resetting ... SPARCstation 5, No Keyboard ROM Rev. 2.15, 96 MB memory installed, Serial #7760400 Ethernet address 8:0:20:76:6a:22, Host ID: 80766a00.
336
|
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
Rebooting with command: cdrom - install tape=/dev/rmt/0n Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@6,0:d File and args: - install tape=/dev/rmt/0n SunOS Release 5.9 Version Generic_118558-11 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Configuring /dev and /devices Using RPC Bootparams for network configuration information. Skipping interface le0 Skipping interface hme0 Searching for configuration file(s)... Using sysid configuration file from /dev/rmt/0n position 0 Search complete. The system is coming up. Please wait. Begin system identification... Starting remote procedure call (RPC) services: sysidns done. System identification complete. Generating software table of contents [this may take a few minutes...] Table of contents complete. Starting Solaris installation program... Searching for Jumpstart directory... Using rules.ok from tape. Checking rules.ok file... Using profile: standard.profile Executing Jumpstart preinstall phase... Searching for SolStart directory... Checking rules.ok file... Using begin script: install_begin Using finish script: patch_finish Executing SolStart preinstall phase... Executing begin script "install_begin"... Begin script install_begin execution completed. Processing profile - Opening Flash archive - Validating Flash archive - Selecting all disks - Configuring boot device - Configuring / (c0t1d0s0) - Configuring swap (c0t1d0s1) - Configuring /export/home (c0t3d0s7) Verifying disk configuration - WARNING: Unused disk space (c0t1d0) - WARNING: Unused disk space (c0t3d0) Verifying space allocation NOTE: 1 archives did not include size information Preparing system for Flash install Configuring disk (c0t1d0) - Creating Solaris disk label (VTOC) Configuring disk (c0t3d0) - Creating Solaris disk label (VTOC) Creating and checking UFS file systems - Creating / (c0t1d0s0) - Creating /export/home (c0t3d0s7) Beginning Flash archive processing Predeployment processing 8 blocks 16 blocks 8 blocks
Przygotowan e n e nteraktywnego procesu odtwarzan a
|
337
No local customization defined Extracting archive: sun2.flar Extracted 0.00 MB ( 0% of 448.73 MB archive) Extracted 1.95 MB ( 0% of 448.73 MB archive) ... Extracted 448.72 MB ( 99% of 448.73 MB archive) Extraction complete Postdeployment processing No local customization defined Customizing system files - Mount points table (/etc/vfstab) - Network host addresses (/etc/hosts) Cleaning devices Customizing system devices - Physical devices (/devices) - Logical devices (/dev) Installing boot information - Installing boot blocks (c0t1d0s0) Installation log location - /a/var/sadm/system/logs/install_log (before reboot) - /var/sadm/system/logs/install_log (after reboot) Flash installation complete Executing JumpStart postinstall phase... The begin script log 'begin.log' is located in /var/sadm/system/logs after reboot. syncing file systems... done rebooting... Resetting...
Po udanym ukończeniu procesu odtwarzania są wykonywane wszystkie odpowiednie dla tego etapu skrypty, a następnie komputer jest ponownie uruchamiany. Jeśli w pliku sysidcfg nie podano szyfrowanego hasła superużytkownika, przy następnym ładowaniu systemu pojawi się prośba o jego wprowadzenie. Proces przywracania zostanie zakończony.
Procedury wykonywane po ukończeniu przywracania Niezależnie od użytej metody (interaktywna lub nieinteraktywna) po przywróceniu danych z obrazu narzędzia Flash Archive może być konieczne wykonanie określonych czynności. Ich liczba i złożoność zależą od konfiguracji systemu. Aby stworzyć pewną procedurę przywracania danych wykonywaną między dwoma węzłami, trzeba zrozumieć, jak skonfigurowano komputery. Jeśli na przykład przy użyciu obrazu narzędzia Flash Archive przywrócono komputer z głównym dyskiem VxVM, system później nie załaduje się. Wynika to stąd, że oprogramowanie Veritas Volume Manager oczekuje znalezienia głównego dysku, który już nie istnieje. W tym przypadku, korzystając z dysku CD systemu Solaris, trzeba załadować system w trybie jednego użytkownika i dokonać modyfikacji niezbędnych do wyłączenia ładowania oprogramowania VxVM, żeby system mógł się poprawnie uruchamiać. Jeżeli komputer przywróci się z zastosowaniem innego głównego dysku, może być konieczna ponowna konfiguracja układu EEPROM urządzenia rozruchowego. Original Server Root Disk c0t0d0s0
338 |
Target Server Root Disk c1t0d0s0
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
Końcowe wnioski Czynności niezbędne przed i po procesie przywracania danych z obrazu narzędzia Flash Archive mogą być wykonywane przez skrypty. Należy zastanowić się, jakie czynności można zautomatyzować w ramach procesów przywracania i instalowania. Oto kilka przykładów typowych zadań wykonywanych przed procesem przywracania: • możliwość interaktywnego określania dysków, wycinków i rozmiarów używanych podczas
procesu przywracania; • zastosowanie w czasie przywracania skryptu inicjującego do utworzenia pliku systemowego
profile. Oto przykłady typowych zadań wykonywanych po zakończeniu przywracania: • określanie struktury systemu plików nieużywanego przez system operacyjny; • modyfikowanie procesu rozruchu; • wprowadzanie zmian w układzie SUN EEPROM.
W porównaniu z tradycyjnymi metodami wdrażania i przywracania komputerów z systemem Solaris obrazy narzędzia Flash Archive są znaczącym ulepszeniem. Obrazy eliminują istotne zależności, które przez długi czas uważano za dopuszczalne, a ponadto dają użytkownikowi większą elastyczność niż kiedykolwiek wcześniej. Należy jednak wspomnieć, że narzędzie Flash Archive, tak jak każdy inny program lub skrypt, będzie bezużyteczne, jeśli nie będą dostępne jasne, precyzyjne i sprawdzone procesy i procedury. Dowolne narzędzie jest jedynie częścią ogólnego procesu, który powinien być regularnie dokumentowany, aby szansa powodzenia była jak największa. Istnieje wiele znakomitych źródeł dokumentacji poświęconej korzystaniu z narzędzia Flash Archive. Pod adresami http://docs.sun.com i http://www.sun.com/blueprints (witryna Sun BluePrints) można znaleźć kilka bardzo przydatnych zasobów, takich jak przewodniki dotyczące podstawowej i zaawansowanej instalacji systemu Solaris. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Końcowe wn osk
|
339
340 |
Rozdz ał 10. Przywracan e od podstaw komputera z systemem Solar s
ROZDZIAŁ 11.
Systemy Linux i Windows
W tym rozdziale wyjaśniono, jak przywracać od podstaw typowe komputery z systemem Linux lub Windows i procesorem x86. Przedstawiona procedura powinna umożliwić przywrócenie dowolnego innego systemu operacyjnego zainstalowanego na standardowych komputerach z procesorami Intela. Procedura była testowana dla systemów CentOS 4.0.2 (inaczej RedHat Enterprise 4), Windows 2000 i Windows XP (procedura nie działa w przypadku komputerów Macintosh z procesorem Intela, ponieważ są dostosowane do współpracy z systemem Mac OS; w rozdziale 14. zamieszczono procedurę dla tego systemu). Procedura wymaga jedynie narzędzi open source. Rozdział jest wynikiem współpracy Reeda Robinsa i W. Curtisa Prestona. Reed jest w firmie GlassHouse Technologies specjalistą od ochrony danych.
Choć omówiona procedura działa tylko w przypadku komputerów z systemem Windows, uwzględnia też dystrybucję Linuksa, którą można uruchomić bezpośrednio z dysku CD. Użytkownicy systemu Windows będą musieli wykonać kilka poleceń linuksowych. Jednak dołożono wszelkich starań, aby je maksymalnie uprościć. Jeśli udałoby się nam znaleźć darmowe narzędzie służące do przywracania komputera od podstaw, które działa pod systemem Windows, poświęcilibyśmy mu oddzielny rozdział. Niestety, w czasie pisania tego rozdziału takie narzędzie nie istniało. Jeżeli Czytelnik jest użytkownikiem systemu Windows i nigdy nie miał do czynienia z Linuksem, namawiamy go, aby zanim zrezygnuje, przynajmniej wypróbował procedury zawarte w rozdziale. Jednak na wypadek gdyby Czytelnik uważał, że te procedury są zbyt trudne, omówiliśmy również produkt open source G4L, który jest podobny do komercyjnego oprogramowania Ghost. Narzędzie G4L działa pod Linuksem, lecz wymaga znacznie bardziej ograniczonej interakcji użytkownika z systemem operacyjnym. Na końcu rozdziału opisaliśmy też kilka komercyjnych produktów. Ze względu na dostępność tanich dysków i łatwość ich przywracania przedstawiona procedura całkowicie bazuje na tego typu urządzeniach. W roli lokalizacji docelowej można wykorzystać uniksowy udział NFS lub udział systemu Windows. Procedura zadziała w przypadku dowolnego dyskowego urządzenia docelowego, które może być podłączone przed rozpoczęciem archiwizacji lub odtwarzania. Jeśli Czytelnik jest zainteresowany innymi dyskowymi urządzeniami docelowymi, może poświęcić trochę czasu na przeczytanie całego dokumentu HOWTO poświęconego archiwizacji i przywracaniu. Dokument ten wchodzi w skład projektu Linux 341
Documentation Project, dostępnego pod adresem http://www.tldp.org/HOWTO. W dokumencie zamieszczono pomocne wskazówki na temat redukowania ilości informacji archiwizowanych na potrzeby odtwarzania systemu operacyjnego w minimalnej wersji.
Działanie procedury Większości administratorów systemu znany jest typowy schemat przywracania komputera od podstaw: zainstalować system operacyjny w minimalnej wersji, a następnie odtworzyć dane. Jednak z taką procedurą wiąże się kilka problemów: trwa zbyt długo, może dojść do konfliktów wywołanych przez otwarte pliki, a także trudno udokumentować i przywrócić modyfikacje wprowadzone przez użytkownika w systemie operacyjnym. Podobnie do innych procedur przywracania komputera od podstaw procedura ta nie wymaga ponownej instalacji systemu operacyjnego w celu jego przywrócenia. Procedura dzieli się na sześć następujących podstawowych kroków:
1. Archiwizacja ważnych metadanych. 2. Archiwizacja danych systemu operacyjnego za pomocą jego narzędzia. 3. Uruchomienie systemu z alternatywnego nośnika. 4. Przygotowanie nowego głównego dysku. 5. Odtworzenie bloku rozruchowego na nowym głównym dysku. 6. Odtworzenie danych systemu operacyjnego. Najpierw przedstawimy trochę podstaw, a następnie opiszemy ogólne aspekty związane z każdym krokiem. Ostatecznie zaprezentujemy szczegółową procedurę dla każdej omówionej metody. Zanim jednak wybierze się metodę archiwizacji i przywracania, trzeba podjąć kilka decyzji, które zostały omówione poniżej.
Uruchomienie systemu z alternatywnego nośnika Aby z łatwością przywrócić system operacyjny, trzeba dysponować ograniczoną powłoką użytkownika root (nazywaną też mini-root), z której poziomu można uruchomić programy: fdisk, mkfs, gzip, pax/tar/cpio, dd, ntfsclone itp. Ponadto musi być obsługiwany wybrany nośnik archiwizacyjny. Zapewniają to dyski ratunkowe lub ładowalna dystrybucja Linuksa umieszczona na dysku CD, nazywana też Live CD. Dyski ratunkowe, takie jak TomsRtBt, zawierają minimalną wersję systemu Linux, a także zazwyczaj uwzględniają wymienione wcześniej narzędzia przywracające. Dyski te oferują też kilka sterowników dla popularnych nośników archiwizujących, takich jak napędy ZIP z portem równoległym, napędy taśmowe SCSI, a także urządzenia bazujące na protokołach NFS i SMB/CIFS. Dystrybucje Live CD są bardziej kompletnymi wersjami systemu Linux, dostępnymi w różnych odmianach. Zwykle obsługują więcej sterowników i narzędzi niż dyski ratunkowe. Ta rozszerzona obsługa i zwiększona elastyczność w połączeniu z obecną powszechnością nośników CD-R sprawiły, że w przykładach zastosowaliśmy dystrybucję Live CD. Pod adresem http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html można znaleźć listę dysków ratunkowych dla komputerów z procesorami x86. Lista dystrybucji Live CD znajduje się pod adresem http://www.frozentech.com/content/livecd.php. W przykładach zdecydowaliśmy się wykorzystać dystrybucję Live CD systemu Linux o nazwie Knoppix (http://www.knoppix.org).
342 |
Rozdz ał 11. Systemy L nux W ndows
JEŻELI to, WTEDY PRZEJDŹ DO Na kilku następnych stronach niniejszego rozdziału zamieszczono sporą dawkę teorii i omówiono ręcznie wykonywane kroki związane z przywracaniem od podstaw komputera z procesorem x86. Podobnie jak w przypadku wielu podręczników, najlepsze pozostawiono na koniec. Jeżeli Czytelnik zamierza od razu zapoznać się z interesującą go metodą, w tym punkcie powinien znaleźć ilość szczegółów wystarczającą do tego, aby wiedzieć, do której części rozdziału przejść. Jeśli używany system to Windows i Czytelnik nigdy niczego nie wpisał w wierszu poleceń Linuksa, prawdopodobnie powinien przejść do podrozdziału „Automatyzowanie przywracania komputera od podstaw za pomocą narzędzia G4L”. Omówiono w nim metodę przywracania komputera od podstaw bazującą na interfejsie z menu (jeśli Czytelnik szuka takiej metody, jest to jedyna przez nas opisana). Jeżeli Czytelnika dotyczy dowolny z niżej wymienionych punktów, musi użyć narzędzia G4L lub skorzystać z metody pełnego obrazu i alternatywnego ładowania. • Używany jest menedżer LVM (Linux Volume Manager) lub inne oprogramowanie RAID. • Korzysta się z systemu o architekturze IA64. • Tabele partycji zawierają odwołania do rozszerzonej tabeli partycji.
Jeśli Czytelnika dotyczy dowolny z powyższych punktów, powinien zapoznać się z poniższymi punktami. • W przypadku ręcznej metody należy przeczytać podrozdział „Metoda pełnego obrazu i alter-
natywnego ładowania”, a automatycznej — podrozdział „Automatyzowanie przywracania komputera od podstaw za pomocą narzędzia G4L”.
• Jeśli Czytelnik używa systemu Linux i zamierza w trybie online spróbować utworzyć kopie
zapasowe na potrzeby przywracania komputera od podstaw, powinien od razu przejść do podrozdziału „Metoda trybu online”.
• Jeżeli korzysta się z komputera z systemami Windows i Linux, a także można sobie po-
zwolić na jego krótki przestój na potrzeby sporządzenia kopii zapasowej do przywracania od podstaw, prawdopodobnie powinno się sprawdzić metodę systemu plików i alternatywnego ładowania bądź metodę obrazu partycji i alternatywnego ładowania. Metody te mogą też zostać zautomatyzowane przy użyciu narzędzia omówionego w podrozdziale „Automatyzowanie przywracania komputera od podstaw za pomocą narzędzia G4L”.
Wybieranie metod archiwizowania Naszym celem było sporządzenie bez użycia komercyjnych narzędzi kopii zapasowej na potrzeby przywracania od podstaw komputera z procesorem x86. Aby skorzystać z utworzonych przez nas procedur, trzeba zdecydować: • Czy kopia zapasowa będzie sporządzana w czasie pracy systemu (w trybie online) czy po
załadowaniu go z alternatywnego dysku rozruchowego?
• Czy jeśli zastosuje się alternatywny dysk rozruchowy, archiwizacja będzie przeprowadzana
na poziomie bloku/obrazu czy systemu plików?
• Jeśli archiwizacja będzie wykonywana na poziomie obrazu, czy utworzy się jeden obraz
dla całej zawartości napędu czy obrazy dla poszczególnych partycji? Dz ałan e procedury
| 343
Partycjonowanie napędu systemu operacyjnego Wiele osób na potrzeby systemu operacyjnego, aplikacji i danych przeznacza jedną dużą partycję. Partycjonowanie dysku twardego w ten sposób ogranicza możliwości przywracania komputera od podstaw. Lepszym rozwiązaniem byłoby utworzenie na dysku partycji wystarczająco pojemnej do przechowywania systemu operacyjnego i jego aplikacji, a także dodatkowej partycji do magazynowania wszystkich danych użytkowników. Dysponując takim układem partycji, można również archiwizować zawartość napędu za pomocą standardowych narzędzi tworzących kopie zapasowe systemów plików (na przykład Amanda, BackupPC, Bacula, rsnapshot i rdiff-backup) i stosować procedury przywracania od podstaw tylko dla partycji systemu operacyjnego. Jeśli takie rozwiązanie interesuje Czytelnika, w celu utworzenia na dysku wielu partycji może skorzystać z takich narzędzi, jak Partition Magic (system Windows) i QTParted (system Linux). Jeżeli Czytelnik nie miał do czynienia z programem QTParted, nie stanowi to problemu, ponieważ działa prawie tak samo jak narzędzie Partition Magic. Jednak jest darmowe i dla Linuksa!
Ładowanie alternatywne czy w trybie online? Pierwsza decyzja, którą trzeba podjąć, dotyczy tego, czy dane będą archiwizowane w czasie pracy systemu (w trybie online) czy po załadowaniu go z alternatywnego nośnika. Archiwizowanie w trybie online obejmuje zastosowanie poleceń tworzących kopie zapasowe plików na poziomie systemu plików. Jeśli używa się systemu Windows, nie trzeba martwić się powyższą kwestią. Konieczne jest zastosowanie metody alternatywnego ładowania, ponieważ w czasie, gdy ta książka była pisana, nie istniał format archiwizacyjny zapisywany w systemie Windows i odczytywany w systemie Linux, który obsługiwałby też listy kontroli dostępu ACL. Jednak jest promyk nadziei, że to się zmieni. Z łatwością można podłączać i tworzyć w systemie Linux systemy plików NTFS. Narzędzie mtftar potrafi odczytywać taśmy zapisane przez program ntbackup, a społeczność rozwijająca program pax twierdzi, że zaczyna on obsługiwać listy kontroli dostępu ACL. Największą zaletą archiwizowania systemu w trybie online jest to, że nie trzeba zamykać systemu, aby sporządzić kopię zapasową. Jednak w zależności od używanego systemu operacyjnego mogą pojawić się problemy z otwartymi plikami lub bazami danych konfiguracji systemowej. Jeśli dla Czytelnika ważne jest, żeby archiwizować system w trybie online, wystarczy, że dobrze przetestuje procedurę, aby mieć pewność, że wyeliminowano wszystkie problemy związane z konkretnym systemem operacyjnym i platformą. Jeżeli nie można zamknąć systemu w celu utworzenia kopii zapasowej na potrzeby przywrócenia komputera od podstaw, a ponadto nie ma możliwości skorzystania z metody archiwizowania w trybie online, należy zapoznać się z podrozdziałem „Rozwiązania komercyjne”, zamieszczonym na końcu rozdziału.
Jeśli nie można pozwolić sobie na zamknięcie systemu, aby sporządzić kopię zapasową na potrzeby przywracania komputera od podstaw, dostępne jest inne rozwiązanie. Polega ono na archiwizowaniu systemu załadowanego z alternatywnego dysku rozruchowego, takiego jak dysk Live CD z dystrybucją Linuksa (tego typu dysk zapewnia w pełni funkcjonalny system operacyjny Linux; system uruchamia się bezpośrednio z dysku). Tak zwana metoda alternatywnego ładowania oferuje też kilka zalet, takich jak brak konieczności zajmowania się formatami 344 |
Rozdz ał 11. Systemy L nux W ndows
systemów plików. Wynika to z tego, że metoda ta archiwizuje dane na poziomie bloku (lub obrazu). Coś takiego nie jest możliwe w przypadku metody archiwizowania w trybie online. Jedyną wadą metody alternatywnego ładowania jest to, że wymaga, aby podczas trwania całego procesu archiwizowania system był zamknięty. Choć nie powinno to stanowić problemu w przypadku domowych użytkowników i niewielkich firm, dla reszty organizacji takie ograniczenie może być nie do zaakceptowania. W książce obie metody archiwizowania są nazywane metodami trybu online i alternatywnego ładowania.
Poziom obrazu czy systemu plików? Jeśli korzysta się z metody alternatywnego ładowania, dostęp do danych można uzyskać na poziomie systemu plików lub niesformatowanych urządzeń dyskowych. Jeżeli dane archiwizuje się za pomocą niesformatowanego urządzenia dyskowego (na przykład /dev/hda lub /dev/hda1), mówimy o archiwizacji na poziomie obrazu. Innym wariantem jest utworzenie kopii zapasowych danych przez podłączenie systemów plików i zastosowanie narzędzia takiego jak tar (nie można w ten sposób archiwizować i odtwarzać partycji z systemem plików NTFS). W książce obie metody archiwizowania są nazywane metodami obrazu i systemu plików.
Archiwizowanie na poziomie obrazu pozwala nie martwić się tym, jaki system operacyjny zainstalowano na dysku. Dopóki archiwizuje się wszystkie bajty zapisane na dysku twardym i odtwarza je na identycznej partycji, wszystko będzie świetnie działać. Właśnie w ten sposób z łatwością można archiwizować system Windows z poziomu Linuksa. Największą wadą kopii zapasowych tworzonych na poziomie obrazu jest to, że uwzględniają każdy bajt znajdujący się na dysku, niezależnie od tego, czy jest używany, czy nie. Jeśli dysponuje się partycją 10 GB, uzyska się kopię zapasową o takim rozmiarze nawet wtedy, gdy na partycji zapisano jedynie pliki o objętości 1 GB (choć kompresja powinna być pomocna w wyeliminowaniu pustych bloków, prawdopodobnie wydłuży czas archiwizacji). Inną wadą archiwizacji na poziomie obrazu jest to, że jest to proces typu „wszystko albo nic”. Z kopii zapasowej sporządzonej na poziomie obrazu nie można odtworzyć wybranych plików.
Cały dysk czy poszczególne partycje? Jeżeli używa się metody alternatywnego ładowania i postanowiono zarchiwizować dane na poziomie obrazu, trzeba podjąć następną decyzję. Czy dysk z systemem operacyjnym zarchiwizuje się jako jeden duży obraz (/dev/hda) czy w postaci obrazu oddzielnych partycji (/dev/hda1, /dev/hda2 itd.)? Aby przeprowadzić archiwizację na poziomie partycji, trzeba utworzyć na dysku twardym wiele partycji. Należy zapoznać się z ramką „Partycjonowanie napędu systemu operacyjnego” zamieszczoną wcześniej w rozdziale.
Dz ałan e procedury
| 345
W książce obie metody archiwizowania są nazywane metodami pełnego obrazu i obrazu partycji.
Z archiwizowaniem całej zawartości dysku z systemem operacyjnym w postaci jednego dużego obrazu jest związana jedna znacząca korzyść: proces przywracania jest niezwykle prosty. Nie trzeba się martwić o ponowne partycjonowanie dysku twardego na potrzeby procesu przywracania, a także o blok rozruchowy (główny rekord rozruchowy MBR). Wystarczy jedynie zarchiwizować cały dysk jako jeden duży obraz. Wadą takiej metody jest pojemność obecnie dostępnych dysków twardych. Jeśli w postaci jednego obrazu zamierza się zarchiwizować całą zawartość dysku, może okazać się konieczne utworzenie obrazu liczącego setki gigabajtów, a nawet terabajt. Nieźle! Oprócz przestrzeni niezbędnej do przechowania takiego obrazu archiwizowanie setek gigabajtów za pomocą jednego polecenia może zająć bardzo wiele czasu, a wtedy system będzie niedostępny. Inna metoda polega na utworzeniu wielu partycji i zarchiwizowaniu każdej z osobna. Dzięki temu procedurę przywracania komputera od podstaw można zastosować tylko dla partycji z systemem operacyjnym, natomiast dla pozostałych danych trzeba użyć narzędzi archiwizujących systemy plików (Amanda, BackupPC, Bacula, rsnapshot i rdiff-backup). Metoda ta pozwala również jednocześnie sporządzać kopie zapasowe wszystkich partycji, dzięki czemu cały proces przebiega znacznie szybciej. W porównaniu z metodą pełnego obrazu metoda obrazu partycji ma kilka wad, które są związane z jej złożonością. Trzeba w większym zakresie zapoznać się ze sposobem partycjonowania posiadanego dysku, a także pamiętać o archiwizowaniu i odtwarzaniu tabeli partycji i rekordu MBR. Gdy na potrzeby przywracania partycjonuje się dysk twardy, tworzone partycje muszą mieć właściwy rozmiar. Jeśli będą zbyt małe, przywracanie zakończy się niepowodzeniem. Z kolei gdy partycje okażą się za duże, utraci się przestrzeń dyskową.
Cztery warianty archiwizacji Trzy wcześniej omówione decyzje przekładają się na cztery metody archiwizacji. Posługując się wyżej podanymi terminami, metody te można nazwać następująco: pełnego obrazu i alternatywnego ładowania, obrazu partycji i alternatywnego ładowania, systemu plików i alternatywnego ładowania oraz trybu online. Metoda pełnego obrazu i alternatywnego ładowania Na metodę składa się ładowanie z dysku Live CD i tworzenie obrazu całego dysku systemu operacyjnego. Choć jest to najprostsza z wszystkich przedstawionych metod, sprawdzająca się w przypadku większości osób, wymaga zamknięcia systemu przez czas niezbędny do zarchiwizowania całego dysku z systemem, a także przestrzeni wystarczającej do przechowywania kopii zapasowej. Metoda obrazu partycji i alternatywnego ładowania Choć metoda ta przypomina metodę pełnego obrazu i alternatywnego ładowania, w jej przypadku tworzy się obraz tylko tych partycji, które trzeba zarchiwizować. Metoda pozwala zaoszczędzić mnóstwo czasu i przestrzeni dyskowej, jeśli dla dysku twardego we właściwy sposób przeprowadzono partycjonowanie. Jednakże metoda wymaga zamknięcia systemu i bardziej obszernej wiedzy na temat zawartości używanego dysku twardego.
346 |
Rozdz ał 11. Systemy L nux W ndows
Metoda systemu plików i alternatywnego ładowania Metoda obejmuje ładowanie systemu z dysku Live CD, takiego jak Knoppix, i zastosowanie narzędzi obsługujących systemy plików w celu archiwizacji dysków twardych. W dystrybucji Knoppix są dostępne programy tar i cpio. Jeśli systemy plików nie są w dużym stopniu zapełnione, metoda ta pozwoli zaoszczędzić mnóstwo miejsca. Jednak spośród wszystkich metod ta jest najbardziej złożona i wymaga zamknięcia systemu. Jeżeli zamierza się skorzystać z metody systemu plików i alternatywnego ładowania lub metody trybu online, trzeba użyć narzędzi zamieszczonych na wybranym dysku Live CD. Zdecydowaliśmy się na dysk Live CD dystrybucji Knoppix ze względu na jej popularność i znakomitą obsługę urządzeń. Knoppix oferuje też bogaty zestaw różnych narzędzi, w tym takich, jak tar, cpio, dd i ntfsclone (ostatnie z wymienionych w rzeczywistości jest programem przetwarzającym obrazy, lecz również obsługującym system plików NTFS; w związku z tym umożliwia archiwizowanie tylko tej części obrazu, która zawiera pliki).
Metoda trybu online Jeśli korzysta się z systemu Linux, lecz nie z menedżera LVM, oprogramowania RAID lub architektury IA64, można archiwizować działający system operacyjny, a następnie, wyłącznie na potrzeby procesu przywracania, zastosować nośnik alternatywnego ładowania. Można użyć dowolnego narzędzia archiwizującego na poziomie systemu plików. Trzeba pamiętać, że metoda nie radzi sobie zbyt dobrze z komputerami z dwoma systemami, ponieważ nie współużytkują one systemu plików. Metoda nie będzie też dostępna dla użytkowników korzystających wyłącznie z systemu Windows. Wynika to stąd, że polecenia wykonywane przez takich użytkowników w celu sporządzenia kopii zapasowej ich komputerów nie będą dostępne z poziomu nośnika stosowanego podczas przywracania danych. Jeśli jednak sporadycznie nie można zamknąć systemu operacyjnego, aby zarchiwizować jego dane, metoda ta może być preferowana (oczywiście w przypadku komputera z dwoma systemami partycje systemu Windows można zarchiwizować po załadowaniu Linuksa). We wszystkich przykładach zamieszczonych w rozdziale w roli docelowego miejsca kopii zapasowych zastosowano katalog /kopie_zapasowe. Może to być punkt podłączenia NFS lub CIFS bądź lokalny przenośny dysk twardy. Ponieważ dysk musi być zapisywalny przez superużytkownika, dla każdego udziału NFS należy zastosować opcję -o rw,root.
Kroki w teorii W dalszej części rozdziału zawarto konkretne procedury dla każdej z czterech przedstawionych metod. W niniejszym podrozdziale bliżej przyjrzano się sześciu ogólnym krokom tworzącym proces przywracania komputera od podstaw.
Krok 1. Archiwizowanie ważnych metadanych W pierwszej kolejności trzeba sporządzić kopię zapasową metadanych. Są to dane na temat danych, czyli informacje dotyczące fizycznej konfiguracji komputera. W tym przypadku mowa o sposobie partycjonowania dysku z systemem operacyjnym. Informacje takie zwykle nie są
Krok w teor
|
347
uwzględniane w zwykłej kopii zapasowej. Tworzenie kopii rekordu MBR i tabeli partycji jest metodą zachowania informacji w formacie, który może posłużyć do odtworzenia głównej partycji dysku. Rekord MBR i tabela partycji znajdują się w pierwszych 512 bajtach dysku twardego. Rekord MBR składa się z trzech części: bloku rozruchowego zapisanego w pierwszych 446 bajtach, tabeli partycji zawartej w następnych 64 bajtach i sygnatury kodu rozruchowego zajmującego pozostałe dwa bajty.
Systemy: Linux, FreeBSD i Solaris x86 Jeśli używa się systemu Linux, FreeBSD, Solaris x86 lub dowolnego innego uniksowego systemu operacyjnego, z łatwością w trybie online można zarchiwizować istotne metadane. Jeżeli korzysta się z linuksowego menedżera LVM, oprogramowania RAID, rozszerzonych partycji lub komputerów o architekturze IA64, trzeba sięgnąć po metodę pełnego obrazu i alternatywnego ładowania, która umożliwia pominięcie tego kroku.
W celu zapisania informacji na temat partycji dysku należy wykonać następujące polecenia: # fdisk -l >/kopie_zapasowe/fdisk.txt # cp /etc/fstab /kopie_zapasowe/fstab.txt
Aby zarchiwizować rekord MBR i tabelę partycji, należy zastosować poniższe polecenie. Tworzy ono kopię zapasową w pliku /kopie_zapasowe/mbr. # dd if=/dev/hda of=/kopie_zapasowe/mbr bs=512 count=1
W późniejszym czasie kopia może posłużyć do odtworzenia rekordu MBR i tabeli partycji.
System Windows Niestety, system Windows nie oferuje odpowiedników dla powyższych poleceń. Do wyboru są dwie opcje. Jeśli używa się metody pełnego obrazu i alternatywnego ładowania, można pominąć ten krok. Gdy zamierza się skorzystać z metody obrazu partycji i alternatywnego ładowania, przed zarchiwizowaniem partycji należy zapisać rekord MBR i tabelę partycji. Po załadowaniu systemu z dysku Knoppix automatycznie zostanie zalogowany użytkownik knoppix. W przykładzie przyjęto, że komputer znajduje się w środowisku z protokołem DHCP i jest dostępny serwer NFS o nazwie serwer_nfs z udziałem /dane08/jan. Oczywiście trzeba zastosować odpowiednie nazwy obecne w zarządzanym środowisku. Ponadto, jeśli na potrzeby tej procedury używa się napędu USB, trzeba go podłączyć zamiast napędu NFS. Aby kontynuować, należy wykonać poniższe polecenia. $ su # mkdir /kopie_zapasowe
Choć system Knoppix jest ładowany z nośnika tylko do odczytu, w całości jest umieszczany w pamięci RAM. W związku z tym faktycznie można tworzyć katalogi, a nawet instalować oprogramowanie w takim środowisku, opartym na pamięci operacyjnej. Oczywiście po ponownym uruchomieniu komputera wszystko, co było w pamięci RAM, przepada.
348 |
Rozdz ał 11. Systemy L nux W ndows
To, które z poniższych dwóch poleceń zostanie wykonane, zależy od tego, czy korzysta się z usługi NFS czy SAMBA. # mount serwer_nfs:/dane08/jan /kopie_zapasowe # mount -t smbfs -o username=administrator,password=HASŁO //nazwa_serwera/udział /kopie_zapasowe
Na końcu należy zapisać informacje na temat partycji. # fdisk -l >/kopie_zapasowe/fdisk.txt # dd if=/dev/hda of=/kopie_zapasowe/mbr bs=512 count=1
Procedura zakłada, że dla dysku z systemem operacyjnym nie zastosowano funkcji dynamicznych dysków systemu Windows.
Krok 2. Archiwizowanie systemu operacyjnego za pomocą wbudowanego narzędzia Jeśli planuje się przywrócenie systemu operacyjnego bez jego ponownej instalacji, trzeba użyć zawsze dostępnego narzędzia.
Systemy: Linux, FreeBSD i Solaris x86 Jeżeli stosuje się metodę trybu online, należy skorzystać z narzędzia tar lub cpio. Bez wątpienia tar jest najczęściej wybierany, ponieważ jest bardziej przenośny niż narzędzie cpio. Jeśli planuje się zastosowanie metody systemu plików i alternatywnego ładowania, trzeba zapoznać się z typami systemów plików, podłączyć je, a następnie zarchiwizować za pomocą programu tar lub cpio. Gdy wybrano metodę pełnego obrazu i alternatywnego ładowania lub metodę obrazu partycji i alternatywnego ładowania, konieczne będzie sięgnięcie po narzędzie dd.
System Windows Jeśli zamierza się archiwizować system Windows przy użyciu metody pełnego obrazu i alternatywnego ładowania lub metody obrazu partycji i alternatywnego ładowania, konieczne będzie skorzystanie z narzędzia dd. Dalej zostanie omówiona składnia, z którą trzeba się zaznajomić. Jeżeli zastosuje się metodę systemu plików i alternatywnego ładowania, trzeba będzie skorzystać z narzędzia ntfsclone dostępnego na dysku CD dystrybucji Knoppix. Program ntfsclone skutecznie powiela (lub kopiuje) system plików NTFS w pliku, uwzględniając tylko używane dane (ponieważ niewykorzystywane dane w pliku rozrzedzonym są reprezentowane przez zera, nie zajmują miejsca). Systemu Windows nie można archiwizować za pomocą metody trybu online. Choć z łatwością można pobrać wersję narzędzia tar dla tego systemu i program ten jest dostępny na dysku CD dystrybucji Knoppix, nie zachowuje on list kontroli dostępu ACL systemu Windows.
Krok 3. Ładowanie systemu z alternatywnego nośnika Aby z łatwością przywrócić system operacyjny, trzeba dysponować ograniczoną powłoką superużytkownika, którą uzyska się po załadowaniu dystrybucji Knoppix.
Krok w teor
| 349
Po uruchomieniu systemu Knoppix z poziomu w pełni funkcjonalnej powłoki superużytkownika będzie można przeprowadzić resztę procedury.
Krok 4. Odtwarzanie informacji bloku rozruchowego Blok rozruchowy jest specjalnym obszarem dysku ładującym system operacyjny za pomocą swojego programu rozruchowego (stąd też nazwa bloku). Blok zawiera po prostu kod uruchomieniowy, który lokalizuje i ładuje jądro. W przypadku platformy z procesorem x86 blok rozruchowy jest określany mianem głównego rekordu rozruchowego MBR (Master Boot Record). Rekord ten można odtworzyć przy użyciu programu dd, tworzącego kopię zapasową w sposób opisany w poprzednim kroku. Jeśli korzysta się z metody pełnego obrazu i alternatywnego ładowania, można pominąć ten krok, ponieważ rekord MBR jest uwzględniany w obrazie.
Jeżeli wcześniej za pomocą narzędzia dd zarchiwizowano rekord MBR i tabelę partycji, przy użyciu tego samego programu można odtworzyć rekord i tabelę. W tym celu należy wykonać poniższe polecenie. Ponieważ plik /kopie_zapasowe/mbr przechowuje rekord MBR, tabelę partycji i sygnaturę rekordu MBR, odtworzenie tego pliku na dysk twardy powoduje partycjonowanie go w sposób identyczny jak w przypadku zarchiwizowanego pliku o takiej samej nazwie. Ponadto po odtworzeniu tego pliku dysk staje się dyskiem rozruchowym. Gdy przeprowadzi się proces odtwarzania pliku /kopie_zapasowe/mbr, można przejść do przywracania systemu operacyjnego. # dd if=/kopie_zapasowe/mbr of=/dev/hda bs=512 count=1
Aby bez konieczności ponownego uruchamiania komputera system Knoppix stwierdził przywrócenie rekordu MBR, trzeba wykonać polecenie fdisk /dev/hda, a następnie w celu zapisania na dysku partycji wybrać opcję w. Choć ponowne uruchomienie komputera da taki sam rezultat, zajmie to więcej czasu.
Krok 5. Partycjonowanie i formatowanie nowego głównego dysku Ponieważ w poprzednich krokach odtworzono zarówno rekord MBR, jak i tabelę partycji, nie ma potrzeby ponownego partycjonowania dysku. Wszystkie partycje zostaną utworzone za użytkownika. Jeśli korzysta się z metody trybu online lub metody systemu plików i alternatywnego ładowania, możliwe jest również przywrócenie zawartości mniejszego dysku na większym. Ponadto można zmienić układ partycji stosownie do potrzeb.
Systemy: Linux, FreeBSD i Solaris x86 Jeżeli używa się metody trybu online lub metody systemu plików i alternatywnego ładowania, za pomocą programu mkfs trzeba będzie utworzyć na dysku systemy plików. W zarchiwizowanym pliku fstab musi być określone, jakiego typu system plików zostanie ustalony dla każdej partycji.
350
|
Rozdz ał 11. Systemy L nux W ndows
Jeśli stosuje się metodę pełnego obrazu i alternatywnego ładowania lub metodę obrazu partycji i alternatywnego ładowania, nie trzeba martwić się o formatowanie dysku. Jest to wykonywane automatycznie podczas odtwarzania zawartości obrazu.
Odtwarzanie na większe dyski twarde Poniższa procedura może posłużyć do odtwarzania zawartości mniejszego dysku twardego na większym. W efekcie na końcu dysku pozostaje po prostu duży niewykorzystany obszar. Można następnie powiększyć lub przeorganizować partycje w celu użycia w środowisku systemu Knoppix dodatkowej przestrzeni dyskowej. System Knoppix oferuje narzędzie QTParted, które działa bardzo podobnie do dobrze znanej aplikacji Partition Magic. Stosownie do potrzeb program QTParted automatycznie zwiększa i zmniejsza rozmiary partycji i systemów plików. Gdy ta książka była pisana, narzędzie QTParted nie obsługiwało systemu plików NTFS. W związku z tym wszelkie partycje z tym systemem plików trzeba było powiększać ręcznie (w dalszym ciągu trzeba to robić w obrębie systemu Knoppix, ponieważ nie można zwiększyć pod systemem Windows pojemności dysku, gdy zawiera plik wymiany). Jednak jest to dość proste. Procedura zadziała tylko wtedy, gdy partycja, którą trzeba powiększyć, jest ostatnią (lub jedyną) na dysku twardym. Jeśli za nią znajdują się jakiekolwiek inne partycje, trzeba będzie skorzystać z komercyjnego produktu, takiego jak Partition Magic (dopóki narzędzie QTParted nie będzie w pełni obsługiwać systemu plików NTFS). 1. W celu uzyskania dostępu do tabeli partycji nowego dysku twardego należy użyć programu fdisk znajdującego się na dysku CD systemu Knoppix. Wciskając klawisz P, należy wyświetlić aktualną tabelę partycji. Uwagę należy zwrócić na początkowy i końcowy cylinder partycji, którą planuje się powiększyć, niezależnie od tego, czy jest rozruchowa, czy nie, a także na typ partycji. Dodatkowo należy przyjrzeć się całkowitej liczbie cylindrów dysku twardego i sprawdzić, czy za powiększaną partycją występują jakieś inne partycje. Jeśli partycja do powiększenia nie jest ostatnią na dysku, nie można zastosować tej procedury. 2. Wciskając klawisz D, należy usunąć partycję przeznaczoną do powiększenia. 3. Posługując się klawiszem N, należy utworzyć nową partycję rozpoczynającą się od tego samego cylindra co oryginalna partycja i kończącą się na ostatnim cylindrze dysku zidentyfikowanym w kroku 1. 4. Jeżeli usunięta partycja była rozruchową, tworzonej partycji trzeba nadać taki status. W tym celu należy wcisnąć klawisz A i wprowadzić numer odpowiedniej partycji. 5. Trzeba również ustawić typ partycji przez wciśnięcie klawisza T, a następnie klawisza L. Spowoduje to wyświetlenie listy partycji, na której należy odszukać kod heksadecymalny typu partycji określonej w kroku 1. Używając tego kodu, należy określić typ partycji. 6. Jeśli ma się pewność, że poprawnie wykonało się wszystkie powyższe kroki, wciskając klawisz W, należy zapisać tabelę partycji, a następnie zamknąć program fdisk (w przeciwnym razie można zakończyć działanie narzędzia bez zatwierdzania żadnych zmian). 7. Dla partycji należy uruchomić program ntfsresize (przykładowo ntfsresize /dev/hda1). Jeżeli potwierdzi się zamiar wykonania operacji, partycja NTFS zostanie automatycznie powiększona do końca dysku. To wszystko!
Krok w teor
|
351
System Windows Jeśli korzysta się z metody pełnego obrazu i alternatywnego ładowania lub metody obrazu partycji i alternatywnego ładowania, nie trzeba przejmować się formatowaniem dysku. Jest to wykonywane automatycznie podczas odtwarzania danych z obrazu. Gdy stosuje się metodę systemu plików i alternatywnego ładowania, dysk jest automatycznie formatowany w ramach procesu odtwarzania za pomocą narzędzia ntfsclone.
Krok 6. Odtwarzanie systemu operacyjnego na nowy główny dysk Najpierw trzeba uzyskać dostęp do zarchiwizowanych danych. W przykładach użyto katalogu będącego udziałem NFS. Konieczne będzie wykonanie jednej z następujących czynności: • podłączenie napędu ZIP lub Jaz jako systemu plików; • zainstalowanie drugiego dysku twardego o jednakowej lub większej pojemności; • załadowanie sterowników sieci i usługi NFS, skonfigurowanie interfejsu sieciowego i podłą-
czenie systemu plików NFS;
• załadowanie sterowników sieci i usługi SMB/CIFS, skonfigurowanie interfejsu sieciowego
i podłączenie systemu plików SMB/CIFS.
Przykładowe kopie zapasowe zapisano w systemie plików NFS. Wymagane do tego sterowniki i narzędzia są dostępne na dysku CD systemu Knoppix.
Założenia W poniższych podrozdziałach zamieszczono procedury dla każdej z czterech omówionych metod — pełnego obrazu i alternatywnego ładowania, obrazu partycji i alternatywnego ładowania, systemu plików i alternatywnego ładowania oraz trybu online. Procedury bazują na kilku założeniach, które objaśniono poniżej. Zakładamy, że jest dostępny serwer DHCP W przypadku naszych przykładów przyjmujemy, że w zarządzanym środowisku znajduje się serwer DHCP dostarczający adresy IP, dzięki czemu nie ma potrzeby wybierania adresu IP i konfigurowania interfejsu sieciowego każdorazowo podczas ładowania systemu Knoppix. Jeśli serwera DHCP nie ma, konieczne będzie ręczne określenie adresu IP. W tym celu należy wykonać następujące polecenia: $ su # ifconfig eth0 adres_IP up # route add default gw adres_IP_bramki
W dalszej kolejności trzeba użyć adresów IP, aby skomunikować się z innymi komputerami, lub w pliku /etc/resolv.conf wprowadzić poprawny adres IP serwera DHCP (używając formatu nameserver adres_IP_serwera_DNS). Zakładamy, że używa się serwera NFS W przytoczonych przykładach przyjmujemy, że w zarządzanym środowisku znajduje się serwer NFS z wystarczającym miejscem do przechowywania danych. Jeśli dane chciałoby się zarchiwizować na udziale systemu Windows, należy zastosować poniższe polecenie. # mount -t smbfs -o username=administrator,password=HASŁO //nazwa_serwera/udział /kopie_zapasowe
352
|
Rozdz ał 11. Systemy L nux W ndows
Metoda pełnego obrazu i alternatywnego ładowania Zamieszczony w tym podrozdziale przykład prezentuje najprostszą z wszystkich procedur. Oznacza to, że najprawdopodobniej procedura zostanie wybrana przez użytkowników systemu Windows, którzy nie są zaznajomieni z Linuksem. Metoda pełnego obrazu i alternatywnego ładowania wymaga zamknięcia systemu (zamiast niego jest uruchamiany system Knoppix) i działa niezależnie od tego, jakiego używa się systemu operacyjnego. Metoda wymaga też wystarczającego miejsca dla kopii całego głównego dysku.
Tworzenie kopii zapasowej na potrzeby przywracania komputera od podstaw W celu utworzenia kopii zapasowej służącej do przywrócenia komputera od podstaw należy wykonać poniższe kroki.
Archiwizowanie ważnych metadanych Metoda nie wymaga tego kroku, ponieważ metadane są uwzględniane podczas archiwizowania zawartości całego dysku twardego w postaci jednego obrazu.
Ładowanie systemu z alternatywnego nośnika Najpierw w napędzie należy umieścić dysk CD systemu Knoppix, a następnie ponownie uruchomić komputer w celu załadowania systemu. Domyślnie Knoppix uaktywnia środowisko graficzne KDE z uprawnieniami użytkownika knoppix. Po przełączeniu na superużytkownika (początkowo nie ma dla niego zdefiniowanego hasła) należy utworzyć punkt podłączenia i podłączyć udział NFS jako /kopie_zapasowe. knoppix@0[knoppix]$ su # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z poprzednim podrozdziałem — „Założenia”.
Archiwizowanie systemu operacyjnego za pomocą wbudowanego narzędzia Przy użyciu programu dd w pliku katalogu NFS można zarchiwizować cały dysk. Poniższe polecenie archiwizuje zawartość głównego dysku twardego (/dev/hda) w pliku /kopie_zapasowe/hda.dd. # dd if=/dev/hda of=/kopie_zapasowe/hda.dd
Alternatywnie, gdy zależy nam na zaoszczędzeniu miejsca, możemy wykonać poniższe polecenie. Zależnie od lokalizacji wąskiego gardła może to przyspieszyć lub spowolnić proces archiwizowania. # dd if=/dev/hda | gzip -c > /kopie_zapasowe/hda.dd.gz
Metoda pełnego obrazu alternatywnego ładowan a
|
353
Przeprowadzanie procesu przywracania komputera od podstaw W celu przywrócenia komputera od podstaw należy zastosować poniższe kroki.
Ładowanie systemu z alternatywnego nośnika Pierwszym krokiem przywracania komputera jest umieszczenie w napędzie dysku CD systemu Knoppix i załadowanie go. Tak jak wcześniej należy otworzyć okno terminala, a następnie przełączyć się na superużytkownika i podłączyć katalog NFS. knoppix@0[knoppix]$ su # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
Niszczenie zawartości dysku twardego! Jeśli próbuje się sprawdzić proces przywracania dysku twardego systemu operacyjnego, można chcieć zniszczyć jego zawartość przed rozpoczęciem testowania procedury (zakładamy, że Czytelnik korzysta z testowego komputera). Pierwsze z poniższych poleceń dd niszczy zarówno blok rozruchowy, jak i informacje na temat partycji dysku. Pozostałe polecenia uszkadzają pierwszych 50 MB każdej partycji. Choć główny system plików nadal istnieje, w razie potrzeby nie będzie można go odnaleźć! Po załadowaniu systemu Knoppix należy wykonać następujące polecenia: # dd if=/dev/zero of=/dev/hda bs=512 count=1 # dd if=/dev/zero of=/dev/hda1 bs=1024k count=50 # dd if=/dev/zero of=/dev/hda2 bs=1024k count=50 # dd if=/dev/zero of=/dev/hda3 bs=1024k count=50 # dd if=/dev/zero of=/dev/hda4 bs=1024k count=50 # reboot Boot Failure Insert Boot diskette in A: Press any key when ready.
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z poprzednim podrozdziałem — „Założenia”.
Odtwarzanie informacji dotyczących bloku rozruchowego Krok ten jest wykonywany podczas przywracania zawartości całego dysku za pomocą programu dd.
Przygotowywanie nowego głównego dysku Krok ten jest wykonywany w ramach przywracania zawartości całego dysku przy użyciu programu dd.
Odtwarzanie systemu operacyjnego W celu przywrócenia zawartości całego dysku należy wykonać następujące polecenie: # dd if=/kopie_zapasowe/hda.dd of=/dev/hda
354 |
Rozdz ał 11. Systemy L nux W ndows
Jeśli w czasie archiwizacji zastosowano narzędzie compress, operację odtwarzania należy przeprowadzić przy jego użyciu. Zależnie od lokalizacji wąskiego gardła program compress może przyspieszyć lub spowolnić odtwarzanie. # gzip -dc /kopie_zapasowe/hda.dd.gz | dd of=/dev/hda
Na tym etapie trzeba wyjąć z napędu dysk CD systemu Knoppix i ponownie uruchomić komputer. System powinien być w pełni funkcjonalny. Czyż nie było to proste?
Metoda obrazu partycji i alternatywnego ładowania W przykładzie zamieszczonym w tym podrozdziale za pomocą programu dd na poziomie partycji zarchiwizowano i przywrócono kompletny system. Metoda wymaga zamknięcia systemu (zamiast niego jest ładowany system Knoppix) i działa niezależnie od używanego systemu operacyjnego. Metoda jest trochę bardziej złożona od metody pełnego obrazu i alternatywnego ładowania, a ponadto wymaga zamknięcia systemu w czasie trwania archiwizacji. Jednakże ta metoda może być szybsza, gdy dla dysku poprawnie przeprowadzi się partycjonowanie. Można zaoszczędzić wiele miejsca i czasu, jeśli na dysku twardym partycje utworzy się w taki sposób, że na jednej z nich będzie znajdować się zarówno system operacyjny, jak i aplikacje, dzięki czemu procedurę będzie można zastosować tylko dla tej partycji (inne partycje można zarchiwizować przy użyciu zwykłych narzędzi tworzących kopie zapasowe systemu plików).
Tworzenie kopii zapasowej na potrzeby przywracania komputera od podstaw W celu sporządzenia kopii zapasowej na potrzeby przywracania komputera od podstaw należy wykonać poniższe kroki.
Archiwizowanie ważnych metadanych Za pomocą poniższego polecenia należy zarchiwizować rekord MBR. # dd if=/dev/hda of=/kopie_zapasowe/mbr bs=512 count=1
Załadowanie systemu z alternatywnego nośnika Po umieszczeniu w napędzie dysku CD systemu Knoppix należy go załadować przez ponowne uruchomienie komputera. Domyślnie Knoppix uaktywnia środowisko graficzne KDE z uprawnieniami użytkownika knoppix. Po przełączeniu na superużytkownika (początkowo nie ma dla niego zdefiniowanego hasła) należy utworzyć punkt podłączenia i podłączyć udział NFS jako /kopie_zapasowe. knoppix@0[knoppix]$ su # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
Metoda obrazu partycj alternatywnego ładowan a
|
355
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z wcześniejszym podrozdziałem „Założenia”.
Archiwizowanie systemu operacyjnego za pomocą wbudowanego narzędzia Przy użyciu programu dd w katalogu NFS można zapisać kopię zapasową systemu operacyjnego. Wykonując poniższe polecenie, można zidentyfikować wybrane partycje i tylko je zarchiwizować. # fdisk -l Disk /dev/hda: 41.1 GB, 41174138880 bytes 255 heads, 63 sectors/track, 5005 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks /dev/hda1 * 1 13 104391 /dev/hda2 14 4874 39045982+ /dev/hda3 4875 5005 1052257+ # dd if=/dev/hda1 of=/kopie_zapasowe/hda1.dd # dd if=/dev/hda2 of=/kopie_zapasowe/hda2.dd
Id 83 83 82
System Linux Linux Linux swap / Solaris
W przykładzie nie zarchiwizowaliśmy partycji /dev/hda3, ponieważ jest to partycja wymiany pozbawiona danych.
Alternatywnie można zastosować kompresję. Zależnie od lokalizacji wąskiego gardła może to przyspieszyć lub spowolnić proces archiwizowania. # dd if=/dev/hda1 | gzip -c > of=/kopie_zapasowe/hda1.dd.gz # dd if=/dev/hda2 | gzip -c > of=/kopie_zapasowe/hda2.dd.gz
Aby jednocześnie było tworzonych kilka kopii zapasowych, na końcu poleceń należy wstawić znak &. Spowoduje on umieszczenie wykonywanych zadań w tle. Jednakże w tym przypadku trzeba monitorować procesy takich zadań, żeby przed ponownym uruchomieniem komputera mieć pewność, że zostały całkowicie wykonane.
Przeprowadzanie procesu przywracania komputera od podstaw W celu przywrócenia komputera od podstaw należy wykonać poniższe kroki.
Ładowanie systemu z alternatywnego nośnika Pierwszym krokiem procesu przywracania komputera jest umieszczenie w napędzie dysku CD systemu Knoppix i załadowanie go. Gdy na tym etapie sprawdzi się tabelę partycji, uzyska się poniższe informacje. # fdisk -l Disk /dev/hda: 41.1 GB, 41174138880 bytes 16 heads, 63 sectors/track, 79780 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Disk /dev/hda doesn't contain a valid partition table
356
|
Rozdz ał 11. Systemy L nux W ndows
Tak jak wcześniej należy otworzyć okno terminala, a następnie przełączyć się na superużytkownika i podłączyć katalog NFS. knoppix@0[knoppix]$ su # mkdir /kopie_zapasowe # mount server_nfs:/dane08/jan /kopie_zapasowe
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z wcześniejszym podrozdziałem „Założenia”.
Odtwarzanie bloku rozruchowego i przygotowywanie nowego głównego dysku Aby móc odtworzyć poszczególne partycje, trzeba przywrócić rekord MBR i tabelę partycji; dopiero wtedy przywraca się wybrane partycje. W celu odtworzenia rekordu MBR i tabeli partycji należy wykonać następujące polecenie: # dd if=/kopie_zapasowe/mbr of=/dev/hda bs=512 count=1
Aby bez konieczności ponownego uruchamiania komputera system Knoppix stwierdził przywrócenie rekordu MBR, trzeba wykonać polecenie fdisk /dev/hda, a następnie w celu zapisania na dysku partycji wybrać opcję w. Choć ponowne uruchomienie komputera da taki sam rezultat, zajmie to więcej czasu.
Odtwarzanie systemu operacyjnego Można rozpocząć przywracanie danych systemu operacyjnego. W tym celu należy użyć programu dd w kolejności odwrotnej do zastosowanej podczas archiwizowania systemu. # dd if=/kopie_zapasowe/hda1.dd of=/dev/hda1 # dd if=/kopie_zapasowe/hda2.dd of=/dev/hda2
Jeśli w czasie archiwizacji zastosowano kompresję, powinno się wykonać poniższe polecenia. # gzip -dc /kopie_zapasowe/hda1.dd.gz | dd of=/dev/hda1 # gzip -dc /kopie_zapasowe/hda2.dd.gz | dd of=/dev/hda2
Również w tym przypadku pominięto partycję /dev/hda3, która nie zawiera żadnych danych. Aby jednocześnie było wykonywanych kilka operacji odtwarzania, na końcu poleceń należy wstawić znak &. Spowoduje on umieszczenie wykonywanych zadań w tle. Jednakże w tym przypadku trzeba monitorować procesy takich zadań, żeby przed ponownym uruchomieniem komputera mieć pewność, że zostały całkowicie wykonane. Pozostało jedynie wyjęcie z napędu dysku CD systemu Knoppix i ponowne uruchomienie komputera.
Metoda trybu online W przykładzie zamieszczonym w niniejszym podrozdziale użyto narzędzia tar do archiwizowania i przywracania systemu na poziomie partycji, dzięki czemu system nie musi być zamykany. Procedura była testowana w systemie Linux. Nie sprawdzaliśmy jej pod systemem Windows, ponieważ nie mogliśmy znaleźć żadnego narzędzia zachowującego listy kontroli dostępu ACL, które dołączono do systemów Windows i Knoppix. Być może uda się to Czytelnikowi. Metoda trybu onl ne
|
357
Tworzenie kopii zapasowej na potrzeby przywracania komputera od podstaw W celu sporządzenia kopii zapasowej na potrzeby przywracania komputera od podstaw należy wykonać poniższe kroki.
Archiwizowanie ważnych metadanych Aby zarchiwizować rekord MBR, należy zastosować następujące polecenie: # dd if=/dev/hda of=/kopie_zapasowe/mbr bs=512 count=1
Archiwizowanie systemu operacyjnego za pomocą wbudowanego narzędzia Po utworzeniu punktu podłączenia należy podłączyć katalog NFS jako /kopie_zapasowe. # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z wcześniejszym podrozdziałem „Założenia”.
Na tym etapie do archiwizacji systemu operacyjnego można użyć dowolnej metody. W omawianym przykładzie zastosowano program tar. Jedną partycję podłączono jako /boot, a resztę danych systemu — jako /. # cd /boot # tar cf /kopie_zapasowe/boot.tar . # cd / # tar cf /kopie_zapasowe/system.tar --exclude /mnt --exclude /proc --exclude /boot -exclude /kopie_zapasowe .
Alternatywnie można użyć kompresji. Zależnie od lokalizacji wąskiego gardła może to przyspieszyć lub spowolnić proces archiwizowania. # cd /boot # tar cfz /kopie_zapasowe/boot.tar.gz . # cd / # tar cfz /kopie_zapasowe/system.tar.gz --exclude /mnt --exclude /proc --exclude /boot --exclude /kopie_zapasowe .
Przeprowadzanie procesu przywracania komputera od podstaw W celu przywrócenia komputera od podstaw należy wykonać poniższe kroki.
Ładowanie systemu z alternatywnego nośnika Pierwszym krokiem procesu przywracania komputera jest umieszczenie w napędzie dysku CD systemu Knoppix i załadowanie go. Gdy na tym etapie sprawdzi się tabelę partycji, uzyska się poniższe informacje. # fdisk -l Disk /dev/hda: 41.1 GB, 41174138880 bytes
358 |
Rozdz ał 11. Systemy L nux W ndows
16 heads, 63 sectors/track, 79780 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Disk /dev/hda doesn't contain a valid partition table
Tak jak wcześniej należy otworzyć okno terminala, a następnie przełączyć się na superużytkownika i podłączyć katalog NFS. knoppix@0[knoppix]$ su # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z wcześniejszym podrozdziałem „Założenia”.
Odtwarzanie bloku rozruchowego i przygotowywanie nowego głównego dysku Aby móc odtworzyć poszczególne partycje, trzeba przywrócić rekord MBR i tabelę partycji; dopiero wtedy odtwarza się wybrane partycje. W celu odtworzenia rekordu MBR i tabeli partycji należy wykonać następujące polecenie: # dd if=/kopie_zapasowe/mbr of=/dev/hda bs=512 count=1
Aby bez konieczności ponownego uruchamiania komputera system Knoppix stwierdził przywrócenie rekordu MBR, trzeba wykonać polecenie fdisk /dev/hda, a następnie w celu zapisania na dysku partycji wybrać opcję w. Choć ponowne uruchomienie komputera da taki sam rezultat, zajmie to więcej czasu. Konieczne jest również przygotowanie partycji dla odtwarzanych systemów plików. Jeśli w kopii zapasowej pliku fstab są widoczne systemy plików ext2, należy wykonać poniższe polecenia (oczywiście ich zawartość zmienia się w zależności od typu wykorzystywanych systemów plików). # mkfs -t ext2 /dev/hda1 -L /boot # mkfs -t ext2 /dev/hda2 -L /
Odtwarzanie systemu operacyjnego Można rozpocząć proces przywracania systemu operacyjnego. Oto polecenia podłączające partycje: # mount /dev/hda1 # mount /dev/hda2
Domyślnie system Knoppix tworzy punkt podłączenia dla każdej zidentyfikowanej partycji. W związku z tym powinny być dostępne punkty podłączenia /mnt/hda1 i /mnt/hda2. Polecenie mount /dev/hda1 podłącza partycję /dev/hda1 do punktu /mnt/hda1. Jeśli tak nie jest, trzeba najpierw utworzyć punkt podłączenia.
Za pomocą polecenia cd należy przejść do nowego głównego systemu plików i wykonać polecenia przywracające. # # # #
cd /mnt/hda1 tar xpkf /kopie_zapasowe/boot.tar cd /mnt/hda2 tar xpkf /kopie_zapasowe/system.tar
Metoda trybu onl ne
|
359
Jeżeli zastosuje się kompresję, należy wykonać poniższe polecenia. cd /mnt/hda1 tar xpkfz /kopie_zapasowe/boot.tar.gz cd /mnt/hda2 tar xpkfz /kopie_zapasowe/system.tar.gz
# # # #
Trzeba jeszcze z napędu wyjąć dysk CD systemu Knoppix i ponownie uruchomić komputer.
Metoda systemu plików i alternatywnego ładowania W przykładzie zamieszczonym w tym podrozdziale do archiwizacji i przywracania partycji linuksowych użyto narzędzia tar, a do tworzenia kopii zapasowych partycji systemu Windows i ich odzyskiwania wykorzystano program ntfsclone. Metoda wymaga zamknięcia systemu (zamiast niego jest ładowany system Knoppix). Metoda powinna zadziałać w przypadku Linuksa i dowolnej wersji systemu Windows obsługującej system plików NTFS.
Tworzenie kopii zapasowej na potrzeby przywracania komputera od podstaw W celu sporządzenia kopii zapasowej służącej do przywrócenia komputera od podstaw należy wykonać poniższe kroki.
Archiwizowanie ważnych metadanych Za pomocą poniższego polecenia należy zarchiwizować rekord MBR. # dd if=/dev/hda of=/kopie_zapasowe/mbr bs=512 count=1
Procedura wymaga również znajomości formatów poszczególnych partycji, a zwłaszcza partycji systemu Windows. Informacje te powinno się zarejestrować przez sporządzenie kopii zapasowej wyniku polecenia fdisk -l i zawartości pliku fstab, a także utworzenie pliku tekstowego z wszelkimi dodatkowymi niezbędnymi danymi. W omawianym przykładzie partycję /dev/hda1 podłączono do /boot, partycję /dev/hda2 — do /, a ścieżka /dev/hda3 identyfikuje partycję systemu Windows.
Załadowanie systemu z alternatywnego nośnika Po umieszczeniu w napędzie dysku CD systemu Knoppix należy go załadować i otworzyć okno terminala. Domyślnie Knoppix uaktywnia środowisko graficzne KDE z uprawnieniami użytkownika knoppix. W dalszej kolejności trzeba przełączyć się na superużytkownika (początkowo nie ma dla niego zdefiniowanego hasła). knoppix@0[knoppix]$ su -
Archiwizowanie systemu operacyjnego za pomocą wbudowanego narzędzia Pierwszą rzeczą, którą trzeba zrobić, żeby procedura zadziałała, jest podłączenie katalogu NFS jako /kopie_zapasowe. # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
360
|
Rozdz ał 11. Systemy L nux W ndows
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z wcześniejszym podrozdziałem „Założenia”.
Następnie konieczne jest podłączenie różnych partycji jako systemów plików. # mount /dev/hda1 # mount /dev/hda2
W celu zarchiwizowania na tym etapie systemu operacyjnego można skorzystać z dowolnej metody. W przykładzie użyliśmy dla partycji linuksowych narzędzia tar, a dla partycji systemu Windows — programu ntfsclone. Choć można też dla partycji systemu Windows zastosować narzędzie tar, stwierdziliśmy, że program ntfsclone z większym prawdopodobieństwem zachowa wszelkie listy kontroli dostępu ACL. W omawianym przykładzie jedną partycję podłączono jako /boot, a resztę danych systemu — jako /. # cd /mnt/hda1 # tar cf /kopie_zapasowe/boot.tar . # cd /mnt/hda2 # tar cf /kopie_zapasowe/system.tar --exclude /mnt --exclude /boot --exclude /kopie_zapasowe .
Alternatywnie można dokonać kompresji. Zależnie od lokalizacji wąskiego gardła może to przyspieszyć lub spowolnić proces archiwizowania. # cd /mnt/hda1 # tar cfz /kopie_zapasowe/boot.tar.gz . # cd /mnt/hda2 # tar cfz /kopie_zapasowe/system.tar.gz --exclude /mnt --exclude /proc --exclude /boot --exclude /kopie_zapasowe .
W dalszej kolejności trzeba zarchiwizować partycję systemu Windows. Program ntfsclone sam w sobie nie jest programem obsługującym systemy plików, ponieważ nie archiwizuje na poziomie plików. W rzeczywistości jest to narzędzie tworzące obrazy, dla którego są zrozumiałe systemy plików NTFS. # ntfsclone --save-image --output /kopie_zapasowe/ntfs-clone.img /dev/hda3
Przeprowadzanie procesu przywracania komputera od podstaw W celu przywrócenia komputera od podstaw należy wykonać poniższe kroki.
Ładowanie systemu z alternatywnego nośnika Pierwszym krokiem procesu przywracania komputera jest umieszczenie w napędzie dysku CD systemu Knoppix i załadowanie go. Gdy na tym etapie sprawdzi się tabelę partycji, uzyska się poniższe informacje. # fdisk -l Disk /dev/hda: 41.1 GB, 41174138880 bytes 16 heads, 63 sectors/track, 79780 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Disk /dev/hda doesn't contain a valid partition table
Metoda systemu pl ków alternatywnego ładowan a
|
361
Tak jak wcześniej należy otworzyć okno terminala, a następnie przełączyć się na superużytkownika i podłączyć katalog NFS. knoppix@0[knoppix]$ su # mkdir /kopie_zapasowe # mount serwer_nfs:/dane08/jan /kopie_zapasowe
Jeśli nie jest dostępny serwer DHCP lub NFS, należy zapoznać się z wcześniejszym podrozdziałem „Założenia”.
Odtwarzanie bloku rozruchowego i przygotowywanie nowego głównego dysku Aby móc odtworzyć poszczególne partycje, trzeba przywrócić rekord MBR i tabelę partycji; dopiero wtedy przywraca się wybrane partycje. W celu odtworzenia rekordu MBR i tabeli partycji należy wykonać następujące polecenie: # dd if=/kopie_zapasowe/mbr of=/dev/hda bs=512 count=1
Aby bez konieczności ponownego uruchamiania komputera system Knoppix stwierdził przywrócenie rekordu MBR, trzeba wykonać polecenie fdisk /dev/hda, a następnie w celu zapisania na dysku partycji wybrać opcję w. Choć ponowne uruchomienie komputera da taki sam rezultat, zajmie to więcej czasu. Konieczne jest również przygotowanie partycji dla odtwarzanych systemów plików. Ponieważ w kopii zapasowej pliku fstab widać, że partycje /dev/hda1 i /dev/hda2 używają systemu plików ext2, należy wykonać poniższe polecenia. # mkfs -t ext2 /dev/hda1 -L /boot # mkfs -t ext2 /dev/hda2 -L /
Nie ma potrzeby przygotowywania partycji NTFS, która jest przywracana przy użyciu narzędzia ntfsclone.
Odtwarzanie systemu operacyjnego Można rozpocząć proces przywracania systemu operacyjnego. Za pomocą narzędzia tar zostaną odtworzone partycje linuksowe, a partycja systemu Windows — przy użyciu programu ntfsclone. Konieczne jest podłączenie następujących partycji: # mount /dev/hda1 # mount /dev/hda2
Za pomocą polecenia cd należy przejść do nowego głównego systemu plików i wykonać polecenia przywracające. cd /mnt/hda1 tar xpkf /kopie_zapasowe/boot.tar cd /mnt/hda2 tar xpkf /kopie_zapasowe/system.tar
# # # #
Jeżeli zastosuje się kompresję, należy wykonać poniższe polecenia. cd /mnt/hda1 tar xpkfz /kopie_zapasowe/boot.tar.gz cd /mnt/hda2 tar xpkfz /kopie_zapasowe/system.tar.gz
# # # #
362
|
Rozdz ał 11. Systemy L nux W ndows
W dalszej kolejności trzeba odtworzyć partycję systemu Windows /dev/hda3. W tym celu należy zastosować narzędzie ntfsclone. # ntfsclone --restore-image /kopie_zapasowe/ntfs-clone.img --overwrite /dev/hda3
Trzeba jeszcze z napędu wyjąć dysk CD systemu Knoppix i ponownie uruchomić komputer.
Automatyzowanie przywracania komputera od podstaw za pomocą narzędzia G4L Po objaśnieniu metod archiwizowania komputerów z dyskiem rozruchowym z zainstalowanym systemem Linux zajmiemy się prostszym rozwiązaniem, które części użytkowników może przypaść do gustu. G4L jest narzędziem umieszczonym na ładowalnym dysku CD-ROM, zapewniającym zestaw menu automatyzujących wcześniej zaprezentowane procesy tworzenia kopii zapasowych na potrzeby przywracania komputera od podstaw z wykorzystaniem alternatywnego ładowania. G4L to darmowe narzędzie, które obecnie bazuje na jądrze 2.6 systemu Linux. Do narzędzia są dołączone programy: dd, ntfsclone i tar, lecz nie mount. Z tego powodu kopie zapasowe na innym komputerze są sporządzane przy wykorzystaniu protokołu FTP. Choć nazwa narzędzia G4L jest skrótem od Ghost 4 Linux, nie należy mylić go z innym projektem, mającym identyczny skrót. Narzędzie G4L nie używa oprogramowania Norton Ghost i posługuje się terminem ghost tylko w ogólnym jego znaczeniu. Termin ten był stosowany długo przed nadaniem przez firmę Norton nazwy „Ghost” swojemu produktowi. Inny projekt, który można znaleźć w internecie, szukając łańcucha Ghost4Linux, ładuje Linuksa za pośrednictwem sieci w celu uaktywnienia symulowanego środowiska DOS umożliwiającego uruchomienie niektórych wersji narzędzia Norton Ghost. Program G4L nie działa w ten sposób, ponieważ jest kompletnym oprogramowaniem.
Zalety narzędzia G4L Narzędzie G4L jest znacznie prostsze do zastosowania niż metody przedstawione w rozdziale. Niezbędne będzie w przypadku większości użytkowników niezaznajomionych z systemem Linux. Ponieważ w porównaniu z protokołem NFS lub CIFS protokół FTP oferuje znacznie bardziej efektywny sposób transferowania danych, zwykle jest szybszy od 20 do 30%. Ze względu na to, że narzędzie G4L używa protokołu FTP, w środowiskach tylko z systemem Windows z łatwością można skonfigurować serwer IIS FTP, który będzie przechowywał obrazy kopii zapasowych. G4L potrafi automatycznie w trybie strumieniowym kompresować kopie zapasowe. W celu zwiększenia szybkości archiwizacji narzędzie odpowiednio stosuje mniejszą lub większą kompresję. Ponadto zapewnia prostą funkcję powielania między dyskami, a także obsługuje urządzenia SAN i może posłużyć do przeprowadzania archiwizacji typu dysk-dysk. Oprogramowanie G4L obejmuje też narzędzia dd_rhelp i dd_rescue przywracające zawartość dysku z uszkodzonymi sektorami. Ponieważ narzędzie G4L działa jako wirtualna maszyna Microsoft Virtual PC, można je przetestować w bezpiecznym środowisku.
Automatyzowan e przywracan a komputera od podstaw za pomocą narzędz a G4L
|
363
Wady narzędzia G4L Oprogramowanie G4L ma kilka ograniczeń. Ponieważ jest rozwiązaniem tworzącym obrazy przeznaczonym dla systemu Linux, w przypadku niektórych urządzeń może nie oferować sterowników. W takiej sytuacji narzędzie tworzy jedynie kopie zapasowe za pośrednictwem sieci, korzystając z protokołu FTP. Obecnie program G4L nie obsługuje punktów podłączeń NFS i SMB/CIFS. Nawet pomimo tego, że narzędzie jest proste w obsłudze i dość intuicyjne, obecnie jego dokumentacja nie jest tak dobra, jak mogłaby być. Można mieć nadzieję, że to się zmieni.
Konfigurowanie narzędzia G4L Konfigurowanie oprogramowania G4L jest bardzo proste. Ponieważ archiwizację przeprowadza się przy użyciu protokołu FTP, wymagany jest serwer FTP. Może być zastosowany serwer IIS FTP, war-ftpd lub dowolny inny serwer FTP. Konieczne będzie utworzenie konta użytkownika i hasła, a także nadanie mu prawa do wysyłania danych. Dodatkowo trzeba utworzyć katalog na tyle pojemny, aby można było zapisać w nim kopie zapasowe. Powinno się przetestować serwer FTP przez nawiązanie połączenia z nim ze stacji roboczej i wysłanie pliku do odpowiedniego katalogu. W dalszej kolejności wymagane jest pobranie obrazu ISO narzędzia G4L i zapisanie go na dysku CD. Strona projektu G4L znajduje się pod adresem http://sourceforge.net/projects/g4l. Po pobraniu obrazu można go umieścić na dysku CD, korzystając z pakietu oprogramowania nagrywarki. Dysponując ładowalnym dyskiem CD z narzędziem G4L, można uruchomić serwer, a następnie zarchiwizować go. Po umieszczeniu dysku CD w napędzie należy przeprowadzić inicjalizację komputera. Z dysku zostanie wczytany ekran z licencją i innymi informacjami. Po wyrażeniu zgody na warunki licencji przez wciśnięcie klawisza Enter pojawi się wiersz poleceń.
Zastosowanie narzędzia G4L W celu uruchomienia programu G4L z poziomu wiersza poleceń należy po prostu wykonać następujące polecenie: bash-3.00# g4l
Pojawi się główne menu umożliwiające wybranie opcji Raw Mode lub File Mode. Pierwsza opcja jest stosowana w przypadku większości archiwizacji. Opcja File Mode wymaga skonfigurowania specjalnego serwera z aktywnym demonem partimaged. Jednak nie ma powodu do obaw, ponieważ w dalszym ciągu przy użyciu opcji Raw Mode i narzędzia ntfsclone można tworzyć kopie zapasowe systemów plików. Opcja Raw Mode oferuje trzy opcje podrzędne: Network Use, Local Use i Click’ n’ Clone. Czytelnik powinien użyć opcji Network Use. Opcja Local Use pozwala na archiwizowanie lub odtwarzanie zawartości pliku kopii zapasowej (umieszczonej na innym dysku) dysku lub partycji. Z kolei opcja Click’ n’ Clone umożliwia powielanie zawartości jednego dysku na drugim. Wybranie opcji Network Use spowoduje wyświetlenie menu z 16 opcjami. Nie należy panikować. W większości przypadków do przeprowadzenia archiwizacji potrzebne będą tylko trzy opcje.
364 |
Rozdz ał 11. Systemy L nux W ndows
Określając ustawienia sieciowe, domyślnie narzędzie G4L używa interfejsu eth0 i protokołu DHCP. Choć jest to wystarczające w przypadku większości środowisk, w razie potrzeby można dokonać odpowiednich modyfikacji. Pierwsza opcja, A: Pick Device, umożliwia wybranie innej karty sieciowej Ethernet. Opcja B: Config Device pozwala ustawić adres IP dla tego interfejsu sieciowego. Przed wykonaniem operacji archiwizowania lub odtwarzania trzeba użyć opcji: D: Config FTP, E: Config useridpass i F: Config Filename. Opcja D: Config FTP jest powiązana z serwerem FTP, na którym umieszcza się kopie zapasowe. Opcja E: Config useridpass ustawia dla serwera FTP identyfikator użytkownika i hasło (wprowadza się łańcuch nazwa_użytkownika:hasło). Opcja F: Config Filename pozwala określić nazwę kopii zapasowej. Dodatkowo, jeśli katalog serwera FTP, w którym zapisuje się kopie zapasowe, nie ma nazwy /img, należy użyć opcji P: Path to Image Directory. Można również określić algorytm kompresji. Opcja G: Toggle Compression pozwala wybrać algorytm None, GZip, Lzop lub BZip2. Nie wnikając w to, która metoda kompresji jest najlepsza, należy zaznaczyć, że algorytm Lzop najszybciej tworzy kopie zapasowe. Większość użytkowników powinna skorzystać z tego algorytmu, ponieważ kopia zapasowa będzie mniejsza, a ponadto zostanie sporządzona w krótszym czasie w przypadku komputerów z procesorem Pentium I lub jego następcami. Po skonfigurowaniu powyższych ustawień można zdecydować, co i jak zarchiwizować. Opcja H: Backup umożliwia wybranie dysku lub partycji, dla której zostanie utworzona kopia zapasowa. Gdy określi się dysk lub partycję i kliknie przycisk OK, proces archiwizacji rozpocznie się. Opcja I: Restore powoduje odtworzenie zawartości kopii zapasowej zapisanej na serwerze FTP. Jeśli zamierza się zarchiwizować system plików, należy użyć opcji N: NTFSCLONE Backup, a następnie wybrać jedną z dostępnych partycji NTFS. Opcja O: NTFSCLONE Restore daje możliwość odtworzenia zawartości kopii zapasowej partycji NTFS. Po utworzeniu kopii zapasowej lub odtworzeniu jej zawartości można zapoznać się z podsumowaniem dotyczącym wydajności operacji. Umożliwia to opcja T: Display Time.
Dostosowywanie narzędzia G4L Narzędzie G4L można dostosowywać pod kątem zarządzanego środowiska. Najprościej zrobić to, korzystając z linuksowego środowiska programowania. Można zdefiniować menu z różnymi domyślnymi opcjami. W tym celu przed zapisaniem na dysku CD obrazu ISO należy go podłączyć jako interfejs pętli zwrotnej i zmodyfikować pliki konfiguracyjne. Domyślne ustawienia można określić w samym pliku narzędzia G4L, modyfikując zmienne: netzip, server, useridpass, netimagename, device i ftppath. Zmienne kolejno identyfikują zastosowaną kompresję, adres IP serwera FTP, utworzone na nim konto użytkownika i hasło, domyślną nazwę pliku kopii zapasowej, urządzenie ethernetowe i katalog serwera FTP, w którym są umieszczane kopie zapasowe. Aby z menu wyeliminować pozycje niemające zastosowania w zarządzanym środowisku, menu można również poddać innym modyfikacjom.
Rozwiązania komercyjne Abstrahując od darmowych metod opisanych w rozdziale, należy wspomnieć o kilku niedrogich komercyjnych narzędziach służących do przywracania komputera od podstaw. Funkcje takie oferuje też wiele produktów archiwizujących dla przedsiębiorstw. Oto kilka tego typu tanich Rozw ązan a komercyjne
|
365
(ceny od około 300 złotych) narzędzi dla systemu Windows: Acronis (http://www.acronis.com), Ghost (http://www.symantec.com), Paragon (http://www.drive-backup.com), Winternals (http://www. ¦winternals.com). Narzędzie Ghost tworzy obrazy krytycznych plików systemowych, umożliwiając przywrócenie ich do znanego poprawnego stanu, pod warunkiem że sprawny jest dysk twardy. Udało nam się znaleźć tylko jedno niedrogie narzędzie służące do przywracania od podstaw komputerów z systemem Linux. Jego producentem jest firma Storix (http://www.storix.com). Biorąc pod uwagę to, że ceny produktu zaczynają się od 99 dolarów, liczba oferowanych przez niego opcji przywracania robi wrażenie. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
366
|
Rozdz ał 11. Systemy L nux W ndows
ROZDZIAŁ 12.
Przywracanie od podstaw komputera z systemem HP-UX
W tym rozdziale omówiono procedury, których administrator systemu użyje w celu przywrócenia systemu operacyjnego HP-UX w przypadku wystąpienia awarii całego komputera (sytuacja, w której nie pozostało nic innego oprócz przywracania go od podstaw). Oprogramowanie Ignite-UX firmy Hewlett-Packard oferuje unikatową metodę przywracania systemu polegającą na integrowaniu w ramach architektury klient-serwer funkcji przywracania komputera od podstaw z ogólnym zestawem narzędzi wdrażających. Programy make_net_recovery i make_tape_ recovery pakietu Ignite-UX mogą posłużyć do tworzenia ładowalnych archiwów umożliwiających odzyskanie po wystąpieniu awarii systemu operacyjnego, który jest umieszczany na nowym lub oryginalnym urządzeniu. Archiwa mogą być zapisywane na dysku za pośrednictwem sieci lub na lokalnych napędach taśmowych. Narzędzie Ignite-UX może być zainstalowane z dysków CD aplikacji systemu HP-UX lub pobrane za darmo z witryny znajdującej się pod adresem http://software.hp.com. W tworzeniu niniejszego rozdziału udział brali Eric Stahl i Ron Goodwyn. Eric od 25 lat jest związany z branżą informatyczną. W tym czasie pracował w firmie HewlettPackard i centrum kontroli lotów promów kosmicznych, a także uczestniczył w próbnych lotach pierwszych egzemplarzy samolotów F15E i B2. Tytuł magistra z dziedziny informatyki Ron uzyskał na uczelni Tuskegee University. W przeszłości napisał kilka artykułów poświęconych oprogramowaniu przywracającemu Ignite-UX.
Przywracanie systemu za pomocą narzędzia Ignite-UX Początkowo narzędzie przywracające Ignite-UX nosiło nazwę make_recovery. Zapewniało administratorom systemów skuteczne środki pozwalające tworzyć ładowalne taśmy z kopiami zapasowymi głównej grupy woluminów (uwzględnia dysk rozruchowy). W aktualnej wersji narzędzia Ignite-UX program make_tape_recovery zastępuje make_recovery, oferując lepszą integrację z architekturą oprogramowania Ignite-UX i rozszerzonymi funkcjami. Dostępny jest również program make_net_recovery, co jest wynikiem większej popularności kompaktowych serwerów panelowych, wyższych przepustowości sieci i dostępności tanich dysków.
367
Począwszy od wersji 11.0 systemu HP-UX narzędzie copyutil, poprzednio zamieszczane na dysku Support Media i służące do tworzenia na taśmie obrazów wykorzystywanych do przywracania systemów HP-UX 9.x i 10.x, powinno być używane jedynie w przewidzianym zakresie jako program diagnostyczny trybu offline. Obecnie oprogramowanie Ignite-UX zapewnia rozszerzoną obsługę instalowania i przywracania dostosowanych systemów HP-UX. Program copyutil wchodzi w skład środowiska ODE (Offline Diagnostic Environment), będącego platformą narzędzi diagnostycznych trybu offline rozwiązujących problemy z komputerem działającym bez systemu operacyjnego lub takim, którego nie można przetestować za pomocą narzędzi trybu online.
Narzędzia make_net_recovery i make_tape_recovery muszą być uruchamiane przez superużytkownika z poziomu wiersza poleceń lub graficznego bądź terminalowego interfejsu użytkownika (GUI/TUI) serwera sieciowego Ignite-UX. Choć programy te można uaktywniać podczas pracy systemu, nie jest zalecane robienie tego w okresach największego obciążenia, gdy może mieć miejsce wiele operacji modyfikacji plików, katalogów i konfiguracji systemowych. Oprogramowanie Ignite-UX obsługuje zarówno menedżera LVM (Logical Volume Manager), jak i menedżera VxVM (Veritas Volume Manager), a także konfiguracje całych dysków.
Przegląd narzędzia Ignite-UX Instalacja i konfiguracja serwera Ignite-UX to wstępne wymaganie w przypadku wykonywania sieciowych operacji za pomocą programów make_net_recovery i make_tape_recovery. Technologia oprogramowania Ignite-UX umożliwia też administratorom systemów zdefiniowanie nowych konfiguracji systemowych, a następnie wdrożenie ich z poziomu zcentralizowanego serwera na klientach, które mogą działać pod kontrolą różnych wersji systemu HP-UX. Przed rozpoczęciem wykonywania takich operacji serwer Ignite-UX trzeba najpierw skonfigurować pod kątem komunikowania się z siecią. Muszą już być przygotowane niestandardowe konfiguracje wdrażania uwzględniające system operacyjny i aplikacje. Czasami przed wdrożeniem czegoś w środowisku produkcyjnym dla testowych systemów jest stosowana metoda prototypowania, która ma na celu sprawdzenie, czy wszystko działa poprawnie. Gdy jednak instalacja jest już w trakcie, w spójny sposób w ciągu kilku godzin można zainstalować wszystkie systemy. Projekt zestawu programów Ignite-UX cechuje się dużą modułowością i obejmuje polecenia, które mogą być wykonywane niezależnie od siebie. Wiele spośród tych narzędzi ma postać skryptów powłoki systemu Unix. Jest to korzystne w przypadku uniksowego środowiska, ponieważ administratorowi systemu jest znacznie łatwiej wykonywać zadania związane z zarządzaniem. Do podstawowych programów uaktywnianych przez narzędzia make_net_recovery i make_tape_recovery należy zaliczyć save_config i make_sys_image. Narzędzie make_tape_recovery używa polecenia make_medialif (dotyczy serwerów HP9000) lub make_ipf_tape (w przypadku serwerów HP Integrity), aby utworzyć składniki inicjalizujące, które ostatecznie są zapisywane na taśmie. Do większości tych poleceń dołączono dokumentację z przydatnymi przykładami. Czytanie dokumentacji i sprawdzanie zawartości skryptów powłoki to dobry sposób na zapoznanie się z funkcjonowaniem mechanizmów oprogramowania Ignite-UX.
368 |
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
Polecenie make_sys_image może być postrzegane jako siła napędowa narzędzi przywracających system. Polecenie to tworzy archiwum umożliwiające przywrócenie systemu. Polecenie save_config zbiera informacje na temat samego systemu. Polecenie make_sys_image można potraktować jako to, które zapewnia kawałki, a polecenie save_config — jako zapewniające pojemnik na nie. Oprogramowanie Ignite-UX i narzędzia systemu HP-UX mogą być użyte do utworzenia dostosowanego ładowalnego nośnika instalacyjnego w formacie CD lub DVD. W przypadku formatu DVD obrazy instalacyjne ISO są sporządzane za pomocą polecenia mkisofs, a następnie zapisywane na nośniku DVD przy użyciu polecenia growisofs. Obrazy instalacyjne formatu CD najpierw mają format systemu plików HFS lub CDFS, a następnie są zapisywane na dysku CD za pomocą polecenia cdrecord. Polecenie make_medialif ułatwia tworzenie ładowalnego nośnika CD lub DVD zarówno dla serwerów HP9000, jak i HP Integrity. Model przywracania systemu HP-UX jest rozwijany na podstawie ogólnego modelu wdrażania sieciowego oprogramowania Ignite-UX. Zamiast instalować ogólne obrazy systemu operacyjnego, programy make_net_recovery i make_tape_recovery tworzą obrazy na podstawie zawartości systemów plików. Niektóre systemy plików są uważane przez narzędzia przywracające oprogramowania Ignite-UX za niezbędne do uzyskania funkcjonalnego systemu. Domyślna lista zasadniczych plików znajduje się w katalogu /opt/ignite/recovery w pliku mnr_essentials. Jeśli w katalogu /var/opt/ignite/recovery istnieje plik mnr_essentials z taką listą zdefiniowaną przez użytkownika, wtedy jest używany. Plik mnr_essentials nie zawiera listy wszystkich plików, które będą archiwizowane (taką listę umieszczono w pliku flist, który omówiono w dalszej części rozdziału). W pliku tym jest wymieniony jedynie minimalny zestaw wymaganych plików. Jeśli modyfikacje pliku mnr_essentials nie są naprawdę istotne z punktu widzenia przywracania systemu, należy ich unikać.
Archiwum umożliwiające przywrócenie systemu zawiera informacje na temat konfiguracji komputera, takie jak nazwa hosta, adres IP, parametry sieci i pliki haseł. Tryb przywracania narzędzia Ignite-UX stosuje reguły, które zapewniają, że pliki z tymi informacjami są odtwarzane, gdy istnieją w archiwum. Dane konfiguracyjne mogą być edytowane przed rozpoczęciem procesu przywracania lub w czasie jego trwania. Archiwa są zapisywane na sieciowym serwerze Ignite-UX za pomocą polecenia make_net_recovery lub na lokalnej taśmie przy użyciu polecenia make_tape_recovery. Jest bardzo ważne, aby zwrócić uwagę, że ani polecenie make_tape_recovery, ani polecenie make_net_recovery nie zastępuje standardowych metod archiwizowania danych na taśmie. Narzędzia przywracające system oferowane w ramach pakietu IgniteUX w celu umożliwienia przywrócenia ładowalnego systemu operacyjnego powinny stanowić część ogólnej strategii archiwizowania i odzyskiwania danych po awarii.
Usługi sieciowe i protokoły zdalnego ładowania Konfigurowanie sieci i rozwiązywanie problemów to być może najbardziej złożony element procesu przywracania systemu przy użyciu oprogramowania Ignite-UX. Pod adresem http://docs. ¦hp.com można znaleźć kompletne instrukcje dotyczące konfigurowania i użytkowania narzędzia
Przywracan e systemu za pomocą narzędz a gn te-UX
| 369
Ignite-UX. Szukając terminu ignite, należy zlokalizować w formacie PDF lub HTML najnowszą wersję dokumentu Ignite-UX Administration Guide. Trzeba pamiętać, że polecenie make_tape_ ¦recovery może być zastosowane od razu po zainstalowaniu na komputerze oprogramowania Ignite-UX bez potrzeby konfigurowania jego serwera. Usługi i protokoły pakietu Ignite-UX (BOOTP, Remote Maintenance Protocol, TFTP i NFS) są dostępne dla systemu Unix od wielu lat. Gdy za pomocą polecenia make_net_recovery jest tworzone archiwum, zapisuje się je za pośrednictwem sieci w skompresowanej postaci na serwerze Ignite-UX przy wykorzystaniu jego punktów podłączenia NFS. Do opcjonalnych metod transferu archiwum należą m.in. remsh i ftp (należy zapoznać się z dokumentem instl_adm(4)). Urządzenia klienta w jednoznaczny sposób są rozpoznawane przez serwer Ignite-UX za pomocą sprzętowych adresów MAC (warstwa łącza) interfejsów sieciowych. Podczas przywracania zawartości archiwum za pośrednictwem sieci, zależnie od systemu i architektury sieci, zdalny klient w celu załadowania może zastosować takie technologie, jak BOOTP, Intel PXE (Preboot Execution Environment), RMP, TFTP i NFS. Systemy klientów HP Integrity z aktywnym środowiskiem PXE komunikują się z sieciowymi serwerami ładowania tylko za pomocą portów 67 i 68. Z kolei systemy klientów HP9000 używające protokołu BOOTP lub RMP mogą łączyć się z sieciowymi serwerami ładowania za pośrednictwem portów 67 i 68 lub 1067 i 1068. W przypadku starszych stacji roboczych z serii HP700 (pojawiła się przed serią 712), które nie stosują protokołu BOOTP, oprogramowanie Ignite-UX obsługuje zdalne ładowanie przy użyciu protokołu RMP. rbootd jest demonem zdalnego serwera ładowania, będącego częścią podstawowego systemu operacyjnego HP-UX. Działając na serwerze Ignite-UX, demon rbootd pełni rolę agenta przekierowującego, który zamienia żądania ładowania RMP na żądania ładowania BOOTP, a następnie wysyła je do serwerowego demona bootpd lub instl_bootd. rbootd przekształca też dane protokołu BOOTP na dane protokołu RMP na potrzeby transmisji zwrotnej do klienta. BOOTP jest protokołem zdalnego ładowania. bootpd to demon serwera ładowania, stanowiący część podstawowego systemu operacyjnego HP-UX. Serwer ten oferuje zarówno protokół DHCP, jak i BOOTP, używając portów 67 i 68 na potrzeby komunikacji między serwerami a klientami HP9000 lub HP Integrity. Opcje konfiguracyjne protokołu DHCP (dynamicznie przydziela hostom adresy IP i nazwy) są określane w pliku /etc/dhcptab, a ustawienia konfiguracyjne protokołu BOOTP — w pliku /etc/bootptab (zawiera stałe wpisy dla wybranych klientów sieciowych). Przed pojawieniem się wersji 11.23 systemu HP-UX demon bootpd był konfigurowany przy użyciu pliku /etc/bootptab, aby serwer Ignite-UX akceptował żądania zdalnego ładowania pochodzące od konkretnych klientów HP Integrity. Począwszy od wersji 11.23 systemu HP-UX za pośrednictwem pliku /etc/dhcptab dla demona bootpd stały się dostępne nowe opcje. Dzięki temu obecnie adresy IP zawarte w grupach pul urządzeń DHCP są dostępne dla anonimowych klientów HP Integrity ładujących się za pośrednictwem sieci. Jest to korzystne wtedy, gdy serwer Ignite-UX pełni rolę zarówno serwera sieciowego DHCP, jak i BOOTP. instl_bootd jest demonem serwera protokołu ładowania dołączonym do oprogramowania IgniteUX, który może być użyty zamiast demona bootpd. Demon instl_bootd jest konfigurowany za pomocą pliku /etc/opt/ignite/instl_bootptab. Początkowo demon ten w celu obsługi komunikacji między serwerami HP9000 a klientami stosował wyłącznie porty 1067 i 1068, specyficzne dla systemów HP-UX. Począwszy od wersji 4.2 oprogramowania Ignite-UX demon instl_bootd
370
|
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
serwera protokołu ładowania mógł być konfigurowany pod kątem portów 67 i 68. W związku z tym oprócz klientów HP9000 z protokołem BOOTP były też obsługiwane klienty HP Integrity z protokołem PXE. Na serwerze sieciowym Ignite-UX można uaktywnić jeden lub oba z demonów bootpd i instl_bootd. Drugi demon może zostać skonfigurowany w jednym z dwóch trybów. Oznacza to, że w przypadku oprogramowania Ignite-UX są możliwe cztery konfiguracje sieciowego serwera ładowania. Każda konfiguracja jest wdrażana przez modyfikację pliku /etc/inetd.conf (więcej na ten temat w dalszej części rozdziału). Przy wybieraniu konkretnej konfiguracji sieciowego serwera ładowania pod uwagę należy wziąć następujące podstawowe kwestie: użytkowane wersje systemu HP-UX i serwera Ignite-UX, obecność w sieci klientów HP9000 i (lub) HP Integrity, współpraca serwera DHCP (za pośrednictwem demona bootpd) z serwerem Ignite-UX, czy protokół DHCP jest już wykorzystywany przez serwer i czy nie powinien zostać wyłączony. Przez usunięcie znaku komentarza z początku poniższego wiersza pliku /etc/inetd.conf można uruchomić demona bootpd, żeby komunikował się z klientami HP9000 lub HP Integrity. Zarówno w przypadku demona bootpd, jak i demona instl_bootd nie powinny być usuwane znaki komentarza dla żadnych innych wierszy. bootps dgram udp wait root /usr/lbin/bootpd bootpd
W celu włączenia demona instl_bootd na potrzeby komunikowania się tylko z klientami HP9000 na początku powyższego wiersza pliku /etc/inetd.conf należy umieścić znak komentarza i dodać drugi poniższy wiersz. #bootps dgram udp wait root /usr/lbin/bootpd bootpd instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd
Aby uaktywnić demona instl_bootd w celu komunikowania się z klientami HP9000 lub HP Integrity, do pliku /etc/inetd.conf należy dodać ostatni z poniższych wierszy. #bootps dgram udp wait root /usr/lbin/bootpd bootpd #instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd bootps dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd
W przypadku tej konfiguracji trzeba sprawdzić, czy na początku wierszy demonów bootpd i instl_bootd znajduje się znak komentarza. Aby skonfigurować oba demony serwerów protokołów ładowania tak, żeby demon instl_bootd monitorował klienty HP9000, a bootpd — klienty HP9000 lub HP Integrity, w pliku /etc/inetd.conf należy umieścić dwa poniższe wiersze bez znaku komentarza. bootps dgram udp wait root /usr/lbin/bootpd bootpd instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd #bootps dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd
Zanim nakaże się demonowi inetd wczytanie takiej nowej konfiguracji pliku inetd.conf, należy wykonać polecenie netstat, które sprawdzi, czy na porcie 67 lub 68 nie ma żadnych aktywnych egzemplarzy demona bootpd. # netstat -an | grep -e "\.67" -e "\.68"
W dalszej kolejności należy wykonać polecenie nakazujące demonowi inetd ponowne wczytanie pliku /etc/inetd.conf i uwzględnienie wszelkich nowych zmian. # inetd -c
Przywracan e systemu za pomocą narzędz a gn te-UX
|
371
Różnice między klientami HP9000 i HP Integrity Po zainicjowaniu na serwerze Ignite-UX zdalnego ładowania klienta HP9000 lub HP Integrity za pośrednictwem sieci na ekranie konsoli klienta pojawia się interfejs TUI oprogramowania Ignite-UX. Można wybrać archiwum, posługując się opisem podanym podczas tworzenia archiwum za pomocą interfejsu TUI. Po uaktywnieniu różnych kart interfejsu TUI należy kliknąć przycisk Go, aby kontynuować. Z poziomu interfejsu serwera Ignite-UX można następnie monitorować status przywracania klienta z archiwum. Przed pojawieniem się interfejsu TUI oprogramowania Ignite-UX po stronie konsoli klienta funkcja zdalnego ładowania komputerów HP Integrity różniła się od oferowanej przez komputery HP9000. Różnice te muszą być wzięte pod uwagę podczas konfigurowania i wdrażania środowiska Ignite-UX. Z punktu widzenia administratora systemu można wyróżnić następujące dwie podstawowe różnice: • Początkowe ustawienia konfiguracyjne serwera Ignite-UX mające na celu przystosowanie
mieszanego środowiska z klientami HP Integrity i HP9000. Ustawienia te omówiono w poprzednim punkcie.
• Wykonywane polecenia konsoli i ekrany wyświetlane na zdalnie załadowanych klientach
HP Integrity i HP9000.
Podczas zdalnego ładowania komputery HP9000 (z uwzględnieniem starszych stacji roboczych z serii 700) mogą żądać usług od wybranych serwerów Ignite-UX BOOTP, używając w tym celu poleceń sprzętowych BCH (Boot Console Handler). W poniższych przykładach polecenia wykonano z poziomu wiersza poleceń BCH, do którego uzyskano dostęp przez przerwanie procesu ładowania systemu HP9000. Z poziomu tego wiersza można wykonywać polecenia dotyczące ładowania systemu, które za pośrednictwem sieci są kierowane do serwera ładowania Ignite-UX. Słowo kluczowe install ma w poleceniach wiersza poleceń BCH systemu HP9000 specjalne znaczenie. Słowo to wskazuje, że ma być zastosowany demon serwera protokołu ładowania BOOTP. Gdy pominie się słowo kluczowe install, poniższe polecenie wiersza poleceń BCH systemu HP9000 poszuka w sieci serwerów ładowania z aktywnym demonem install_bootd. BCH> search lan
Użycie w następnym poleceniu słowa kluczowego install spowoduje, że pod adres IP serwera Ignite-UX zostanie wysłane żądanie zdalnego ładowania. Administratorowi systemu wiadome jest, że na serwerze tym jest przechowywane potrzebne archiwum umożliwiające przywrócenie danych. Ponadto wie on, że na serwerze tym jest uruchomiony demon bootpd protokołu sieciowego BOOTP. BCH> boot lan.192.168.10.10 install
Następne przykładowe polecenie szuka w sieci dostępnych serwerów ładowania (z uwzględnieniem pomocniczych serwerów ładowania Ignite-UX). Użyte w poleceniu słowo kluczowe install powoduje wzięcie pod uwagę skonfigurowanych serwerów z demonem bootpd. Wynikiem polecenia jest lista serwerów ładowania, które odpowiedziały. Każdy serwer jest identyfikowany przez wybieralną wartość znajdującą się w kolumnie Path Number. BCH> search lan install Searching for potential boot device.
372
|
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
This may take several minutes. To discontinue, press ESCAPE Path Number
Device Path
Device
P0 P1
LAN.10.128.70.127.3.254 LAN.10.128.70.128.3.254
odwaga ibanez
Type
BCH> boot P1
Komputery HP Integrity korzystające z protokołu PXE nie dysponują podobnymi poleceniami lokalizującymi sieciowy serwer ładowania Ignite-UX. Takie serwery są konfigurowane w specjalny sposób, tak aby obsługiwały żądania klientów HP9000, pojedynczych klientów HP Integrity i (lub) wielu anonimowych klientów HP Integrity. W przytoczonym przykładzie administrator systemu za pomocą programu telnet zalogował się w konsoli MP (Management Processor) serwera HP Integrity rx7620, który może lub nie dysponować działającym lub ładowalnym systemem operacyjnym. W przypadku różnego rodzaju serwerów zarówno HP9000, jak i HP Integrity tego typu zdalny dostęp do konsoli to wygodny sposób na to, aby nie musieć udawać się w długą podróż do centrum danych. # telnet eiger-mp1 Trying... Connected to eiger-mp1.rose.hp.com. Escape character is '^]'. Local flow control off MP login: Admin MP password: Welcome to the rx7620 Management Processor (c) Copyright 1995-2004 Hewlett-Packard Co., All Rights Reserved. Version A.7.002 MP MAIN MENU: CO: VFP: CM: CL: SL: HE: X:
Consoles Virtual Front Panel (partition status) Command Menu Console Logs Show Event Logs Help Exit Connection
[mp] MP>
Korzystając z tego menu, można przemieszczać się między wieloma rozruchowymi partycjami sprzętowymi (nPar) skonfigurowanymi na serwerze, resetować komputery lub uaktywnić konsolę już uruchomionego systemu operacyjnego. W przykładzie rozruchowa partycja sprzętowa (nPar) będąca celem operacji przywracania systemu operacyjnego została zresetowana, a następnie przerwano proces ładowania, aby wyświetlić konsolę Intel EFI (Extensible Firmware Interface). Pod kilkoma względami podobna do konsoli BCH serwera HP9000, konsola EFI zapewnia na poziomie sprzętowym dostęp do narzędzi ładujących komputerów HP Integrity. Konsola umożliwia wybranie dowolnego programu uruchamiającego system operacyjny z każdego obsługiwanego nośnika rozruchowego. Korzystając z interfejsu menu konsoli EFI, trzeba użyć poprawnej emulacji terminala ANSII lub alternatywy dla niego, na przykład vt102. Przywracan e systemu za pomocą narzędz a gn te-UX
|
373
Gdy po zresetowaniu komputera nie będzie ustawiony znacznik autoboot, zostanie wykonane mapowanie urządzeń i pojawi się menu EFI Boot Manager. Jeśli znacznika tego użyto, konsola wyświetli komunikat Press Any Key to interrupt Autoboot. W obrębie menu EFI Boot Manager można się przemieszczać przy użyciu klawiszy strzałek skierowanych w dół i w górę lub klawiszy ^ i V. EFI Boot Manager ver 1.10 [14.61] Please select a boot option HP-UX Primary Boot: 0/0/0/3/0.6.0 HP-UX HA Alternate Boot: 0/0/0/3/0.5.0 Acpi(HWP0002,8C)/Pci(1|0)/Pci(4|0)/Mac(00306EF397E9) EFI Shell [Built-in] Boot Option Maintenance Menu Use ^ and v to change option(s). Use Enter to select an option
W przykładzie możliwe jest załadowanie systemu przy użyciu określonego interfejsu sieciowego identyfikowanego przez adres MAC (00306EF397E9) warstwy łącza. W celu dodania, usunięcia lub innej modyfikacji opcji ładowania należy wybrać menu Boot Option Maintenance Menu, a następnie na przykład pozycję Add a Boot Option. Na końcu dokonane zmiany należy zapisać w pamięci NVRAM.
Planowanie magazynowania archiwum Ignite-UX i przywracania jego zawartości Klient Ignite-UX dysponuje podzestawem oprogramowania zainstalowanego na serwerze IgniteUX. Podstawowa różnica między klientem i serwerem polega na tym, że ten drugi posłuży do zarządzania między innymi procesem przywracania jednego lub większej liczby klientów. Proces ten przede wszystkim obejmuje uaktywnienie dodatkowych usług sieciowych, przeznaczenie przestrzeni dyskowej na potrzeby przechowywania archiwów przywracanych danych i przygotowywanie procedury zdalnego ładowania używanej podczas przywracania.
Kwestie związane ze zdalnym ładowaniem klientów Poniżej wymieniono wstępne kwestie dotyczące zdalnego ładowania klientów z systemem HP-UX, które mają być przywrócone przy wykorzystaniu oprogramowania Ignite-UX. Czy klient dysponuje działającym systemem operacyjnym oferującym funkcje sieciowe? Jeśli na komputerze znajduje się sprawny system z obsługą sieci, proces sieciowego ładowania klienta może być zainicjowany z serwera Ignite-UX przechowującego obraz przywracanych danych, który za pośrednictwem sieci jest transferowany do klienta. W tym przypadku serwer Ignite-UX za pomocą polecenia bootsys rozpoczyna proces przywracania systemu operacyjnego na jednym lub kilku klientach, nie wymagając interakcji z konsolą każdego z nich. Polecenie bootsys kopiuje z serwera Ignite-UX do klienta w wersji instalacyjnej jądro i główny system plików, konfiguruje klienta, aby przy użyciu tego jądra automatycznie się ładował, a także ponownie uruchamia komputer. W dalszej kolejności za pośrednictwem sieci jest przeprowadzany proces przywracania zawartości archiwum. Jeżeli klient jest pozbawiony systemu operacyjnego komunikującego się z siecią, musi zostać załadowany za pomocą bezpośrednio podłączonej lub zdalnej konsoli, żeby z serwera Ignite-UX można było pobrać za pośrednictwem sieci obraz przywracanych danych. 374
|
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
Gdy w ten sposób, pobierając obraz, za pośrednictwem sieci załaduje się klienta HP Integrity, będzie można skorzystać z dowolnego interfejsu sieciowego obsługiwanego przez konsolę EFI. Ładując przy użyciu tej metody klienta HP9000, trzeba zastosować jego wbudowany interfejs sieciowy. W przeciwnym razie klient HP9000 będzie musiał być przywracany z lokalnego obrazu zapisanego na przykład na taśmie (polecenie make_tape_recovery), niestandardowym ładowalnym dysku CD/DVD Ignite-UX lub innym nośniku instalacyjnym systemu operacyjnego. Oczywiście w tym przypadku należy przyjąć, że klienty są wyposażone w napęd taśmowy lub CD/DVD. Czy klienty i serwery Ignite-UX są zlokalizowane w tej samej podsieci? Jeśli klient i serwer ładowania Ignite-UX znajdują się w różnych podsieciach, w podsieci klienta trzeba skonfigurować pomocniczy serwer ładowania Ignite-UX lub — jak już wspomniano — przed połączeniem się z serwerem Ignite-UX należy skorzystać z lokalnej taśmy lub dysku CD/DVD w celu przeprowadzenia wstępnego ładowania. Zadaniem pomocniczego serwera ładowania jest zapewnienie tymczasowego adresu IP, a także instalacja jądra i głównego systemu plików. Inaczej mówiąc, wstępne sieciowe ładowanie klienta z poziomu serwera protokołu ładowania musi przebiegać w obrębie jednej podsieci. Gdy to nastąpi, klient będzie mógł nawiązać połączenie z serwerem Ignite-UX znajdującym się w innej podsieci, aby pobrać i zainstalować archiwum z przywracanymi danymi. Konfigurowanie pomocniczego serwera ładowania szczegółowo omówiono w przewodniku Ignite-UX Administration Guide, dostępnym pod adresem http://docs.hp.com. Jak można wcześniej przygotować się na różne scenariusze związane ze zdalnym ładowaniem? W przypadku klientów, które mogą zawieść w sytuacji, gdy niezbędne jest sieciowe ładowanie za pomocą oprogramowania sprzętowego przy wykorzystaniu lokalnej konsoli klienta i jego wybranego interfejsu sieciowego, pomocne może okazać się wcześniejsze przygotowanie się: zgromadzenie informacji na temat sieci, przydatnych podczas procesu przywracania. W poprzednim przykładzie serwer HP Integrity wyposażono w pięć interfejsów sieciowych, z których cztery wchodzą w skład 4-portowej karty sieciowej. Główny interfejs stosowany do zdalnego sieciowego ładowania jest identyfikowany przez adres sprzętowy 0/0/8/1/0/4/0. Oznaczenie rx zawarte w nazwie modelu wskazuje, że ma się do czynienia z serwerem HP Integrity. Wynik polecenia lanscan obejmuje adresy sprzętowe i adresy MAC warstwy łącza. W wyniku polecenia ioscan widnieją numery nadawane interfejsom przez firmę HP. # model ia64 hp server rx7620 # lanscan Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI Path Address In# State NamePPA ID Type Support Mjr# 0/0/8/1/0/4/0 0x00306EF397E9 0 UP lan0 snap0 1 ETHER Yes 119 0/0/14/1/0/4/0 0x000E7F4FB144 1 UP lan1 snap1 2 ETHER Yes 119 0/0/14/1/0/5/0 0x000E7F4FB145 2 UP lan2 snap2 3 ETHER Yes 119 0/0/14/1/0/6/0 0x000E7F4FB146 3 UP lan3 snap3 4 ETHER Yes 119 0/0/14/1/0/7/0 0x000E7F4FB147 4 UP lan4 snap4 5 ETHER Yes 119 # ioscan -fnC lan Class I H/W Path Driver S/W State H/W Type Description ===================================================================== lan 0 0/0/8/1/0/4/0 igelan CLAIMED INTERFACE HP A6794-60001 PCI 1000Base-T lan 1 0/0/14/1/0/4/0 btlan CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port lan 2 0/0/14/1/0/5/0 btlan CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port lan 3 0/0/14/1/0/6/0 btlan CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port lan 4 0/0/14/1/0/7/0 btlan CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port
Planowan e magazynowan a arch wum gn te-UX przywracan a jego zawartośc
|
375
Ustalanie rozmiaru archiwum przywracanych danych Ważne jest, żeby poprawnie określić rozmiar archiwum przywracanych danych. Jeśli archiwum jest duże i zastosuje się polecenie make_tape_recovery, może zająć wiele taśm. Coś takiego powoduje pewną niedogodność zarówno przy tworzeniu archiwum, jak i przywracaniu jego zawartości. Polega ona na tym, że użytkownik musi uczestniczyć w całym procesie, który w przeciwnym razie mógłby przebiegać automatycznie (na przykład po zastosowaniu zadania narzędzia cron). Wielu administratorów systemów planuje zapisywanie archiwum na taśmie wtedy, gdy system jest w mniejszym stopniu obciążony (na przykład w nocy i w czasie weekendu). W przypadku archiwów sporządzanych przy użyciu polecenia make_net_recovery pojawiają się dodatkowe trudności związane z obliczeniami niezbędnej przestrzeni dyskowej, a także pojemności zewnętrznego magazynu i czasu trwania archiwizacji na taśmie. Warto zauważyć, że liczba kolejnych archiwów przechowywanych na dysku jest określana za pomocą interfejsu serwera Ignite-UX lub z poziomu wiersza poleceń przy użyciu opcji -n. Parametr serwera Ignite-UX przechowujący taką informację nosi nazwę save_num_archives i znajduje się w pliku /var/opt/ignite/clients/client_names/recovery/defaults. Następną kwestią dotyczącą ustalania rozmiaru archiwów przywracanych danych jest umieszczanie w innych grupach woluminów systemów plików, które normalnie są zlokalizowane w głównej grupie woluminów. Nie wolno ulec pokusie rozdzielenia w różnych grupach woluminów wymaganych plików i katalogów systemowych. Decydując, co powinno zostać dodane do głównej grupy woluminów i archiwum przywracanych danych, a co nie, najlepiej w całości w głównej grupie woluminów pozostawić ładowalny system o rozsądnej wielkości. Tworząc archiwum zawartości samego serwera Ignite-UX, warto rozważyć wykluczenie zbioru dyskowych archiwów służących do przywracania klientów. Domyślnie archiwa te są zlokalizowane w obrębie systemu plików /var. Katalog /home jest kolejnym przykładem systemu plików, który może być wyłączony z archiwum przywracanych danych. Rozmiar tego systemu plików należy odnieść do wielkości reszty zawartości archiwum. Ponadto należy zastanowić się, jak często są sporządzane archiwa i czy dopuszczalne byłoby odtworzenie po zakończeniu procesu przywracania systemu operacyjnego danych z najnowszej wersji zwykłej kopii zapasowej katalogu /home zapisanej na taśmie.
Polecenie make_net_recovery za pośrednictwem sieci zapisuje i pobiera archiwa, korzystając z dwóch punktów podłączenia NFS. Pierwszy punkt podłączenia służy do przechowywania danych konfiguracyjnych na temat klienta, drugi magazynuje samo archiwum. Archiwum nie musi być magazynowane na serwerze Ignite-UX. Można je umieścić na dowolnym poprawnie skonfigurowanym serwerze NFS. W tym przypadku proces oprogramowania Ignite-UX zarządzający przywracaniem angażuje trzy różne komputery: serwer Ignite-UX, klienta i zdalny serwer archiwów (opcjonalny). Domyślne miejsce przechowywania poszczególnych archiwów przywracanych danych jest określane na etapie wstępnej konfiguracji klienta za pomocą interfejsu serwera Ignite-UX. Używając opcji -a polecenia make_net_recovery, można wybrać alternatywne lokalizacje. Parametr serwera Ignite-UX rejestrujący te informacje nosi nazwę recovery_location i znajduje się w pliku /var/opt/ignite/clients/client_name/recovery/defaults. Zanim alternatywna lokalizacja będzie mogła być zastosowana, trzeba dla niej ręcznie utworzyć katalogi i reguły eksportowania NFS.
376
|
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
Konfigurowanie serwera sieciowego Ignite-UX Po przeprowadzeniu instalacji oprogramowania Ignite-UX za pomocą polecenia swinstall można rozpocząć proces konfiguracji serwera sieciowego Ignite-UX. Ma to miejsce, gdy superużytkownik po raz pierwszy przy użyciu programu /opt/ignite/bin/ignite wywołuje interfejs serwera. Choć konfigurowanie serwera Ignite-UX jest wymagane przed wykonaniem sieciowego polecenia make_net_recovery, z polecenia make_tape_recovery można skorzystać od razu po zainstalowaniu oprogramowania Ignite-UX w systemie HP-UX, aby na lokalnym napędzie taśmowym zapisać archiwa przywracanych danych. Zaletą wykonywania poleceń make_net_recovery i make_tape_recovery na serwerze Ignite-UX jest to, że oprogramowanie Ignite-UX niezbędne do przeprowadzenia procesu przywracania danych archiwów jest automatycznie instalowane na klientach.
W wyświetlanym na początku ekranie Welcome To Ignite-UX znajdują się przyciski Server Setup i Tutorial and Demo (należy go kliknąć, aby uzyskać dostęp do elektronicznej pomocy). Kreator Server Setup w ramach kolejnych kroków pozwala administratorowi systemu wykonać następujące czynności:
1. Ustawienie tymczasowych adresów IP ułatwiających klientom serwera ładowania pobranie
z niego i zainstalowanie jądra w celu przygotowania się do procesu instalacji lub przywracania. Ważne jest, aby sprawdzić, czy adresy te nie są wykorzystywane. Jeden adres jest wymagany dla każdej jednocześnie realizowanej operacji instalacji lub przywracania.
2. Określenie (opcjonalne) adresów przydzielonych przez serwer DHCP i używanych przez
klienty po wykonaniu wstępnego zdalnego ładowania obsługiwanego przez serwer IgniteUX. Serwer DHCP jest stosowany wyłącznie w przypadku klientów, dla których wcześniej nie ustalono nazwy hosta i adresu IP.
3. Utworzenie magazynu oprogramowania obejmującego podstawowe aplikacje systemu operacyjnego wykorzystywane w modelu wdrażania serwera Ignite-UX (nie jest to stosowane w przypadku przywracania systemu).
Następnym razem, gdy po przeprowadzeniu konfiguracji pojawi się ekran Welcome To IgniteUX, należy kliknąć przycisk OK, aby wyświetlić główny interfejs serwera Ignite-UX. Po znalezieniu w nim menu rozwijanego Options należy wybrać pozycję Server Configuration, żeby przejrzeć i zmodyfikować numer serwera Ignite-UX i parametry konfiguracyjne. Opcje sesji kontrolują zachowanie klientów w czasie instalacji lub przywracania. Z menu Actions należy wybrać pozycję Add New Client for Recovery. Po podaniu nazwy klienta za pomocą programu remsh lub ssh serwer Ignite-UX pobierze od klienta wymagane informacje. Oprogramowanie przywracające niezbędne po stronie klienta jest automatycznie instalowane lub aktualizowane z poziomu interfejsu serwera Ignite-UX. Jeśli polecenie make_net_recovery wykona się z poziomu wiersza poleceń klienta i wersja oprogramowania przywracającego różni się od wersji znajdującej się na serwerze, może zostać wygenerowany błąd. Aby ręcznie zainicjować aktualizację (a nie instalację) oprogramowania przywracającego klienta, w dokumentacji polecenia make_net_recovery należy poszukać przykładowego skryptu, który używa programów /opt/ignite/lbin/check_version i SD-UX swinstall.
Planowan e magazynowan a arch wum gn te-UX przywracan a jego zawartośc
|
377
Wspomniana już nowa funkcja demona bootpd systemu HP-UX 11.23, czyli obsługa grup puli urządzeń DHCP, wymaga ręcznej edycji pliku /etc/dhcptab. Modyfikacja polega na zastosowaniu nowych opcji konfiguracyjnych re i ncid (sekcja dhcp_device_group). Opcja re nakazuje serwerowi DHCP dopasowywanie wyrażeń regularnych do identyfikatora klasy. Opcja ncid wskazuje, że odpowiedź z serwera nie będzie zawierać identyfikatora klasy, ponieważ protokół BOOTP nie obsługuje w pełni protokołu PXE. Poniżej zamieszczono przykład sekcji dhcp_device_group z dwoma nowymi opcjami, które począwszy od wersji 11.23 systemu HP-UX są używane przez demon bootpd. Opcja bf (boot file) określa program sieciowego ładowania początkowego dla dysków rozruchowych EFI (Extensible Firmware Interface — interfejs wykorzystywany przez serwery HP Integrity), których zawartość zostanie pobrana w celu kontynuowania ładowania. Inne opcje sekcji dhcp_device_group zastosowane w przykładzie odpowiadają za przypisanie adresów IP. dhcp_device_group:\ re:\ ncid:\ class-id="PXEClient:Arch:00002:.*":\ lease-time=300:\ subnet-mask=255.255.255.0:\ addr-pool-start-address=192.168.1.10:\ addr-pool-last-address=192.168.1.20:\ bf=/opt/ignite/boot/nbp.efi
W celu uzyskania szczegółów dotyczących kompletnej konfiguracji należy zapoznać się z najnowszą wersją dokumentu Ignite-UX Administration Guide, dostępną pod adresem http://docs.hp.com, a także plikami pomocy dołączonymi do poleceń serwera Ignite-UX i systemu HP-UX.
Zarządzanie archiwami przywracanych danych Proces tworzenia archiwów lub przywracania ich zawartości można zainicjować z poziomu graficznego interfejsu serwera Ignite-UX lub wiersza poleceń. Jeśli serwer nie jest wyposażony w graficzny wyświetlacz, należy skorzystać z trybu TUI, aby uruchomić interfejs ignite. Polecenie make_net_recovery można wykonać w wierszu poleceń klienta lub za pomocą interfejsu serwera Ignite-UX. Polecenie make_tape_recovery można wywołać z poziomu wiersza poleceń klienta lub za pośrednictwem interfejsu serwera Ignite-UX. Gdy proces zainicjuje się na serwerze Ignite-UX, polecenie make_tape_recovery zostanie wykonane po stronie klienta, zapisując dane na jego napędzie taśmowym. Jeżeli do wywołania polecenia make_tape_recovery zamiast interfejsu serwera Ignite-UX zastosuje się wiersz poleceń klienta, nie będzie wymagane podłączanie systemu plików NFS ani jakakolwiek konfiguracja serwera Ignite-UX. Jeśli w celu określenia serwera Ignite-UX po stronie klienta wykona się polecenie make_tape_recovery z opcją -s, nastąpi podłączenie systemu plików NFS. Ponadto polecenie użyje danych konfiguracyjnych zapisanych po zakończeniu ostatniej sesji programu make_tape_recovery załadowanego na serwerze. Po ukończeniu wstępnej konfiguracji serwera Ignite-UX w celu zarządzania sieciowymi archiwami w dalszym ciągu można korzystać z serwerowego interfejsu GUI lub TUI. Oto kilka zalet takiego interfejsu: • Scentralizowane administrowanie operacjami sieciowymi i ich kontrolowanie. • Ustawienia konfiguracyjne wprowadzone za pomocą interfejsu GUI lub TUI są zapisywane
na serwerze Ignite-UX i automatycznie wczytywane przy kolejnych jego uruchomieniach. 378
|
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
• Niezbędne narzędzia przywracające są automatycznie instalowane i aktualizowane na
klientach. • Widoczna jest ikona reprezentująca archiwizowany system. Może też zostać wyświe-
tlony monitor statusu, który od początku do końca informuje o postępie procesu tworzenia archiwum. • Domyślne katalogi są automatycznie tworzone wraz z powiązanymi punktami podłączenia
NFS i danymi konfiguracyjnymi exportfs, ułatwiającymi interakcję między klientem i serwerem. Jeśli do przechowywania archiwów nie są stosowane domyślne katalogi (z uwzględnieniem tego, że są zlokalizowane na serwerze innym niż Ignite-UX), wyżej wymieniona czynność musi zostać wykonana ręcznie zarówno po stronie serwera Ignite-UX, jak i serwera archiwizującego. Oto trzy scenariusze, w przypadku których użytkownicy mogą rozważyć użycie wiersza poleceń: • Polecenia przywracające dane zostały wywołane z poziomu graficznego interfejsu i ustawie-
nia zapisane po tej sesji muszą zostać nadpisane. • Polecenia przywracające dane zostały wykonane z poziomu graficznego interfejsu i ich
przyszłe wywołania powinny skorzystać z tych samych ustawień co zapisane. • Polecenia przywracające dane zostały wywołane po raz pierwszy i Czytelnik, będąc doświad-
czonym użytkownikiem, chce bezpośrednio zapoznać się z wynikiem tych poleceń.
Przykład wdrożenia Administrator systemu zauważył, że dzienniki systemowe wskazują na błędy sprzętowe i uszkodzenie systemu plików w głównej grupie woluminów. W celu wyizolowania awarii napędu dysku rozruchowego dodatkowa analiza obejmowała diagnostykę urządzeń komputera. Pora na przeprowadzenie przywracania komputera od podstaw, aby znów był w pełni funkcjonalny. Poniższy przykład ilustruje użycie polecenia make_net_recovery (kroki wykonywane w przypadku polecenia make_tape_recovery powinny być podobne). Zanim wystąpiła awaria, administrator systemu utworzył archiwum przywracanych danych. Oto kroki, które wykonał:
1. Instalacja oprogramowania Ignite-UX (dostępne pod adresem http://software.hp.com lub na nośniku HP-UX Applications) na serwerze sieciowym.
2. Po ukończeniu instalacji administrator wykonał polecenie /opt/ignite/bin/ignite, żeby uaktywnić interfejs GUI/TUI i skonfigurować serwer Ignite-UX.
3. Nadal korzystając z interfejsu serwera Ignite-UX, administrator wprowadził nazwę komputera klienta przeznaczonego do archiwizacji. Po połączeniu się z klientem serwer Ignite-UX zbiera wymagane informacje i wyświetla ikonę klienta.
4. Administrator prawym przyciskiem myszy kliknął ikonę i z menu wybrał pozycję Create
Network Recovery Archive. W dalszej kolejności serwer Ignite-UX wyświetlił serię ekranów z różnymi instrukcjami i wskazówkami.
5. Po wyświetleniu przez serwer Ignite-UX domyślnych ustawień archiwów administrator
zmienił kilka opcji, takich jak maksymalna liczba przechowywanych archiwów i ich opis. Dalej administrator sprawdził, czy w docelowym katalogu jest wystarczająco dużo miejsca
Przykład wdrożen a
|
379
do zapisania archiwum. Ścieżka domyślnego katalogu serwera to var/opt/ignite/recovery/ ¦archives/. Domyślnie serwer Ignite-UX archiwizuje wyłącznie główną grupę woluminów. Choć opcjonalnie w archiwum może być uwzględniona zawartość innych dysków i grup woluminów, dobrą praktyką jest archiwizowanie tylko głównej grupy z jednoczesnym sprawdzeniem, czy zawiera jedynie to, co jest niezbędne do załadowania systemu operacyjnego.
6. Po wybraniu opcji Finish został rozpoczęty proces tworzenia archiwum. 7. Kolor ikony odzwierciedla powodzenie operacji, błędy lub ostrzeżenia wygenerowane przez proces archiwizacji (kolor zielony oznacza sukces, natomiast czerwony i żółty — odpowiednio błędy i ostrzeżenia). W celu monitorowania w czasie rzeczywistym postępu procesu archiwizacji należy prawym przyciskiem myszy kliknąć ikonę i wybrać pozycję Client Status.
8. Administrator systemu wywołał następne polecenie archiwizujące, make_net_recovery,
z poziomu interfejsu serwera Ignite-UX lub wiersza poleceń klienta (kroki od 1. do 7. są wymagane tylko przy pierwszym tworzeniu archiwum).
Gdy doszło do awarii i zidentyfikowano uszkodzenie, zamówiono i odebrano zastępczy napęd dyskowy. Administrator systemu rozpoczął proces przywracania, wykonując następujące kroki:
1. Wyłączenie komputera klienta, a następnie wymiana uszkodzonego dysku rozruchowego. 2. Ponieważ nowy dysk jest pozbawiony systemu operacyjnego, administrator włączył komputer klienta, po czym ujrzał komunikat oprogramowania sprzętowego i zainicjował zdalne ładowanie w celu przeprowadzenia instalacji jądra z serwera Ignite-UX.
3. Używając w obrębie konsoli klienta interfejsu TUI serwera Ignite-UX, administrator wy-
brał archiwum, z którego zostaną przywrócone dane (etykiety archiwów bazują na opisie wprowadzonym w momencie ich sporządzenia; domyślna konwencja nazewnicza zaleca zastosowanie formatu uwzględniającego datę i godzinę utworzenia archiwum, na przykład Archiwum przywracania 2006-02-04,07:43).
4. Administrator systemu zrobił sobie filiżankę kawy i monitorował proces przywracania do chwili jego zakończenia (trwało to mniej więcej 45 minut).
Przykłady z zastosowaniem wiersza poleceń W poniższych przykładach użycia polecenia make_net_recovery przyjęto, że plik defaults został automatycznie wygenerowany za pomocą opcji Add New Client for Recovery (zastosowano nazwę klienta hal). Z kolei serwerowi Ignite-UX nadano nazwę ibanez. ibanez: /var/opt/ignite/clients/hal/recovery # cat defaults # # Plik służy do określenia domyślnych ustawień dla polecenia # make_net_recovery. Plik jest nadpisywany każdorazowo, gdy # uruchomi się interfejs przywracania, nawet jeśli nie utworzono # archiwum. Plik nie powinien pełnić roli pewnego źródła # informacji na temat dowolnego archiwum. # RECOVERY_TYPE=net RECOVERY_LOCATION=ibanez:/var/opt/ignite/recovery/archives/hal
380 |
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
TAPE_DESTINATION=none RECOVERY_DESCRIPTION=Recovery Archive SAVE_NUME_ARCHIVES=2 ARCHIVE_TYPE=tar
Ponieważ serwer Ignite-UX już dysponuje konfiguracją archiwów, poniższe polecenie może być wykonane w wierszu poleceń klienta (zamiast inicjalizowania za pośrednictwem interfejsu serwera Ignite-UX), aby utworzyć sieciowe archiwum oparte na istniejącej konfiguracji klienta przechowywanej na serwerze ibanez. # make_net_recovery -s ibanez
W celu automatycznego wywoływania polecenia z wybraną częstotliwością można zdefiniować zadanie programu cron. Poniższe polecenie zapisuje na lokalnym napędzie taśmowym archiwum systemu, używając ustawień uzyskanych po ostatnim wykonaniu tego samego polecenia. # make_tape_recovery -s ibanez
Przyjmijmy, że wyczerpuje się wolne miejsce systemu plików /var serwera Ignite-UX i brakuje przestrzeni dyskowej niezbędnej do pomieszczenia nowego archiwum. Poniższe polecenie nadpisuje istniejący parametr recovery_location, przy założeniu, że ręcznie ustalono lokalizację nowego archiwum i poprawnie wyeksportowano ją za pośrednictwem usługi NFS. # make_net_recovery -s ibanez -a ibanez:/depot/recovery/archives/hal
Każde z tych trzech przykładowych poleceń tworzy minimalne archiwum przywracanych danych, zawierające wyłącznie katalogi i pliki, które oprogramowanie Ignite-UX uważa za niezbędne, aby system mógł działać (wykorzystywany jest plik mnr_essentials). Zwykle podczas sporządzania archiwum są uwzględniane dowiązania symboliczne, lecz nie lokalizacje, do których się odwołują. Jeśli jednak dowiązanie wymieniono w pliku mnr_essentials, zostaną zarchiwizowane również dane, na które ono wskazuje.
Poniższe przykładowe polecenia używają opcji -x inc_entire=, żeby utworzyć archiwum zawierające całą główną grupę woluminów (w tym przypadku vg00), obejmującą wszelkie katalogi i pliki wyszczególnione w pliku mnr_essentials (niekoniecznie zlokalizowane w głównej grupie). # make_net_recovery -x inc_entire=vg00 -s ibanez # make_tape_recovery -x inc_entire=vg00 # make_tape_recovery -x inc_entire=vg00 -s ibanez
Opcja -A poleceń make_tape_recovery i make_net_recovery dość znacząco różni się od opcji -A starszego polecenia make_recovery. Obecnie opcja -A powoduje, że jeśli dowolny dodatkowo dołączony plik lub katalog znajduje się poza obrębem głównej grupy woluminów, grupy dysków lub dysku, w archiwum zostanie uwzględniona cała grupa woluminów, grupa dysków lub dysk.
Weryfikowanie zawartości archiwum Zanim zaufa się archiwom służącym do przywrócenia systemu w środowisku produkcyjnym, należy je przetestować. Jeśli nie będzie można odtworzyć zawartości takiego archiwum, lepiej stwierdzić to przed wystąpieniem awarii komputera produkcyjnego. Jedyną pewną metodą Przykład wdrożen a
|
381
weryfikacji archiwum jest przeprowadzenie operacji przywracania całej jego zawartości na komputerze, na którym oryginalnie się znajdowało. Oto kilka sposobów testowania przez serwer Ignite-UX: Zastosowanie trybu podglądu w celu stwierdzenia, czy powiedzie się archiwizacja obecnie działającego systemu. Aby skorzystać z podglądu przetwarzania, które nie powoduje utworzenia faktycznego archiwum, w poleceniu make_net_recovery lub make_tape_recovery należy użyć opcji -p. Poniższe przykładowe polecenie wykonano po stronie klienta, uaktywniając na serwerze ibanez tryb podglądu procesu sporządzania archiwum. # make_net_recovery -s ibanez -p
Na serwerze Ignite-UX należy wyświetlić zawartość pliku flist, żeby zapoznać się z listą plików, które wchodziłyby w skład rzeczywistego archiwum. Jeśli kolejne sesje polecenia make_net_recovery z trybem podglądu uruchomi się przed faktycznym sporządzeniem archiwum, każdorazowo serwer Ignite-UX utworzy katalog nowego archiwum przywracanych danych. W nazwie każdego takiego katalogu będzie umieszczona data i godzina. Najnowszy katalog będzie miał swoje dowiązanie o nazwie latest. # view /var/opt/ignite/clients/hal/recovery/2006-06-22,12:01/flist
Po wywołaniu polecenia make_net_recovery w trybie podglądu jego kolejne wykonanie z opcją -r spowoduje utworzenie archiwum przy wykorzystaniu danych konfiguracyjnych zawartych w katalogu wskazywanym przez dowiązanie latest. Jeżeli polecenie make_tape_recovery uaktywni się w trybie podglądu, należy sprawdzić plik flist znajdujący się po stronie klienta w niżej podanej lokalizacji. Kolejne sesje polecenia make_tape_recovery w trybie podglądu, po których następuje identyczne polecenie z opcją -r, przebiegają podobnie jak w przypadku polecenia make_net_recovery. # view /var/opt/ignite/recovery/latest/flist
Przeglądanie listy katalogów i plików archiwum przywracanych danych. Plik flist jest generowany w trybie podglądu, gdy tworzy się rzeczywiste archiwum. Plik ten można otworzyć za pomocą edytora tekstowego. Stwierdzenie, czy można odczytać archiwa. Poniższe polecenia wczytują indeks narzędzia tar z określonego archiwum umieszczonego na dysku serwera Ignite-UX i zapisują go w konkretnym pliku wyjściowym. Choć format narzędzia tar jest domyślnym formatem archiwizacyjnym, można zastosować format programu cpio. Do odczytu obu formatów można też użyć polecenia pax. W poniższych przykładach użyto narzędzi tar i pax w celu uzyskania dostępu do jednego z dwóch archiwów utworzonych przy użyciu polecenia make_net_ ¦recovery i przechowywanych w katalogach o unikatowych nazwach, utworzonych na podstawie daty i godziny sporządzenia poszczególnych archiwów. # cd /var/opt/ignite/recovery/archives/hal # file 2006* 2006-01-24,19:51: gzip compressed 2006-01-31,17:06: gzip compressed # gunzip -c 2006-01-31,17:06 | tar -tvf - > /tmp/file.list # gunzip -c 2006-01-31,17:06 | pax -vf - > /tmp/file.list
Podobnie można postąpić w przypadku taśm zapisanych za pomocą polecenia make_tape_ recovery serwera HP9000. Poniższe przykładowe polecenia wczytują dane z taśmy umiesz-
czonej w określonym napędzie (warto zwrócić uwagę na zastosowanie pliku urządzenia bez przewijania), przeszukując ją za obszarem rozruchowym w celu uzyskania dostępu do archiwum. Narzędzie pax odczytuje z archiwum przywracanych danych indeks programu tar i zapisuje go w określonym pliku wyjściowym. 382
|
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
# mt -r /dev/rmt/0m rew # mt -t /dev/rmt/0mn fsf 1 # pax -vf /dev/rmt/0m > /tmp/file.list
Porównanie przy użyciu polecenia check_net_recovery lub check_tape_recovery zawartości istniejącego archiwum z zawartością komputera, na którym je utworzono. Jeśli archiwum umieszczono na zdalnym serwerze, po stronie klienta przeznaczonego do sprawdzenia należy wykonać poniższe polecenie, podając nazwę serwera Ignite-UX, który zawiera sieciowe archiwum umożliwiające przywrócenie danych. Wynik tego polecenia pozwala stwierdzić, czy jakiekolwiek pliki archiwum zostały dodane, usunięte lub zmodyfikowane od czasu jego sporządzenia. # check_net_recovery -s ibanez
Sprawdzenie, czy klient zostanie załadowany z poziomu serwera Ignite-UX przechowującego archiwum tego klienta utworzone za pomocą polecenia make_net_recovery (lub zapisane na taśmie przy użyciu polecenia make_tape_recovery). W celu uzyskania najnowszych informacji dotyczących operacji przywracania danych z taśmy w przypadku serwerów HP Integrity należy zajrzeć do dokumentacji dostępnej pod adresem http://docs.hp.com. Aby w pełni skorzystać z poleceń takich jak make_ipf_tape, które udostępniają nowe funkcje serwerów HP Integrity, należy zastosować aktualną wersję oprogramowania Ignite-UX. Począwszy od wersji C.6.8 narzędzie Ignite-UX obsługuje własne ładowalne taśmy UEFI 2.0 (aby to było możliwe, w przypadku większości serwerów HP Integrity wymagana jest aktualizacja oprogramowania sprzętowego). W przypadku serwerów HP Integrity należy sprawdzić, czy podłączony napęd taśmowy i kontroler HBA (Host Bus Adapter) obsługują funkcje bezpośredniego ładowania taśm zapisanych w formacie UEFI 2.0. Jeśli taśmy zostały sformatowane pod kątem ładowania na serwerach HP9000, w przypadku serwerów HP Integrity należy przeprowadzić proces ładowania wykorzystujący dwa nośniki. Najpierw dane są ładowane z dysku DVD (na przykład nośnik instalacyjny systemu operacyjnego), a następnie z taśmy mającej format LIF (Logical Interchange Format). Wszystkie taśmy służące do przywracania utworzone przed pojawieniem się wersji C.6.3 oprogramowania Ignite-UX mają format zgodny z serwerami HP9000. Z kolei taśmy sporządzone przy wykorzystaniu narzędzia Ignite-UX w wersjach od C.6.3 do C.6.7 nie są kompatybilne z formatem UEFI 2.0. W ich przypadku trzeba najpierw przeprowadzić rozruch z dysku DVD, a później z taśmy. Po sprawdzeniu, czy klient może być załadowany w celu przeprowadzenia procesu przywracania danych z archiwum, z poziomu konsoli klienta należy użyć interfejsu itool serwera Ignite-UX. W ten sposób można zapoznać się z konfiguracją, która zostanie zastosowana, gdy faktycznie zainicjuje się proces przywracania. itool () /------\/--------\/--------\/-------------\/--------\ | Basic|| Software||System||File System || Advanced | | \------------------------------------------------------------------\ | | | Configurations: [ HP-UX B.11.00 Default ->] [ Description... ] | | Environments: [ ->] (HP-UX B.11.00) | | | | [ Root Disk... ] SEAGATE_ST32151N, 8/16/5.5.0, 2048 MB | | | | File System: [ Logical Volume Manager (LVM) with VxFS ->] | | | | [ Root Swap (MB)... ] 1024 Physical Memory (RAM) = 2560 MB | | |
Przykład wdrożen a
| 383
| [ Languages... ] [ Keyboards... ][ Additional... ] | | | \-------------------------------------------------------------------------/ [ Show Summary... ] [Reset Configuration ] --------------------------------------------------------------------------[ Go! ] [ Cancel ] [ Help ]
Diagnozowanie operacji przywracania Ogólnie mówiąc, ze wstępną fazą diagnozowania są związane następujące pytania: • Czy określony serwer Ignite-UX z powodzeniem był wykorzystywany w ramach innych
operacji tworzenia archiwów i przywracania z nich danych? Jeśli tak, czym się różni obecnie wykonywana operacja? Jeśli nie, czy serwer Ignite-UX został poprawnie skonfigurowany?
• Czy klient i serwer Ignite-UX znajdują się w tej samej podsieci? Jeśli nie, czy skonfigurowano
pomocniczy serwer ładowania Ignite-UX?
• Czy konkretne archiwum przywracanych danych sporządzono na tym samym komputerze,
na którym obecnie przeprowadza się proces przywracania? Czy używane archiwum kiedykolwiek z powodzeniem udało się wykorzystać w procesie przywracania?
• Jakie dokładnie zaobserwowano komunikaty o błędach? Jakie szczegóły znaleziono w odpo-
iednich plikach dzienników?
Gdy zawiedzie proces przywracania, po stronie klienta w obrębie konsoli należy poszukać komunikatu objaśniającego specyfikę problemu razem z wierszem polecenia umożliwiającym zastosowanie powłoki debuggera. Oto przykład: ERROR:
The ifconfig(1M) command (ifconfig lan2 inet 15.43.233.125 netm ask 255.255.248.0 up) failed to enable the lan2 interface (return value: 1). Check that the system's networking hardware is functioning and properly connected.
ERROR:
Could not start networking. The configuration process has incurred an error, would you like to push a shell for debugging purposes? (y/[n]): y * Type "exit" to reboot, "exit 2" to ignore error To continue the recovery after working from the debug shell, enter exit 2.
W następnym przykładzie po zainicjowaniu operacji przywracania zawartości archiwum sieciowy serwer Ignite-UX w ustalonych odstępach czasu monitorował plik install.log klienta i ostatecznie wygenerował następujące ostrzeżenie: WARNING:
Client hal appears to be hung. Since the server started checking, the client's logfile has not been updated in 20 minutes. The timeout in effect is 20 minutes.
Po ujrzeniu ostrzeżenia należy przejrzeć plik install.log klienta, aby zidentyfikować ten moment procesu przywracania, w którym mogło dojść do awarii. W przytoczonym przykładzie nazwa klienta to hal, a lokalizację pliku dziennika instalacji klienta zapisanego na serwerze Ignite-UX identyfikuje ścieżka /var/opt/ignite/clients/hal/install.log. Z kolei po stronie klienta, korzystając z powłoki debuggera, można wyświetlić zawartość pliku /var/opt/ignite/local/install.log. Oto ona: * Loading_software: Begin * Installing boot area on disk. * Enabling swap areas. * Backing up LVM configuration for "vg00". * Processing the archive source (Recovery Archive). * Fri Sep 20 15:08:07 EDT 2002: Starting archive load of the source (Recovery Archive).
384 |
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
ERROR:
Cannot load OS archive (Recovery Archive) The configuration process has incurred an error, would you like to push a shell for debugging purposes? ([y/n]): *
Powyższy błąd może mieć kilka przyczyn; między innymi może to być awaria fizycznego połączenia sieciowego lub jego niepoprawne funkcjonowanie. W przypadku kiepskiej wydajności należy stwierdzić, czy między serwerem i klientem Ignite-UX znajduje się przełącznik sieciowy. Gdy w czasie ładowania jądra z serwera Ignite-UX interfejsowi sieciowemu klienta nie uda się w ramach procesu automatycznej negocjacji ustalić z przełącznikiem szybkości i ustawień związanych z dupleksowaniem, domyślnie zostanie użyta szybkość 100 Mb/s i półdupleks, niezależnie od konfiguracji przełącznika. Spowoduje to wyjątkowo wolną instalację z wykorzystaniem archiwum przywracanych danych. Jeśli automatyczna negocjacja nie jest stosowana przez przełącznik biorący udział w procesie przywracania i nie zostaną uzgodnione szybkość transferu sieciowego i ustawienia dupleksowania, domyślna konfiguracja używana przez serwer Ignite-UX może być zmodyfikowana w instalacyjnym systemie plików (INSTALLFS) znajdującym się na serwerze Ignite-UX lub pomocniczym serwerze ładowania. Z serwerami tymi łączy się klient w celu przeprowadzenia zdalnego ładowania. Za pomocą polecenia instl_adm w obrębie systemu plików INSTALLFS serwera Ignite-UX jest modyfikowany parametr _hp_lanadmin_args. Składnię pliku konfiguracyjnego serwera Ignite-UX omówiono w dokumencie instl_adm(4). Najpierw przez wykonanie poniższego polecenia należy wczytać bieżącą konfigurację serwera Ignite-UX do pliku tymczasowego. # instl_adm -d >/tmp/installfs.cfg
W dalszej kolejności, postępując zgodnie z opisem zawartym w dokumencie instl_adm(4), w pliku /tmp/installfs.cfg dla parametru set_hp_lanadmin_args należy ustawić wartość -X 100FD. Na końcu w systemie plików INSTALLFS należy zapisać nową konfigurację serwera Ignite-UX. # instl_adm -f /tmp/installfs.cfg
Powielanie systemów W przypadku powielania (klonowania) zawartość archiwum umożliwiającego przywrócenie systemu jest wyodrębniana na komputerze innym niż ten, na którym archiwum sporządzono. Jest to normą w wielu scenariuszach związanych z przywracaniem. Powielanie zyskuje też na popularności wśród administratorów systemu, którzy szukają uproszczonych metod zarządzania komputerami z podobnymi konfiguracjami. Gdy dla komputera jest tworzone archiwum, wiele aspektów konfiguracji tego hosta może być podobnych w przypadku innych komputerów. Przykładowo komputery mogą znajdować się w tej samej podsieci i korzystać z identycznych tabel routingu. Być może komputery są wyposażone w takie same karty sieciowe bądź kontrolery SCSI lub Fibre Channel. Być może komputery bazują nawet na identycznym modelu macierzy dyskowych lub bibliotek taśmowych, co oznacza, że używają tych samych wersji oprogramowania sprzętowego. Jednak pomimo tego nadal mogą wystąpić niezgodności, gdy do powielania systemów zastosuje się archiwa przywracanych danych. Proces przywracania może się nie powieść, jeśli konfiguracja systemowa zapisana w archiwum będzie zbyt różnić się od konfiguracji nowego docelowego komputera. Gdy podejmie się próbę odtworzenia archiwum na komputerze z odmiennym sprzętem, narzędzie przywracające powinno wykryć brak zgodności urządzeń. Zwykle można to stwierdzić Pow elan e systemów
| 385
w oknie konsoli podczas trwania procesu przywracania. Jeżeli proces powielania zostanie ukończony, może być konieczna zmiana ustawień systemowych takich jak adresy IP i nazwy hostów. Choć można to zrobić po przeprowadzeniu wdrożenia, te konkretne parametry mogą zostać zmienione przed wyodrębnieniem archiwum. Umożliwia to interfejs itool serwera IgniteUX uaktywniany z poziomu konsoli klienta. Rozważmy przykład, w którym komputer będący celem procesu przywracania danych z archiwum ma główną grupę woluminów z dyskami lub jednostkami LUN o różnej pojemności lub z liczbą dysków inną niż w przypadku komputera, na którym sporządzono archiwum. Oprogramowanie Ignite-UX wykrywa, że klient dysponuje odmienną konfiguracją sprzętową, dlatego też wywołuje interfejs użytkownika itool, za pomocą którego administrator systemu może zmodyfikować wartości parametrów związanych z dyskami, woluminami i systemami plików. Jeśli administrator nie skonfiguruje ręcznie tych ustawień, w czasie instalacji oprogramowanie Ignite-UX spróbuje zmodyfikować rozmiar logicznych woluminów i systemów plików, aby zapewnić, że będzie dostępne wolne miejsce o domyślnej pojemności wynoszącej 10%. Jeżeli okaże się, że będzie za mało wolnej przestrzeni, żeby oprogramowanie Ignite-UX mogło działać, zostanie wygenerowany błąd.
Bezpieczeństwo Ważne jest zrozumienie implikacji związanych z bezpieczeństwem, wynikających z zastosowania narzędzi przywracających systemu HP-UX. Gdy użyje się serwera Ignite-UX, mogą być wymagane określone usługi, takie jak NFS, TFTP i BOOTP, a także opcjonalne polecenia (na przykład bootsys). Przed skorzystaniem z narzędzi przywracających należy sprawdzić zasady bezpieczeństwa organizacji i przeanalizować czynniki ryzyka związane z uruchamianiem wymienionych protokołów i poleceń. Należy również zapoznać się ze środowiskiem sieciowym. Czy istnieją w nim firewalle i jakie narzucą ograniczenia? Można wyłączyć część nieużywanych usług i poleceń. Przykładowo polecenie bootsys inicjujące na serwerze Ignite-UX proces zdalnego ładowania klienta może być zablokowane dla konkretnych serwerów (należy zapoznać się z dokumentacją narzędzia bootsys). Jeśli organizacja określiła zasadę bezpieczeństwa, zgodnie z którą usługa NFS nie może być stosowana na żadnym serwerze, należy rozważyć użycie dla każdego lokalnego klienta polecenia make_tape_recovery zamiast polecenia make_net_recovery (lub wyłączenie usługi NFS po utworzeniu archiwum za pomocą narzędzia make_net_recovery). Trzeba pamiętać, że w czasie procesu przywracania systemu zwykle są tworzone dwa punkty podłączenia NFS: pierwszy dla katalogu serwera Ignite-UX zawierającego dane konfiguracyjne klienta, a drugi dla archiwum z zawartością klienta. Ponadto należy mieć świadomość tego, że serwer Ignite-UX niekoniecznie jest tym samym komputerem co serwer archiwizujący. Gdy są to dwa różne komputery, powinno się zmodyfikować plik /etc/exports, aby udzielić dostępu wyłącznie do archiwizowanego klienta lub klientów. Serwer Ignite-UX można tak skonfigurować, żeby nie udzielał dostępu anonimowym klientom. Można to osiągnąć na przykład przez przydzielenie na czas instalacji i ładowania tymczasowych adresów IP tylko wybranym interfejsom sieciowym identyfikowanym za pomocą sprzętowych adresów MAC warstwy łącza. Weźmy pod uwagę kwestię planowania i wdrażania procedury przywracania po wystąpieniu nieszczęśliwego zdarzenia. Pojedynczy komputer może jednocześnie pełnić rolę zarówno klienta, jak i serwera Ignite-UX. Jeśli jednak serwer się zepsuje, skąd będą przywracane dane? 386 |
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
Jeżeli z zarządzanym środowiskiem stanie się coś złego, w jaki sposób i skąd uzyska się dane, aby je odtworzyć? Nawet wtedy, gdy w sieci są dwa lub więcej serwerów Ignite-UX położonych w zdalnych względem siebie lokalizacjach, trzeba zadbać o plan przywracania dla każdego z tych serwerów. Równie istotne jest zapewnienie spójności i bezpieczeństwa samych archiwów przywracanych danych. Po utworzeniu archiwum zawartość całego komputera znajduje się w pliku lub na taśmie. Jest to niemal wszystko, czego potrzebuje intruz, aby włamać się do komputera lub całej sieci. Przykładowo istnieje kilka programów łamiących hasła, które mogą posłużyć do odgadnięcia haseł zapisanych na komputerze w pliku /etc/passwd. Inne krytyczne informacje, takie jak tabele routingu, też mogą zostać uzyskane z archiwum. Czy serwery i biblioteki taśmowe są fizycznie zabezpieczone? Czy taśmy są przechowywane w zdalnej lokalizacji i czy jest ona bezpieczna? Czy w przypadku serwera Ignite-UX są stosowane właściwe praktyki dotyczące bezpieczeństwa systemów uniksowych? W czasie gdy ta książka była pisana, archiwa przywracające systemy nie były szyfrowane. Oznacza to, że zasadniczą rolę odgrywa fizyczne zabezpieczenie takich archiwów, niezależnie od tego, czy umieszczono je na lokalnej taśmie czy na sieciowym serwerze.
Przywracanie danych komputera i powielanie dysków Archiwum tworzone za pomocą narzędzi przywracających dane komputera wymaga, aby w celu utrzymania konfiguracji powielanych dysków wykonać dodatkowe kroki. Programowe powielanie dysków jest stosowane przez menedżery woluminów w celu zapewnienia nadmiarowości zasobów, takich jak dyski i systemy plików. Dane z jednego dysku są mapowane na drugim, o identycznej pojemności (w przypadku menedżera LVM odbywa się to na poziomie logicznych woluminów). Jeśli jeden z dysków przestanie działać, system nadal będzie funkcjonować, korzystając z mechanizmu przełączania po awarii na aktywny dysk. Gdy odtwarza się dane z archiwum, narzędzia przywracające nie zachowają konfiguracji powielania na poziomie programowym. W środowisku z oprogramowaniem Ignite-UX administratorzy systemu zwykle dysponują skryptami, które ponownie konfigurują powielanie programowe po przywróceniu systemu z archiwum. Narzędzie Ignite-UX posługuje się własnym językiem konfiguracyjnym, umożliwiając automatyczne wywoływanie niestandardowych skryptów na etapie czynności konfiguracyjnych. Skrypty te nie będą istnieć, dopóki administrator systemu ich nie utworzy i nie zintegruje następnie z konfiguracją związaną z przywracaniem systemu. Dokument dostępny w katalogu /opt/ignite/share/docs/diskmirror.pdf jest instalowany razem z serwerem Ignite-UX. Zamieszczono w nim instrukcje dotyczące modyfikowania plików konfiguracyjnych w celu odtworzenia powielonych dysków. Narzędzia omówione w rozdziale mogą okazać się bezcenne, ponieważ zagwarantują możliwość przywrócenia komputerów z systemem HP-UX, gdy zepsują się dyski z systemami operacyjnymi. Mamy nadzieję, że zamieszczone informacje okażą się pomocne. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Przywracan e danych komputera pow elan e dysków
|
387
388 |
Rozdz ał 12. Przywracan e od podstaw komputera z systemem HP-UX
ROZDZIAŁ 13.
Przywracanie od podstaw komputera z systemem AIX
W tym rozdziale objaśniono procedury, których użyje się do przywrócenia zawartości dysku z systemem operacyjnym IBM AIX, gdy komputer będzie miał awarię (mowa o sytuacji, w której pozostanie jedynie przywrócić go od podstaw). W pracach nad niniejszym rozdziałem brał udział Mark Perino z firmy Hitachi Data Systems. Gdy nie jest zaabsorbowany pisaniem bądź wędrowaniem latem lub zimą po parku Yosemite ze swoją żoną Marissą, a także dziećmi o imionach Steven i River, zajmuje się problemami dotyczącymi wydajności, systemów AIX i Linux oraz technologii NAS.
Firma IBM jako pierwszy producent systemów uniksowych dostarczyła prawdziwe narzędzie przywracające komputer od podstaw — mksysb. Program ten sporządza kompletną „ładowalną” kopię zapasową wyłącznie głównej grupy woluminów (rootvg). Dzięki temu można przeprowadzić proces przywracania od podstaw komputera z systemem operacyjnym AIX. Za pomocą narzędzia mksysb można nawet archiwizować dane na ładowalnej taśmie, dysku CD/DVD lub serwerze NIM (Network Install Manager). W książce Unix Backup & Recovery wspomniano o zastosowaniu programu Sysback do tworzenia kopii zapasowej grup woluminów. Narzędzie to dołączono do niektórych komercyjnych produktów firmy IBM i innych producentów tworzących oprogramowanie dla systemów AIX 5.x. Ponieważ w książce skupiono się na omówieniu darmowych metod archiwizowania i odtwarzania danych, zrezygnowano z prezentowania programu Sysback.
Narzędzia mksysb i savevg firmy IBM mksysb jest podstawowym narzędziem służącym do przywracania od podstaw komputera z systemem AIX. Program dodano do tego systemu. Narzędzie archiwizuje wszystkie pliki głównej grupy woluminów rootvg. Oto one: • pliki rozruchowe, • podstawowe pliki systemu operacyjnego,
389
• pliki systemowe i konfiguracyjne, • dodatkowe oprogramowanie zainstalowane w grupie rootvg.
Ponadto są archiwizowane następujące dane: • informacje na temat grupy woluminów rootvg, • informacje dotyczące logicznych woluminów, • informacje na temat obszaru stronicowania.
W celu zaoszczędzenia miejsca narzędzie mksysb nie umieszcza w kopii zapasowej obszaru stronicowania, który odbudowuje w czasie procesu odtwarzania. Program mksysb przede wszystkim jest wykorzystywany do przywracania komputera od podstaw. Narzędzie to ma też swoje ograniczenia, które mogą spowodować, że nie będzie jedynym używanym oprogramowaniem archiwizującym. Oto kilka z tych ograniczeń: • brak możliwości archiwizowania systemów plików znajdujących się poza obrębem grupy
rootvg (należy zapoznać się z narzędziem savevg), • brak możliwości uwzględnienia w kopii zapasowej niesformatowanych logicznych urządzeń, • ograniczona zdolność zachowywania układu logicznych woluminów (systemy AIX 4.x), • restrykcje dotyczące odtwarzania w przypadku różnych architektur RS/6000 (należy zajrzeć
do zamieszczonego dalej podrozdziału „Powielanie systemów”), • brak możliwości monitorowania kopii zapasowych lub sporządzania kopii przyrostowych, • brak kontrolek obsługujących automaty taśmowe, • możliwość archiwizowania na zdalnie podłączonym napędzie taśmowym, lecz bez opcji
ładowania z niego. Przed pojawieniem się systemu AIX 5.x między poszczególnymi wersjami programu mksysb występowały znaczne różnice. W przypadku wersji 5.x systemu AIX narzędzie mksysb jest bardziej stabilne. Wszystkie te wersje systemu AIX są w stanie zachowywać charakterystyki logicznych woluminów i rozmiar obszaru stronicowania. Program mksysb nie archiwizuje niesformatowanych logicznych woluminów. Nie potrafi tworzyć kopii zapasowej niczego innego oprócz głównej grupy woluminów. Narzędzie mksysb może okazać się dobrym rozwiązaniem, gdy na wypadek awarii dysku od czasu do czasu trzeba na taśmie zapisać kopie zapasowe. Program ten może też być znakomitym uzupełnieniem dla innych narzędzi archiwizujących, które obsługują dane aplikacji i użytkowników, a także zapewniają funkcje nieobecne w programie mksysb, takie jak przyrostowe kopie zapasowe i zdalne odtwarzanie danych. mksysb nie sprawdzi się w przypadku środowisk, w których używa się niesformatowanych logicznych woluminów, dane przechowuje poza grupą rootvg lub wymaga sporządzania przyrostowych kopii, elastycznego odtwarzania i archiwizowania za pośrednictwem sieci. Przed i po zastosowaniu aktualizacji obsługi technicznej firmy IBM zawsze powinno się tworzyć kopie zapasowe. Takie aktualizacje z poprawkami dla systemów plików JFS i JFS2 mogą nie być zgodne wstecz. W związku z tym nie dysponując aktualnymi i starszymi kopiami zapasowymi, ryzykuje się, że nie będzie możliwe podłączenie systemów plików.
390
|
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
Wersje 4.3.3 i 5.x systemu AIX oferują narzędzie savevg, które w rzeczywistości jest dowiązaniem do polecenia mksysb. Gdy program mksysb uruchomi się w ten sposób, można zarchiwizować dowolną grupę woluminów komputera. Jednak w dalszym ciągu obowiązują inne ograniczenia narzędzia mksysb. Oto inne wymagania programu savevg: • woluminy zarchiwizowane za pomocą programu savevg muszą być modyfikowane i mieć
podłączone własne systemy plików, • narzędzie savevg nie potrafi archiwizować zdalnie podłączonych systemów plików NFS
i CIFS, • systemy plików muszą być typu JFS lub JFS2.
Narzędzia mksysb i savevg mogą tworzyć kopie zapasowe następujących nośników: • taśma (w przypadku grupy rootvg jest możliwość ładowania z niej), • dysk CD/DVD (w przypadku grupy rootvg jest możliwość ładowania z niego), • plik obrazu zlokalizowany w punkcie podłączenia NFS.
Programy mksysb i savevg umożliwiają odtworzenie danych z następujących nośników: • taśma (w przypadku grupy rootvg jest możliwość ładowania z niej), • dysk CD/DVD (w przypadku grupy rootvg jest możliwość ładowania z niego), • wewnętrzny dysk (niezalecany w przypadku grupy rootvg), • punkt podłączenia NFS (możliwość ładowania, gdy zastosuje się menedżer NIM).
Format programów mksysb i savevg Narzędzie mksysb umieszcza kilka plików na taśmie, dysku CD/DVD lub w pliku obrazu. Kilka pierwszych plików odpowiada za załadowanie jądra i zapewnienie układu menedżera LVM dla zarchiwizowanych danych. W ostatnich plikach znajdują się dane do odtworzenia mające format programu backup zgodny z wersjami 4.3.3 i 5.x systemu AIX (format ten w zasadzie jest taki sam jak format narzędzia dump). Zasadniczo kopie zapasowe narzędzia savevg różnią się od kopii programu mksysb tylko tym, że są pozbawione informacji dotyczących ładowalnego jądra. Rysunek 13.1 przedstawia logiczną reprezentację takiej taśmy.
Rysunek 13.1. Logiczna reprezentacja taśmy zapisanej za pomocą programu mksysb
Rozmiar bloku zapisanego na taśmie dla pierwszych trzech plików wynosi 512 bajtów. W przypadku danych obrazu wielkość bloku zmienia się zależnie od ustawień napędu taśmowego obowiązujących podczas archiwizowania. Jeśli dla tego urządzenia ustawi się rozmiar bloku równy 0, w miarę możliwości systemy będą archiwizować, używając 1024 bajtów. Gdy dane archiwizuje się na dysku CD/DVD lub w pliku obrazu, nie ma potrzeby określania rozmiaru bloku. Narzędz a mksysb savevg f rmy BM
|
391
Przygotowanie do zastosowania programów mksysb i savevg Można wyróżnić następujące trzy podstawowe rodzaje operacji wykonywanych przez narzędzie mksysb: • archiwizowanie danych na napędzie taśmowym i odtwarzanie ich, • tworzenie ładowalnego dysku CD/DVD, • archiwizowanie danych w punkcie podłączenia NFS i odtwarzanie ich za pośrednictwem
serwera NIM.
Pierwsze dwie operacje wymagają fizycznego nośnika. Zarówno na taśmie, jak i na dysku CD/DVD jest umieszczany ładowalny obraz umożliwiający przywracanie. Archiwizowanie w punkcie podłączenia NFS jest ograniczone przez szybkość sieci IP w czasie przeprowadzania operacji. Szybkość odtwarzania w przypadku serwera NIM też jest zależna od przepustowości sieci. Choć archiwizowanie danych w udziale NFS i odtwarzanie ich za pośrednictwem serwera NIM wiąże się z większą ilością przygotowań, za pomocą skryptów można zautomatyzować sporządzanie okresowych kopii zapasowych grupy rootvg, eliminując potrzebę ładowania nośnika przez operatora. Innym wariantem obsługiwanym przez niektórych za pomocą skryptów jest zapisywanie kopii zapasowych na lokalnym dysku, niebędącym członkiem grupy rootvg, a następnie przenoszenie ich na zdalny host przy wykorzystaniu protokołu FTP/SCP/RCP. Większość użytkowników powinna tego unikać, ponieważ w strategii archiwizacji może pojawić się słaby punkt. Co się stanie, gdy zawiedzie skrypt kopiujący, a potrzebna kopia zapasowa, choć poprawna, będzie zlokalizowana na uszkodzonym komputerze? Proste odtwarzanie właśnie znacznie się skomplikowało. Jeśli zastosowanie usługi NFS nie wchodzi w grę, a trzeba użyć innej metody transferu, konieczne będzie napisanie niezawodnych skryptów weryfikujących, wykonywanych zarówno po stronie klienta, jak i docelowego serwera. Niezależnie od tego, jak się postąpi, nigdy nie wolno umieszczać kopii zapasowych narzędzia mksysb w grupie rootvg. Jeżeli Czytelnik będzie miał do czynienia z taką sytuacją, może odtworzyć dane z dysku CDROM lub przy użyciu starszej wersji narzędzia mksysb, zastosować aktualizacje obsługi technicznej w celu uzyskania poziomu z chwili wystąpienia awarii komputera, podłączyć system plików z kopiami zapasowymi i za pomocą wybranej wersji programu mksysb wykonać ponowną operację odtwarzania. Po wybraniu lokalizacji kopii zapasowych trzeba zdecydować, czy w celu zarchiwizowania głównej grupy woluminów zablokować użytkownikom dostęp do systemu. Czy na czas trwania archiwizacji wyloguje się wszystkich użytkowników i (lub) zamknie aplikacje? Odpowiedź na to pytanie jest uzależniona od konfiguracji systemu. Archiwizacja prawdopodobnie potrwa co najmniej godzinę. Ponadto wszelkie modyfikacje plików podczas archiwizacji mogą spowodować zapisanie na taśmie niespójnego obrazu. Choć nie powinno być żadnych problemów z archiwizowaniem otwartych plików, wszelkie operacje zapisu pliku wykonywane w chwili jego archiwizowania oczywiście sprawią, że plik nie znajdzie się w archiwum umieszczonym na taśmie. Jeśli większość lub wszystkie dane użytkowników znajdują się poza grupą rootvg i pliki systemowe nie są nieustannie modyfikowane, nie powinno być problemu z tworzeniem za pomocą narzędzia mksysb kopii zapasowych aktywnego systemu. Jeżeli do przywrócenia innych komputerów użyje się obrazu narzędzia mksysb, można zdecydować się na dodatkowe przygotowanie grupy rootvg. Przykładowo można wykonać następujące czynności: 392
|
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
• wyczyszczenie zawartości katalogu /tmp; • wyłączenie dostępu do sieci (przez umieszczenie w plikach: inittab, rc.net, rc.tcpip i rc.nfs
znaku komentarza w wierszach, które mogłyby spowodować zawieszenie się komputera w przypadku braku połączenia z siecią lub po wystąpieniu konfliktu adresów IP);
• usunięcie hasła superużytkownika lub ustawienie dla niego hasła ogólnie znanego w zarzą-
dzanym środowisku; • wyczyszczenie za pomocą programu errclear zawartości raportu dotyczącego błędów, a także
plików: /var/spool, /var/adm, /var/logs i innych. W dalszej kolejności należy zdecydować, co trzeba zarchiwizować. Tworząc plik /etc/exclude.rootvg i używając opcji -e narzędzia mksysb (lub savevg), można zapobiec uwzględnianiu w archiwum wybranych plików. Wpisy znajdujące się w tym pliku mogą mieć postać prostych list plików. Oto przykład: /etc/passwd
Jeśli zastosuje się opcję -e, za pośrednictwem narzędzia egrep program mksysb przefiltruje pliki wymienione w pliku /etc/exclude.rootvg. Oznacza to, że można korzystać ze składni programu egrep i tworzyć złożone wpisy podobne do poniższych. .*/core$ ^/tmp/ .*\.o$
Przygotowywanie do procesu odtwarzania Plik /image.data, znajdujący się w obrębie archiwizowanego systemu plików, przechowuje informacje na temat sposobów przywracania z kopii zapasowej dysków, systemów plików, logicznych woluminów i obszaru stronicowania. Ogólnie rzecz biorąc, wpisy pliku image.data korelują z opcjami poleceń mklv i crfs (używane do tworzenia logicznych woluminów i systemów plików). Wykonanie polecenia mkszfile przed poleceniem mksysb spowoduje utworzenie pliku image.data. Można również uaktywnić polecenie mksysb z opcją -i, która nakazuje programowi mkszfile automatyczne wygenerowanie pliku image.data. Przez niezależne wywołanie polecenia mkszfile można zmodyfikować plik image.data i zdecydować, co ma być zarchiwizowane, a także zmienić rozmiar systemów plików i inne zmienne. W celu określenia tego, co ma zostać uruchomione po odtworzeniu zawartości obrazu, edycji można poddać plik bosinst.data. Jeśli wykona się polecenie mkszfile i zmodyfikuje plik image.data, trzeba pamiętać o wywołaniu polecenia mksysb bez opcji -i, w przeciwnym razie wprowadzone zmiany zostaną nadpisane. Zmienną RECOVER_DEVICES zawartą w pliku bosinst.data warto poddać edycji. Zmienna decyduje o tym, czy odtworzyć, czy nie definicje ODM istniejące w momencie tworzenia kopii zapasowej. Domyślna wartość zmiennej (YES) jest właściwa, gdy dane planuje się przywrócić na komputerze dysponującym identycznym lub podobnym sprzętem. Jeżeli sporządza się kopię zapasową w celu uzyskania podstawowego obrazu systemu, należy ustawić wartość NO. Jeśli w poleceniu mkszfile użyje się opcji -m, dla każdego logicznego woluminu uwzględnionego w archiwum zostanie utworzony plik mapowania. Każdy taki plik określa, gdzie na dysku w czasie odtwarzania powinien zostać utworzony logiczny wolumin. Podobne efekty dają opcje polecenia mklv (umożliwia odtworzenie dokładnego układu woluminów). Plik mapowania powiązany z konkretnym logicznym woluminem zawiera jeden wiersz dla każdej fizycznej partycji, która jest zajmowana. Dodatkowo w wierszach jest zidentyfikowany dysk
Narzędz a mksysb savevg f rmy BM
|
393
twardy (hdisk), na którym znajdują się partycje. Warto zauważyć, że plik mapowania przydaje się tylko wtedy, gdy docelowy komputer dysponuje dokładnie takim samym układem dysków co źródłowy host. Poniżej przedstawiono przykładowe wpisy pliku image.data. W dokumentacji systemu AIX można znaleźć bardziej szczegółowy opis wszystkich opcji wyszczególnionych w pliku. [SHRINK = yes]
Podczas procesu odtwarzania zmniejsza rozmiar systemów plików. [VG_SOURCE_DISK_LIST = hdisk0]
Zmienia docelowy dysk, na którym zostaną odtworzone dane. Po ukończeniu archiwizacji nie można edytować plików image.data i bosinst.data umieszczonych na taśmie lub dysku CD/DVD. Jednak można utworzyć niestandardową dyskietkę z plikiem image.data i (lub) plikiem bosinst.data. W czasie odtwarzania można użyć tej dyskietki zamiast plików zawartych w kopii zapasowej. Aby przygotować taką dyskietkę, należy wykonać niżej omówioną prostą procedurę. Po zmodyfikowaniu plików image.data i bosinst.data (lub jednego z nich) wyodrębnionych z taśmy lub innego nośnika (należy skorzystać z instrukcji umożliwiających pobranie pojedynczego pliku z kopii zapasowej zapisanej na taśmie za pomocą narzędzia mksysb) w napędzie należy umieścić dyskietkę i wykonać następujące polecenie: # ls ./bosinst.data ./image.data | backup -ivqf /dev/rfd0
Archiwizowanie przy użyciu narzędzia mksysb Narzędzie mksysb oferuje kilka opcji, które omówiono w niniejszym podrozdziale. Pierwszą możliwością jest archiwizacja i odtwarzanie danych przy wykorzystaniu lokalnie podłączonego napędu taśmowego. Kopie zapasowe można również zapisać na zdalnym napędzie taśmowym, lecz dane trzeba będzie przywracać z lokalnie podłączonego tego typu urządzenia. Przy użyciu programu mksysb kopię zapasową systemu można zapisać na dysku takim jak centralnie zlokalizowany system plików NFS. Jeśli tak się postąpi, do wyboru będą dwa warianty przywracania. Pierwszy polega na utworzeniu za pomocą narzędzia mkcd ładowalnych dysków CD/DVD, a następnie wykonaniu z nich rozruchu podczas procesu przywracania. Drugi wariant sprowadza się do wykonania operacji ładowania z poziomu serwera NIM i odtworzenia danych bezpośrednio z obrazu podłączonego przy użyciu usługi NFS. Można także utworzyć dyski CD/DVD, korzystając bezpośrednio z programu mkcd. Przyjrzyjmy się tym metodom.
Podsumowanie dotyczące narzędzia mksysb Oto krótkie podsumowanie opcji narzędzia mksysb, które zostaną użyte w tym podrozdziale: • -e. Wyklucza podczas archiwizowania pliki wymienione w pliku /etc/exclude.rootvg. Reguły
wykluczania są zgodne z zasadami dopasowywania wzorca stosowanymi przez polecenie grep.
• -i. Opcja wywołuje polecenie mkszfile, które generuje plik /image.data. W pliku tym znajdują
się informacje dotyczące grup woluminów, logicznych woluminów, systemów plików, obszaru stronicowania i fizycznych woluminów. Informacje te są uwzględniane w kopii zapasowej w celu wykorzystania ich w przyszłości przez proces instalacji.
394 |
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
• -m. Uruchamia polecenie mkszfile z opcją -m, aby utworzyć pliki mapowania (użycie tej opcji
powoduje uaktywnienie również funkcji opcji -i).
Archiwizowanie grupy rootvg na lokalnie podłączonym napędzie taśmowym W najprostszym scenariuszu wszystkie systemy plików grupy rootvg są archiwizowane na lokalnie podłączonym napędzie taśmowym. W tym przypadku z poziomu konsoli superużytkownika należy wykonać następujące polecenie: # mksysb -i /dev/rmt0
Odmienność różnych metod jest związana z dostępem do urządzenia taśmowego komputerów z systemem AIX. Zilustrowano to w tabeli 13.1 i dokładnie objaśniono w dokumentacji. Tabela 13.1. Konwencje nazewnicze urządzeń systemu AIX Nazwa urządzen a
Gęstość
Przew jan e po ukończen u procesu
Retencja przy rozpoczęc u procesu
/dev/rmt∗
Ustawienie #1
Tak
Nie
/dev/rmt∗ 1
Ustawienie #1
Nie
Nie
/dev/rmt∗ 2
Ustawienie #1
Tak
Tak
/dev/rmt∗ 3
Ustawienie #1
Nie
Tak
/dev/rmt∗ 4
Ustawienie #2
Tak
Nie
/dev/rmt∗ 5
Ustawienie #2
Nie
Nie
/dev/rmt∗ 6
Ustawienie #2
Tak
Tak
/dev/rmt∗ 7
Ustawienie #2
Nie
Tak
Zamiast tego polecenia oczywiście można skorzystać z menu narzędzia smit (System Management Interface Tool). Wykonując poniższe polecenie, można szybko przejść do odpowiedniego ekranu. # smit mksysb
Powinno być możliwe zastosowanie dowolnego lokalnie podłączonego napędu taśmowego obsługiwanego przez system AIX.
Archiwizowanie grupy rootvg na zdalnym napędzie taśmowym Korzystając z poniższej procedury, za pomocą narzędzia mksysb kopię zapasową można umieścić bezpośrednio na zdalnym napędzie taśmowym. Na potrzeby przytoczonego przykładu rozważmy następujące komputery: serwer_napedu_tasmowego Komputer z lokalnie podłączonym napędem taśmowym. klient Komputer przeznaczony do archiwizacji.
Arch w zowan e przy użyc u narzędz a mksysb
|
395
Najpierw trzeba sprawdzić, czy dla obu komputerów poprawnie skonfigurowano plik /.rhosts lub /etc/hosts.equiv w celu umożliwienia nawiązania za pomocą programu rsh połączenia między klientem i serwerem napędu taśmowego. Po stronie serwera należy wykonać poniższą procedurę, żeby ręcznie utworzyć obraz narzędzia mksysb.
1. Ustawienie w sekcji ładowania domyślnego rozmiaru bloku na taśmie równego 512 bajtów. serwer_napedu_tasmowego# chdev -a block_size=512 urządzenie
2. Przewinięcie taśmy. serwer_napedu_tasmowego# mt -f urządzenie rewind
3. Utworzenie plików ładowalnego obrazu. serwer_napedu_tasmowego# bosboot -d urządzenie_bez_przewijania -a
4. Zapisanie na taśmie ładowalnego obrazu. serwer_napedu_tasmowego# mkinsttape urządzenie_bez_przewijania
5. Zapisanie fikcyjnej tabeli zawartości. serwer_napedu_tasmowego# echo "Fikcyjna tabela zawartości taśmy" | dd of=urządzenie_bez_przewijania bs=512 conv=sync
6. Zmiana dla reszty taśmy rozmiaru bloku na 1024 bajty. serwer_napedu_tasmowego# chdev -a block_size=1024 urządzenie
Gdy już dysponujemy częścią ładowalną taśmy (mowa o bloku rozruchowym), plikami instalacyjnymi i fikcyjną tabelą zawartości, trzeba dokonać transferu danych. Po stronie klienta należy wykonać polecenie mkszfile i utworzyć plik /etc/exclude.vg zawierający jedynie wpis dla pliku /tmp/mksysb.pipe. W dalszej kolejności należy dla narzędzia mksysb zdefiniować nazwany potok. Na końcu za pomocą programu cat należy zawartość potoku umieścić na napędzie taśmowym serwera.
1. Utworzenie potoku dla narzędzia mksysb. klient# mknod p /tmp/mksysb.pipe
2. Umieszczenie na zdalnym napędzie taśmowym zawartości potoku. klient# cat /tmp/mksysb.pipe \ | rsh serwer_napędu_taśmowego "dd of=urządzenie obs=100b bs=1024 > /dev/null 2>&1" &
3. Wykonanie polecenia mksysb z opcją -e dla wcześniej utworzonego potoku. klient# mksysb -e /tmp/mksysb.pipe
Jeśli Czytelnik ceni wygodę: wszystkie powyższe kroki są realizowane przez skrypt rmksysb napisany przez Henka van Doorna.
Archiwizowanie na dysku Choć możliwe jest zarchiwizowanie systemu na lokalnie podłączonym dysku, oczywiście w takim przypadku pojawią się komplikacje na etapie odtwarzania. Możliwe jest nawet zarchiwizowanie grupy rootvg w pliku stanowiącym jej część. Jednakże z kilku różnych powodów byłby to naprawdę zły pomysł. A zatem częstą praktyką jest przygotowywanie na oddzielnym serwerze udziału NFS, w którym będą przechowywane kopie zapasowe.
396
|
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
Aby system plików zezwolił na utworzenie plików o rozmiarze 9 GB, trzeba dla niego włączyć obsługę dużych plików i skonfigurować parametr ulimit (domyślnie jest dla niego ustawiona pojemność 1 GB). W celu sprawdzenia bieżącego ustawienia parametru ulimit należy wykonać następujące polecenie: klient# ulimit -f 2097151
Domyślne ustawienie obowiązujące w całym systemie określa się w pliku /etc/security/limits. Wartość parametru ulimit można też zmienić w oknie powłoki, stosując polecenie ulimit (9 GB plus odrobina na dodatkowe potrzeby). klient# ulimit -f 19000000
Gdy już można zapisać duży plik (o rozmiarze przekraczającym 1 GB), kopię zapasową grupy rootvg umieścimy w punkcie podłączenia NFS po stronie klienta. W poniższych przykładach do przechowywania kopii zapasowych narzędzia mksysb użyto katalogu /Udzial_NFS/mksysb serwera Serwer_NFS. Zostanie wykonane polecenie mksysb -e -m /nazwa_katalogu/nazwa_pliku. Opcja -e nakazuje programowi mksysb wykluczenie wzorców wymienionych w pliku /etc/ ¦exclude.rootvg. Z kolei opcja -m określa nośnik, na którym zostaną zapisane dane. Ostatnim argumentem powinna być pełna ścieżka pliku obrazu. klient# mksysb -e -m /Udzial_NFS/mksysb/klient-6-1-06.msb_image Creating information file (/image.data) for rootvg.. Creating list of files to back up. Backing up 39932 files. ........ # 39932 of 39932 files (100%) 0512-038 mksysb: Backup Completed Successfully.
Sporządzenie kopii zapasowej grupy rootvg jest po prostu takie łatwe. Dysponujemy kopią zapasową, z której na komputerze można odtworzyć dane. W przypadku wystąpienia mniej istotnego problemu można odtworzyć pojedynczy plik. Z kolei gdy pojawi się poważny problem, w celu odtworzenia danych można utworzyć ładowalny dysk DVD lub przeprowadzić proces przywracania przy użyciu serwera NIM.
Tworzenie ładowalnego dysku CD/DVD za pomocą istniejącego obrazu narzędzia mksysb Po zapisaniu na dysku obrazu programu mksysb można go wykorzystać do utworzenia zestawu ładowalnych dysków CD lub DVD, które mogą następnie posłużyć do bardzo szybkiego przywrócenia systemu. Proces ten składa się z następujących trzech kroków:
1. Program mkcd tworzy tymczasowe pliki, których używa do wygenerowania obrazów ISO. 2. Narzędzie mkcd tworzy obrazy ISO na podstawie tymczasowych plików. 3. Obrazy ISO są wykorzystywane do uzyskania dysków CD/DVD. W przypadku pierwszych dwóch kroków wymagana będzie określona lokalna przestrzeń robocza. Przestrzeń ta nie powinna stanowić części grupy rootvg i musi być na tyle duża, aby pomieścić tymczasowy system plików dysku CD/DVD i umieszczane na nim obrazy ISO. W przypadku każdego dysku CD jest to obszar około 645 MB, z kolei dysk DVD wymaga obszaru o rozmiarze 4,38 GB. Pliki tymczasowe prawdopodobnie mogą znajdować się w katalogu
Arch w zowan e przy użyc u narzędz a mksysb
|
397
NFS. Jednak najlepszym rozwiązaniem będzie raczej lokalne przechowywanie obrazów ISO w celu uniknięcia problemów z buforowaniem podczas tworzenia dysków CD lub DVD. W tym celu zostaną użyte następujące opcje polecenia mkcd: -e
Opcja wyklucza z kopii zapasowej pliki i (lub) katalogi wyszczególnione w pliku /etc/exclude. ¦volume_group. Opcji tej nie można zastosować razem z opcją -m lub -s. -m nazwa_pliku Łańcuch nazwa_pliku identyfikuje nazwę obrazu wcześniej utworzonego przez narzędzie mksysb. Jeśli nie użyje się opcji -m, polecenie mkcd wywoła polecenie mksysb (aby uzyskać więcej informacji na temat lokalizacji obrazu narzędzia mksysb, należy skorzystać z opcji -M). -C katalog
Opcja pozwala określić system plików służący do utworzenia struktury systemu plików dysku CD. System plików musi oferować co najmniej 645 MB dostępnej przestrzeni dyskowej (maksymalnie 4,38 GB w przypadku obrazów zapisywanych na dyskach DVD). Obraz dysku CD zajmuje na nim tylko tyle miejsca, ile jest niezbędne do pomieszczenia wszystkich danych. -I katalog
Opcja określa katalog lub system plików, w obrębie którego będą przechowywane obrazy dysku CD przed zapisaniem ich za pomocą nagrywarki obsługującej format dysków CD-R, DVD-R lub DVD-RAM. Gdy nie użyje się tej opcji, program mkcd zastosuje katalog /mkcd/ ¦cd_images, jeśli ten już istnieje. W przeciwnym razie program utworzy katalog /mkcd/cd_images w grupie woluminów rootvg (jeśli nie użyje się opcji -V) lub innej (gdy zastosuje się opcję -V). -P
Opcja powoduje przeprowadzenie fizycznego mapowania partycji podczas sporządzania kopii zapasowej za pomocą polecenia mksysb lub savevg. Opcji tej nie można zastosować razem z opcją -m lub -s. -R
Opcja uniemożliwia programowi mkcd usunięcie finalnych obrazów dysków CD. Domyślnie narzędzie to, kończąc pracę, usuwa wszystko, co utworzyło. Opcja -R daje możliwość magazynowania wielu zestawów obrazów dysków CD lub utworzenia dysku CD (nagrania go) na innym komputerze. Jeśli wymaganych jest wiele woluminów, finalne obrazy są w unikatowy sposób nazywane przy użyciu identyfikatora procesu i sufiksów woluminów. -S
Opcja przerywa działanie programu mkcd przed zapisem na dysku CD-R, DVD-R lub DVD-RAM bez usuwania finalnych obrazów dysków CD. Opcja umożliwia utworzenie wielu zestawów dysków CD lub sporządzenie takich dysków na innym komputerze. Obrazy pozostają w katalogu określonym za pomocą opcji -I lub w katalogu /mkcd/cd_images, gdy tej opcji nie zastosowano. Jeśli niezbędnych jest wiele woluminów, finalne obrazy są w unikatowy sposób nazywane przy użyciu identyfikatora procesu i sufiksów woluminów. -d nagrywarka_CD_lub_DVD
Opcja identyfikuje urządzenie zapisujące dane na dyskach formatu CD-R, DVD-R lub DVD-RAM (na przykład /dev/cd1). Opcja jest wymagana, jeśli nie użyje się opcji -S.
398 |
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
W poniższych przykładach host o nazwie Serwer_NFS jest wyposażony w nagrywarkę DVD. Ponadto dysponuje lokalnym systemem plików /mkcd o pojemności 18 GB, służącym do przechowywania zarówno tymczasowych obrazów, jak i obrazów ISO. Host Serwer_NFS udostępnia system plików /Udzial_NFS/mksysb innym klientom, żeby mogły umieszczać w nim swoje kopie zapasowe utworzone za pomocą narzędzia mksysb (jest to ten sam katalog, w którym w poprzednim przykładzie zapisywano kopie zapasowe). W następnym przykładzie zastosowano serwer NFS w celu utworzenia ładowalnego obrazu dysku CD na podstawie obrazu klient-6-1-06.msb_image narzędzia mksysb, zapisanego w poprzednim przykładzie w punkcie podłączenia NFS /Udzial_NFS/mksysb. Do magazynowania tymczasowych obrazów wykorzystano katalog /mkcd/cd_fs, a finalnych obrazów ISO — /mkcd/cd_images. Serwer_NFS# mkcd -m /Udzial_NFS/mksysb/klient-6-1-06.msb_image -C /mkcd/cd_fs -I /mkcd/cd_images -R -S Initializing mkcd log: /var/adm/ras/mkcd.log... Verifying command parameters... Populating the CD or DVD file system... Copying backup to the CD or DVD file system... . Building chrp boot image... Creating Rock Ridge format image: /mkcd/cd_images/cd_image_295108.vol1 Running mkisofs ... . mkrr_fs was successful. Making the CD or DVD image bootable... Copying the remainder of the backup to the CD or DVD file system... Creating Rock Ridge format image: /mkcd/cd_images/cd_image_295108.vol2 Running mkisofs ... . mkrr_fs was successful. Copying the remainder of the backup to the CD or DVD file system... Creating Rock Ridge format image: /mkcd/cd_images/cd_image_295108.vol3 Running mkisofs ... . mkrr_fs was successful.
W efekcie uzyskano trzy obrazy ISO znajdujące się w katalogu /mkcd/cd_images. Po utworzeniu obrazu na dysku CD są usuwane tymczasowe dane skopiowane do katalogu /mkcd/cd_fs. Obraz ten można przetransferować na inny serwer z nagrywarką CD i przy jej użyciu zapisać obrazy ISO. Jeśli planuje się na dysku DVD zapisać obraz, należy wykonać poniższe polecenie z opcją -L. Serwer_NFS# mkcd -L -m /Udzial_NFS/mksysb/klient-6-1-06.msb_image -C /mkcd/cd_fs -I / mkcd/cd_images -R -S Initializing mkcd log: /var/adm/ras/mkcd.log... Verifying command parameters... Populating the CD or DVD file system... Copying backup to the CD or DVD file system... ........ Building chrp boot image... Creating Rock Ridge format image: /mkcd/cd_images/cd_image_405642 Running mkisofs ... ........ mkrr_fs was successful. Making the CD or DVD image bootable...
Arch w zowan e przy użyc u narzędz a mksysb
| 399
We wcześniejszym przykładzie wygenerowano trzy obrazy ISO o pojemności dysku CD. Jednak w tym przykładzie użyto opcji -L, dlatego uzyskano jeden duży obraz ISO dla dysku DVD. Obrazy te można wykorzystać do utworzenia dysku CD lub DVD na dowolnym komputerze. Jeżeli zamierza się w jednym kroku utworzyć obrazy i zapisać je na dyskach CD/DVD, należy usunąć opcje -S i -R, a także dodać opcję -d i wstawić nazwę urządzenia będącego nagrywarką CD/DVD. Serwer_NFS# mkcd -d /dev/cd0 -e -m /Udzial_NFS/mksysb/klient-6-1-06.msb_image -C /mkcd/cd_fs -I /mkcd/cd_images
Jeśli chce się nagrać dysk CD, wykorzystując wcześniej utworzony obraz ISO, należy użyć następującego polecenia: Serwer_NFS# burn_cd /dev/cd0 /Udzial_NFS/mksysb/klient-6-1-06.msb_image
Gdy istnieje więcej niż jeden plik obrazu dla dysku CD, dla każdego z nich należy wykonać powyższe polecenie. Jeżeli zamierza się nagrać dysk DVD przy użyciu obrazu ISO, do polecenia należy dodać opcję -d. Serwer_NFS# burn_cd /dev/cd0 /Udzial_NFS/mksysb/klient-6-1-06.msb_image
Tworzenie w jednym kroku kopii zapasowej na dysku CD/DVD Jeśli Czytelnik jest posiadaczem komputera z nagrywarką CD/DVD, dla którego zamierza utworzyć dyski DVD, a ponadto ma do dyspozycji obszar roboczy wystarczający do sporządzenia obrazu CD, za pomocą narzędzia mkcd w jednym kroku może uzyskać dysk CD/DVD. Choć wszystkie kroki wcześniej omówionej metody w dalszym ciągu są wymagane i wykonywane, program mkcd zarządza całym procesem i automatyzuje go, począwszy od sporządzenia kopii zapasowej narzędzia mksysb, a skończywszy na nagraniu dysków CD/DVD. W poniższym przykładzie na ładowalnym dysku DVD jest zapisywana kopia zapasowa grupy rootvg z plikami mapowania (powiązane z odtwarzaniem logicznych woluminów), z wykluczeniem wszystkich plików i katalogów wymienionych w pliku /etc/exclude.rootvg. Serwer_NFS# mkcd -L -P -e -M /Udzial_NFS/mksysb -C /mkcd/cd_fs -I /mkcd/cd_images -R -S Initializing mkcd log: /var/adm/ras/mkcd.log... Verifying command parameters... Creating image.data file... Creating mksysb image... Creating list of files to back up. Backing up 39945 files. ............. 39945 of 39945 files (100%) 0512-038 mksysb: Backup Completed Successfully. Populating the CD or DVD file system... Copying backup to the CD or DVD file system... ....... Building chrp boot image... Creating Rock Ridge format image: /mkcd/cd_images/cd_image_323664 Running mkisofs ... ....... mkrr_fs was successful. Making the CD or DVD image bootable... Serwer_NFS#
400 |
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
Powyższe polecenie sporządza przy użyciu programu mksysb kopię zapasową grupy rootvg, a następnie na podstawie tej kopii tworzy obraz ISO dla ładowalnego dysku DVD. Obraz o nazwie cd_image_323664 jest umieszczany w katalogu /mkcd/cd_images. Obraz można przetransferować na inny komputer PC (wyposażony w nagrywarkę DVD) i przy jego wykorzystaniu utworzyć dysk DVD. Dysk taki można również nagrać na lokalnym komputerze, wstawiając w poleceniu mkcd argument -d urządzenie. Jeśli zamierza się wygenerować obrazy dla dysku CD, wystarczy wykonać to samo polecenie bez opcji -L. Polecenie utworzy wiele obrazów, gdy rozmiar kopii zapasowej będzie przekraczać pojemność jednego dysku CD.
Konfigurowanie menedżera NIM Niektórzy zamiast tworzyć dyski CD lub DVD, wolą po prostu obrazy sporządzone za pomocą programu mksysb pozostawić na serwerze plików i odczytać bezpośrednio z niego podczas procesu przywracania. Jeżeli Czytelnik chce tak postąpić, musi zastosować menedżera NIM (Network Install Manager). Zaletą tego rozwiązania jest to, że w celu przeprowadzenia operacji odtwarzania nie ma potrzeby wczytywania żadnego fizycznego nośnika. Z kolei wadą jest to, że proces odtwarzania jest ograniczany przez szybkość sieci Ethernet. Ponadto odtwarzanie mogą skomplikować problemy z tego typu siecią. Jeśli nie dysponuje się jeszcze serwerem NIM, trzeba będzie go skonfigurować. Dobrą wiadomością jest to, że choć serwer NIM jest dość złożony, przygotowanie środowiska NIM tylko na potrzeby odtwarzania nie jest zbyt trudne. Konieczne będzie skonfigurowanie serwera NIM, dodanie do niego klienta i utworzenie dla klienta definicji za pomocą programu mksysb.
Konfigurowanie serwera NIM Celem serwera NIM jest dostarczenie ładowalnego obrazu klientowi za pośrednictwem sieci wykorzystującej protokoły BOOTP i TFTP. W omawianym przypadku zależy nam na załadowaniu i zainstalowaniu obrazu wcześniej utworzonego przy użyciu narzędzia mksysb. Najprostszym sposobem konfiguracji serwera NIM jest zastosowanie kreatora eznim dołączonego do wersji 5.2 systemu AIX. Serwer_NIM# smit eznim
W przypadku wersji systemu starszych niż 5.2 dla serwera NIM dostępny jest zwykły panel smit, który oferuje opcję konfiguracji. Serwer_NIM# smit nim
Konfigurowanie serwera NIM za pośrednictwem panelu smit to najprostsza i najbardziej zrozumiała metoda. Jeśli serwer postanowi się zainstalować przy użyciu interfejsu wiersza poleceń, w dokumentacji narzędzia nim_master_setup należy poszukać informacji na temat wszelkich opcji, które przydadzą się w przypadku zarządzanego środowiska. Poniższe instrukcje w szybki i prosty sposób przeprowadzają konfigurację serwera NIM z poziomu wiersza poleceń.
1. Korzystając z najnowszego zalecanego poziomu obsługi technicznej zainstalowanego systemu AIX, należy poszukać dysku CD o nazwie POWER Version X Volume 1.
2. W napędzie należy umieścić dysk CD i podłączyć go. 3. Po zlokalizowaniu polecenia nim_master_setup należy je wykonać. Serwer_NIM# nim_master_setup
Konf gurowan e menedżera N M
|
401
Polecenie konfiguruje domyślny serwer NIM. W obrębie głównego systemu plików tworzy katalogi /tftpboot i /export.
Dodanie do serwera NIM definicji klienta W tym punkcie objaśniono krok polegający na dodaniu do serwera NIM hosta, który będzie archiwizowany. Operację trzeba wykonać tak, aby serwer NIM wiedział, komu ma udostępniać obrazy. Najprostsza metoda dodania klienta polega na zastosowaniu panelu smit. Serwer_NIM# smit nim_mkmac
Klienta można też zainstalować i skonfigurować z poziomu interfejsu wiersza poleceń. Poniższe instrukcje dotyczą typowego klienta. Zarówno klient, jak i serwer muszą mieć możliwość rozpoznania się za pośrednictwem usługi DNS. Host użyty w przykładzie ma nazwę klient i ma architekturę chrp mp wykorzystującą skrętkę. W celu uzyskania dodatkowych informacji dotyczących interfejsu wiersza poleceń należy zajrzeć do dokumentacji polecenia niminit. Polecenie to wykonuje się z poziomu klienta, a nie serwera. Wynika z tego korzyść polegająca na zapewnieniu, że klient może komunikować się z serwerem NIM. klient# niminit -a name=klient -a master=Serwer_NIM -a pif_name=en0 -a platform=chrp a netboot_kernel=mp -a cable_type1=tp
Tworzenie dla klienta definicji narzędzia mksysb Po dodaniu klienta można wybrać typ instalacji. W ten sposób serwer NIM jest informowany o tym, który obraz klient powinien zainstalować. Najprostszą metodą określenia obrazu narzędzia mksysb, którego klient użyje do załadowania, jest zastosowanie interfejsu smit. W tym celu jako zasób obrazu należy wybrać mksysb, a także określić lokalizację. klient# smit update_client_eznim
W panelu smit należy wybrać typ instalacji mksysb - Install from a mksysb i ustawić obraz, z którego będą odtwarzane dane. Operację można również przeprowadzić z poziomu interfejsu wiersza poleceń. Aby uzyskać szczegółowe informacje na temat korzystania z interfejsu, należy zajrzeć do dokumentacji polecenia nim. W przykładzie host o nazwie klient ma zostać załadowany za pośrednictwem serwera Serwer_NIM z pliku obrazu /export/kopie_zapasowe/klient-6-1-06.msb_image. Dodatkowo plikowi temu przypisano nazwę zasobu mksysb_res1. klient# nim -o define -t mksysb -a server=Serwer_NIM -a location=/export/kopie_zapasowe/ klient-6-1-06.msb_image mksysb_res1
Zastosowanie narzędzia savevg Obsługa programu savevg wygląda prawie tak samo jak narzędzia mksysb. Różnica polega jedynie na tym, że zamiast grupy rootvg w przypadku programu savevg należy określić archiwizowaną grupę woluminów. Grupa woluminów musi być aktywna, a system plików — podłączony. Lista wykluczeń dla programu savevg znajduje się w pliku /etc/exclude., 402 |
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
gdzie w miejsce łańcucha należy wstawić nazwę grupy woluminów przeznaczonej do archiwizacji.
Użycie programu savevg do archiwizacji grupy woluminów W przytoczonym przykładzie w udziale NFS zostanie zarchiwizowana grupa datavg. klient# mount Serwer_NFS:/Punkt_NFS/savevg /Punkt_NFS/savevg klient# savevg -e -m -f /Punkt_NFS/savevg/klient-datavg-6-1-06.svg_image datavg Creating information file for volume group datavg. Creating list of files to back up. Backing up 13 files 13 of 13 files (100%) 0512-038 savevg: Backup Completed Successfully.
Weryfikowanie kopii zapasowej utworzonej za pomocą narzędzia mksysb lub savevg Gdy na taśmie lub dysku umieszczono już kopię zapasową, można sprawdzić jej zawartość. Choć najdokładniejszym testem kopii zapasowej programu mksysb będzie faktyczny proces odtwarzania, przez wyświetlenie zawartości archiwum można stwierdzić, jaka jest spójność danych zapisanych na taśmie. W przypadku taśmy trzeba upewnić się, czy jest przewinięta do początku. # mt -f urządzenie rewind
W dalszej kolejności należy wykonać polecenie restore, aby wygenerować zawartość taśmy lub pliku. # restore -s4 -Tvf [urządzenie_bez_przewijania | nazwa_pliku]
W efekcie uzyska się listę wszystkich zarchiwizowanych plików, datę i czas przeprowadzenia procesu, a także liczbę plików umieszczonych w kopii zapasowej.
Przywracanie systemu AIX za pomocą narzędzia mksysb W niniejszym podrozdziale wyjaśniono, jak całkowicie przywrócić system, korzystając z jednej z wcześniej zaprezentowanych metod bazujących na narzędziu mksysb. Aby przeczytać o odtwarzaniu pojedynczych plików za pomocą programu restore, należy zajrzeć do rozdziału 3.
W przypadku wystąpienia nieszczęśliwego zdarzenia komputer można załadować z taśmy, dysku CD/DVD lub za pośrednictwem sieci, a następnie przeprowadzić proces pełnego odtwarzania. Ponieważ te procesy są bardzo podobne, zostaną omówione w ramach jednej procedury. Oto ona:
1. Jeśli komputer nadal jest włączony, przed jego wyłączeniem można go tak skonfigurować, żeby ładowanie zostało przeprowadzone z taśmy lub dysku CD.
Przywracan e systemu A X za pomocą narzędz a mksysb
| 403
a. W celu załadowania z dysku CD/DVD należy wykonać następujące polecenie: klient# bootlist -m normal cd0
b. Aby komputer załadować z taśmy, należy zastosować poniższe polecenie. klient# bootlist -m normal rmt0
c. W celu załadowania za pośrednictwem sieci należy wykonać następujące polecenie: klient# bootlist -m normal en0
2. Należy wyłączyć komputer. 3. Należy podłączyć terminal (lub monitor i klawiaturę). 4. Należy przygotować nośnik. a. Jeżeli nośnikiem jest taśma, należy podłączyć napęd taśmowy i umieścić w nim taśmę. b. Jeśli nośnikiem jest dysk CD, najpierw należy go umieścić w napędzie.
5. Należy uruchomić komputer. 6. Należy wyświetlić menu SMS. Jeśli przed wyłączeniem komputera nie udało się wybrać
urządzenia z listy rozruchowej, po włączeniu trzeba poinstruować hosta, żeby dokonał ładowania z właściwego urządzenia. W przypadku komputerów z podłączoną konsolą HMC przed uaktywnieniem partycji można wybrać tryb ładowania. Domyślnie jest wyświetlane menu SMS. Niektóre komputery z systemem AIX w celu uzyskania dostępu do menu SMS wymagają przerwania procesu ładowania. W przypadku części starszych komputerów należy wcisnąć klawisz F1, gdy na ekranie monitora są widoczne ikony procedury POST. Większość nowszych komputerów wymaga wciśnięcia klawisza F5, gdy na ekranie monitora widać ikony procedury POST. W celu uzyskania informacji dotyczących operacji przerywania procesu ładowania posiadanego komputera z systemem AIX należy zajrzeć do dołączonej dokumentacji sprzętowej.
7. W menu SMS należy wybrać pozycję Maintenance Mode i ustawić jedną z następujących opcji odtwarzania/ładowania.
a. Opcję Select Boot Device należy wybrać, aby móc przeprowadzić operację odtwarzania z dysku CD/DVD lub taśmy. b. Gdy jest dostępny serwer NIM, należy wybrać opcję Installation from Network. W tym przypadku może być konieczne podanie dodatkowych parametrów sieciowych, zależnie od sposobu skonfigurowania serwera NIM.
8. Dalej jest sprawdzana zgodność kopii zapasowej. Jeśli kopia jest kompatybilna ze sprzę-
tem, na którym zostanie przywrócona jej zawartość, proces odtwarzania jest wstrzymywany na pięć sekund, a następnie automatycznie wznawiany. Przywracana jest grupa rootvg przy wykorzystaniu ustawień znajdujących się w pliku image.data i (lub) bosinst.data. Jeśli zamierza się przerwać instalację, w czasie 5-sekundowej pauzy trzykrotnie należy wcisnąć klawisz 0. Spowoduje to wymuszenie odtwarzania w trybie interaktywnym. W sytuacji gdy kopia zapasowa nie jest zgodna z urządzeniami komputera, automatycznie zostanie rozpoczęty proces interaktywnego odtwarzania, który przebiega bardzo podobnie jak w przypadku wstępnej fazy instalacji systemu AIX. Różnica jest taka, że na końcu interaktywnego odtwarzania przywraca się system.
9. W przypadku nieinteraktywnego odtwarzania proces ten trwa bez przerw aż do ukończenia.
Z kolei gdy wykonuje się proces interaktywnego odtwarzania, możliwa staje się zmiana fizycznych dysków, na których zostaną umieszczone przywracane dane, zmniejszanie rozmiaru systemów plików itp.
404 |
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
10. Gdy zakończy się odtwarzanie, komputer zmieni swoje urządzenie rozruchowe, aby zainstalować docelowe urządzenia dla grupy rootvg. Na końcu komputer zostanie ponownie uruchomiony.
Powielanie systemów Powielanie systemu polega na odtworzeniu całego obrazu jednego komputera na innym komputerze. A zatem odtworzony system jest idealną kopią oryginalnego systemu. Coś takiego może być przydatne w przypadku pożaru lub podobnego nieszczęśliwego zdarzenia, które spowodowało całkowitą utratę sprzętu. W takiej sytuacji, korzystając z kopii zapasowej sporządzonej przez program mksysb i przechowywanej w innym miejscu, na nowym komputerze można przywrócić zawartość starego komputera.
System operacyjny AIX 4.x Wersje 4.x systemu AIX wymagają szczególnej uwagi, ponieważ nie wszystkie sterowniki są instalowane razem z podstawowymi składnikami systemu. W tym przypadku do wyboru są dwa następujące warianty: • Instalacja sterownika każdego urządzenia dla wszystkich dostępnych architektur przed
sporządzeniem kopii zapasowej systemu przy użyciu narzędzia mksysb. Umożliwia to wykonanie operacji ładowania z taśmy i odtworzenie danych na dowolnym komputerze IBM RS/6000. • Jeśli sterowniki urządzeń nie są zainstalowane, po prostu nowy komputer można zała-
dować z dysku CD-ROM zawierającego system operacyjny AIX 4.x. Po uruchomieniu systemu należy wybrać opcję Restore from tape backup, a następnie w napędzie umieścić taśmę z kopią zapasową narzędzia mksysb i rozpocząć proces odtwarzania.
System operacyjny AIX 5.x W przypadku systemu AIX 5.x wszystkie sterowniki urządzeń i obsługiwane jądra są instalowane razem z podstawowymi składnikami. Oznacza to, że kopia zapasowa systemu przeważnie powinna być niezależna od sprzętu. Jednak podczas archiwizowania starszych, 32-bitowych systemów pojawiają się problemy. Jeśli kopię zapasową 32-bitowego systemu AIX działającego w trybie 32-bitowym odtworzy się na 64-bitowym sprzęcie, system ten nadal będzie używał 32-bitowego trybu. Gdy 64-bitowy system przywróci się na 32-bitowym sprzęcie, nie zadziała, ponieważ takie urządzenia nie są w stanie obsługiwać 64-bitowego oprogramowania. Aby dowiedzieć się, jak przełączać tryby systemowe między 32- i 64-bitowymi, należy zajrzeć do przewodnika firmy IBM dotyczącego obsługi posiadanej wersji systemu AIX. Powinno się poddać edycji plik bosinst.data, żeby ustawić zmienną RECOVER_DEVICES. Zmienna określa, czy będą odtwarzane, czy nie definicje ODM istniejące w momencie archiwizacji. Ponieważ kopia zapasowa może być przywrócona na komputerze o bardzo różnej konfiguracji sprzętowej, podczas ładowania należy umożliwić systemowi AIX odbudowanie własnych definicji ODM.
Pow elan e systemów
| 405
Jeśli przy wykorzystaniu innej platformy tworzy się ładowalny dysk CD/DVD, w wierszu polecenia mkcd trzeba uwzględnić opcję -G. Spowoduje to umieszczenie na dysku CD/DVD ładowalnych obrazów: chrp, rs6k i rspc. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
406 |
Rozdz ał 13. Przywracan e od podstaw komputera z systemem A X
ROZDZIAŁ 14.
Przywracanie od podstaw komputera z systemem Mac OS X
Choć system Mac OS X pod wieloma względami przypomina inne odmiany systemu Unix, w kwestiach związanych z kopiami zapasowymi pojawiają się między nimi różnice. Część dostępnych narzędzi jest identyczna. Jednak znane narzędzia mogą nie być najlepszą propozycją. Podobnie do innych systemów operacyjnych omówionych w tej części książki, również w przypadku systemu Mac OS X różnią się metody używane do zapisywania krytycznych metadanych i ładowania z przywróconego dysku. Zachowując format poprzednich rozdziałów, w niniejszym rozdziale wyjaśniono, jak w prosty i ekonomiczny sposób utworzyć kopię zapasową systemu Mac OS X na potrzeby przywracania komputera od podstaw. W pracach nad rozdziałem brał udział Leon Towns-von Stauber. Leon od 1990 roku użytkuje różne odmiany systemu Unix i administruje nimi. Odkąd w 1991 roku kupił stację roboczą NeXT, zaczął interesować się systemem Mac OS X.
Jak to działa? W poniższych punktach zaprezentowano procedurę, za pomocą której można przeprowadzić proces pełnego przywracania komputera z systemem Mac OS X bez potrzeby uprzedniego instalowania systemu operacyjnego. Kolejność wykonywanych czynności generalnie jest taka sama jak w przypadku innych platform. Znakomitą porą na przetestowanie procedury będzie moment odebrania nowego komputera Macintosh, na którym nie ma jeszcze żadnych danych.
Najpierw, wykonując poniższe kroki, trzeba przygotować się do procesu przywracania.
1. Podłączenie do komputera urządzenia archiwizującego. 2. Zarchiwizowanie ważnych metadanych. 3. Zarchiwizowanie systemu operacyjnego za pomocą jego wbudowanego narzędzia.
407
Gdy później stanie się coś niedobrego, należy przeprowadzić przywracanie. Oto wymagane kroki:
1. Załadowanie systemu z alternatywnego nośnika. 2. Partycjonowanie i formatowanie nowego głównego dysku. 3. Odtwarzanie systemu operacyjnego. 4. Skonfigurowanie komputera, tak aby system ładował z nowego głównego dysku. Najpierw dokonamy ogólnego przeglądu, a następnie zajmiemy się przykładem konkretnej procedury. W przypadku dowolnej metody archiwizacji system bezpieczeństwa jest jedynie tak dobry jak ostatnia kopia zapasowa. W związku z tym duże znaczenie ma zaplanowanie wykonywania kopii zapasowych i testowanie procedur przywracania.
Przygotowanie do przywracania komputera od podstaw Przedstawiona procedura w roli nośnika archiwizacyjnego może wykorzystać dowolny zewnętrzny napęd dysku twardego. Przykładem takiego napędu jest urządzenie magazynujące FireWire lub USB z pojemnością wystarczającą do pomieszczenia pełnej kopii zapasowej. Zależnie od wymagań dotyczących magazynowania danych nawet urządzenie iPod może być znakomitą alternatywą. Następną opcją jest zastosowanie laptopa Mac w trybie FireWire Target Disk Mode, przy założeniu, że jest wyposażony w port FireWire. Można również użyć udziału NFS dowolnego serwera uniksowego. Choć napędy USB i FireWire mogą być znakomitą propozycją dla pojedynczego użytkownika, w przypadku centrum danych zwykle najlepszy jest udział NFS. Niestety, nie zadziała udział SMB, ponieważ sterowniki SMB nie są dostępne z poziomu konsoli instalacyjnego dysku CD, która będzie stosowana podczas przywracania (więcej na ten temat w dalszej części rozdziału). W celu włączenia trybu Target Disk Mode należy wybrać pozycję Apple Menu/System Preferences/Startup Disk/Target Disk Mode…. Alternatywnie podczas uruchamiania laptopa Mac należy trzymać wciśnięty klawisz T. Za pomocą kabla FireWire należy połączyć ze sobą laptop i komputer, który będzie archiwizowany. Laptop będzie pełnił rolę zewnętrznego napędu FireWire.
Po podłączeniu zewnętrznego dysku archiwizacyjnego trzeba zebrać informacje niezbędne do sformatowania dysku zastępczego, zanim zostaną odtworzone na nim dane. Wyniki poleceń: diskutil list, pdisk urządzenie -dump (dotyczy komputerów z procesorem PowerPC) i mount -t hfs należy zapisać w plikach zlokalizowanych na dysku archiwizacyjnym. Pliki te zostaną użyte podczas przywracania. W czasie pisania książki firma Apple wprowadziła na rynek pierwsze modele komputerów Mac wyposażone w procesory Intel x86 zamiast procesorów PowerPC. Jeśli Czytelnik dysponuje komputerem Mac z układem Intela, nie będzie mógł skorzystać z polecenia pdisk. Ponadto narzędzie fdisk nie dostarczy informacji dotyczących dysku, z którego je załadowano (więcej na ten temat w dalszej części rozdziału).
Dobrym pomysłem jest zapisanie w pliku za pomocą polecenia nvram -p zmiennych oprogramowania sprzętowego Open Firmware, na wypadek gdyby razem z głównym dyskiem przepadła zawartość pamięci NVRAM. Ponadto zapobiegawczo warto przechowywać kopię wyniku
408 |
Rozdz ał 14. Przywracan e od podstaw komputera z systemem Mac OS X
wygenerowanego przez narzędzie System Profiler. W ten sposób uzyska się naprawdę kompletną dokumentację sprzętu komputera i konfiguracji oprogramowania (z poziomu menu Apple Menu należy uruchomić aplikację System Profiler, po czym wybierając pozycję About This Mac/More Info…, a następnie pozycję File/Save, utworzyć profil konfiguracji komputera). Pora zarchiwizować dane, które posłużą do przywrócenia systemu operacyjnego. Choć do wyboru jest kilka systemowych narzędzi archiwizujących, w omawianej procedurze zostanie użyty program ditto systemu Mac OS X. W przypadku wersji 10.4 lub nowszej tego systemu możliwe jest zastosowanie narzędzia tar zamiast ditto. Jednakże podczas procesu przywracania w roli nośnika rozruchowego zostanie użyty dysk instalacyjny. Na dysku tym nie ma narzędzi kompresujących (gzip lub compress) wykorzystywanych przez program tar. Z kolei narzędzie ditto ma wbudowany mechanizm kompresji programu PKZIP. Aby zaoszczędzić miejsce na nośniku archiwizacyjnym i zachować zgodność ze starszymi wersjami systemu operacyjnego, przykładowa procedura szczegółowo przedstawiona w dalszej części rozdziału na potrzeby archiwizowania i przywracania używa programu ditto. W celu uzyskania dodatkowych informacji na temat wbudowanych narzędzi Mac OS X należy zajrzeć do rozdziału 3.
Przeprowadzanie procesu przywracania komputera od podstaw Gdy nadejdzie dzień, w którym trzeba będzie sięgnąć po kopię zapasową w celu przywrócenia systemu (niezależnie od tego, czy będzie się robiło to w ramach ćwiczenia czy gdy stanie się coś strasznego), pierwszą rzeczą po wymianie wszelkich uszkodzonych komponentów jest załadowanie komputera. Najprostszą metodą umożliwiającą to jest zastosowanie tego samego nośnika optycznego, z którego zainstalowano nową kopię systemu Mac OS X. Z tego rozwiązania skorzystamy w omawianym przykładzie. Po uruchomieniu komputera należy przeprowadzić partycjonowanie i formatowanie nowego dysku. W tym przypadku należy posłużyć się wynikami poleceń diskutil i pdisk zapisanymi w czasie archiwizowania. Partycjonowanie i formatowanie umożliwia polecenie diskutil partitionDisk. Odtwarzanie danych naprawdę jest zupełnym przeciwieństwem ich archiwizowania. W celu dekompresji i rozpakowania plików archiwów należy zastosować program ditto. Jeśli trzeba przywrócić konfigurację oprogramowania sprzętowego Open Firmware, należy wykonać polecenie nvram -f nazwa_pliku. Gdy już wszystkie dane zostały odtworzone, za pomocą narzędzia bless należy tak skonfigurować komputer, żeby ładował się z nowego dysku.
Przykładowy proces przywracania komputera od podstaw W przykładzie w celu zarchiwizowania i przywrócenia kompletnego systemu Mac OS X komputera Apple iBook użyto programów: diskutil, pdisk, mount, nvram, ditto i bless. W roli nośnika archiwizacyjnego zastosowano urządzenie iPod. W ramach omawianej procedury zostanie też przedstawionych kilka innych przykładów. Wszystkie woluminy sformatowano przy użyciu systemu plików HFS+.
Przykładowy proces przywracan a komputera od podstaw
| 409
Archiwizowanie danych Najpierw do komputera należy podłączyć dysk archiwizacyjny. Wolumin dysku jest automatycznie montowany przez program diskarbitrationd. W przytoczonym przykładzie przyjęto, że wolumin podłączono jako katalog /Volumes/iPod. Docelowym dyskiem może być również udział serwera NFS. Aby tak było, udział trzeba podłączyć. Jeśli na przykład na serwerze NFS o adresie IP 192.168.0.1 znajduje się udział NFS /kopie_zapasowe, wykonując poniższe polecenia, można go podłączyć jako /kopie_zapasowe. # mkdir /kopie_zapasowe # mount -t nfs 192.168.0.1:/kopie_zapasowe /kopie_zapasowe
Pora zapisać ważne metadane. W celu uzyskania nazw i rozmiarów partycji, a także nazwy głównego dysku (zwykle /dev/disk0), należy skorzystać z programu diskutil. Mając te informacje, należy uruchomić narzędzie pdisk, żeby otrzymać dokładny rozmiar partycji wyrażony w blokach. Ponadto należy użyć programu mount w celu zapoznania się z główną partycją i wszelkimi specjalnymi opcjami partycjonowania (na przykład rejestrowanie lub rozróżnianie wielkości znaków). Poniżej pokazano wynik wykonania tych poleceń. % mkdir /Volumes/iPod/Backup % diskutil list | tee /Volumes/iPod/Backup/diskutil.txt /dev/disk0 #: type name size 0: Apple_partition_scheme *18.6 GB 1: Apple_partition_map 31.5 KB 2: Apple_HFS Mac OS X 7.9 GB 3: Apple_HFS Mac OS X Alt 7.9 GB 4: Apple_HFS Local 2.5 GB /dev/disk1 #: type name size 0: Apple_partition_scheme *18.6 GB 1: Apple_partition_map 31.0 KB 2: Apple_MDFW 32.0 MB 3: Apple_HFS iPod 18.6 GB
identifier disk0 disk0s1 disk0s3 disk0s5 disk0s7 identifier disk1 disk1s1 disk1s2 disk1s3
% sudo pdisk /dev/disk0 -dump | tee /Volumes/iPod/Backup/pdisk.txt Partition map (with 512 #: type 1: Apple_partition_map 2: Apple_Free 3: Apple_HFS 4: Apple_Free 5: Apple_HFS 6: Apple_Free 7: Apple_HFS 8: Apple_Free
byte blocks) on '/dev/disk0' name length Apple 63 262144 Apple_HFS_Untitled_1 16515072 262144 Apple_HFS_Untitled_2 16515072 262144 Apple_HFS_Untitled_3 5253424 16
@ @ @ @ @ @ @ @
Device block size=512, Number of Blocks=39070080 (18.6G) DeviceType=0x0, DeviceId=0x0 % mount -t hfs | tee /Volumes/iPod/Backup/mount.txt /dev/disk0s3 on / (local, journaled) /dev/disk0s5 on /Volumes/Mac OS X Alt (local, journaled) /dev/disk0s7 on /Volumes/Local (local, journaled) /dev/disk1s3 on /Volumes/iPod (local, nodev, nosuid)
410
|
Rozdz ał 14. Przywracan e od podstaw komputera z systemem Mac OS X
base 1 64 262208 16777280 17039424 33554496 33816640 39070064
( size ) (128.0M) ( 7.9G) (128.0M) ( 7.9G) (128.0M) ( 2.5G)
Jeśli korzysta się z komputera Mac z procesorem Intela, nie będzie dostępny program pdisk, a narzędzie fdisk nie wygeneruje raportu dotyczącego dysku, z którego je uruchomiono. A zatem trzeba zrobić coś jeszcze. Można skorzystać z wyniku programu diskutil, lecz nie będzie tak dokładny. Inną opcją jest załadowanie systemu z nośnika instalacyjnego i uaktywnienie terminala, a następnie uruchomienie programu fdisk i zapisanie wyników w pliku na napędzie archiwizacyjnym.
Wykonując polecenie nvram, należy zapisać zmienne oprogramowania sprzętowego Open Firmware. % sudo nvram -p > /Volumes/iPod/Backup/nvram.txt
Jak już wspomniano, na tym etapie można również zapamiętać informacje uzyskane z narzędzia System Profiler. Pora zarchiwizować dane. Aby uniknąć niespójności systemów plików systemu w stanie spoczynku, należy sporządzić kopię zapasową dla każdej partycji głównego dysku. % % % % % %
cd "/Volumes/Mac OS X" sudo ditto -c -k -rsrc -X . "/Volumes/iPod/Backup/Mac OS X.zip" cd "/Volumes/Mac OS X Alt" sudo ditto -c -k -rsrc -X . "/Volumes/iPod/Backup/Mac OS X Alt.zip" cd "/Volumes/Local" sudo ditto -c -k -rsrc -X . "/Volumes/iPod/Backup/Local.zip"
Powyższe polecenia tworzą archiwum ZIP dla każdej archiwizowanej partycji. Wszystkie zasoby rozwidleń i pliki metadanych są uwzględniane w plikach archiwów. Jeśli naprawdę zamierza się zastosować program tar w przypadku wersji 10.4 lub nowszej systemu Mac OS X, w miejsce polecenia ditto należy wstawić tar. Oto przykład: % sudo tar clpzf /Volumes/iPod/Backup/partycja.tgz .
Można również na napędzie archiwizującym umieścić kopię katalogu /usr/bin/gzip. W czasie przywracania do ścieżki poleceń należy dodać katalog zawierający kopię programu gzip. # export PATH=${PATH}:/Volumes/iPod/Backup
Poniższe polecenia odtwarzają dane. # cd /Volumes/partycja # tar xpzf /Volumes/iPod/Backup/partycja.tgz
Po odłączeniu dysku archiwizującego należy umieścić go w bezpiecznym miejscu (jeśli używa się udziału NFS, trzeba będzie go tylko odłączyć).
Przywracanie systemu Załóżmy, że główny dysk komputera z systemem Mac OS X przestał działać. Jeśli postępowano zgodnie z wcześniej omówioną procedurą, proces przywracania nie powinien być problemem. Najpierw należy włączyć komputer, a następnie trzymać wciśnięty klawisz Option do momentu pojawienia się graficznej listy urządzeń rozruchowych. Gdy to nastąpi, w napędzie należy umieścić instalacyjny dysk CD lub DVD systemu Mac OS X (pierwszy dysk w przypadku zestawu) i kliknąć przycisk reload, aby dysk został uwzględniony na liście urządzeń rozruchowych. Po wybraniu dysku instalacyjnego należy kontynuować ładowanie. Gdy ładowanie zostanie zakończone i wybierze się język, pojawi się ekran powitalny. Na górze ekranu widoczny Przykładowy proces przywracan a komputera od podstaw
|
411
będzie pasek menu. Z menu Utilities należy wybrać pozycję Terminal, aby uzyskać dostęp do wiersza poleceń. Pora podłączyć dysk archiwizujący. Podobnie jak w przypadku procedury archiwizowania program diskarbitrationd obsługuje podłączanie. Po wykonaniu tej operacji podłączone będą następujące urządzenia magazynujące: napęd optyczny z dyskiem instalacyjnym systemu Mac OS X podłączonym jako /, zewnętrzny dysk archiwizujący podłączony jako /Volumes/iPod i nowy wewnętrzny dysk twardy bez punktu podłączenia (jeśli z jakiegoś powodu podłączono partycje tego dysku, należy je odłączyć za pomocą polecenia diskutil unmountDisk disk0). Alternatywą dla napędu USB lub FireWire, takiego jak iPod, jest zastosowanie udziału NFS. Oprócz serwera NFS będzie wymagany adres IP. Jeśli dostępny jest serwer DHCP, adres IP uzyska się automatycznie. W przeciwnym razie adres IP trzeba będzie ręcznie ustawić, wykonując następujące polecenie: # ifconfig en0 adres_IP netmask maska_sieci broadcast adres_rozgłaszania
Następnie trzeba podłączyć udział NFS. Zakładając, że serwer NFS ma adres IP 192.168.0.1 i katalog udziału nosi nazwę /kopie_zapasowe, polecenie podłączające będzie wyglądać tak: # mkdir /var/tmp/kopie_zapasowe # mount -t nfs 192.168.0.1:/kopie_zapasowe /var/tmp/kopie_zapasowe
W efekcie będzie możliwe uzyskanie dostępu do kopii zapasowych udziału /kopie_ ¦zapasowe. Należy pamiętać o odłączeniu udziału po odtworzeniu z niego danych.
Aby dokonać partycjonowania nowego dysku, należy przejrzeć pliki /Volumes/iPod/Backup/ ¦diskutil.txt i /Volumes/iPod/Backup/pdisk.txt. Wynik polecenia diskutil zawiera nazwy partycji. W celu określenia wielkości każdej partycji, korzystając z wyniku narzędzia pdisk, rozmiar partycji należy dodać do rozmiaru wolnego obszaru wyszczególnionego wcześniej. Uzyskaną sumę należy podzielić przez dwa, aby 512-bajtowe bloki wyrazić w kilobajtach. Przykładowo wielkość pierwszych dwóch partycji wynosi (16515072+262144)/2 = 8388608, a rozmiar ostatniej partycji jest równy (5253424+262144)/2 = 2757784. Tego typu obliczenia są wykonywane, ponieważ wyrażanie rozmiarów w gigabajtach (jak w wyniku polecenia diskutil) zwykle powoduje, że wielkość partycji jest nieznacznie większa lub mniejsza od oczekiwanej. Jeśli jednak przywraca się system komputera Mac z procesorem Intela, wynik programu diskutil może być jedyną dostępną informacją.
W celu przeprowadzenia partycjonowania dysku należy zastosować program diskutil. # diskutil partitionDisk disk0 3 JournaledHFS+ "Mac OS X" 8388608K \ JournaledHFS+ "Mac OS X Alt" 8388608K JournaledHFS+ Local 2757784K Started partitioning on disk disk0 Creating Partition Map Formatting Disk 5% .. Formatting Disk 32% .. Formatting Disk 54% .. Formatting Disk 100% .. /dev/disk0 #: type name size identifier 0: Apple_partition_scheme *18.6 GB disk0 1: Apple_partition_map 31.5 KB disk0s1 2: Apple_HFS Mac OS X 7.9 GB disk0s3 3: Apple_HFS Mac OS X Alt 7.9 GB disk0s5 4: Apple_HFS Local 2.5 GB disk0s7
412
|
Rozdz ał 14. Przywracan e od podstaw komputera z systemem Mac OS X
W dokumentacji polecenia diskutil można znaleźć więcej szczegółów na temat jego składni i opcji. Warto zauważyć, że jeśli na komputerze uaktywni się tryb Classic zgodny z systemem Mac OS 9, za argumentem określającym liczbę partycji powinno się wstawić parametr OS9Drivers. Jeżeli w pliku diskutil.txt znajduje się kilka dodatkowych partycji Apple_Driver, oznacza to, że na starym dysku zainstalowano sterowniki systemu Mac OS 9. Po utworzeniu na dysku nowych partycji zostaną one automatycznie podłączone. Można przejść do odtworzenia zawartości systemów plików. W razie potrzeby można też zresetować zmienne oprogramowania sprzętowego Open Firmware. # # # #
ditto ditto ditto nvram
-x -x -x -f
-k -rsrc "/Volumes/iPod/Backup/Mac OS X.zip" "/Volumes/Mac OS X" -k -rsrc "/Volumes/iPod/Backup/Mac OS X Alt.zip" "/Volumes/Mac OS X Alt" -k -rsrc /Volumes/iPod/Backup/Local.zip /Volumes/Local /Volumes/iPod/Backup/nvram.txt
Ostatnim krokiem procesu przywracania jest przygotowanie nowego dysku do ładowania. Poniższe polecenie bless umieszcza w bloku MDB (Master Directory Disk) dysku identyfikator wyznaczonego katalogu (identyfikator systemu plików HFS+ analogiczny do numeru i-węzła systemu plików UFS). Ponadto polecenie to tak ustawia zmienną bootdevice oprogramowania sprzętowego Open Firmware, żeby przy następnym uruchomieniu komputera system został załadowany z nowego dysku. # bless -folder "/Volumes/Mac OS X/System/Library/CoreServices" -setBoot
W czasie uruchamiania system poszuka w katalogu polecenia bless pliku typu tbxi i znajdzie plik BootX zawierający kod programu ładowania początkowego, umożliwiającego rozpoczęcie procesu inicjalizacji jądra. Jeśli zainstalowano pakiet Developer Tools, wykonując poniższe polecenie, można sprawdzić, czy na komputerze znajduje się tego typu plik. % /Developer/Tools/GetFileInfo \ /System/Library/CoreServices/BootX
Jeżeli komputer ma oferować obsługę systemu Mac OS 9, trzeba wykonać następujące polecenie: # bless -folder "/Volumes/Mac OS X/System/Library/CoreServices" -setBoot \ -folder9 "/Volumes/Mac OS 9/System Folder" \ -bootBlockFile /usr/share/misc/bootblockdata
Więcej informacji można znaleźć w dokumentacji polecenia bless. Na końcu należy ponownie uruchomić system i wrócić do pracy (ewentualnie zabawy). Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Przykładowy proces przywracan a komputera od podstaw
|
413
414
|
Rozdz ał 14. Przywracan e od podstaw komputera z systemem Mac OS X
CZĘŚĆ V
Archiwizowanie baz danych
Część V składa się z następujących ośmiu rozdziałów: Rozdział 15. „Archiwizowanie baz danych” W rozdziale dokonano przeglądu problematyki archiwizowania baz danych, a także omówiono związane z nimi pojęcia, terminy i procedury. Rozdział 16. „Archiwizowanie i odtwarzanie bazy danych Oracle” W rozdziale wyjaśniono, jak za pomocą narzędzia rman sporządzać „gorące” kopie zapasowe bazy Oracle lub kopie zarządzane przez użytkownika. Rozdział 17. „Archiwizowanie i odtwarzanie bazy danych Sybase” W rozdziale pokazano, w jaki sposób przy użyciu serwera Backup Server zarchiwizować bazę Sybase ASE. Rozdział 18. „Archiwizowanie i odtwarzanie bazy danych IBM DB2” W rozdziale omówiono archiwizowanie i przywracanie baz danych DB2. Rozdział 19. „SQL Server” W rozdziale wyjaśniono, jak archiwizować i odtwarzać bazy danych SQL Server. Rozdział 20. „Exchange” W rozdziale przedstawiono archiwizowanie i przywracanie baz danych Exchange za pomocą jego wbudowanego dodatku ntbackup. Rozdział 21. „PostgreSQL” W rozdziale objaśniono archiwizowanie i odtwarzanie baz danych PostgreSQL. Rozdział 22. „MySQL” W rozdziale dokonano przeglądu różnych opcji archiwizowania i przywracania dostępnych w przypadku serwera MySQL.
ROZDZIAŁ 15.
Archiwizowanie baz danych
Regularne sporządzanie kopii zapasowych baz danych jest obecnie jednym z najtrudniejszych zadań administratora systemu. Główny powód jest taki, że bazy danych są nieporównanie większe i bardziej złożone niż proste systemy plików. Aby poprawnie zarchiwizować bazę danych, trzeba najpierw spełnić następujące warunki: • zrozumienie wewnętrznej struktury używanej bazy danych, • zapoznanie się z dostępnymi narzędziami, • osiągnięcie znakomitego poziomu współpracy administratorów systemów, magazynów
danych i baz danych. Gdy powyższe wymagania zostaną spełnione, konieczne będzie wybranie jednego spośród następujących wariantów: • wyłączenie bazy danych i archiwizowanie jej plików w trybie offline („zimne” kopie zapa-
sowe); • przełączenie bazy danych w tryb umożliwiający zarchiwizowanie jej plików w czasie
pracy bazy („gorące” kopie zapasowe); • zastosowanie wbudowanego narzędzia bazy danych w celu zarchiwizowania jej zawartości
na dysku lub taśmie (bez wymogu używania komercyjnego oprogramowania);
• nabycie agenta komercyjnego narzędzia, który zarchiwizuje bazę danych na wykorzy-
stywanych przez nią urządzeniach. Prawie każdy, kto przeczyta tę listę, co najmniej jeden z punktów uzna za przerażający. Wiele osób na co dzień zajmuje się bazami danych działającymi 24 godziny na dobę i siedem dni w tygodniu. Nie mogą po prostu pozwolić sobie na wyłączenie na kilka godzin baz danych w celu ich archiwizacji. Jeśli nawet byłoby to możliwe, gdy baza danych używa niesformatowanych urządzeń, nie można jej zarchiwizować za pomocą narzędzia obsługującego systemy plików. Oczywiście, w tym celu można skorzystać z uniksowego programu dd, ale oznaczałoby to wykonywanie jednego zadania dla systemów plików, innego dla baz danych. Często w książce podkreśla się, że inne jest złe. Każdy specjalny przypadek wiąże się z ryzykiem niepowodzenia. Pojawia się coś jeszcze, co trzeba zaprogramować, coś jeszcze, co trzeba monitorować, i coś jeszcze, co może zawieść. W efekcie tworzenie kopii zapasowych bazy danych nie jest proste.
417
Część problemu tkwi w procesie projektowania mechanizmu samej bazy danych. Z upływem czasu zapotrzebowanie na większe magazyny danych i szybsze wykonywanie zapytań sprawiło, że w projekcie bazy danych trzeba było zapewnić znacznie więcej niż tylko możliwość archiwizowania bazy we własnym zakresie. W ciągu kilku ostatnich lat pojemność baz danych z gigabajta zwiększyła się do kilku terabajtów. Taki wzrost rozmiaru baz i ich wydajności nastąpił, ponieważ takie wymagania stawiały ogromne bazy klientów. Niestety, w parze z tym nie szło żądanie udostępnienia narzędzia, które obsługiwałoby takie olbrzymie bazy danych.
Czy to może być zrobione? Niech Czytelnik z ogólnej perspektywy spojrzy na archiwizowanie baz danych i porówna je z tworzeniem kopii zapasowych systemów plików. Obecnie na rynku jest dostępnych kilka dobrych narzędzi archiwizujących. Dlaczego po prostu nie ma tak wielu programów archiwizujących bazy danych? Bez wątpienia jest na nie zapotrzebowanie. Jednym z powodów jest złożoność zadania, jakim jest stworzenie produktu archiwizującego bazy danych. Aby wprowadzić do sprzedaży taki produkt, firma musi rozważyć kilka kwestii: Wiele ruchomych celów W jaki sposób spowodować, że baza danych pozostanie w bezruchu? Czy kiedykolwiek próbowało się wykonać zdjęcie 100 osób? Projektowanie narzędzia archiwizującego dla bazy danych jest bardzo trudne, ponieważ w danej chwili trzeba zrobić „zdjęcie” setek plików. Wewnętrzne powiązania między plikami Dla programu tworzącego kopie zapasowe bazy danych muszą być zrozumiałe wszystkie jej elementy i sposób, w jaki są ze sobą powiązane. Konieczność współpracy z mechanizmem bazodanowym Jest to kluczowa sprawa. Jeśli baza danych wie, że zainicjowano archiwizację, może być pomocna. Gdy nie będzie się współpracować z bazą danych, wyniki archiwizacji będą nieprzewidywalne. Skala zadania W jaki sposób w ciągu godziny na napędzie archiwizującym zapisać ponad terabajt danych? Właśnie takie są niektóre wymagania związane z archiwizowaniem danych! Możliwość przywrócenia a koszt Choć wszystkie powyższe warunki są niezbędne, nie trzeba obciążać domu hipoteką, aby je spełnić. Różne poziomy automatyzacji Klienci oczekują różnych poziomów automatyzacji. Część chce, aby wszystko było zarządzane przez bibliotekę, część wolałaby raczej mieć możliwość wykonania operacji samemu. Czy przy tego typu wymaganiach jest jakakolwiek nadzieja na uzyskanie narzędzi, które podołają wyzwaniu? Odpowiedź jest twierdząca! Producenci baz danych wreszcie zdali sobie sprawę z tego, że narzędzia bazodanowe mają wpływ na ogólną sprzedaż serwerów baz danych. W końcu zaczęli projektować dobre programy, które współpracują z innymi komercyjnymi produktami archiwizującymi. Dostawcy nawet aktywnie zadbali o to, żeby klienci korzystali z narzędzia, które działa poprawnie zarówno w przypadku archiwizowania, jak i odtwarzania danych. Choć obecnie istnieją porządne narzędzia archiwizujące, pojawia się następny problem, zamieszanie. 418
|
Rozdz ał 15. Arch w zowan e baz danych
Zamieszanie — tajemnice architektury baz danych Każdy administrator systemu, jakkolwiek długo pracuje w zawodzie, prawdopodobnie może powiedzieć, jak zarchiwizować katalogi domowe znajdujące się na dowolnym komputerze. Gdy jednak pojawią się pytania dotyczące tworzenia kopii zapasowej bazy danych, nawet bardziej doświadczeni administratorzy mogą zaniemówić. Dla wielu administratorów architektura bazy danych jest tajemnicą. Niestety, naprawdę trzeba zrozumieć zasady funkcjonowania bazy danych, aby poprawnie przywrócić ją po wystąpieniu jakiegoś nieszczęśliwego zdarzenia. Administratorzy wiedzą, jak zarchiwizować system plików. Jeśli jednak poprosi się ich o znalezienie kopii zapasowych obszaru danych A bazy danych B wchodzącej w skład instancji C, w ich oczach może pojawić się strach! Może to wynikać z zupełnego braku doświadczenia administratorów w projektowaniu baz danych lub braku czasu, aby je zdobyć. Jeżeli administratorzy zarządzają heterogenicznym środowiskiem z więcej niż jedną bazą danych, wszystko może im się skomplikować jeszcze bardziej. Jedyną nadzieją jest to, że administratorzy baz danych wiedzą, co robią. Takie osoby wiedzą wszystko na temat budowy baz danych. Potrafią archiwizować zawartość bazy na dysku lub być może niezależnym napędzie archiwizującym. Mogą nie mieć żadnego doświadczenia z komercyjnym oprogramowaniem archiwizującym lub dużymi zautomatyzowanymi bibliotekami. Jeśli baza jest zbyt duża, aby ją zarchiwizować na dysku, i nie jest dostępny odpowiedni niezależny napęd archiwizujący, w celu utworzenia kopii zapasowych administratorzy baz danych muszą współpracować z administratorami systemów. Jedyny problem polega na tym, że administratorzy baz danych nie posługują się takimi samymi terminami co administratorzy systemów, ponieważ dla tych drugich nie jest zrozumiała architektura baz. Produkty bazodanowe różnią się między sobą. Warto spróbować ustalić, co dla administratorów baz danych Informix i Oracle jest obszarem tabel! Jednym z powodów trudności uzyskania jednoznacznej odpowiedzi jest to, że różne produkty używają identycznego terminu dla odmiennych logicznych elementów. To, co Informix nazywa obszarem tabel, Oracle określa mianem segmentu. Jednak nie należy tej definicji segmentu mylić z segmentem bazy danych Sybase (w tym przypadku znaczenie segmentu jest bliższe temu, co Oracle nazywa obszarem tabel). Czy dla Czytelnika nadal jest to niejasne? Nie ma powodu do obaw.
Niech wszystko stanie się jasne — bazy danych objaśnione prostym językiem W tym rozdziale omówiono wszystkie podstawowe informacje niezbędne do tego, aby rozszerzyć swoją wiedzę na temat archiwizowania i przywracania baz danych. Czytelnik zostanie przygotowany do lektury następnych rozdziałów książki, poświęconych konkretnym bazom danych, a także dowolnego fragmentu ulubionej książki lub dokumentacji przeznaczonej dla administratora baz danych. W niniejszym rozdziale przyjęto, że Czytelnik nie ma żadnej wiedzy, i najpierw przedstawiono kilka bardzo podstawowych elementów, takich jak tabele i wiersze. W związku z tym wszystko będzie zrozumiałe nawet dla osoby o najmniejszym stażu. Jednak nie oznacza to, że rozdziału nie powinien czytać doświadczony administrator systemów lub baz danych. Ponieważ informacje zamieszczone w rozdziałach zostały dostarczone przez kilku
N ech wszystko stan e s ę jasne — bazy danych objaśn one prostym język em
|
419
doświadczonych administratorów różnego typu baz danych, niemal każdy administrator powinien dowiedzieć się z rozdziału czegoś nowego. W rozdziale znajdują się przydatne tabele, które wyszczególniają wszystkie elementy mechanizmu magazynowania dla każdej spośród kilku baz danych: DB2, Informix1, MySQL, Oracle, PostgreSQL, SQL Server i Sybase. Jeśli Czytelnik nie jest administratorem baz danych, zamieszczone tu informacje pozwolą mu na sprawne przedyskutowanie kwestii dotyczących archiwizowania z osobą odpowiedzialną za bazy danych. Jeżeli Czytelnik administruje jednym produktem bazodanowym, rozdział będzie pomocny w bezproblemowym omówieniu strategii archiwizowania i magazynowania danych z administratorami innych produktów bazodanowych! Dla organizacji pożądana jest możliwość ustalenia przez administratora wszystkiego, co ma związek z powodami i metodami ochrony danych. Jaki piękny byłby taki świat!
Na czym polega cały problem? Dlaczego tworzenie kopii zapasowych baz danych jest takie trudne? Czy nie można po prostu zamknąć bazy danych i zarchiwizować zawartości całego komputera? Takie pytania mogą przyjść na myśl Czytelnikowi. Jeśli już zna odpowiedzi na nie, może od razu przejść do następnego podrozdziału. Dlaczego tak wiele słyszy się o archiwizowaniu baz danych? W ciągu kilku ostatnich lat w sposób wykładniczy wzrosło zapotrzebowanie na systemy zarządzania relacyjnymi bazami danych RDBMS (Relational Database Management System). Nie tylko jest więcej baz danych, ale też są one szybsze, większe i znacznie bardziej złożone niż kiedykolwiek. Wzrasta liczba firm, które do przechowywania swoich danych (gdyby przepadły, nie mogłyby zostać zastąpione) używają coraz pojemniejszych baz. Klienci zaczęli zdawać sobie sprawę z ważności zabezpieczania danych. W efekcie pojawiło się zwiększone zapotrzebowanie na lepsze narzędzia archiwizujące i przywracające. Producenci baz danych i aplikacji bazodanowych w końcu udostępnili narzędzia, które spełniają oczekiwania. Dlaczego archiwizowanie baz danych jest takie złożone? W rzeczywistości tworzenie kopii zapasowych baz danych nie jest takie trudne. To operacja odtwarzania bazy wiele osób doprowadziła do obłędu! Jednak mówiąc poważnie, powodem tego, że archiwizowanie bazy jest takie skomplikowane, jest to, że niezbędni są dobrzy administratorzy bazy i systemu, którzy opracują odpowiedni plan archiwizacji. Większość osób zna się dobrze tylko na systemach lub bazach danych. Jeśli Czytelnik lub znane mu osoby opanowali oba zagadnienia, można mówić o szczęściu. W niektórych firmach trudne jest uzyskanie sytuacji, w której administratorzy systemów i baz danych bez problemów ze sobą współpracują. Czy można po prostu wyłączyć bazę danych i zarchiwizować zawartość całego komputera? W określonych sytuacjach jest to możliwe. Istnieje kilka czynników, które mogą to uniemożliwić, na przykład używana platforma bazodanowa, stosowanie urządzeń z systemem plików lub bez niego, konieczność przywracania do stanu z wybranej chwili, nie wspominając o utracie dostępności bazy podczas operacji archiwizowania. Więcej szczegółów zamieszczono w odpowiednich rozdziałach książki. 1
W książce Unix Backup & Recovery znajduje się rozdział poświęcony bazie danych Informix. Choć z braku miejsca rozdział ten nie trafił do tej książki, w dalszym ciągu jest dostępny pod adresem http://www.backupcentral.com.
420 |
Rozdz ał 15. Arch w zowan e baz danych
Czy trzeba nabyć komercyjne narzędzie, aby zarchiwizować używaną bazę danych? Jeśli bazę danych można zarchiwizować na dysku bądź sporządzić „zimną” lub „gorącą” kopię zapasową za pomocą standardowego narzędzia archiwizującego, odpowiedź na pytanie jest przecząca. Jeżeli nie można wykonać takich czynności, prawdopodobnie konieczne będzie kupienie komercyjnego oprogramowania.
Struktura bazy danych Podczas omawiania systemów RDBMS pojawia się wiele terminów. Dobrą wiadomością jest to, że nie trzeba ich wszystkich znać, żeby poprawnie archiwizować i przywracać bazy danych. Jednak konieczna jest znajomość części pojęć, czyli około 20. Warto znać następujące rzeczy: • wszystkie różne elementy magazynowania danych i ich nazwy, • logiczną strukturę tych elementów w obrębie systemu RDBMS, • dostępne ułatwienia związane z ochroną i archiwizowaniem danych.
Informacje takie mogą być złożone, ponieważ w znacznej mierze są zależne od sposobu spojrzenia na dane. W rozdziale najpierw dane te zostaną zaprezentowane z perspektywy zaawansowanego użytkownika, a następnie administratora baz danych. Zanim zdefiniuje się różne elementy bazy danych, być może trzeba będzie się trochę natrudzić!
A co z serwerem Exchange? W rozdziale 20. omówiono serwer Exchange, który wśród baz danych jest jednak pewnego rodzaju odmieńcem. Choć w gruncie rzeczy Exchange jest relacyjną bazą danych, Microsoft naprawdę dobrze się stara, aby ukryć to przed administratorami i użytkownikami. W efekcie rozmawiając na temat serwera Exchange, nie posługują się żadnymi terminami bazodanowymi. Choć w niniejszym rozdziale w miarę możliwości serwer Exchange jest omawiany, to nie w takim stopniu jak inne produkty.
Punkt widzenia zaawansowanego użytkownika — logiczne elementy bazy danych Zanim przyjrzymy się metodom przechowywania baz danych na dysku, Czytelnik powinien się dowiedzieć, jak bazę postrzega zaawansowany użytkownik. Jest to konieczne, ponieważ części terminów używa się podczas definiowania elementów magazynowania danych. Posłużyliśmy się określeniem „punkt widzenia zaawansowanego użytkownika” ze względu na to, że wielu użytkowników ma niewielką lub żadną znajomość tych terminów. Jeśli jednak takie osoby nie postanowią wykonać zadania administratora baz danych polegającego na zaprojektowaniu bazy, terminy te mogą być wszystkim, co będzie im w ogóle potrzebne. Pojęcia przedstawiono bez żadnego szczególnego uporządkowania, ponieważ bardzo trudno zdefiniować jeden termin bez sięgnięcia po inny. W związku z tym w przypadku części Czytelników pomocne może okazać się przeczytanie tego punktu więcej niż raz. Punkt widzenia zaawansowanego użytkownika można też nazwać logicznym, ponieważ wiele opisanych tu elementów nie występuje w fizycznej postaci. To jedna z wielu rzeczy, które system RDBMS odróżniają od prostej aplikacji arkusza kalkulacyjnego. Tego typu aplikacja ma jedną Struktura bazy danych
|
421
tabelę, znajdującą się w pojedynczym fizycznym pliku. Z kolei tabela systemu RDBMS sprawia wrażenie, że jej dane są zlokalizowane w jednym miejscu, lecz w rzeczywistości mogą być rozmieszczone w obrębie całego systemu.
Instancja DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
nstancja
Se we
nstancja
nstancja
nstancja
Klaste
nstancja
Se we
Instancja prawdopodobnie jest najtrudniejszym terminem do objaśnienia, ponieważ dla różnych osób (jak również producentów platform bazodanowych) znaczy co innego. Najprostsza definicja mówi, że instancja to jeden lub większa liczba procesów uruchomionych na jednym lub kilku komputerach, za pośrednictwem których bazy danych działające na komputerze (lub grupie komputerów) komunikują się ze wspólną pamięcią. W obrębie instancji może być wiele baz danych. Ponadto baza danych może korzystać z wielu instancji na tym samym komputerze lub niezależnych komputerach wchodzących w skład klastra. A zatem instancja i baza danych to dwa zupełnie odmienne pojęcia. Za terminem serwer (lub serwer danych) stosowanym w przypadku bazy danych Sybase stoi pierwotne zamierzenie, zgodnie z którym każdy komputer/serwer miał mieć jedną instancję/serwer Sybase (jednak obecnie dość typowa jest sytuacja, w której na każdym komputerze znajduje się więcej niż jedna instancja). Firma Informix sporadycznie definiuje termin w ten sposób, co może raczej wprowadzać zamieszanie. Firma ta ma w zwyczaju używać pojęcia serwer, mając na myśli oprogramowanie, a terminu instancja w przypadku działającego środowiska, zwłaszcza wtedy, gdy jest omawiane uruchamianie wielu egzemplarzy serwera. Jeśli z jakiegoś powodu trzeba wyłączyć instancję i ponownie uruchomić, w czasie trwania operacji zamykania nie będą dostępne wszystkie bazy danych znajdujące się w obrębie tej instancji. Może to być pomocne w zrozumieniu oryginalnej definicji, ponieważ wszystkie bazy instancji dysponują pojedynczym połączeniem ze wspólną pamięcią zapewnianą przez instancję. Jeżeli instancja jest wyłączona, połączenie to nie będzie dostępne (na rysunku 15.1 w graficzny sposób przedstawiono instancję).
Baza danych DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Baza danych
Baza danych
Baza danych
Baza danych
Baza danych
Baza danych
Baza danych
Baza danych
Baza danych jest zbiorem obiektów. Może to być bardzo prosta baza z jedną tabelą i bez żadnych indeksów, może też zawierać wiele tabel, indeksów i innych obiektów bazodanowych (wszystkie produkty bazodanowe mają więcej niż jeden obiekt i typ obiektu). Przykładowo w bazie danych może znajdować się tabela z adresami klientów i indeks powiązany z tą tabelą. W takiej bazie może również być tabela typu BLOB (Binary Large Object) przechowująca zeskanowany obraz kontraktu podpisanego z klientem, zwykła tabela zawierająca szczegóły tego kontraktu i indeks dla tej tabeli. Może też istnieć inna baza danych, rejestrująca wszystkie produkty sprzedawane przez firmę (na rysunku 15.1 w graficzny sposób przedstawiono bazę danych).
422 |
Rozdz ał 15. Arch w zowan e baz danych
Rysunek 15.1. Instancja bazy danych
Tabela DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Tabela
Nie dotyczy
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela grupuje powiązane ze sobą informacje (właśnie z tego powodu w oficjalnej terminologii bazodanowej tabelę określa się mianem relacji). Informacje zwykle są zestawiane w taki sposób, że dane nie powielają się w różnych tabelach (inaczej jest tylko w razie konieczności). W poprzednim przykładzie baza danych mogła zawierać tabelę z informacjami na temat klientów, z których każdy ma własne konto o unikatowym numerze. Tabela typu BLOB przechowująca kontrakt podpisany przez klienta musiałaby w takiej sytuacji magazynować jedynie numer konta, aby móc powiązać ze sobą dwa rodzaje informacji (dane typu BLOB omówiono w dalszej części rozdziału). Taka metoda spowoduje zajęcie mniejszej przestrzeni, niż gdyby wraz z kontraktem przechowywano imię i nazwisko klienta. W tabeli zamówień też znalazłby się numer konta. Używając tylko numeru produktu, tabela ta jest w stanie wygenerować listę tego, co klient zamówił. Aby móc uzyskać szczegóły dotyczące tego numeru produktu, posługując się tym numerem, instancja może odwołać się do bazy danych produktów (na rysunkach 15.2 i 15.3 w graficzny sposób przedstawiono tabelę). Struktura bazy danych
| 423
Rysunek 15.2. Struktura tabeli
Rysunek 15.3. Struktura obszaru tabel
424 |
Rozdz ał 15. Arch w zowan e baz danych
Powiązanym terminem jest widok, który zwykle odnosi się do wirtualnej tabeli. Przykładowo można utworzyć widok, który w celu przedstawienia zestawienia informacji na temat wybranego klienta odwołuje się do tabel: klientów, zamówień i produktów. Dane często są replikowane w wielu widokach. Jednak ze względu na to, że są to wirtualne tabele, nie zajmują na dysku dodatkowej przestrzeni. Widok standardowo jest generowany dynamicznie na podstawie wyników instrukcji SELECT.
Indeks DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
ndeks
Nie dotyczy
ndeks
ndeks
ndeks
ndeks
ndeks
ndeks
Indeks jest specjalnym obiektem umożliwiającym szybsze przeszukiwanie zwykłej tabeli. Tabela jest indeksowana za pomocą wartości, która zostałaby użyta do przeszukania rekordu (wiersza). Przykładowo baza danych klientów może być indeksowana przy użyciu nazwiska, jeśli klienci często dzwonią i nie znają numeru swojego konta. Z indeksem jest związana unikatowa możliwość pojawiająca się podczas przywracania bazy danych. Polega ona na tym, że zamiast przywracać indeks, zwykle można go odbudować na podstawie istniejącej tabeli.
Duże obiekty DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
BLOB CLOB i DBCLOB
Wiadomości pocztowe
Obsza BLOB
Typy danych
BLOB CLOB i BFILE
ByteA BLOB i tekst
Typy danych
Typy danych znakowy i image
*blob i *text
ntext text i image
Duże obiekty danych zyskały na popularności w ciągu kilku ostatnich lat. Obiekt taki odnosi się do wszystkiego, co nie mieści się w zwykłej tabeli. Może to być zarówno duża porcja danych tekstowych, jak i zeskanowany obraz. Większość baz danych rozróżnia duży obiekt znakowy (tekst) i binarny (grafika i tym podobne). Jeśli duży obiekt danych jest przechowywany w bazie, nie ma żadnych specjalnych wymagań dotyczących archiwizowania. Jednak użycie typów danych umożliwiających magazynowanie takich obiektów poza bazą (czyli w obrębie systemu plików) to już inna sprawa. Choć takie typy danych mogą na wiele sposobów poprawić wydajność, stawiają wyjątkowe wymagania związane z archiwizowaniem. Dane obiektu BLOB muszą być synchronicznie archiwizowane z zawartością bazy danych, ponieważ rejestruje ona lokalizację poszczególnych plików. Przyjmijmy, że dane obiektu BLOB dodano o godzinie 11. Jeżeli system plików zarchiwizowano o 10, a dla bazy danych kopię zapasową sporządzi się o 12, baza będzie wiedziała o istnieniu nowego pliku w systemie plików. Jednak plik ten nie będzie obecny w kopii zapasowej systemu plików. Całość skomplikuje się jeszcze bardziej, gdy czas archiwizowania systemu plików pokryje się z porą tworzenia kopii zapasowej bazy danych. Inaczej mówiąc, archiwizacja systemu plików rozpocznie się o 10, a zakończy o 16, z kolei proces tworzenia kopii zapasowej bazy danych zacznie się o 12 i zakończy o 14 (choć baza danych PostgreSQL pozwala na zapisywanie dużych obiektów danych w systemie plików, domyślnie będą one archiwizowane w następnych wersjach serwera PostgreSQL).
Struktura bazy danych
| 425
Istnieją tylko dwie metody poradzenia sobie z zaistniałym konfliktem. Najprostsza polega na wyłączeniu bazy danych lub przełączeniu jej w tryb tylko do odczytu w czasie trwania archiwizacji systemu plików. W przypadku wielu środowisk może to być niepraktyczne. Druga metoda, wykorzystująca pojęcie migawki, umożliwia wykonanie w zaledwie kilka sekund obrazu (migawki) całego systemu plików. Taki obraz jest następnie w nocy archiwizowany. W ten sposób zapewnia się spójny obraz systemu plików z określonej chwili. Microsoft w rzeczywistości nie mówi wiele o tym, że wiadomości pocztowe są dużymi obiektami danych. Jeśli jednak przez chwilę się nad tym zastanowić, okaże się, że wiadomości są właśnie takimi obiektami. Wiadomość pocztowa może zawierać zarówno prosty wiersz tekstu, jak i ogromny załącznik. Wszystkie te dane są przechowywane w bazie serwera Exchange. A zatem z punktu widzenia baz danych wiadomości takie muszą być traktowane jak duże obiekty danych.
Obiekt DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Obiekt
Nie dotyczy
Obiekt
Obiekt
Obiekt
Obiekt
Obiekt
Obiekt
Ogólny termin obiekt odnosi się do dowolnego elementu zarządzanego przez bazę danych. Można wyróżnić kilka typów obiektów, takich jak tabele proste i złożone (BLOB), indeksy, procedury przechowywane, funkcje, pakiety, synonimy i wyzwalacze.
Wiersz DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
K otka
Nie dotyczy
K otka
K otka
K otka
K otka
Wie sz
K otka
Wiersz (w oficjalnej terminologii bazodanowej stosuje się określenie krotka) jest zbiorem powiązanych ze sobą atrybutów. Przykładowo może istnieć wiersz zawierający wszystkie podstawowe informacje na temat klienta, takie jak jego imię, adres, numer konta i telefonu (przypomina to wiersz arkusza kalkulacyjnego). Każdy wiersz zwykle ma przynajmniej jeden unikatowy atrybut (na przykład numer konta), za pomocą którego jest odróżniany od innych wierszy. Wiersz czasami nazywa się rekordem (na rysunku 15.2 w graficzny sposób przedstawiono wiersz).
Atrybut DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
At ybut
Nie dotyczy
At ybut
At ybut
At ybut
At ybut
At ybut
At ybut
Atrybut jest podstawowym elementem danych znajdujących się w tabeli (na rysunku 15.2 w graficzny sposób przedstawiono atrybut). Atrybut jest pojedynczą wartością, taką jak imię lub kod pocztowy klienta. Atrybut może być bardzo mały (kod pocztowy) lub bardzo duży (obiekt BLOB). Atrybut jest wartością, którą użytkownik bazy danych zmienia podczas realizowania transakcji. Transakcje omówiono w dalszej części rozdziału.
426 |
Rozdz ał 15. Arch w zowan e baz danych
Punkt widzenia administratora baz danych — fizyczne elementy środowiska bazodanowego Administrator baz danych musi wiedzieć trochę więcej na ich temat niż nawet najbardziej zaawansowany użytkownik. Wynika to stąd, że taki administrator odpowiada za tworzenie baz danych, dostrajanie ich, archiwizowanie i przywracanie po wystąpieniu awarii. Administratorzy baz danych muszą również znać wybraną odmianę języka programowania SQL, który umożliwia konstruowanie precyzyjnych typów zapytań zwiększających przydatność bazy danych. Dobrzy administratorzy muszą też coś wiedzieć na temat systemów operacyjnych, aby móc efektywnie korzystać z technologii magazynowania danych obecnych w zarządzanym środowisku. Dobra wiadomość jest taka, że jeśli Czytelnik nie jest administratorem baz danych, nie musi wiedzieć tego wszystkiego, żeby poprawnie archiwizować i przywracać bazy. W tym punkcie omówiono fizyczne elementy systemu bazodanowego, a także wyjaśniono, w jaki sposób są one powiązane z wcześniej przedstawionymi logicznymi elementami. Zła wiadomość jest taka, że w przeciwieństwie do terminów dotyczących użytkownika bazy danych fizyczne elementy bazy danych są nazywane w różny sposób w przypadku prawie każdego produktu. Często ten sam termin użyty w poprzednim punkcie jest stosowany do identyfikacji odmiennego typu elementów różnych produktów. Możliwość omówienia ich wszystkich w jednym rozdziale wymagała sporego nakładu pracy. Często bardzo trudne było znalezienie ogólnego terminu, który pasowałby w przypadku wszystkich produktów i nie powodował zamieszania. A zatem terminy pełniące rolę nagłówków poniższych podpunktów często są słowami wymyślonymi tylko w tym konkretnym celu. Takie ogólne terminy są używane w niniejszym rozdziale podczas omawiania różnego typu elementów magazynowania danych i sposobu ich powiązania. Pojęcia specyficzne dla poszczególnych produktów są stosowane tylko w przypadku odwoływania się do nich. Część z poniższych terminów może być przydatna tylko w dyskusji z kimś, kto przeczytał ten rozdział. Jeśli na temat elementów magazynowania danych Czytelnik będzie rozmawiać z administratorem baz danych, który nie czytał niniejszego rozdziału, będzie musiał posłużyć się odpowiednimi terminami dotyczącymi konkretnego produktu i znanymi tej osobie.
Strona DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
St ona
St ona
St ona
St ona
Blok
St ona
St ona
St ona
Strona, nazywana też blokiem, jest podstawowym elementem tworzącym każdą bazę danych. Jest to najmniejsza ilość danych przenoszonych w ramach operacji wejścia-wyjścia. Choć nie do końca, strona przypomina blok systemu plików (blok o rozmiarze 2 kB może znajdować się w obrębie bazy, która korzysta z systemu plików z blokiem o wielkości 8 kB2). Rozmiar
2
Właśnie z tego powodu zamiast bloku stosowanego przez firmę Oracle wolę posługiwać się terminem „strona”. Ułatwia mi to odróżnienie bloków systemów plików od bloków lub stron baz danych. Widziałem, jak admiStruktura bazy danych
|
427
stron zawiera się w przedziale od 2 do 32 kB. Jednak niektóre produkty bazodanowe dają możliwość ustawienia w przypadku zarządzanego środowiska niestandardowego rozmiaru strony. Niezależnie od wielkości strony jest to najmniejsza jednolita jednostka bazy danych. Modyfikując tabelę bazy danych, wprowadza się zmiany w jednej lub większej liczbie stron przechowywanych gdzieś na dysku (na rysunkach 15.2 i 15.3 w graficzny sposób przedstawiono stronę).
Plik danych DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Kontene
Plik danych
Po cja
Plik danych
Plik danych
Plik danych
Plik danych
U ządzenie
Plik danych jest miejscem, w którym są przechowywane dane. Może to być niesformatowane urządzenie (/dev/hda1 w przypadku systemu Linux) lub plik systemu plików (/oracle/data/dbs01.dbf lub c:\database\plik.dbf). Część produktów wymaga użycia niesformatowanych partycji, część jedynie coś takiego sugeruje. Niektóre produkty pozwalają na jednoczesne zastosowanie niesformatowanych partycji i plików systemu plików. Spośród różnic występujących między tymi dwoma typami plików danych dla administratora baz danych tak naprawdę istotne są jedynie te związane z tworzeniem i archiwizowaniem tych plików. Oba rodzaje plików danych w obrębie bazy wyglądają identycznie (na rysunku 15.3 w graficzny sposób przedstawiono plik danych).
Zakresy DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Zak es
Nie dotyczy
Zak es
Zak es
Zak es
Zak es
Zak es
Zak es
Zakres jest zestawem stron logicznie ze sobą pogrupowanych i logicznie sąsiadujących. Strony mogą lub nie fizycznie ze sobą sąsiadować (jeśli strony zakresu faktycznie do siebie przylegają, oznacza to, że fizycznie występują jedna obok drugiej). Zakresy bazy danych Informix fizycznie sąsiadują ze sobą, jednak w przypadku innych baz jest z tym różnie w zależności od momentu i metody utworzenia zakresów. Wszystkie zakresy są uważane za logicznie sąsiadujące, ponieważ traktuje się je jako pojedynczy blok magazynujący dane, który jest przydzielony tabeli. Choć zakresy nie obejmują więcej niż jednego pliku danych, może on zawierać dowolną liczbę zakresów. Rzeczywisty rozmiar zakresu jest wyznaczany przez system bazodanowy (na rysunkach 15.2 i 15.3 w graficzny sposób przedstawiono zakres). Dotyczy administratorów baz danych Informix: termin obszar tabel (ang. tablespace) użyty w tym rozdziale odnosi się do obszaru dbspace. Definicja obszaru tabel jest następująca: jest to obszar, w którym umieszcza się tabele. Informix posługuje się tym określeniem (a także podobnym terminem tblspace), mając na myśli coś innego. Jak widać na rysunku 15.1, obszar tabel może składać się z zakresów znajdujących się w różnych plikach danych. Gdy tabela korzysta z kilku plików danych, Informix używa terminu tblspace, aby odwołać się do części tabeli zlokalizowanej w pojedynczym pliku danych. Z kolei termin obszar tabel dotyczy ilości miejsca zajmowanego przez tabelę.
nistratorzy baz danych i systemów nie rozumieli się, ustalając rozmiar bloku, jaki powinien być ustawiony dla bazy danych Oracle.
428 |
Rozdz ał 15. Arch w zowan e baz danych
Obszar tabel DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Obsza tabel
G upa magazynu lub magazynow ania
Dbspace
Obsza tabel ( nnoDB i NDB)
Obsza tabel
Obsza tabel
G upa plików
Segment
Obszar tabel jest zbiorem jednego lub większej liczby plików danych, a także miejscem, w którym umieszcza się tabele (na rysunku 15.3 w graficzny sposób przedstawiono obszar tabel). Tabela jest tworzona w tym obszarze (na przykład za pomocą polecenia create table in tablespace alfa). W przypadku większości produktów bazodanowych, gdy definiuje się instancję, określa się, który plik danych będzie głównym lub systemowym obszarem tabel. W dalszej kolejności ten obszar tabel jest tworzony automatycznie. Wszystkie bazy danych Sybase mają co najmniej dwa segmenty: domyślny i systemowy. Są automatycznie generowane po wykonaniu polecenia create database. Można też utworzyć własne segmenty zawierające jedno lub więcej urządzeń bazy Sybase, a także segmenty te wstawić w poleceniu create table. Tabele systemowe znajdują się w segmencie systemowym. Jeśli nie utworzy się własnych segmentów, wszystkie tabele użytkowników będą umieszczane w domyślnym segmencie. Oznacza to, że segmenty są tożsame z obszarami tabel. Jednak ze względu na to, że wielu administratorów baz danych Sybase nie definiuje niestandardowych segmentów, nie traktuje ich jak obszarów tabel. Serwer SQL Server nazywa swoje obszary tabel grupami plików. W głównej grupie plików są przechowywane tabele systemowe, a w domyślnej grupie — pozostałe tabele. Można również tworzyć własne grupy plików i umieszczać w nich tabele. Ponieważ dane wybranego użytkownika serwera Exchange są przechowywane w pojedynczej grupie magazynowania i istnieje tabela użytkowników, można powiedzieć, że grupa magazynu lub magazynowania jest odpowiednikiem obszaru tabel. W przypadku bazy danych MySQL obszarem tabel dysponują wyłącznie tabele obsługiwane przez mechanizmy składowania InnoDB i NDB.
Partycja DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Pa tycja
Nie dotyczy
F agment
Pa tycja
Pa tycja
Pa tycja
Pa tycja
Pa tycja
Jedną z największych zalet technologii RDBMS jest możliwość rozdzielania lub partycjonowania tabeli w obrębie wielu zasobów. Dawniej tabela musiała być zawarta we wcześniej omówionym obszarze tabel. Obecnie niektóre produkty bazodanowe pozwalają na partycjonowanie tabeli w obrębie wielu obszarów tabel, na podstawie wartości określonych atrybutów. Przykładowo można utworzyć tabelę partycjonowaną w obszarach tabel A i B. Można zdecydować, że wszystkie rekordy z wartościami atrybutu A od 1 do 100 trafią do obszaru A, a rekordy atrybutu A z wartościami od 101 do 200 zostaną umieszczone w obszarze B (na rysunku 15.1 w graficzny sposób przedstawiono partycjonowaną tabelę). Partycja bazy danych DB2 umożliwia przydzielenie tabeli wielu procesorów. Partycjonowana tabela nie stawia żadnych specjalnych wymagań dotyczących archiwizowania.
Struktura bazy danych
| 429
Główna baza danych DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Katalog
Bazy danych z p ywatnymi i publicznymi info macjami
Sysmaster plik onconfig i plik rootdb
Baza danych MySQL
Plik kont olny
Tabele systemowe
Główna baza danych
Główna baza danych
Każda instancja w jakiś sposób rejestruje wszystkie elementy magazynujące, które ma do dyspozycji. Główna baza danych monitoruje wszystkie urządzenia i ich status, a także wszelkie informacje, do których dostęp muszą mieć wszystkie bazy danych. Jeśli możliwe jest istnienie wielu baz danych, muszą być rejestrowane przez główną bazę. Serwer Sybase używa do tego specjalnej bazy danych, a serwer Oracle — pliku kontrolnego, który monitoruje tego typu informacje. Serwer Informix też ma specjalną bazę danych, o nazwie Sysmaster, która rejestruje status każdego obiektu instancji. Jednakże część informacji jest śledzona przez plik onconfig i zarezerwowane strony znajdujące się w pliku rootdb.
Transakcja DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
T ansakcja
T ansakcja
T ansakcja
T ansakcja
T ansakcja
T ansakcja
T ansakcja
T ansakcja
Transakcja jest operacją wykonywaną w obrębie bazy danych, która zmienia jeden lub więcej atrybutów jednej lub kilku tabel. Jeśli użytkownik modyfikuje adres klienta, ma miejsce transakcja. Można wyróżnić dwa typy transakcji: prostą i złożoną. Prosta transakcja jest realizowana za pomocą jednej instrukcji (na przykład update atrybut X in tabela Y to 100). Z kolei złożona transakcja może być znacznie dłuższa. Ponadto jest rozpoczynana instrukcją inicjującą i kończona przy użyciu instrukcji finalizującej. Między tymi dwoma instrukcjami może się znaleźć kilka prostych instrukcji lub też skomplikowany skrypt SQL aktualizujący setki wartości na podstawie określonych parametrów. Przykładowo dość powszechne stały się zmiany kodu pocztowego, bo miasta powiększają się i dodatkowo dzieli się kody. Może zostać przeprowadzona złożona transakcja, która sprawdzi numery telefonów wszystkich klientów i na podstawie 3-cyfrowego prefiksu zmieni numer kierunkowy tych numerów. Złożona transakcja jest traktowana jako zdarzenie jednolite. Obowiązuje zasada: wszystko albo nic. Zarówno początkowa, jak i końcowa instrukcja transakcji jest rejestrowana w dzienniku transakcji (zostanie omówiony później). Jeśli cokolwiek wydarzy się przed zapisaniem instrukcji finalizującej transakcję, zostaną wycofane wszystkie zmiany dokonane przez tę transakcję. Do rzeczy, które mogą coś takiego spowodować, należy zaliczyć wylogowanie się użytkownika w trakcie trwania procesu, zamknięcie bazy danych, zawieszenie się systemu, a nawet zmianę przez użytkownika początkowych zamiarów. Nie wszystkie mechanizmy magazynowania danych serwera MySQL obsługują transakcje. Transakcje można realizować w przypadku tabel spełniających warunki modelu ACID (Atomicity Consistency Isolation Durability — Atomowość Spójność Izolacja Trwałość). Jednak domyślny mechanizm magazynowania (MyISAM) nie pozwala na zastosowanie transakcji.
430 |
Rozdz ał 15. Arch w zowan e baz danych
Dziennik wycofań DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Dziennik t ansakcji
Dziennik t ansakcji
Fizyczny dziennik
Segment wycofań ( nnoDB)
Segment pow otu segment wycofań
Wewnęt zn a tabela
Dziennik t ansakcji
Dziennik t ansakcji
Z punktu widzenia spójności danych ważne jest uświadomienie sobie, jaką rolę pełni transakcja. Choć użytkownik widzi, że transakcja zmienia rekord w bazie danych, w rzeczywistości jest modyfikowana jedna lub więcej stron. Proces przywracania transakcji odbywa się na poziomie stron. Jeśli określona transakcja zmodyfikuje 100 stron i nie zostanie ukończona, wszystkie te strony muszą być cofnięte do stanu sprzed zainicjowania transakcji. Operacja taka jest określana mianem cofania strony do stanu sprzed obrazu (za pomocą stwierdzenia „sprzed obrazu” identyfikuje się wygląd strony, zanim została zmieniona). Poniższe elementy reprezentują rozwiązania, które bazy danych muszą zapewnić, aby operacja wycofywania (i inne działania związane ze spójnością danych) mogła zostać poprawnie wykonana. Dziennik wycofań jest miejscem, w którym baza danych zapisuje obraz sprzed modyfikacji. Bazy danych Informix i Oracle tylko w tym celu wykorzystują dedykowany dziennik. Obraz sprzed modyfikacji każdej zmienionej strony jest przechowywany w takim dzienniku do momentu ukończenia lub zatwierdzenia transakcji. Bazy danych: Sybase, SQL Server i DB2 w dzienniku transakcji rejestrują zarówno obraz sprzed modyfikacji, jak i dane transakcji. Godne uwagi jest to, że obraz sprzed modyfikacji musi być fizycznie zapisany na dysku, zanim zostaną zmienione jakiekolwiek strony. W ten sposób zapewnia się, że gdy wystąpi awaria systemu, będzie dostępny obraz. To, jak w rzeczywistości taki obraz zostanie wykorzystany, w znacznym stopniu różni się w przypadku poszczególnych produktów bazodanowych. Oracle zmienił sposób działania operacji wycofywania i obecnie zamiast segmentu wycofań stosuje segment powrotu. Baza PostgreSQL w samej tabeli przechowuje obraz rekordów sprzed ich modyfikacji. W określonym momencie proces opróżniający usuwa poprzedni stan rekordów.
Dziennik transakcji DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Dziennik t ansakcji
Dziennik t ansakcji
Logiczny dziennik
Dziennik t ansakcji
Dziennik powtó zeń
Dziennik zapisów z wyp ze dzeniem
Dziennik t ansakcji
Dziennik t ansakcji
Załóżmy, że system uszkodził się w taki sposób, że wymagał przywrócenia z najnowszej kopii zapasowej bazy danych. Jeśli nie byłoby żadnej możliwości powtórzenia transakcji, które miały miejsce od chwili sporządzenia ostatniej kopii zapasowej, wszystkie zostałyby utracone. Dziennik transakcji rejestruje każdą transakcję i strony, które zostały zmienione. Informacje zawarte w tym dzienniku są używane wtedy, gdy po wystąpieniu awarii systemu trzeba ponownie zrealizować transakcje. Głównej bazie danych znany jest status każdego pliku danych. Po uruchomieniu baza ta sprawdza każdy taki plik. Jeśli stwierdzi, że dowolny z plików został uszkodzony, trzeba go przywrócić z kopii zapasowej. Gdy to nastąpi, główna baza danych sprawdza plik danych i stwierdza, że został odtworzony do wcześniejszego stanu. W związku z tym baza
Struktura bazy danych
|
431
używa dziennika transakcji, aby powtórzyć wszystkie transakcje, które od tego czasu zostały zarejestrowane. Oznacza to, że są wycofywane transakcje, których nie zatwierdzono. Faktyczny przebieg tego procesu różni się w przypadku poszczególnych produktów. Jednak jego podstawowy cel pozostaje taki sam. Dzienniki wycofań i transakcji współdziałają, aby zagwarantować, że po wystąpieniu awarii lub ponownym uruchomieniu komputera wszystkie strony zostaną przywrócone do poprawnego stanu. Wiele osób ma problem ze zrozumieniem różnicy występującej między dziennikiem wycofań i dziennikiem transakcji. W tym przypadku pomocna jest terminologia firmy Informix, ponieważ takie jej pojęcia, jak fizyczny i logiczny dziennik, dokładnie identyfikują to, co dzienniki zawierają. W fizycznym dzienniku znajduje się fizyczny obraz strony sprzed momentu, gdy została zmodyfikowana przez transakcję. Dla fizycznego dziennika nie jest istotne, jak strona została zmieniona. Dziennik wie jedynie, jak strona wyglądała przed modyfikacją. Z kolei logiczny dziennik rejestruje to, w jaki sposób stronę zmieniono. Dzięki temu po przywróceniu danych baza danych może odtworzyć taką zmianę. Dziennik powrotu lub wycofań umożliwia cofnięcie lub usunięcie zmian wprowadzonych przez transakcję, której jeszcze nie zatwierdzono. Dzienniki powtórzeń (inaczej zwane dziennikami transakcji) pozwalają powtórnie wykonać zatwierdzone transakcje. Baza danych MySQL dysponuje binarnym dziennikiem zawierającym instrukcje SQL, które mogą być ponownie wykonane dla spójnej bazy. Jednak dziennik ten nie jest używany w przypadku przywracania po wystąpieniu awarii. Na potrzeby tego każdy mechanizm magazynowania ma własny dziennik transakcji.
Punkt kontrolny DB2
Exchange
nform x
MySQL
Oracle
PostgreSQL
SQL Server
Sybase
Punkt kont olny
Punkt kont olny
Punkt kont olny
Punkt kont olny
Punkt kont olny
Punkt kont olny
Punkt kont olny
Punkt kont olny
Aby zwiększyć wydajność, bazy danych mnóstwo danych umieszczają w pamięci. Trafiają do niej ostatnio zmienione strony, często używane strony, obrazy sprzed zmodyfikowania stron i same transakcje. Oznacza to, że jeśli w określonym momencie system uszkodzi się, część danych przepadnie, ponieważ zawartość pamięci RAM jest ulotna. Baza danych musi w jakiś sposób cofnąć się do momentu, w którym wszystko było na dysku, a w pamięci nic. Moment taki określa się mianem punktu kontrolnego. Z określoną częstotliwością baza danych zapisuje wszystko na dysku. A zatem wszystkie pliki danych i dzienniki są spójne. Jeśli system by się uszkodził, a pliki danych nie, baza cofnęłaby się do odpowiedniego punktu kontrolnego, a następnie ponownie wykonała wszelkie transakcje zarejestrowane od momentu utworzenia tego punktu. Na końcu zostałyby wycofane wszystkie niekompletne transakcje. W ten sposób zapewnia się, że baza danych zawsze zostanie zarchiwizowana, gdy będzie w spójnym stanie.
Omówienie modyfikowania stron Od systemów RDBMS żąda się mnóstwa rzeczy. Oczekuje się, że będą pojemne i szybkie, lecz przy tym zawsze zagwarantują spójność danych. Aby spełnić wymagania dotyczące szybkości, systemy te muszą sporo rzeczy umieszczać w pamięci. Jednak żeby zapewnić spójność, muszą 432 |
Rozdz ał 15. Arch w zowan e baz danych
być bardzo „ostrożne”. Trudno bawić się nożami bez świadomości poniesienia poważnych konsekwencji. Czytając niniejszy podrozdział, należy korzystać z rysunku 15.4. Widać na nim cztery podstawowe obszary magazynowania danych systemu RDBMS. Są to: plik danych, dziennik wycofań, dziennik transakcji i wspólna pamięć, która dodatkowo dzieli się na bufor danych, bufor dziennika wycofań i bufor dziennika transakcji (w pamięci mogą też być inne elementy; tu wymieniono jedynie związane z modyfikowaniem stron). Choć nie wszystkie systemy RDBMS działają dokładnie w ten sposób, pod tym względem są do siebie podobne. Co się dzieje, gdy użytkownik inicjuje transakcję? Zanim do czegokolwiek dojdzie, transakcja i to, co się zmieni, są rejestrowane w dzienniku transakcji. W dalszej kolejności dla każdej strony, która musi zostać zmieniona, są wykonywane poniższe kroki (warto zauważyć, że numery kroków odpowiadają numerom na rysunku 15.4).
Rysunek 15.4. Przebieg operacji modyfikacji strony
1. System RDBMS wczytuje stronę przeznaczoną do modyfikacji i umieszcza ją w buforze
danych. Do momentu, gdy zostaną zastosowane właściwe zabezpieczenia, w tym miejscu strona pozostanie.
2. Dalej transakcja zmieni stronę, lecz wcześniej zapisze kopię aktualnego stanu strony, która trafia do bufora dziennika wycofań.
3. Jeszcze niedokonana zmiana strony jest rejestrowana w buforze dziennika transakcji. 4. Transakcja może zmodyfikować stronę. Zmiana jest dokonywana tylko na kopii strony
znajdującej się w buforze danych. Rejestrowanie zmiany w buforze dziennika transakcji przed jej faktycznym wprowadzeniem pełni rolę zabezpieczenia.
5. Warto zauważyć, że do tego momentu na dysku nie zapisano żadnych zmian. Jeśli nagle
system zepsuje się, dyski nie będą dysponowały zapisem transakcji. Zanim system może utrwalić na dysku jakiekolwiek zmiany, musi mieć pewność, że bezpieczny jest obraz strony Omów en e modyf kowan a stron
| 433
sprzed modyfikacji. Wynika to stąd, że system będzie wymagał tego obrazu, aby cofnąć zmianę strony, gdy nie zostanie ukończona na skutek anulowania transakcji lub ponownego uruchomienia komputera. W celu zagwarantowania dostępności obrazu strony sprzed modyfikacji system zapisuje zawartość bufora dziennika wycofań w fizycznym dzienniku wycofań (znajduje się na dysku).
6. Zmiana dokonana dla strony jest zapisywana w fizycznym dzienniku transakcji. Zmiana ta będzie potrzebna, gdy pojawi się konieczność ponownego zrealizowania transakcji.
7. Gdy już system bezpiecznie zachował obraz strony sprzed modyfikacji i zmianę, która dla strony zostanie dokonana, zmienioną stronę może zapisać na dysku.
W pewnym momencie transakcja jest zatwierdzana. Fakt ten jest od razu rejestrowany w dzienniku transakcji. Dzięki temu system wie, że cała transakcja została ukończona i powinna być powtórzona po wystąpieniu awarii. Taki proces zapewnia, że niezależnie od tego, kiedy system się uszkodzi (i czy to się stanie), stan systemu pozostanie spójny.
Zgodność z modelem ACID Model ACID określa cztery warunki, które muszą być spełnione przez każdy system RDBMS, aby był z nim zgodny. Baza danych, która nie jest zgodna z tym modelem, nie będzie tak niezawodna lub elastyczna, jak baza spełniająca wymagania modelu ACID. Oto definicje tych czterech warunków: Atomowość Wszystkie zmiany wprowadzane w bazie danych są typu „wszystko albo nic”. Niezależnie od tego, co się stanie, transakcja może zakończyć się całkowitym powodzeniem lub zupełną porażką. Spójność Nie będą dozwolone żadne transakcje, które spowodują, że baza danych znajdzie się w niespójnym stanie. Jeśli jakaś transakcja narusza określone reguły spójności bazy danych, zostanie cofnięta. Izolacja Transakcje nie mogą ze sobą kolidować. Przykładowo jedna transakcja nie powinna wczytywać danych tymczasowo utworzonych przez drugą transakcję. Jest to przede wszystkim zapewniane za pomocą rejestrowania. Trwałość Transakcje zatwierdzone w bazie danych w żadnym wypadku nie zostaną utracone. Właśnie w tym celu są tworzone kopie zapasowe i dzienniki transakcji.
Co może stać się z systemem RDBMS? Może wydarzyć się mnóstwo rzeczy, które zakłócą normalne funkcjonowanie bazy danych. To, co będzie trzeba zrobić w celu przywrócenia bazy danych do działania, przede wszystkim będzie zależne od tego, co spowodowało, że przestała funkcjonować. Poniżej zamieszczono listę kilku rzeczy, które mogą się przydarzyć systemowi RDBMS.
434 |
Rozdz ał 15. Arch w zowan e baz danych
Zmiana właściciela urządzenia Ktoś przypadkowo może zmienić właściciela niesformatowanych urządzeń lub plików, które są przez bazę danych wykorzystywane na potrzeby magazynowania plików danych. Ponieważ w takiej sytuacji baza nie może zapisywać danych w plikach, przestaje działać. Trzeba będzie przywrócić urządzeniu właściwego właściciela i ewentualnie odtworzyć dane. Zmiana uprawnień urządzenia Sytuacja ta przypomina zmianę właściciela, ponieważ mechanizm bazodanowy nie może niczego zapisywać w pliku. Rozwiązanie jest takie samo jak w przypadku poprzedniego problemu. Zniszczenie lub awaria dysku Jedyną rzeczywistą ochroną przed uszkodzonym dyskiem jest macierz RAID bądź określonego rodzaju archiwizacja lub replikacja. Logiczne uszkodzenie Baza danych na wiele sposobów może zostać logicznie uszkodzona. Przykładem takiego uszkodzenia jest usunięcie ważnej tabeli. Proces pobierania i zapisywania stron też powoduje logiczne uszkodzenie, które może być stwierdzone tylko za pomocą operacji eksportowania lub narzędzia sprawdzającego spójność bazy danych. Awaria kontrolera Jeśli powiela się zawartość części urządzeń, powinno się to robić tak, aby urządzenie podłączone do jednego kontrolera SCSI było powielane przez urządzenie obsługiwane przez inny kontroler. W ten sposób zapewni się, że gdy zepsuje się kontroler SCSI, jednocześnie nie staną się niedostępne oba powielane urządzenia. Przypisanie niesformatowanemu urządzeniu bazy danych roli systemu plików lub partycji wymiany Nie jest to dobry pomysł. W tym przypadku przyda się odpowiednia dokumentacja, która będzie również pomocna wtedy, gdy administratorzy zostali tak wyszkoleni, żeby przed użyciem urządzenia sprawdzić, kto jest jego właścicielem. Jeśli będzie należało do kogoś innego niż superużytkownik, nie należy go stosować. W celu poradzenia sobie z tym problemem należy cofnąć efekty poczynionych działań i odtworzyć dane z kopii zapasowej. Inna aplikacja używa niesformatowanego urządzenia do powielania danych Jest to sytuacja podobna do powyższej. Z myślą o czymś innym niż baza danych administrator próbuje użyć jednego z wykorzystywanych przez nią dysków. Również w przypadku tego problemu trzeba cofnąć efekty poczynionych działań i odtworzyć dane z kopii zapasowej.
Archiwizowanie systemu RDBMS Ochrona systemu RDBMS jest bardzo trudna. Istnieje kilka elementów magazynowania danych, takich jak pliki danych, dzienniki wycofań, dzienniki transakcji i główna baza danych. W jaki sposób wszystkie dane umieścić na dodatkowym nośniku, jeśli nieustannie się zmieniają? W rozdziale przede wszystkim skoncentrowano się na archiwizowaniu zawartości bazy danych. Zakładamy, że Czytelnik archiwizuje też inne ważne składniki, takie jak system operacyjny, aplikacja bazodanowa i schemat bazy.
Arch w zowan e systemu RDBMS
| 435
Fizyczne i logiczne kopie zapasowe Można wyróżnić dwie podstawowe metody archiwizowania bazy danych systemu RDBMS, które w efekcie tworzą fizyczne i logiczne kopie zapasowe. W fizycznej kopii zapasowej są umieszczane pliki danych. Kopię taką określa się również mianem kopii bazy danych. Istnieją dwa typy fizycznych kopii zapasowych: „zimna” i „gorąca”. „Zimna” kopia zapasowa jest sporządzana po zamknięciu bazy danych. Często jest to najprostsza metoda archiwizacji bazy, zwłaszcza wtedy, gdy pliki danych bazy znajdują się w obrębie systemu plików. Wszystko, co trzeba zrobić, to wyłączyć bazę danych i uruchomić zwykłe narzędzie archiwizujące system plików. Niestety, metoda ta może wymagać niedostępności bazy danych przez długi czas. Właśnie z tego powodu w przypadku coraz większej liczby środowisk są tworzone „gorące” kopie zapasowe, które nie wymagają wyłączenia bazy. Oczywiście tego typu kopie zapasowe powodują, że w tle jest realizowanych znacznie więcej operacji. Wynika to stąd, że próbuje się skopiować pliki danych, gdy baza danych próbuje zapisać w nich dane. Konieczne będzie też zastosowanie narzędzia archiwizującego, dla którego jest zrozumiała wewnętrzna struktura bazy danych. Oto kilka metod sporządzania fizycznych kopii zapasowych: • W przypadku większości baz danych przechowujących pliki danych w obrębie systemu
plików po prostu wyłącza się bazę i wykonuje pełną kopię zapasową systemu. Ponieważ wszystko ma postać zwykłego pliku systemu plików, nic nie zostanie pominięte w kopii zapasowej. Jeśli pojawi się konieczność odtworzenia zawartości bazy danych, w całości można ją przywrócić z takiej kopii zapasowej. W tym przypadku dla starych plików bazy danych trzeba będzie ponownie zrealizować transakcje zapisane w dziennikach. Wiele baz danych nie pozwala na powtórzenie transakcji, gdy kopia zapasowa została utworzona w ten sposób. W przypadku takich baz (należy do nich zaliczyć takie, jak DB2, Sybase i SQL Server) ta metoda archiwizacji nie sprawdzi się.
• Jeżeli pliki danych mają postać niesformatowanych partycji systemu Unix, można zamknąć
bazę danych i zarchiwizować je, pod warunkiem że dysponuje się odpowiednim narzędziem lub skryptem. Przykładowo w systemie Unix należy użyć w tym celu programu dd. Jednak w porównaniu z poprzednią metodą ta jest znacznie bardziej złożona, ponieważ trzeba wiedzieć, dla których urządzeń uruchomić program dd.
• Następna metoda archiwizowania bazy danych polega na umieszczaniu zawartości aktywnej
bazy w kopii zapasowej zapisywanej na dysku lub taśmie za pomocą służącego do tego narzędzia. Baza danych Oracle używa w tym celu programu rman, DB2 stosuje polecenie db2 backup, a bazy Sybase i SQL Server korzystają z narzędzia dump. W przypadku serwera Exchange można użyć programu ntbackup.
• Inna metoda archiwizowania baz danych sprowadza się do użycia narzędzia, które jeden
lub więcej strumieni danych przesyła do komercyjnego menedżera magazynowania (może to być oprogramowanie archiwizujące). Jeśli można sobie na tę metodę pozwolić (dla jednego systemu może być konieczne wydanie kilku tysięcy złotych), będzie najwygodniejsza. Każdy z większych dostawców baz danych zapewnia interfejs API, który może być wykorzystany przez zewnętrzne menedżery magazynowania w celu uzyskania możliwości archiwizacji zawartości bazy.
• Kilka komercyjnych narzędzi oferuje funkcję różniącą się od wcześniej zaprezentowanych.
Spośród tych narzędzi najpopularniejsza jest aplikacja SQL Backtrack, która obecnie jest sprzedawana przez firmę BMC Software. Narzędzia te używają niektórych programów
436 |
Rozdz ał 15. Arch w zowan e baz danych
wchodzących w skład bazy danych i nie stosują API dostarczonego przez producenta bazy. Pozwalają one również na wysyłanie strumienia danych do komercyjnych produktów archiwizujących. Część produktów oferuje interfejsy dla tych narzędzi. Niektóre narzędzia udostępniają interfejsy do produktów, które nie używają nowszych interfejsów. O przydatności programów archiwizujących i przywracających, które nie korzystają z API producenta bazy danych, niech Czytelnik zdecyduje sam. Operacja tworzenia logicznej kopii zapasowej kopiuje lub eksportuje obiekty danych (zwykle tabele), lecz nie rejestruje lokalizacji danych. Z takiej kopii można odtworzyć usuniętą tabelę bez konieczności przywracania wszystkich plików danych, w których tabela jest przechowywana. Korzystając z takiej kopii, można też przenieść tabelę z jednej bazy danych do drugiej. Operacje takie są możliwe dzięki przeznaczeniu logicznej kopii zapasowej, którym jest archiwizowanie danych, a nie rejestrowanie ich lokalizacji. A zatem dane umieszczone w takiej kopii mogą zostać odtworzone w dowolne miejsce. Jednakże logiczne kopie zapasowe nie pozwalają na przeprowadzenie procesu przywracania danych do stanu z określonej chwili. Ponadto takie kopie mogą wywołać problemy ze spójnością odwołań, ponieważ można wczytać tabelę wymagającą informacji z innej tabeli, która nie jest dostępna. Jednak największy problem związany z operacją eksportowania jest taki, że prawie zawsze musi być realizowana przy wyłączonej bazie danych. Logiczne kopie zapasowe w rzeczywistości są znacznie prostsze od fizycznych kopii. Każda baza danych dysponuje narzędziem eksportującym, które w pliku sporządza logiczną kopię zapasową jednego lub większej liczby obiektów. Część komercyjnych narzędzi umożliwia też włączenie logicznych i fizycznych kopii zapasowych do używanego systemu archiwizującego.
Porównanie niesformatowanych urządzeń i plików systemów plików W kręgu administratorów baz danych jest to często poruszana kwestia. Wielu administratorów woli używać niesformatowanych urządzeń, ponieważ wierzą, że zapewnią większą szybkość niż w przypadku stosowania plików systemów plików. Część administratorów preferuje pliki systemów plików ze względu na łatwość zarządzania nimi. Dotychczas niesformatowane partycje były wykorzystywane z powodu większej wydajności i spójności danych. Baza danych spędza wiele czasu na podejmowaniu prób mających na celu zapewnienie, że wszystkie dane znajdują się w odpowiednim stanie. Baza rejestruje każdą zmienioną stronę i w każdej chwili zna dokładny status dowolnej strony. Baza zakłada, że gdy nakaże systemowi operacyjnemu zapisanie strony w pliku danych, ten tak postąpi. Jednak w celu poprawienia wydajności wiele systemów plików buforuje operacje zapisu. Oznacza to, że baza danych jest „przekonana”, że zmodyfikowana strona została zapisana na dysku, gdy w rzeczywistości tak nie jest. Nie jest to coś dobrego. Nowsze bazy danych radzą sobie z tym problemem, otwierając plik systemu plików w trybie O_SYNC, który automatycznie zapisuje na dysku wszelkie zmiany przechowywane przez system operacyjny w buforze. Oznacza to, że w przypadku większości baz niedogodność związana z buforowaniem operacji zapisu straciła na znaczeniu. A zatem wydajność jest jedynym powodem, dla którego warto stosować niesformatowane partycje na potrzeby plików danych. Wiele osób twierdzi, że w porównaniu z plikami systemów plików uzyskuje się wzrost wydajności wynoszący 5 – 15%. Wynik uzyskany przez Czytelnika może się różnić. Wartości te otrzymano w czasie testów, które można porównać do przeprowadzanych na zamkniętej drodze przez zawodowego kierowcę. Zaleca się zrobić takie testy samemu i stwierdzić, co będzie najlepszym rozwiązaniem.
Arch w zowan e systemu RDBMS
|
437
Uwzględnienie każdej instancji W rozdziale 2. znajduje się punkt „Czy archiwizuje się to, co faktycznie zaplanowano?”. Wyjaśniono w nim, w jaki sposób programy archiwizujące powinny być projektowane, aby cała zawartość komputera była automatycznie wykrywana i archiwizowana. Jeśli dodano nowy system plików, nie powinno być konieczne edytowanie skryptów archiwizujących w celu uwzględnienia go w kopii zapasowej. Coś takiego tym bardziej nie może mieć miejsca w przypadku baz danych, ponieważ nierzadko są one dodawane i usuwane znacznie częściej niż systemy plików. Niezbędna jest metoda gwarantująca, że zostanie zarchiwizowana instancja każdej bazy danych znajdującej się na każdym serwerze. Komercyjne produkty archiwizujące mogą automatycznie pobrać od systemu operacyjnego informacje dotyczące jego napędów i systemów plików. Czy nie byłoby dobrze, gdyby coś takiego było możliwe w przypadku baz danych? Zacznijmy od baz Oracle i Sybase. Baza Sybase ma plik interfaces, który wyszczególnia każdy serwer uruchomiony na dowolnym komputerze. Jeśli instancja nie zostanie wymieniona w tym pliku, użytkownicy nie będą mogli się z nią połączyć. Baza danych Oracle dysponuje plikiem oratab, który pełni identyczną rolę, lecz w przeciwieństwie do pliku interfaces jego użycie nie jest obowiązkowe. Programy mogą pobierać z rejestru systemu Windows informacje na temat baz danych Exchange lub SQL Server uaktywnionych na określonym serwerze. Administratorzy bazy danych DB2 mają możliwość wysyłania zapytań do jej katalogu. Niestety, baza Informix nie oferuje tego typu funkcji. Trzeba ją stworzyć samemu. Ponieważ omówione tu pliki nie zawsze są używane, choć powinny, chciałbym podkreślić to, co właśnie napisałem — niezbędny jest scentralizowany plik wyszczególniający wszystkie instancje serwera. A zatem najpierw należy sprawdzić taki plik, żeby stwierdzić, jakie instancje znajdują się na wybranym serwerze — instancje, które muszą zostać zarchiwizowane. Pisząc skrypty startowe uruchamiające tylko te instancje, które wymieniono w pliku oratab, należy wymusić jego stosowanie. Niesforny (lub zapracowany) administrator baz danych może jednak utworzyć instancję bez uwzględniania jej w pliku oratab i nawet uaktywnić ją. Jeśli jednak zrestartuje się serwer wystarczającą ilość razy, administrator taki na pewno umieści instancję w pliku startowym, żeby nie musiał jej każdorazowo ręcznie ładować! W przypadku bazy danych Informix należy utworzyć plik podobny do oratab i napisać skrypty startowe, które będą jedynie uaktywniać bazy wyszczególnione w tym pliku.
Zrzuty dzienników transakcji nie są przyrostowymi kopiami zapasowymi To istotne zagadnienie często jest niewłaściwie interpretowane. Powodem tego są dokumentacje serwerów Sybase i SQL Server, w których często zrzut dziennika transakcji traktuje się jak przyrostową kopię zapasową. Jednak nie są to te same rzeczy! Czym się one różnią? Przyrostowa kopia zapasowa jest specjalną kopią zawierającą wyłącznie strony (bloki) zmodyfikowane od momentu wykonania ostatniej pełnej kopii zapasowej (lub przyrostowej wyższego poziomu). Zrzut dziennika transakcji jest kopią zapasową wszystkich transakcji, które miały miejsce od czasu sporządzenia ostatniego takiego zrzutu. Choć definicje te mogą wyglądać podobnie, nie są takie same. Zrzutami dzienników transakcji znacznie trudniej zarządzać i są o wiele dłużej wczytywane.
438 |
Rozdz ał 15. Arch w zowan e baz danych
Być może najlepszym sposobem zilustrowania tego byłoby omówienie programu rman bazy Oracle, który tworzy zarówno przyrostowe kopie zapasowe, jak i kopie dzienników transakcji. Przyjmijmy, że w piątek sporządzono pełną kopię zapasową. W tygodniu nie wykonano żadnej pełnej kopii, a jedynie kopie zapasowe dziennika powtórzeń (transakcji). Załóżmy dodatkowo, że jest czwartek i trzeba odtworzyć bazę danych. Do dyspozycji będzie piątkowa pełna kopia i kopie dziennika powtórzeń z każdego dnia. W celu przeprowadzenia procesu odtwarzania trzeba wczytać pełną kopię, a następnie kolejno każdy plik dziennika powtórzeń. Przyjmując, że każdego dnia użyto innego woluminu archiwizacyjnego, będzie ich wymaganych siedem. Załóżmy dokładnie taki sam scenariusz jak powyższy, z tą różnicą, że dodatkowo każdej nocy wykonywano przyrostową kopię zapasową. Jeśli bazę danych trzeba będzie odtworzyć w czwartek, konieczna będzie piątkowa pełna kopia zapasowa, wolumin z najnowszą przyrostową kopią (przypuszczalnie ze środy) i dzienniki powtórzeń z czwartku. Innymi słowy, zamiast siedmiu wymagane są trzy woluminy. Wynika to stąd, że przyrostowa kopia zapasowa zawiera wszystkie zmiany dokonane od czasu sporządzenia pełnej kopii. Pomijając różnicę w złożoności, wczytywanie przyrostowej kopii zapasowej przebiega znacznie szybciej niż kopii dziennika transakcji. Można zapytać każdego, kto miał do czynienia z dziennikami transakcji z zapisem z okresu kilku dni. Przeprowadzony przeze mnie test wykazał, że odczytanie dzienników transakcji z okresu dwóch tygodni zajęło 36 godzin. Wczytywanie przyrostowej kopii zapasowej obejmującej taki sam okres trwało tylko godzinę. Powód tego jest prosty: określona strona może być kilka razy zmieniona. Odczytanie dziennika transakcji też spowoduje kilkukrotne zmodyfikowanie strony. Gdy wczyta się zawartość prawdziwej przyrostowej kopii zapasowej, strona będzie zmieniona tylko raz. Dla strony zostanie ustawiona ostatnia wartość. Baza danych DB2 oferuje przyrostowe kopie zapasowe, które uwzględniają wszystkie zmiany od czasu sporządzenia ostatniej pełnej kopii, a także kopie zapasowe delta (archiwizują wyłącznie zmiany wprowadzone od chwili utworzenia ostatniej kopii zapasowej dowolnego typu). Baza DB2 dysponuje też kopiami zapasowymi dzienników transakcji. Bazy danych Oracle i Informix obsługują wiele poziomów kopii zapasowych (na przykład poziom 0, poziom 1 itd.).
Zrób to sam — pisanie własnego narzędzia archiwizującego Nie trzeba korzystać z kosztownego komercyjnego narzędzia, żeby móc archiwizować bazy danych. Choć takie oprogramowanie z pewnością sprawi, że kopie zapasowe będą bardziej zautomatyzowane lub centralnie zarządzane, cena większości komercyjnych narzędzi, wynosząca tysiące złotych (w przeliczeniu na jeden komputer), powoduje, że wiele osób używa rozwiązań domorosłych programistów.
Dysk pośredniczący Jest to jedna z najpopularniejszych metod sporządzania kopii zapasowych baz danych. Metoda jest szybka, wygodna i prosta. Podstawowym zamysłem jest użycie skryptu archiwizującego na dysku zawartość bazy danych. Uzyskana kopia jest traktowana jak zwykły plik i uwzględniana w kopii zapasowej systemów plików sporządzanej w nocy. Kompresując pliki kopii zapasowych, można nawet zaoszczędzić trochę potrzebnej przestrzeni dyskowej. Jeśli naprawdę brakuje miejsca, można zastosować nazwane potoki, aby kompresja miała miejsce w czasie archiwizowania danych. W tym przypadku potrzebny będzie dysk archiwizujący o pojemności
Arch w zowan e systemu RDBMS
| 439
wynoszącej jedynie od 1/3 do 1/2 rozmiaru oryginalnego dysku bazy danych (zależnie od uzyskanego współczynnika kompresji). Jeśli nie zarządza się bardzo dużą bazą danych, prawdopodobnie będzie to tańsze rozwiązanie od nabycia komercyjnego narzędzia, które to umożliwia. W każdym rozdziale książki poświęconym archiwizowaniu baz danych poszczególnych producentów wyjaśniono, jak to zrobić.
Dedykowany napęd taśmowy Korzystając z utworzonych we własnym zakresie skryptów, można archiwizować dane na dedykowanym napędzie taśmowym. Jest to trochę bardziej skomplikowane i wymaga większego nakładu pracy. Zależnie od rozmiaru bazy danych wariant ten może okazać się trochę droższy lub tańszy od archiwizowania danych na dysku. Jednak na pewno będzie wolniejszy. Poza tym rozwiązanie to jest bardziej złożone, ponieważ trzeba rejestrować każdy wolumin i nadawać mu etykietę, aby było wiadomo, jaką bazę danych na nim zarchiwizowano (gdy dane archiwizuje się na dysku, w celu umożliwienia identyfikacji odpowiedniej kopii zapasowej wystarczy jej nadać nazwę bazy danych).
Skrypty powłoki lub wsadowe Zakładam, że wcześniej omówione kopie zapasowe Czytelnik wykonuje przy użyciu określonego typu skryptu powłoki lub wsadowego. Skrypty są znacznie lepsze od prostego wpisu programu cron lub at, który wydaje polecenie: zarchiwizuj bazę danych A na urządzeniu B. Skrypty w dużym zakresie przeprowadzają kontrolę błędów i można im nakazać na przykład powiadamianie administratora bazy danych, gdy coś pójdzie nie tak.
Wzywanie profesjonalisty Segment narzędzi archiwizujących bazy danych rośnie jak mało który w całej branży związanej z produktami archiwizującymi. Większość komercyjnych produktów archiwizujących systemy plików oferuje obecnie interfejsy umożliwiające automatyczne archiwizowanie zawartości baz danych na woluminach zarządzanych przez powiązaną z nimi aplikację. Choć jest to naprawdę cudowne, sporo kosztuje! Każdy większy dostawca baz danych, z uwzględnieniem wymienionych w książce, zapewnia API, za pomocą którego komercyjne produkty archiwizujące mogą sporządzać kopie zapasowe baz danych (komercyjna aplikacja archiwizująca często jest nazywana menedżerem magazynowania). Wszystkie te narzędzia archiwizujące zasadniczo działają w taki sam sposób. Program dostawcy bazy danych generuje jeden lub więcej strumieni archiwizacji, z którymi za pośrednictwem API interakcję mogą prowadzić menedżery magazynowania. Firmy projektujące takie menedżery mogą napisać narzędzie, które z jednej strony będzie komunikować się ze swoim menedżerem, z drugiej — z API programu dołączonego do bazy danych. Choć narzędzia archiwizujące bazy danych są dodawane do produktów bazodanowych, tego typu narzędzia dołączane do komercyjnego oprogramowania archiwizującego kosztują tysiące złotych. Takie narzędzia archiwizujące czasami nie będą funkcjonować bez menedżera magazynowania. Przykładowo program rman bazy Oracle i narzędzie onbar bazy Informix muszą mieć dostęp do menedżera magazynowania, żeby dane zarchiwizować na taśmie. Program rman potrafi jednak archiwizować dane na dysku bez wymogu dostępności menedżera. Z kolei narzędzie dump baz danych Sybase i SQL Server, polecenie db2 backup bazy DB2 i program ntbackup
440 |
Rozdz ał 15. Arch w zowan e baz danych
serwera Exchange mogą archiwizować dane na taśmie lub dysku bez obecności żadnego menedżera magazynowania. Ponieważ firmy Oracle i Informix nie chciały zmuszać swoich klientów do kupowania menedżera magazynowania lub interfejsu do ich narzędzia archiwizującego, poszły na kompromis. Obaj producenci udostępnili darmową, okrojoną wersję menedżera magazynowania, który zapewnia funkcje wystarczające do tego, aby użyć programów rman i onbar do tworzenia kopii zapasowych. Na rysunku 15.5 pokazano bazę danych Oracle i taką wersję menedżera magazynowania, żeby zilustrować różne elementy układanki tworzącej proces archiwizowania bazy danych. Firma Oracle używa programu rman w roli interfejsu, który z jednej strony komunikuje się z bazą danych, z drugiej — z modułem bazodanowym menedżera magazynowania. Z kolei menedżer z jednej strony łączy się z nośnikiem archiwizacyjnym, a z drugiej — z modułem bazodanowym. Menedżer posługuje się modułem w roli interfejsu między nim i programem rman. Archiwizowane dane z bazy Oracle trafiają kolejno do narzędzia rman, modułu bazodanowego, menedżera magazynowania, a na końcu są zapisywane na nośniku archiwizacyjnym. Oczywiście odtwarzane dane zmierzają w odwrotnym kierunku.
Rysunek 15.5. Konfiguracja typowego komercyjnego narzędzia archiwizującego bazę danych
Narzędzia stworzone dla poszczególnych dużych baz danych mają własną historię związaną z archiwizowaniem i przywracaniem danych.
DB2 Polecenie db2 backup ma długą historię i zawsze miało związek z archiwizowaniem i przywracaniem. Możliwe jest odtwarzanie baz danych utworzonych na różnego typu platformach. Narzędzie odtwarzające może też być użyte do przywracania zawartości obrazów archiwizacyjnych wygenerowanych w przypadku poprzedniej wersji bazy DB2 (dotyczy to maksymalnie dwóch wcześniejszych wersji), pod warunkiem że długość słowa jest identyczna (32- lub 64-bitowa). Można nawet zarchiwizować bazę danych utworzoną w systemie Linux for zSeries (jest przeznaczony dla serwerów przemysłowych IBM zSeries), a następnie odtworzyć ją na serwerze DB2 UDB działającym pod kontrolą systemu operacyjnego AIX. W ostatnim czasie do bazy danych DB2 dodano polecenie recovery, które ułatwia proces odtwarzania.
Exchange Exchange jest bazą danych specjalnego przeznaczenia i nie ma wbudowanego polecenia archiwizującego. Jednak oferuje API wykorzystywany przez narzędzie ntbackup, za pomocą którego można archiwizować działający serwer Exchange i przywracać jego zawartość. Można również tworzyć kopie zapasowe i odtwarzać ich zawartość na poziomie grupy magazynowania. Jeśli zamierza się sporządzić kopie zapasowe na poziomie skrzynek pocztowych, trzeba skorzystać z innych narzędzi.
Arch w zowan e systemu RDBMS
|
441
Informix Dawniej kopie zapasowe bazy danych Informix były tworzone przy użyciu programu tbtape (obecnie nosi nazwę ontape), który jest niezależnym poleceniem archiwizującym przeznaczonym do umieszczania kopii zapasowych na taśmie. Narzędzie ontape jest proste, obsługuje przyrostowe kopie zapasowe, a także zapisuje kopie na dysku i archiwizuje aktywną bazę danych. Część funkcji tego narzędzia, które zawsze miały być obecne w innych systemach bazodanowych (tak zakładali użytkownicy baz Informix), pojawia się w nich dopiero teraz. Baza Informix dysponuje też programem onbar, który zaprojektowano w celu wysyłania strumienia archiwizowanych danych do komercyjnego produktu. Niezależnie od użytego polecenia można będzie przywrócić wybrane obszary dbspace.
MySQL To, w jaki sposób zarchiwizuje się bazę danych MySQL, będzie zależeć od używanego mechanizmu magazynowania. Każdy ważniejszy mechanizm magazynowania oferuje własną metodę archiwizowania i przywracania danych.
Oracle Bazy danych Oracle mogą być archiwizowane za pomocą narzędzia Recovery Manager lub rman. Od chwili pojawienia się program rman pokonał długą drogę i zapewnia znacznie prostszą metodę archiwizowania i odtwarzania bazy danych niż to, co obecnie Oracle nazywa mechanizmem tworzenia kopii zapasowych zarządzanych przez użytkownika.
PostgreSQL Można wyróżnić dwie podstawowe metody archiwizowania baz danych PostgreSQL. Pierwsza jest odpowiednikiem mechanizmu sporządzania „gorących” kopii zapasowych zarządzanych przez użytkownika, który oferuje baza Oracle. W przypadku tej metody uruchamia się skrypt, który przełącza bazę w tryb archiwizacji, a następnie kopiuje jej pliki. Druga metoda bazuje na poleceniu (pg_dump lub pg_dumpall) zrzucającym całą zawartość bazy danych do dużego pliku tekstowego lub binarnego.
Sybase Firma Sybase może pochwalić się długim stażem w branży związanej z archiwizowaniem. Obecnie baza Sybase umożliwia przywrócenie pojedynczego obszaru tabel lub urządzenia. Niestety, ze względu na to, że wiele osób używa jedynie domyślnego segmentu lub domyślnej grupy plików, większość administratorów baz danych musi odtwarzać całą bazę lub nic. Ułatwieniem w tym przypadku może być utworzenie dodatkowych segmentów lub grup plików.
SQL Server Narzędzie archiwizujące bazy danych SQL Server zapewnia podstawowe funkcje archiwizacji i odtwarzania. Narzędzie umożliwia tworzenie przyrostowych, różnicowych i pełnych kopii zapasowych, a także kopii dzienników transakcji. Nie są do tego wymagane żadne zewnętrzne programy.
442 |
Rozdz ał 15. Arch w zowan e baz danych
Odtwarzanie systemu RDBMS Oczywiście proces odtwarzania systemu RDBMS różni się w zależności od zastosowanych metod archiwizacji. To, w jaki sposób odtworzy się dane, będzie zależne od statusu dysków z danymi i bez nich, a także od tego, czy w trybie online można wykonać operację częściowego odtwarzania bazy danych.
Utrata dysku nieprzechowującego danych Dysk danych jest definiowany jako dowolny dysk zawierający obiekt bazodanowy (ten i inne terminy omówiono wcześniej w rozdziale). Jeśli obiekty bazodanowe pozostały nienaruszone, w rzeczywistości nie ma potrzeby odtwarzania bazy danych. Wystarczy jedynie przywrócić wszystkie składniki, które spowodują, że baza znów zadziała! Może to oznaczać odtworzenie pojedynczego pliku konfiguracji bazy lub przywrócenie całej zawartości bazy na innym komputerze. Pliki wykonywalne Baza danych nie może funkcjonować, gdy są niedostępne jej pliki wykonywalne. Ta część procesu przywracania jest znacznie prostsza, jeśli wszystkie pliki wykonywalne znajdują się w specjalnym systemie plików. Pliki konfiguracyjne Mówiąc w skrócie, pliki wykonywalne można odtworzyć przez skopiowanie ich z zaufanego komputera. Jednak nie można tak postąpić w przypadku plików konfiguracyjnych bazy danych. Każda instancja często ma plik inicjalizujący, który ustawia określone zmienne, takie jak nazwa instancji i położenie głównej bazy danych. Takie pliki konfiguracyjne zwykle mogą być ponownie wygenerowane, jeśli dysponuje się poprawnymi dziennikami pozwalającymi stwierdzić, jak pliki na początku utworzono. Jednak prawdopodobnie łatwiejsze będzie przywrócenie plików z kopii zapasowej. Dostosowane pliki systemu operacyjnego Bazy danych często wymagają edytowania systemowych plików konfiguracyjnych, takich jak /etc/system. Spośród modyfikacji wprowadzanych w tych plikach można wymienić optymalizację wspólnej pamięci lub zmianę portu TCP, za pośrednictwem którego będzie się komunikować oprogramowanie. Jeśli dane odtwarza się w świeżo zainstalowanym systemie lub na innym komputerze, dokonane zmiany będą musiały być zastosowane ponownie. Często o modyfikacjach plików systemu operacyjnego zapomina się lub są one kiepsko udokumentowane. Jeśli odpowiednio nie przygotowano się na taką sytuację, prostsze będzie raczej postępowanie po prostu zgodnie z instrukcjami standardowej instalacji. Jeżeli ktoś to czyta jeszcze przed wystąpieniem takiej konieczności, pora, aby stwierdził, jakie wprowadzono zmiany, i udokumentował je. Jeśli wiadomo, jakie pliki są zwykle edytowane, można nawet napisać program, który automatycznie stworzy dla nich dokumentację zmian. Pliki konfiguracyjne licencji Choć produkty bazodanowe zazwyczaj nie stosują narzędzi, które wymuszają używanie licencji, z czasem może się to zmienić. Jeśli zarządzany serwer bazodanowy korzysta z takiego oprogramowania (na przykład FlexLM), zanim baza będzie mogła poprawnie funkcjonować, trzeba odtworzyć pliki konfiguracyjne licencji.
Odtwarzan e systemu RDBMS
| 443
Utrata dysku z danymi Złożoność i trudność procesu odtwarzania mogą się znacząco różnić w zależności od tego, jaki dysk z danymi utracono i jak dobrze przygotowano się na taką sytuację. Główna baza danych W przypadku całkowitej utraty głównej bazy danych serwera Sybase lub SQL Server, bazy rootdbs serwera Informix, katalogu serwera DB2 lub pliku kontrolnego serwera Oracle bardzo trudno będzie odzyskać takie dane. Jest to na tyle poważna sprawa, że trzeba zadbać o to, żeby do czegoś takiego nigdy nie doszło (jeśli się tego nie zrobi, można mieć pretensje tylko do siebie!). Należy powielać główną bazę danych serwera Sybase, katalog serwera DB2 i pliki kontrolne serwera Oracle. Po prostu trzeba to robić. Jeśli nawet nie można uzyskać miejsca na dysku wystarczającego do powielania reszty danych, koniecznie należy wygospodarować je dla kopii tych bardzo ważnych danych. Nie zajmą one zbyt wiele dodatkowej przestrzeni dyskowej, a można sobie oszczędzić wiele stresu i zyskać mnóstwo czasu. Jest to najprostsza rzecz, którą można wykonać, żeby w czasie większej operacji odtwarzania zaoszczędzić ogromne ilości czasu. Inne bazy danych Jeśli nie korzysta się z serwera bazodanowego Oracle (w jego przypadku między bazą i instancją występuje relacja typu jeden do jednego), w obrębie instancji może znajdować się wiele baz. Jeżeli utraci się urządzenie przypisane bazie danych (innej niż główna baza), poradzenie sobie z tym nie będzie zbyt trudne. W czasie odtwarzania prawdopodobnie będzie można pozostawić w trybie online resztę instancji i wszelkie inne bazy danych. Najlepszą rzeczą, którą można zrobić w celu zautomatyzowania odtwarzania pojedynczych baz danych, jest poprawne dokumentowanie tego, gdzie są zlokalizowane i z jakich urządzeń korzystają. Kopie zapasowe Jedną z najpopularniejszych metod archiwizacji bazy danych jest zapisanie jej zawartości na dysku, a następnie umożliwienie programowi archiwizującemu systemy plików umieszczenia jej na woluminie archiwizacyjnym. Z wielu powodów metodę tę można uznać za bardzo efektywną. Jednak ma ona jedną wadę. Załóżmy, że utracono dysk z danymi i dysk, na którym magazynowano kopie zapasowe. Najpierw trzeba by było odtworzyć z woluminu archiwizacyjnego plik kopii zapasowej dysku. W dalszej kolejności z pliku należałoby przywrócić bazę danych. Jeśli ta 2-etapowa procedura okaże się niezbędna, zajmie więcej czasu niż przywracanie danych bezpośrednio z woluminu archiwizacyjnego. Kopie zapasowe dzienników transakcji To samo dotyczy kopii zapasowych dzienników transakcji. Potrzebna będzie każda taka kopia sporządzona od chwili utworzenia ostatniej pełnej lub przyrostowej kopii zapasowej bazy danych. Zanim rozpocznie się dużą operację odtwarzania, należy sprawdzić datę i godzinę utworzenia pełnej lub przyrostowej kopii zapasowej i upewnić się, że dysponuje się kopiami wszystkich dzienników transakcji wygenerowanych od tego czasu. Jeżeli nie będą dostępne wszystkie dzienniki transakcji, będzie można je przywrócić, zanim faktycznie okażą się potrzebne.
444 |
Rozdz ał 15. Arch w zowan e baz danych
Utrata głównej bazy danych Proces przywracania głównej bazy danych jest pełen paradoksów, ponieważ mnóstwo danych konfiguracyjnych i informacji dotyczących statusu znajduje się właśnie w tej bazie. Dane te mogą zostać odtworzone, gdy przepadną. Jednak trzeba to zrobić ręcznie. Musi być dostępna kompletna historia instancji, dokumentująca jej powstanie, identyfikująca położenie plików bazy i dzienników, a także ich status. Dodatkowo głównej bazie danych trzeba przekazać wszystko, o czym powinna już „wiedzieć”. Nie będzie to zbyt trudne, jeśli wszystkie te informacje zapisano w łatwo dostępnym miejscu. W przeciwnym razie ma się przed sobą długi i męczący proces przywracania.
Jeżeli rzadko wykonuje się kopie zapasowe bazy danych, do ukończenia procesu odtwarzania może być wymagana znaczna liczba kopii dzienników transakcji. Odtwarzając dzienniki, trzeba zadbać o wystarczającą ilość miejsca. Może być niezbędne przywrócenie dzienników w alternatywnej lokalizacji lub poddanie ich kompresji. Gdy program odtwarzający poprosi o dzienniki transakcji, będzie można je przenosić po kilka naraz lub dekompresować.
Aktywne dzienniki transakcji Właśnie one mogą przepaść. Jeśli nawet dysponuje się poprawną kopią zapasową i wszystkimi dziennikami transakcji od momentu sporządzenia ostatniej kopii, może pojawić się problem, gdy utraci się dane zawierające aktywne dzienniki transakcji. Dane takie mogłyby być na dysku przechowującym logiczny dziennik bazy danych Informix lub aktywne dzienniki powtórzeń bazy Oracle (serwery bazodanowe: Sybase, SQL Server i DB2 magazynują aktywny dziennik transakcji w głównej bazie danych). Jedną z metod pozwalających uniknąć tej tragedii jest powielanie aktywnego dziennika transakcji.
Częściowe odtwarzanie bazy danych w trybie online Niektóre bazy danych pozwalają na pozostawienie ich części w trybie online i wyłączenie wybranego obszaru tabel lub pliku danych. Taka częściowa dostępność bazy daje operatorowi więcej czasu na zakończenie trudnej operacji odtwarzania lub zmniejszenie jej ogólnego wpływu na społeczność użytkowników. Jest tak szczególnie wtedy, gdy w odtwarzanej części bazy danych znajduje się tabela, która nie jest zbyt często używana. Jednak zanim pod uwagę weźmie się taki wariant odtwarzania, należy uwzględnić poniższe kwestie. Wzajemna zależność danych zawartych w bazie Jeśli w tabeli znajdują się rzadko używane dane, może to być znakomity kandydat do częściowego odtwarzania. Taką operację można również rozważyć, gdy bez dostępności tej tabeli reszta bazy danych może normalnie funkcjonować (lub w tylko nieznacznie ograniczonym zakresie). Załóżmy jednak, że jest to baza danych działu sprzedaży, a w interesującej nas tabeli są wszystkie transakcje sprzedaży. Z resztą bazy danych nie ma problemów (czyli z nazwiskami, numerami telefonów i adresami), lecz jej jedynym celem jest rejestrowanie sprzedaży. Bez tej tabeli z danymi transakcji baza staje się bezużyteczna. Ponieważ operacja częściowego odtwarzania wydłuża ogólny czas trwania procesu, wykonanie jej w tym przypadku byłoby złym pomysłem.
Odtwarzan e systemu RDBMS
| 445
Fizyczne powiązanie tabel i obszarów tabel Większość produktów archiwizujących bazy danych nie umożliwia odtwarzania na poziomie tabel. Jednak czasami pozwalają one na przywracanie danych na poziomie obszarów tabel. Przyjmijmy, że utracono jeden dysk. Trzeba przywrócić obszar tabel, który znajdował się na tym dysku. Zgadza się? Załóżmy, że utworzono partycjonowaną tabelę, która wchodziła w skład wielu obszarów tabel. Oznaczałoby to, że cała tabela będzie niedostępna. Jeśli tabela ta nie jest niezbędna bazie danych do normalnej pracy, jak już wspomniano, można rozważyć operację częściowego odtwarzania. Jednak trzeba pamiętać, że wydłuża ona całkowity czas trwania procesu odtwarzania. Wymóg dotyczący czasu ukończenia odtwarzania W przypadku niektórych środowisk nikt nie chce słyszeć o częściowo funkcjonujących bazach danych. „Powiedz mi, kiedy baza będzie działać. Nie mów mi, że jest częściowo lub prawie funkcjonalna. Po prostu powiedz mi, kiedy będzie to skończone!”. Firmy mające takie środowiska bardziej zwracają uwagę na ogólny czas przestoju i w związku z tym powinny być odpowiednio traktowane. Oznacza to odtworzenie bazy danych w najszybszy możliwy sposób. Prawdopodobnie sprowadzi się to do wyłączenia bazy i odtworzenia wymaganego obszaru tabel.
Dokumentacja i testowanie Odtwarzanie systemu RDBMS jest najbardziej złożoną procedurą, jaką Czytelnik ma szansę wykonać. Zwykle będzie na to przeznaczone bardzo mało czasu. Użytkownicy chcą, żeby baza danych była od razu dostępna, i naprawdę nie interesuje ich, że administrator nigdy wcześniej jej nie przywracał. Trzeba dokumentować i często testować procedury archiwizacji bazy danych, aby mieć pewność, że działają. Pomocne mogą być poniższe wytyczne. • Należy skonfigurować dodatkowy komputer pozbawiony baz danych. Nie musi to być
pojemny komputer, a nawet przeznaczony do jednego celu. Jednak będzie dobrze, jeśli na potrzeby nowego testu ponownie zainstaluje się na nim system operacyjny. Często można to zrobić po zakupie nowego komputera. Zanim naprawdę skorzysta się z procedury odtwarzania bazy danych, należy przetestować ją na tym komputerze. • Sprawdzając procedurę odtwarzania, należy przetestować ją w najgorszym scenariuszu.
Trzeba mieć pewność, że się wie, jak zainstalować produkt na nowym komputerze, i że są znane wszystkie pliki, które muszą zostać poddane edycji, żeby stały się przydatne. Właśnie z tego powodu powinno się to robić w świeżo zainstalowanym systemie operacyjnym. Dzięki temu zawsze trzeba będzie zmodyfikować na przykład uniksowy plik /etc/system i nie zapomni się o tym — co miałoby poważne konsekwencje — ponieważ plik był już edytowany. • Można utworzyć testową instancję, a następnie zarchiwizować ją i odtworzyć. Jednak
najlepszą rzeczą będzie sporządzenie normalnej kopii zapasowej bazy danych jednego z produkcyjnych serwerów i próba odtworzenia jej na komputerze testowym.
• Procedura powinna być na tyle szczegółowa, żeby mogła z niej skorzystać dowolna osoba
mająca odpowiednie umiejętności w administrowaniu systemem lub bazą danych. W miarę możliwości procedura nie powinna być sprawdzana przez osobę, która ją stworzyła. Jest to zadanie idealne dla wynajętego konsultanta. Należy sprawdzić, czy procedury może użyć ktoś, kto jest zorientowany w temacie, lecz nie zna konkretnego środowiska.
446 |
Rozdz ał 15. Arch w zowan e baz danych
• Trzeba postarać się o to, aby w testach uczestniczyli wszyscy administratorzy baz danych,
niezależnie od tego, czy mają czas, czy nie! Najgorsze, co może się przydarzyć, to sytuacja, w której tylko jedna lub dwie osoby wiedzą, jak odtworzyć bazy danych. Gdy baza się uszkodzi, może akurat być tak, że jedna z tych osób zachorowała, a druga właśnie odeszła z pracy lub spędza wakacje na Bahamach (miałem sposobność widzieć proces odtwarzania trwający wiele godzin, ponieważ administrator baz danych nie wiedział, że musiał wcisnąć klawisz Enter! Zadzwonił do mnie, mówiąc: „Człowieku, to potrwa całą wieczność!”). Trzeba się upewnić, że każdy administrator wie, jak odtworzyć podlegające mu bazy danych!
Unikatowe wymagania baz danych Specjalnym wymaganiom każdej z baz danych omówionych w tej książce, dotyczącym archiwizowania i przywracania, można by poświęcić oddzielne wydawnictwo (osobne dla każdego serwera bazodanowego). A zatem jaki jest cel tego i następnych rozdziałów? Jest on prosty: zburzyć raz i na zawsze „mur berliński” stojący między administratorami baz danych a administratorami systemów. Do tej pory, aby dowiedzieć się, jak zarchiwizować bazę danych DB2, trzeba było nabyć poświęconą jej książkę. Jednym z problemów związanych z takimi książkami jest to, że przyjmuje się w nich, że czytelnik jest administratorem baz danych! Autorzy zakładają, że dla czytelnika zrozumiałe są obszary tabel, a także dzienniki transakcji i wycofań. Efekt tego jest taki, że czytelnik nie zdobywa pełnowartościowej wiedzy. Z kolei w przypadku tej książki przyjęto jedynie, że Czytelnik przeczytał ten i inne jej rozdziały. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
Un katowe wymagan a baz danych
|
447
448 |
Rozdz ał 15. Arch w zowan e baz danych
ROZDZIAŁ 16.
Archiwizowanie i odtwarzanie bazy danych Oracle
Oracle jest bardzo popularnym komercyjnym systemem zarządzania relacyjnymi bazami danych. Baza danych Oracle może być archiwizowana przy użyciu dwóch różnych metod, z których każda ma swoje zalety i wady, jak również zagorzałych zwolenników i przeciwników.
Dwie metody archiwizowania Metoda archiwizacji i przywracania z najdłuższą historią obecnie jest określana mianem metody kopii zapasowych zarządzanych przez użytkownika. Metoda ta polega na przełączeniu bazy Oracle w stan „przyjazny dla archiwizacji” i zarchiwizowaniu jej plików za pomocą dowolnego narzędzia, które przyjdzie na myśl. Po utworzeniu kopii zapasowej plików bazę danych można przełączyć z tego stanu na normalny. Choć metoda kopii zapasowych zarządzanych przez użytkownika jest udokumentowana i obsługiwana, nie jest tą, którą obecnie firma Oracle polecałaby swoim klientom. Preferowana metoda archiwizowania baz danych Oracle wykorzystuje narzędzie Recovery Manager (rman), które po raz pierwszy pojawiło się w wersji 8. serwera Oracle. W celu archiwizacji bazy danych Oracle na dysku lub taśmie program rman może być zastosowany razem z komercyjnym oprogramowaniem archiwizującym lub niezależnie od niego. W porównaniu z metodą kopii zapasowych zarządzanych przez użytkownika program ten oferuje kilka korzyści, takich jak tworzenie przyrostowych kopii zapasowych, sprawdzanie spójności danych, przywracanie nośnika na poziomie bloków i zautomatyzowane odtwarzanie. Dla osób, które dopiero dowiedziały się o istnieniu narzędzia rman, szczególnie jest polecana jego nowa i ulepszona wersja dołączona do serwera Oracle 10g. Gdy ta książka była pisana, mniej więcej połowa społeczności użytkowników bazy danych Oracle korzystała z programu rman, a reszta stosowała metodę kopii zapasowych zarządzanych przez użytkownika. Oba rozwiązania zostaną omówione w tym rozdziale. Na początek należy je ze sobą porównać.
449
rman W porównaniu z metodą kopii zapasowych zarządzanych przez użytkownika narzędzie rman ma kilka zalet. Pierwsza jest taka, że na prace rozwojowe i badawcze związane z programem rman jest przeznaczanych znacznie więcej funduszy niż w przypadku metody kopii zapasowych zarządzanych przez użytkownika. W ciągu kilku ostatnich lat metoda ta nie zmieniła się znacząco, natomiast w tym samym czasie do narzędzia rman dodano kilkadziesiąt funkcji. Program rman ma kilka funkcji, które nigdy nie będą dostępne w przypadku metody kopii zapasowych zarządzanych przez użytkownika. Przyrostowe kopie zapasowe Narzędzie rman może tworzyć kopie zapasowe zawierające bloki, które zmieniły się od czasu sporządzenia ostatniej pełnej kopii. W przypadku serwera Oracle 10g znacząco poprawiono wydajność procesu tworzenia przyrostowych kopii zapasowych. Przyrostowe aktualizowanie kopii zapasowych Jeśli korzysta się z dysku jako docelowego urządzenia programu rman, możliwe jest wykonanie najnowszej przyrostowej kopii zapasowej i scalenie jej z pełną kopią znajdującą się już na dysku. Tym sposobem uzyskuje się nową pełną kopię zapasową bez potrzeby tworzenia jej od nowa. Sprawdzanie spójności danych Dotychczas w celu sprawdzenia spójności bloków dysku trzeba było przeprowadzić operację eksportowania bazy danych Oracle. Obecnie narzędzie rman sprawdza integralność w ramach archiwizacji. Przywracanie uszkodzonego pliku danych na poziomie bloków Jeżeli program rman zidentyfikuje jakiekolwiek uszkodzone bloki pliku danych, może je przywrócić (jeden blok naraz). Zautomatyzowane odtwarzanie i przywracanie Gdy narzędziu rman nakaże się odtworzenie bazy danych, stwierdzi, co musi być przywrócone, i automatycznie przeprowadzi proces. Wiele innych funkcji Firma Oracle kontynuuje dodawanie do programu rman wielu funkcji, z których żadna nie będzie dostępna w przypadku metody kopii zapasowych zarządzanych przez użytkownika. W porównaniu z metodą kopii zapasowych zarządzanych przez użytkownika program rman ma dwie wady: krzywą uczenia i koszt. Choć metoda ta nie jest łatwa do opanowania, istnieje znacznie dłużej i jest zrozumiała dla wielu administratorów baz danych. W dalszym ciągu wielu takich administratorów podchodzi do narzędzia rman z obawą. Często wynika to z konieczności przeczytania obszernej dokumentacji. Druga wada powoduje, że trzeba archiwizować dane na dysku lub nabyć dodatkowy menedżer nośników, który umożliwi zapisywanie kopii zapasowych na taśmie. Niektóre firmy nie dysponują środkami na dysk o pojemności wystarczającej do pomieszczenia kopii całej bazy danych (nawet po zastosowaniu kompresji). Jednak mają napęd taśmowy, na którym za pomocą programu dump, tar, cpio lub ntbackup mogą zapisać zarchiwizowane dane. Jeśli firma nie ma pieniędzy na pojemniejszy dysk, nie będzie też jej stać na komercyjny menedżer nośników pozwalający archiwizować dane na taśmie.
450 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Jeżeli Czytelnikowi zależy na zaletach programu rman, lecz nie chce kupować komunikującego się z nim interfejsu komercyjnego narzędzia archiwizującego, w inny sposób może umożliwić współpracę tego oprogramowania. Polega on na zarchiwizowaniu bazy danych na dysku za pomocą programu rman, a następnie sporządzeniu kopii zapasowej zawartości tego dysku przy użyciu stosowanego narzędzia archiwizującego. Choć nie jest to idealne rozwiązanie, lepsze to niż nic.
Kopie zapasowe zarządzane przez użytkownika Największym plusem metody kopii zapasowych zarządzanych przez użytkownika jest jej długa historia. Dla każdego administratora, który od dłuższego czasu ma do czynienia z bazą danych Oracle, prawdopodobnie metoda ta będzie zrozumiała. Wykonanie kopii zapasowych zarządzanych przez użytkownika może być dość proste, zwłaszcza wtedy, gdy można wyłączyć bazę danych, aby sporządzić „zimną” kopię zapasową. Zamknięcie bazy danych to wszystko, co trzeba zrobić przed zarchiwizowaniem systemu plików w standardowy sposób za pomocą dowolnego narzędzia. Jeśli nie można wyłączyć bazy, należy przełączyć ją w tryb archiwizacji (omówiono go w dalszej części rozdziału) i sporządzić kopię zapasową. Po przeprowadzeniu archiwizacji należy uruchomić bazę danych lub przełączyć ją do normalnego trybu pracy. Taka procedura pozwala zintegrować kopie zapasowe bazy danych Oracle z dowolnym narzędziem archiwizującym bez konieczności płacenia za jego interfejs komunikujący się z programem rman. Choć program ten jest darmowy, współpracujący z nim interfejs używanego narzędzia archiwizującego darmowy z pewnością nie będzie. Koszt takich interfejsów w przeliczeniu na serwer to kilka tysięcy złotych. W celu połączenia się z bazami danych Oracle 9i i 10g w rozdziale użyto poleceń sqlplus /nolog i connect /as sysdba. Jeśli korzysta się z bazy Oracle 9i, można wykonać polecenia svrmgrl i connect internal (w dalszej części rozdziału zostaną podane naprawdę znakomite powody, dla których warto przeprowadzić aktualizację serwera bazodanowego Oracle do wersji 10g).
Architektura bazy danych Oracle Jak wspomniano w rozdziale 15., ważne jest zrozumienie architektury archiwizowanej bazy danych. W związku z tym niniejszy rozdział należy rozpocząć od omówienia budowy bazy Oracle. Choć w poprzednim rozdziale podano podobne informacje, w tym rozdziale skoncentrowano się na szczegółach dotyczących bazy danych Oracle. Tak jak w rozdziale 15. najpierw zostanie przedstawiona baza danych z punktu widzenia zaawansowanego użytkownika, a następnie administratora baz. W tym rozdziale zastosowano terminy specyficzne dla serwera Oracle. Aby sprawdzić, jak określony termin jest powiązany z pojęciem używanym w przypadku baz danych: DB2, SQL Server, Sybase, należy zajrzeć do rozdziału 15. Na tyle, na ile było to możliwe, elementy architektury bazy danych omówiono zgodnie z kolejnością prezentowania ich na rysunku 15.1. Jako pierwsze opisano elementy, które są używane do objaśnienia innych elementów. Przykładowo przed omówieniem przeznaczenia polecenia backup tablespace zostało wyjaśnione, czym jest obszar tabel.
Arch tektura bazy danych Oracle
|
451
Punkt widzenia zaawansowanego użytkownika Jeśli zaawansowany użytkownik nie chce wykonać zadania administratora baz danych polegającego na zaprojektowaniu bazy, poniższe terminy powinny być wszystkim, co będzie mu w ogóle potrzebne. Punkt widzenia zaawansowanego użytkownika można też nazwać logicznym, ponieważ wiele opisanych tu elementów nie występuje w fizycznej postaci.
Instancja Instancja jest zbiorem procesów, za pośrednictwem których baza danych Oracle komunikuje się ze wspólną pamięcią. Pamięć tę baza danych wykorzystuje na swoje potrzeby. Często na jednym komputerze istnieje więcej niż jedna instancja. Gdy uaktywni się instancję serwera Oracle, powiązana z nią baza danych staje się dostępna. W przypadku komputera z systemem Linux lub Unix instancja może być identyfikowana przez zestaw procesów mających w nazwie wzorzec ora_funkcja_SID, w którym łańcuch funkcja pozwala stwierdzić, jaka funkcja serwera Oracle jest stosowana dla procesu. Z kolei łańcuch SID określa nazwę instancji. Gdy korzysta się z systemu Windows, każda instancja serwera Oracle ma własną usługę o nazwie OracleServiceSID, w której łańcuch SID identyfikuje nazwę instancji. W przypadku systemu Linux lub Unix instancja jest automatycznie uruchamiana za pomocą skryptu dbstart, a zamykana przez skrypt dbshut. W celu ręcznego zatrzymywania lub uaktywniania serwera Oracle można posłużyć się tymi skryptami lub poleceniami narzędzia SQL*Plus. W systemie Unix lub Linux skrypty takie trzeba umieścić w odpowiednim katalogu i utworzyć dla nich dowiązania symboliczne, żeby po ponownym załadowaniu systemu były automatycznie wykonywane. Aby instancje w systemie Windows były uaktywniane i zamykane automatycznie, w oknie panelu sterowania dla odpowiedniej usługi OracleServiceSID powinno się włączyć automatyczne uruchamianie (jeśli w panelu nie można znaleźć usługi OracleServiceSID, można ją utworzyć za pomocą narzędzia oradim). W dalszej kolejności trzeba nakazać serwerowi Oracle, aby automatycznie uaktywniał bazę danych po uruchomieniu usługi. W tym celu w oknie Administrative Assistant należy prawym przyciskiem myszy kliknąć SID i z menu wybrać pozycję Startup/Shutdown Options. Po uaktywnieniu karty Oracle Instance należy zaznaczyć opcję Start up instance when service is started lub Shut down instance when service is stopped, bądź obie opcje.
Baza danych Baza danych jest tym, o czym myśli większość osób korzystających z serwera Oracle. Wynika to stąd, że w bazie znajdują się dane! Baza danych jest zbiorem plików zawierających tabele, indeksy i inne ważne obiekty bazodanowe. Jeśli nie używa się klastrów Oracle RAC (Real Application Clusters), między instancjami i bazami danych będzie występować relacja typu jeden do jednego. Bez technologii RAC baza danych łączy się z tylko jedną instancją, a instancja podłącza wyłącznie jedną bazę. Klastry RAC obsługują wiele instancji (najprawdopodobniej znajdujących się na kilku serwerach), które współużytkują pojedynczą bazę danych. Właśnie z tego powodu administratorzy baz danych często zamiennie stosują te dwa terminy. Jednak z technicznego punktu widzenia instancja jest zestawem procesów, za których pośrednictwem baza danych komunikuje się z segmentami wspólnej pamięci serwera Oracle. Z kolei baza danych jest zbiorem plików przechowujących dane. 452 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Tabela Tabela jest zbiorem powiązanych wierszy mających identyczne atrybuty. W przypadku bazy danych Oracle można wyróżnić trzy typy tabel: relacyjne, obiektowe i XML.
Indeks Indeks bazy danych to analogia indeksu książki. Umożliwia bazie Oracle szybkie odszukanie danych. Indeks bazy Oracle jest taki sam jak dowolny inny indeks i nie ma żadnych specjalnych wymagań dotyczących archiwizowania. Indeks to obiekt pochodny, ponieważ tworzy się go na podstawie atrybutów innej tabeli. Oznacza to, że indeks można odbudować podczas procesu przywracania. Zwykle ponowne utworzenie indeksu będzie szybsze od jego odtworzenia. Baza danych Oracle oferuje kilka rodzajów indeksów, w tym takie, jak zwykły, bitmapowy, partycjonowany, oparty na funkcji i domenowy.
Typy danych dużych obiektów Oracle 8 dysponuje specjalnymi typami danych: BLOB, CLOB i BFILE, służącymi do przechowywania dużych obiektów, takich jak tekst lub grafika. Dane typów BLOB i CLOB nie stawiają żadnych szczególnych wymagań związanych z archiwizowaniem, ponieważ są magazynowane w samej bazie danych (typ BLOB zwykle jest używany do przechowywania plików obrazów, a CLOB — danych tekstowych). Jednak typ danych BFILE jest wykorzystywany do przechowywania w bazie danych wyłącznie wskaźnika do pliku, który w rzeczywistości znajduje się gdzieś w obrębie systemu plików serwera bazodanowego. W czasie archiwizowania trzeba zwrócić szczególną uwagę na tę kwestię. Więcej informacji można znaleźć w podpunkcie „Duże obiekty” w rozdziale 15.
Obiekt Obiekt jest dowolnego typu obiektem bazodanowym, takim jak tabela lub indeks. W rzeczywistości jest to bardziej termin ogólny niż ściśle związany z bazą danych Oracle. Niestety, firma Oracle posługuje się też terminem obiekt w odniesieniu do komponentu wielokrotnego użycia tworzonego przez instrukcje zorientowanego obiektowo języka programowania SQL. Tu jednak termin ten pełni jedynie rolę ogólnego identyfikatora odwołującego się do dowolnego typu tabeli, indeksu lub innej jednostki wchodzącej w skład bazy danych Oracle.
Wiersz Wiersz jest zbiorem powiązanych ze sobą atrybutów, takich jak wszelkiego rodzaju informacje dotyczące konkretnego klienta. Baza danych Oracle może też posługiwać się równorzędnym terminem rekord.
Atrybut Atrybut (nazywany również kolumną lub polem) jest dowolną konkretną wartością znajdującą się w wierszu.
Arch tektura bazy danych Oracle
| 453
Punkt widzenia administratora baz danych Po przedstawieniu logicznej struktury bazy danych Oracle zajmijmy się fizyczną. Ponieważ tylko administrator baz danych powinien zapoznać się z tym zagadnieniem, niniejszy punkt zatytułowano „Punkt widzenia administratora baz danych”.
Bloki Blok jest najmniejszą porcją danych, która może być przemieszczana w obrębie bazy. Serwer Oracle pozwala na określenie dla każdej instancji niestandardowego rozmiaru bloku, który zawiera się w przedziale od 2 do 32 kB. Dla każdego obszaru tabel (definicję zamieszczono poniżej) można ustawić inny rozmiar bloku. W przypadku innych systemów RDBMS blok jest określany mianem strony.
Zakresy Zakres jest zbiorem ciągłych bloków bazy danych Oracle, traktowanych jako jedna całość. Rozmiar zakresu zmienia się w zależności od kombinacji różnych czynników. Najważniejszym z nich jest metoda przydzielania przestrzeni obszaru tabel określana podczas jego tworzenia.
Segment Segment jest zbiorem zakresów przypisanych obiektowi bazodanowemu (tabela, indeks itp.). Zależnie od rodzaju obiektu zakresy mogą być przydzielane lub odbierane w celu spełnienia wymagań określonej tabeli związanych z magazynowaniem. Choć baza danych Oracle 8 korzystała z segmentu wycofywania, w nowszych wersjach zastąpiono go segmentem powrotu przechowywanym w obszarze tabel powrotu (należy zapoznać się z zamieszczonymi dalej podpunktami „Obszar tabel” i „Obszar tabel powrotu”).
Plik danych Plik danych bazy Oracle może być magazynowany na niesformatowanym urządzeniu dyskowym lub w obrębie systemu plików. Gdy pliki danych są utworzone, sposób pracy z nimi jest taki sam zarówno w przypadku niesformatowanego urządzenia, jak i systemu plików. Jeśli jednak pliki danych bazy Oracle nie są archiwizowane za pomocą narzędzia rman, skrypty archiwizujące będą musiały wziąć pod uwagę ich typ. Jeżeli skrypt taki obsługuje pliki danych zapisane na niesformatowanych partycjach, konieczne będzie zastosowanie programu dd lub innego polecenia, które umożliwia archiwizowanie tego typu partycji. Użycie narzędzia cp lub tar nic nie da, ponieważ obsługują one wyłącznie pliki systemów plików. Każdy plik danych bazy Oracle zawiera specjalny blok nagłówka przechowujący numer SCN pliku (System Change Number). Numer ten jest przypisywany każdej transakcji. Numer SCN każdego pliku danych jest aktualizowany każdorazowo, gdy w pliku została wprowadzona zmiana. Aktualną wartość numeru SCN przechowuje plik kontrolny. Po uruchomieniu instancji aktualny numer SCN jest porównywany z numerem SCN każdego pliku danych (należy zapoznać się z podpunktem „Plik kontrolny” w dalszej części rozdziału).
454 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Należy zwrócić uwagę na istotne omówienie w zamieszczonym dalej punkcie „Rozwianie mitów związanych z „gorącymi” kopiami zapasowymi” roli pełnionej przez numer SCN podczas tworzenia „gorącej” kopii zapasowej.
Obszar tabel Obszar tabel jest wirtualnym obszarem, w którym administrator baz danych tworzy tabele i inne obiekty. Obszar ten składa się z jednego lub większej liczby plików danych i jest generowany za pomocą polecenia create tablespace nazwa_obszaru_tabel datafile urządzenie. W obszarze tabel może znajdować się kilka tabel. Miejsce zajmowane przez każdy obiekt (np. tabelę) w obszarze tabel jest nazywane segmentem (definicję zamieszczono wcześniej). W przypadku wersji 10g serwera Oracle każda jego baza danych dysponuje przynajmniej trzema obszarami tabel: systemowym, sysaux i powrotu. Systemowy obszar tabel przechowuje dane słownikowe, programy PL/SQL, definicje widoków i innego typu informacje dotyczące całej instancji. W obszarze tabel sysaux znajdują się tabele i indeksy niesystemowe, które tradycyjnie umieszczano w systemowym obszarze tabel. Rozwinięcie nazwy sysaux brzmi auxiliary system. Obszar tabel powrotu zawiera segmenty powrotu, które zastąpiły segmenty wycofywania. Biorąc pod uwagę archiwizowanie i przywracanie, podstawowa różnica między tymi obszarami tabel a pozostałymi jest taka, że te pierwsze muszą być odtwarzane w trybie offline. Wynika to stąd, że bez tych obszarów tabel instancja nie może zostać uaktywniona. Inne obszary tabel mogą być przywracane po uruchomieniu instancji.
Partycja Tabelę lub indeks można podzielić na porcje nazywane partycjami, które w celu poprawienia wydajności i dostępności mogą być rozmieszczone w obrębie wielu obszarów tabel. Dopóki archiwizuje się wszystkie obszary tabel, partycjonowane tabele nie stanowią żadnego wyzwania dla procesów archiwizowania i przywracania.
Plik kontrolny Plik kontrolny jest pewnego rodzaju bazą rejestrującą status wszystkich plików, które tworzą określoną bazę danych. Ponadto plik kontrolny utrzymuje metadane archiwizacyjne narzędzia rman, a także dysponuje informacjami na temat wszystkich obszarów tabel, plików danych, dzienników archiwum i powtórzeń znajdujących się w bazie danych. Plikowi kontrolnemu znany jest również aktualny status wszystkich tych plików, ponieważ rejestruje numer SCN każdego obiektu. Każdej transakcji jest przypisywany numer SCN. Każdorazowo po wprowadzeniu zmiany numer SCN jest aktualizowany zarówno w pliku kontrolnym, jak i w każdym pliku danych (należy zapoznać się z wcześniejszym podpunktem „Plik danych”). Dzięki temu, gdy instancja jest uaktywniana, plik kontrolny zawiera zapis numeru SCN, jaki plik powinien mieć, i porównuje go z numerem SCN, który plik ma. W ten sposób plik kontrolny stwierdza, że plik jest starszy od niego i niezbędne jest przywracanie. Ponadto, gdy będzie używany starszy plik kontrolny, serwer Oracle stwierdzi, że numer SCN plików danych jest większy od numerów zarejestrowanych w tym pliku kontrolnym. Właśnie w takiej sytuacji serwer Oracle wyświetli komunikat o błędzie datafile is more recent than the controlfile (plik danych jest nowszy od pliku kontrolnego).
Arch tektura bazy danych Oracle
| 455
Jeśli tworzy się kopie zapasowe zarządzane przez użytkownika, pliki kontrolne powinny być archiwizowane za pomocą poleceń backup controlfile to nazwa_pliku i backup controlfile to trace. Jeżeli korzysta się z narzędzia rman, można zastosować polecenie backup controlfile lub nakazać programowi rman automatyczne sporządzanie kopii zapasowej pliku kontrolnego każdorazowo podczas przeprowadzania archiwizacji (w tym celu dla parametru controlfile autobackup należy ustawić wartość on). W oknie narzędzia sqlplus powinno się też wykonać polecenie backup controlfile to trace. Dodatkowo dobrą praktyką jest skopiowanie wyników tego polecenia w znane miejsce, aby bez problemów skorzystać z nich w czasie przywracania. W podrozdziale „Przywracanie bazy danych Oracle” zostanie zaprezentowana sytuacja, w której wynik tego polecenia okaże się całkiem przydatny. Odtwarzanie plików kontrolnych jest trochę złożone. Przebieg tej operacji omówiono w podrozdziale „Przywracanie bazy danych Oracle” w dalszej części rozdziału. Kopię zapasową pliku kontrolnego trzeba zapisać w pliku lub sporządzić za pomocą narzędzia rman; należy także zarchiwizować plik kontrolny, wykonując polecenie backup controlfile to trace.
Najlepiej unikać odtwarzania lub odbudowywania pliku kontrolnego. W tym celu pliki kontrolne należy powielać w obrębie serwera Oracle, korzystając z funkcji nazywanej przez firmę Oracle multipleksowaniem. Umożliwia ona utworzenie dwóch lub większej liczby kopii pliku kontrolnego. Każda z kopii jest zapisywana każdorazowo, gdy plik kontrolny jest uaktualniany. Nie należy mylić terminu multipleksowanie używanego przez firmę Oracle z jego znaczeniem w przypadku wszelkich innych zastosowań związanych z archiwizowaniem i przywracaniem (wysyłanie do pojedynczego napędu taśmowego jednocześnie wielu strumieni archiwizowanych danych). Aby zminimalizować ryzyko nieporozumień, w niniejszym rozdziale multipleksowanie firmy Oracle jest określane mianem multipleksowania (powielania).
Multipleksowanie (powielanie) nieznacznie różni się od powielania na poziomie dysków i oferuje dodatkowy poziom ochrony. W przypadku powielania na poziomie dysków jeden plik kontrolny jest kopiowany na wielu dyskach przy wykorzystaniu technologii RAID 1. W ten sposób można ochronić się przed awarią dysku, lecz nie przed ludzkim błędem. Jeśli ktoś omyłkowo usunie plik kontrolny, zostanie on również natychmiast usunięty z każdego dysku, na którym był powielany. Przechowywanie multipleksowanych (powielanych) plików kontrolnych na oddzielnych dyskach zabezpiecza przed awarią dysku, jak również przypadkowym usunięciem. Jeśli pojedynczy plik kontrolny zostanie usunięty lub uszkodzony, instancja przestanie funkcjonować. Jednakże usunięty lub uszkodzony plik kontrolny z łatwością można odtworzyć, korzystając z jednej z multipleksowanych kopii. Gdy tak się postąpi, instancja znów zacznie normalnie działać. Trzeba się upewnić, że pliki kontrolne multipleksuje (powiela się) na oddzielnych dyskach. Pliki te zajmują bardzo niewiele miejsca i zapewniają niebywałą elastyczność związaną z przywracaniem.
456 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Transakcja Transakcja jest dowolną operacją wykonywaną przez użytkownika lub administratora baz danych, która powoduje zmianę jednego lub większej liczby atrybutów bazy danych Oracle (zestaw poleceń zakończony instrukcją commit jest traktowany jak jedna transakcja). Na poziomie logicznym transakcja modyfikuje jeden lub kilka atrybutów. Jednak ostatecznie na poziomie fizycznym jest zmieniany jeden lub większa liczba bloków bazy danych Oracle.
Obszar tabel powrotu Dane powrotu mają trzy zastosowania. Pierwszym z nich jest wycofywanie przerwanej transakcji lub takiej, która w momencie awarii bazy danych nie była jeszcze zatwierdzona. Tego typu dane zapewniają też spójny odczyt wymagany przez długo wykonywane zapytania (należy zajrzeć do podrozdziału „Zgodność z modelem ACID” w rozdziale 15.). Dane powrotu mogą również być użyte przez funkcję Flashback bazy danych Oracle, która pozwala ręcznie wycofywać transakcje. Z tych powodów ważne jest, żeby jak najdłużej przechowywać dane powrotu. Przed pojawieniem się wersji 9i odwoływanie było obsługiwane za pomocą segmentów wycofywania. W przypadku tych segmentów największym wyzwaniem była próba określenia rozmiaru, jaki powinny mieć. Jeśli były zbyt duże, tracono przestrzeń dyskową. Gdy okazały się za małe, był generowany niemiły komunikat o błędzie ORA-01555 snapshot too old, wskazujący, że długo wykonywane zapytanie nie było w stanie uzyskać spójnego odczytu. W przypadku zarządzania bardzo aktywną bazą danych z mnóstwem długich transakcji lub długo realizowanych zapytań mogłoby to stanowić poważny problem. W serwerze Oracle 9i wprowadzono funkcję automatycznego zarządzania danymi powrotu AUM (Automatic Undo Management). Choć nadal można ręcznie zarządzać tymi danymi za pomocą segmentów wycofywania, komuś, kto uświadomi sobie wartość funkcji AUM, trudno będzie zrozumieć, dlaczego miałby z niej zrezygnować. Konfigurując bazę danych Oracle, można obecnie utworzyć obszar tabel powrotu. Serwer Oracle automatycznie wygeneruje w tym obszarze segmenty powrotu, zamiast wymagać ręcznego tworzenia segmentów wycofywania. Funkcja AUM eliminuje skomplikowane administrowanie obszarem segmentów wycofywania i umożliwia ustalenie, przez jaki czas dane powrotu będą utrzymywane, zanim zostaną nadpisane. Firma Oracle mocno namawia do używania na potrzeby zarządzania danymi powrotu obszarów tabel powrotu zamiast segmentów wycofywania. Początkowo ciężko odróżnić obszary tabel przeznaczone dla segmentów wycofywania i segmentów powrotu. Być może pomocne będzie wyjaśnienie tego, w jaki sposób serwer Oracle zarządza automatycznym usuwaniem starszych danych powrotu. Za pomocą parametru undo_retention można określić minimalny czas, przez który dane powrotu będą utrzymywane. Gdy serwer Oracle wymaga miejsca na dodatkowe dane powrotu, robi wszystko, żeby przestrzegać wartości ustawionej dla tego parametru. W tym celu w pierwszej kolejności usuwa najstarsze, nieaktualne dane powrotu. Jeśli jednak w obszarze tabel powrotu zabraknie miejsca, serwer Oracle może zacząć usuwać ważne dane powrotu, co może, niestety, spowodować wygenerowanie tego samego komunikatu o błędzie, ORA-01555 snapshot too old, co w przypadku segmentów wycofywania. Jeżeli dla obszaru tabel powrotu włączy się opcję autoextend, obszar automatycznie zwiększy swój rozmiar do maksymalnej wielkości, którą podano. Zautomatyzowane zarządzanie miejscem jest tym, co sprawiło, że funkcja AUM stała się tak popularna.
Arch tektura bazy danych Oracle
|
457
Punkt kontrolny Punkt kontrolny identyfikuje chwilę, w której wszystkie zmodyfikowane dane przechowywane w pamięci są zapisywane na dysku. Choć w przypadku serwera Oracle administrator baz danych za pomocą polecenia alter system checkpoint może wymusić wystąpienie punktu kontrolnego, dzieje się to samoczynnie każdorazowo, gdy baza danych przełącza na inną grupę aktywnych dzienników powtórzeń.
Obszar dyskowy FRA (Flash Recovery Area) Składniki tworzące różne pliki związane z archiwizowaniem i przywracaniem (na przykład narzędzie rman oraz polecenia alter database backup controlfile i alter system switch logfile) nie dysponują żadnymi informacjami ani na swój temat, ani na temat dostępnej przestrzeni systemu plików, w obrębie którego są przechowywane dane. Jednym z poważnych powodów, dla których warto zaktualizować serwer Oracle do wersji 10g, jest oferowany przez nią obszar dyskowy FRA, który rozwiązuje powyższy problem przez automatyczne zarządzanie plikami związanymi z archiwizacją. Kolejno należy wybrać lokalizację na dysku, ustalić górny limit dla przestrzeni dyskowej i utworzyć zasadę retencji, która decyduje o tym, przez jaki czas pliki kopii zapasowych będą wymagane na potrzeby przywracania. Baza danych samoczynnie zarządza miejscem przechowywania kopii zapasowych, archiwalnych dzienników powtórzeń i innych plików niezbędnych do przywrócenia bazy. W celu utworzenia obszaru dyskowego FRA należy określić wartości dla parametrów db_recovery_ ¦file_dest i db_recovery_file_size, znajdujących się w pliku startowym. Aby archiwalne dzienniki były umieszczane w obszarze dyskowym FRA, jako wartość jednego z parametrów log_archive_dest_n należy ustawić location = use_db_recovery_file_dest.
Dziennik powtórzeń Jeśli obszar tabeli powrotu lub segmenty wycofywania zawierają informacje umożliwiające wycofanie transakcji, w dzienniku powtórzeń znajdują się dane pozwalające ponownie zrealizować transakcje. Serwer Oracle zapisuje w dzienniku powtórzeń wektor zmiany za każdym razem, gdy musi zmodyfikować plik na dysku. Oznacza to, że serwer rejestruje to, w jaki sposób zmodyfikowano blok, a nie samą wartość uzyskaną po wprowadzeniu zmiany. Pomocne może tu być matematyczne objaśnienie. Załóżmy, że istnieje zmienna o wartości 100, do której dodano 1. W celu zarejestrowania wektora zmiany należałoby zapisać +1. Aby zapisać zmodyfikowaną wartość, należałoby zarejestrować 101. W taki właśnie sposób normalnie funkcjonujący serwer Oracle umieszcza informacje w dziennikach powtórzeń. Jak wyjaśniono nieco dalej w punkcie „Rozwianie mitów związanych z „gorącymi” kopiami zapasowymi”, gdy obszar tabel nie jest w trybie tworzenia „gorącej” kopii zapasowej, serwer Oracle dokonuje przełączenia, żeby zarejestrować zmienioną wartość. Podczas trwania procesu przywracania dziennik powtórzeń służy do ponownego wykonania transakcji, które miały miejsce od ostatniego punktu kontrolnego lub od czasu sporządzenia kopii zapasowej użytej do odtwarzania. Serwer Oracle można tak skonfigurować, aby można było korzystać z dzienników powtórzeń zarówno online, jak i offline (archiwalne dzienniki).
458 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Dzienniki powtórzeń online i offline odgrywają kluczową rolę w przypadku przywracania po wystąpieniu awarii bazy danych lub dysku. W związku z tym należy dowiedzieć się jak najwięcej na temat działania tych dzienników i chronić je jak prawdziwy skarb!
Początkowo było kilka (zwykle trzy) plików dzienników powtórzeń online, w których serwer Oracle umieszczał wpisy dla każdej transakcji. W przypadku takiego rozwiązania problem polegał na tym, że dziennik, do którego serwer Oracle w danej chwili zapisywał dane, zawsze przechowywał jedyną kopię najbardziej aktualnych wpisów dotyczących transakcji. Jeśli zepsuł się dysk, na którym zapisano ten dziennik, serwer Oracle nie był w stanie przywrócić danych do momentu wystąpienia tego nieszczęśliwego zdarzenia. Właśnie z tego powodu oprócz multipleksowania (powielania) pliku kontrolnego serwer Oracle obsługuje też multipleksowanie (powielanie) dzienników powtórzeń. Zamiast korzystać z pojedynczych dzienników powtórzeń, obecnie informacje można zapisywać w grupie takich dzienników. Grupa dzienników jest zestawem liczącym jeden lub więcej plików jednocześnie zapisywanych przez serwer Oracle. W zasadzie jest to mechanizm powielania dzienników powtórzeń. Można temu wierzyć lub nie, ale wymagane jest, aby w każdej grupie dzienników znajdował się tylko jeden członek. Oczywiście, jeśli jednak w grupie nie będzie wielu członków, nie okaże się zbytnio pomocna. Typową praktyką jest umieszczenie trzech członków w każdej grupie dzienników znajdującej się na oddzielnym dysku (często są to te same urządzenia, na których powiela się pliki kontrolne). Poszczególne pliki wchodzące w skład grupy dzienników są nazywane członkami. Każda taka grupa jest traktowana jak niezależny plik dzienników. Wszystkie wpisy transakcji są jednocześnie rejestrowane na wszystkich dyskach wykorzystywanych przez aktywną grupę dzienników. Zamiast trzech lub większej liczby oddzielnych plików, z których uszkodzenie dowolnego może sprawić, że baza danych będzie bezużyteczna, istnieją trzy lub większa liczba niezależnych grup dzienników złożonych z multipleksowanych (powielanych) plików. Jeśli każdej takiej grupie przypisze się więcej niż jednego członka, każda transakcja będzie rejestrowana w więcej niż jednym miejscu. Po wystąpieniu awarii serwer Oracle może wczytać dowolnego z tych członków, aby przeprowadzić proces przywracania. Serwer Oracle w cykliczny sposób zapisuje dane w grupach dzienników. Najpierw umieszcza dane w jednej grupie dzienników aż do jej zapełnienia. W dalszej kolejności następuje przełączenie dzienników, po czym serwer zaczyna zapisywać w następnej grupie dzienników. Od razu, gdy to nastąpi, właśnie wypełniona grupa dzienników jest kopiowana do pliku archiwalnych dzienników powtórzeń (pod warunkiem że baza danych działa w trybie archivelog i włączono automatyczne archiwizowanie). Jeśli nie uaktywniono trybu archivelog, grupa dzienników nie zostanie skopiowana i po prostu jej zawartość zostanie nadpisana, gdy serwer Oracle uzna za konieczne zapisywanie informacji w tej grupie. Jeżeli nie włączono automatycznego archiwizowania, instancja zawiesi się, gdy serwer Oracle będzie musiał dokonać zapisu w dzienniku powtórzeń, którego nie zarchiwizowano. W przypadku klientów używających wersji bazy danych Oracle innej niż Enterprise każdy z dzienników powtórzeń online jest kopiowany jako plik, którego nazwa jest określana przez wartość jednego lub większej liczby parametrów log_archive_dest_n, a następnie przez inkrementowany łańcuch, będący wartością parametru log_archive_format. Dla przykładu przyjmijmy, że dla parametru log_archive_dest_0 ustawiono wartość /archivelogs/arch, a dla parametru log_archive_format — wartość %s.log (%s jest zmienną serwera Oracle identyfikującą aktualny numer sekwencyjny). Jeśli bieżący numer sekwencyjny wynosi 293, zawartość katalogu archivelogs może wyglądać tak: Arch tektura bazy danych Oracle
| 459
# cd /archivelogs/arch # ls -l arch* arch291.log arch292.log arch293.log
Parametr log_archive_dest_n jest rozszerzoną wersją parametru log_archive_dest. Choć dla parametru log_archive_dest można określić tylko jedną docelową lokalizację, jest możliwe zastosowanie wielu parametrów log_archive_dest_n, dla których można ustawić katalog lub obszar dyskowy FRA (stosując parametr db_recovery_file_dest; należy zapoznać się z podpunktem „Obszar dyskowy FRA (Flash Recovery Area)” zamieszczonym wcześniej w rozdziale). Zależnie od stopnia aktywności bazy danych, po jakimś czasie w katalogu będącym docelową lokalizacją archiwalnych dzienników może być kilkaset plików. Jeżeli archiwalne dzienniki umieści się bezpośrednio w katalogu, serwer Oracle nie będzie nim zarządzać. Jeśli jednak dzienniki te wyśle się do obszaru dyskowego FRA, serwer Oracle zajmie się zarządzaniem nim za administratora. Gdy samemu zarządza się przestrzenią dyskową, trzeba będzie utworzyć zadanie programu cron, które będzie czyścić zawartość docelowych lokalizacji archiwalnych dzienników. Dopóki pliki te są archiwizowane na określonego typu nośniku, mogą być usuwane po upływie kilku dni. Jednakże im więcej dzienników znajduje się na dysku, w tym lepszej sytuacji baza danych się znajdzie, ponieważ czasami może być konieczne odtworzenie z kopii zapasowej, która nie jest tą najnowszą (przykładowo może do tego dojść, gdy bieżący wolumin archiwizacyjny uszkodzi się). Jeśli są dostępne wszystkie archiwalne dzienniki istniejące od czasu utworzenia starej kopii zapasowej, nie ma żadnego problemu. W przeciwnym razie dzienniki te też trzeba odtworzyć. W przypadku wielu środowisk coś takiego może spowodować problem z dostępnym miejscem. Właśnie z tego powodu zalecam dysponowanie przestrzenią dyskową wystarczającą do przechowania archiwalnych dzienników obejmujących swoim zakresem dwa cykle archiwizacyjne. Jeśli na przykład każdej nocy system sporządza pełną kopię zapasową bazy danych, powinno być miejsce na dysku wystarczające do magazynowania w trybie online dzienników powtórzeń co najmniej z okresu dwóch dni. Gdy baza jest archiwizowana raz w tygodniu, powinna być dostępna przestrzeń dyskowa będąca w stanie pomieścić dzienniki transakcji z dwóch tygodni (jest to następny powód, dla którego warto co noc archiwizować dane). Podsumowując, dzienniki powtórzeń trybu online znajdują się zwykle w trzech lub większej liczbie grup dzienników, których serwer Oracle cyklicznie używa w celu zapisywania aktualnych danych dziennika transakcji. Grupa dzienników jest zestawem liczącym jeden lub więcej dzienników, które serwer Oracle traktuje jak jeden dziennik powtórzeń. Grupy dzienników powinny mieć więcej niż jednego członka, ponieważ dzięki temu jest niewielkie zagrożenie uszkodzenia danych w przypadku wystąpienia awarii dysku. Gdy serwer Oracle wypełni jedną grupę dzienników powtórzeń online, jej zawartość skopiuje w miejsce określone jako docelowa lokalizacja archiwalnych dzienników. Kopia będzie miała postać oddzielnego pliku, w którego nazwie będzie zawarty numer sekwencyjny. Kopia taka zostanie wykonana tylko wtedy, gdy uaktywniono tryb archivelog i włączono automatyczne archiwizowanie.
Parametry inicjalizujące W przypadku serwera Oracle istnieje kilka parametrów inicjalizujących, o których trzeba wiedzieć podczas procesu przywracania. W związku z tym istotne jest, aby się zorientować, gdzie parametry te są przechowywane zarówno w obrębie bazy danych, jak i poza nią. 460 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Dawniej parametry inicjalizujące znajdowały się w pliku tekstowym o nazwie init.ora. Choć można było zmodyfikować większość parametrów wewnątrz bazy danych, aby zmiany nie przepadły po ponownym uruchomieniu systemu, trzeba było wprowadzić je również w tym pliku. Wraz z wprowadzeniem do sprzedaży serwera Oracle 9i pojawiło się pojęcie pliku parametrów serwera. Jest to binarny plik o nazwie spfile.ora, który zwykle jest przechowywany w katalogu ORACLE_HOME/dbs. Choć pliku nie można edytować, może być kontrolowany bezpośrednio przez serwer Oracle. Dzięki temu w pliku tym automatycznie mogą być zapisywane dynamiczne zmiany konfiguracyjne, które przetrwają po ponownym załadowaniu systemu. Dla osób, które korzystały z plików init.ora, plik spfile.ora może być pewnym udogodnieniem, ponieważ nie wymaga żadnej edycji. Można wyróżnić kilka metod modyfikowania parametrów inicjalizujących. Jeśli baza danych jest aktywna, po prostu należy skonfigurować konkretny parametr, wykonując polecenie alter system set nazwa_parametru=wartość. Polecenie to spowoduje natychmiastową zmianę wartości parametru działającej bazy danych i zapisanie jej w pliku spfile.ora. Z pewnością jest to prostsze od starszej metody polegającej na modyfikowaniu parametru wewnątrz bazy i w pliku init.ora. Niektóre parametry, takie jak log_archive_start, nie mogą być edytowane w ten sposób. Trzeba je zmodyfikować w pliku spfile.ora, a następnie ponownie uruchomić komputer. Używając w zapytaniach nazw tabel v$parameter i v$sparameter, można sprawdzać wartości zarówno obecnie używanych parametrów, jak i tych przechowywanych w pliku parametrów.
Jeśli zamierza się zmodyfikować parametr zawarty w pliku spfile.ora bez używania w tym celu bazy danych, trzeba utworzyć tekstową wersję pliku, poddać go edycji, a następnie zaimportować do nowego pliku spfile.ora. Poniższa instrukcja SQL na podstawie pliku spfile.ora generuje plik nazwa_pliku_pfile. SQL> create pfile='nazwa_pliku_pfile' from spfile
Po wprowadzeniu w pliku nazwa_pliku_pfile odpowiednich zmian można za pomocą poniższej instrukcji SQL utworzyć nowy plik spfile.ora. SQL> create spfile from pfile='nazwa_pliku_pfile'
Choć można sprawdzać zawartość tabel v$parameter i v$sparameter nawet wtedy, gdy baza danych jest wyłączona, pomocne może być wyeksportowanie od czasu do czasu w postaci tekstowej pliku spfile.ora, aby mieć możliwość przejrzenia go podczas przywracania.
Odtwarzanie i przywracanie Firma Oracle rozróżnia terminy odtwarzanie i przywracanie. Odtwarzanie ma tradycyjne znaczenie: przez wczytanie kopii zapasowej z taśmy lub dysku uzyskuje się plik danych z chwili przeprowadzenia ostatniej archiwizacji. Po odtwarzaniu rozpoczyna się proces przywracania, który stosuje dziennik powtórzeń dla pliku danych, aby przywrócić go do aktualnego stanu. Proces ten określa się również mianem przywracania nośnika.
Arch tektura bazy danych Oracle
|
461
Szukanie wszystkich instancji W przypadku wszystkich procedur zamieszczonych w rozdziale założono, że Czytelnik wie, jakie instancje są na serwerze lub ma możliwość stwierdzenia tego. Niestety, nie ma pewnej metody zidentyfikowania wszystkich instancji każdego komputera. Przykładowo mógłbym zaproponować użycie pliku oratab w przypadku systemu Unix. Jednak nie każdy korzysta z tego pliku i może być nieaktualny. Gdy Czytelnik używa systemu Windows, może poszukać kluczy rejestru pasujących do określonego wzorca. Jednak podobnie do pliku oratab klucze te nie zawsze reprezentują rzeczywiste instancje. Inną metodą byłoby wygenerowanie listy instancji, które faktycznie uruchomiono na komputerze. Oczywiście znajdzie się w tym przypadku aktywne instancje, ale tych, które nie były uruchomione podczas archiwizowania, już nie. Najlepiej poinformować wszystkich o używanej przez siebie metodzie identyfikującej instancje, a następnie pozostać przy niej. Trzeba innym powiedzieć, że jeśli coś znajduje się w pliku oratab lub w rejestrze systemu Windows, zostanie zarchiwizowane. W przeciwnym razie nie będzie uwzględnione w kopii zapasowej. Ponadto konieczne jest przekazanie reszcie osób, że zamierza się archiwizować wszelkie aktywne instancje, a nie te, które zostały ręcznie wyłączone. Wystarczy podjąć decyzję i odpowiednio ją rozgłosić. Można wymusić stosowanie pliku oratab (dotyczy systemów Unix i Linux) lub kluczy rejestru systemu Windows przez automatyczne uaktywnianie tylko tych baz danych, które tam wyszczególniono, i tłumacząc, że tak musi być, każdemu, kto poskarży się, że instancja nie została uaktywniona po ponownym uruchomieniu komputera. Trzeba takim osobom wyjaśnić, że instancja musi być w rejestrze lub pliku oratab. Jeśli instancji nie ma w pliku oratab, nie zostanie automatycznie załadowana i zarchiwizowana! Plik oratab zwykle jest zlokalizowany w katalogu /etc/oratab lub /var/oracle/oratab. W systemie Windows należy sprawdzić następujące drzewo rejestru: \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn
Choć zazwyczaj n ma wartość 0, mogą istnieć dodatkowe drzewa rejestru z innymi cyframi, gdy na komputerze skonfigurowano większą liczbę instalacji ORACLE_HOME. Poniżej tego drzewa rejestru powinno się znaleźć jedną lub więcej następujących wartości: • ORA_SID_AUTOSTART, • ORA_SID_PFILE, • ORA_SID_SHUTDOWN.
W celu uzyskania listy identyfikatorów SID instancji serwera Oracle należy sprawdzić powyższe wartości. Jeśli planuje się skorzystać z metody bazującej na pliku oratab lub rejestrze systemu Windows, ale również chce się mieć dodatkową pewność, że wszystko się uwzględni, można zastosować niżej przedstawioną metodę listy procesów, aby sprawdzić, czy są aktywne instancje niewymienione w pliku oratab lub rejestrze.
Jedna z metod polega po prostu na wyświetleniu listy instancji uruchomionych na komputerze. Oczywiście lista ta będzie uwzględniać wyłącznie aktywne instancje. Aby uzyskać listę wszystkich instancji działających w systemie Unix lub Linux, należy wykonać polecenie podobne do poniższego. $ ps -ef|grep "ora_.*pmon" | awk '{print $6}' \ | awk -F_ '{print $2}'
462 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Otrzymany wynik polecenia ps może oczywiście być inny w przypadku różnych wersji systemu Unix. Aby powyższe polecenie okazało się przydatne, być może Czytelnik będzie musiał zmienić wyświetlaną przez nie kolumnę z $6 na inną.
W przypadku systemu Windows każda instancja serwera Oracle ma własną usługę OracleServiceSID, gdzie SID jest nazwą instancji. Wykonując poniższe polecenie, można uzyskać listę instancji uruchomionych w systemie Windows. C:\> net start | find "OracleService" OracleServiceXYZ OracleServiceABC
Aby lista ta była jeszcze lepsza, z witryny projektu GnuWin32 (http://gnuwin32.sourceforge.net) należy pobrać program sed i uwzględnić go w wierszu poleceń. Poniższe polecenie nakazuje programowi sed wycięcie wszystkich znaków aż do końca łańcucha OracleService. W efekcie otrzymuje się następującą listę nazw instancji: C:\> net start | find "OracleService" \ | sed "s/.*OracleService//" XYZ ABC
Również w tym przypadku najlepsze będzie wybranie jednej z zaprezentowanych metod (preferowana jest metoda wykorzystująca plik oratab lub rejestr systemu Windows), a następnie poinformowanie o niej i nakazanie jej stosowania.
Tworzenie fizycznych kopii zapasowych bez użycia narzędzia rman W przypadku wielu środowisk z serwerem Oracle o zastosowaniu narzędzia rman decyduje jego otwartość. Ponadto docenia się to, że można z nim całkowicie zintegrować stosowane komercyjne oprogramowanie archiwizujące. Wyłącznie za pomocą programu rman można utworzyć prawdziwe przyrostowe kopie zapasowe plików danych. Oprócz tego narzędzie rman pozwala też na archiwizowanie dysku bez potrzeby nabywania agenta dla komercyjnego systemu archiwizującego. Jednakże niektórzy administratorzy baz danych wolą to, co firma Oracle nazywa kopiami zapasowymi zarządzanymi przez użytkownika. Przed sporządzeniem kopii zapasowej osoby te przełączają bazę danych w tryb archiwizacji, a po jej zakończeniu przywracają normalny tryb. Czasami wynika to z tego, że długo korzystały z metody kopii zapasowych zarządzanych przez użytkownika i dobrze ją znają, a czasami z kosztu dysku, który trzeba by zastosować, aby używać programu rman bez menedżera nośników, bądź kosztu samego menedżera. Niezależnie od powodu w przybliżeniu połowa klientów firmy Oracle sporządza kopie zapasowe we własnym zakresie. Jednak z każdym dniem liczba takich klientów maleje. W niniejszym podrozdziale omówiono metody, które mogą posłużyć do bezpiecznego archiwizowania bazy danych Oracle bez konieczności używania narzędzia rman. Dane można zarchiwizować na dysku, a następnie jego zawartość umieścić w kopii zapasowej w ramach standardowej procedury archiwizacji. Możliwe jest też zarchiwizowanie bazy danych bezpośrednio na taśmie.
Tworzen e f zycznych kop zapasowych bez użyc a narzędz a rman
| 463
Podobnie do większości systemów RDBMS, bazy danych Oracle mogą znajdować się w plikach systemu plików lub na niesformatowanych urządzeniach dyskowych (dostępne tylko w przypadku systemu Unix). Jeśli nawet tego typu urządzenia są dostępne, wielu administratorów baz danych Oracle umieszcza swoje bazy w plikach systemu plików. Jednym z powodów jest to, że jeśli wszystkie pliki bazy danych są dostępne na poziomie systemu plików, archiwizowanie staje się bardzo proste. Dowolne standardowe narzędzie kopiujące (np. cp lub copy) lub archiwizujące (np. dump, cpio lub komercyjna aplikacja) może skopiować dane. Jeśli bazę danych Oracle zainstalowano pod systemem Unix i postanowiono zlokalizować ją na niesformatowanych partycjach, trzeba będzie użyć narzędzia, które potrafi archiwizować takie partycje (np. dd). Kopie zapasowe mogą być wykonywane w trybie offline („zimna” kopia) lub online („gorąca” kopia). Jeżeli zamierza się utworzyć kopie zapasowe we własnym zakresie, trzeba zarchiwizować wszystkie z niżej wymienionych danych. • pliki danych, • pliki kontrolne, • dzienniki powtórzeń online (w przypadku sporządzania „zimnej” kopii zapasowej), • plik parametrów, • archiwalne dzienniki powtórzeń, • plik haseł (jeśli jest używany), • katalog ORACLE_HOME.
Tworzenie „zimnej” kopii zapasowej „Zimna” kopia zapasowa bazy danych Oracle znajdującej się w plikach systemu plików jest najprostsza do sporządzenia spośród wszystkich bazodanowych kopii zapasowych, ponieważ większość firm już dysponuje określonym systemem, który archiwizuje systemy plików ich serwerów. Może to być utworzony we własnym zakresie skrypt uruchamiający program dump lub ntbackup bądź komercyjny produkt archiwizujący. W celu wykonania „zimnej” kopii zapasowej bazy danych Oracle przed rozpoczęciem standardowej archiwizacji po prostu należy bazę wyłączyć (nie wolno wykonywać polecenia shutdown abort). Standardowy proces zamykania bazy danych tworzy punkt kontrolny, przenosi z pamięci na dysk wszelkie zmodyfikowane dane, po czym zatrzymuje wszystkie procesy udzielające dostępu do bazy. Procedura ta sprawia, że wszystkie pliki bazy danych Oracle znajdują się w spójnym i statycznym stanie. Oczywiście procedura zakłada użycie plików systemu plików. Baza danych Oracle w przypadku uniksowego serwera może też być zainstalowana na niesformatowanych urządzeniach. „Zimna” kopia zapasowa takiej bazy wymaga trochę większego nakładu pracy, ponieważ trzeba się zapoznać ze strukturą bazy danych. Procedura rozpoczyna się tak samo jak w przypadku plików systemu plików, czyli od zamknięcia bazy danych. Jednak na tym etapie proces archiwizacji zawartości systemu plików uwzględnia jedynie pliki wykonywalne i wszelkie obiekty bazodanowe, takie jak plik kontrolny. Sama baza danych wymaga dodatkowych działań. Pierwszą rzeczą jest zidentyfikowanie położenia wszystkich plików bazy danych. Choć skrypt może o to „zapytać” serwer Oracle, wysyłając zapytanie sprawdzające tabelę v$datafile, trzeba by było go napisać. Gdy jest już znane położenie wszystkich plików, program dd może je zarchiwizować w pliku umieszczonym gdzieś w obrębie systemu plików lub zapisać bezpośrednio na woluminie archiwizacyjnym. Jeśli pliki będą archiwizowane w pliku systemu
464 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
plików, operacja musi zostać wykonana przed zaplanowaną standardową archiwizacją systemu plików. Dzięki temu pliki automatycznie zostaną uwzględnione w kopii zapasowej umieszczanej na woluminie archiwizacyjnym. A zatem archiwizowanie bazy danych Oracle używającej niesformatowanych partycji jest trudniejsze od tworzenia kopii zapasowej plików systemu plików. Jest to jeden z powodów, dla których dotychczas administratorzy baz danych Oracle używali systemu plików do przechowywania plików bazy, nawet pomimo tego, że niesformatowane partycje oferowały trochę lepszą wydajność.
Tworzenie „gorącej” kopii zapasowej Jeśli baza danych Oracle zapewnia dane witrynie internetowej obsługującej klientów lub dowolnej innej aplikacji wymagającej ciągłej dostępności bazy, „zimna” kopia zapasowa jest niedopuszczalna. Wynika to stąd, że tego typu kopia wymaga standardowego wyłączenia bazy danych. Jeśli nawet bazę danych zamknie się późno w nocy, klienci witryny internetowej mogą skorzystać z jej usług o dowolnej porze. Firma internetowa będzie znacznie lepiej postrzegana, gdy jest w stanie zapewnić nieustanną dostępność swojej witryny. W takim razie niezbędne jest to, co określa się mianem „gorącej” kopii zapasowej. Baza danych musi działać w trybie archivelog, żeby można było sporządzać dla niej „gorące” kopie zapasowe.
„Gorąca” kopia zapasowa wymaga znacznie więcej pracy niż „zimna”. Jest tak szczególnie wtedy, gdy wykonuje się „zimną” kopię zapasową bazy danych korzystającej z niesformatowanych urządzeń. Poniższe kroki muszą zostać wykonane za każdym razem, gdy tworzy się „gorącą” kopię zapasową.
1. Określenie nazw i lokalizacji wszystkich obszarów tabel i powiązanych z nimi plików danych.
a. Jeśli używa się serwera Oracle 10gR2 lub nowszego, trzeba pobrać z niego listę wszystkich plików danych. Umożliwia to poniższa instrukcja SQL. SQL> select file_name from sys.dba_data_files; /oracle/product/10.2.0/oradata/orcl/users01.dbf /oracle/product/10.2.0/oradata/orcl/sysaux01.dbf /oracle/product/10.2.0/oradata/orcl/undotbs01.dbf /oracle/product/10.2.0/oradata/orcl/system01.dbf /oracle/product/10.2.0/oradata/orcl/example01.dbf
a. Jeżeli korzysta się z serwera starszego niż Oracle 10gR2, trzeba uzyskać z niego listę wszystkich plików danych i obszarów tabel. Umożliwia to poniższa instrukcja SQL. SQL> select tablespace_name, file_name from sys.dba_data_files; USERS /oracle/product/10.2.0/oradata/orcl/users01.dbf SYSAUX /oracle/product/10.2.0/oradata/orcl/sysaux01.dbf UNDOTBS1 /oracle/product/10.2.0/oradata/orcl/undotbs01.dbf SYSTEM /oracle/product/10.2.0/oradata/orcl/system01.dbf EXAMPLE /oracle/product/10.2.0/oradata/orcl/example01.dbf
1. Wykonując poniższą instrukcję SQL, z serwera Oracle należy uzyskać lokalizację archiwalnych dzienników powtórzeń. Ponieważ możliwe jest określenie wielu lokalizacji, należy tak zmodyfikować zapytanie, żeby zwróciło parametry spełniające warunek like 'log_archive_dest_%'. Tworzen e f zycznych kop zapasowych bez użyc a narzędz a rman
| 465
SQL> select name,value from v$parameter where name like 'log_archive_dest_%' log_archive_dest_1 location=/backups/archive
3. Bazę danych należy przełączyć w tryb archiwizacji. a. Jeśli używa się serwera Oracle 10gR2 lub nowszego, za pomocą instrukcji SQL alter database begin backup całą bazę danych można przełączyć w tryb archiwizacji. b. Jeżeli korzysta się z wersji serwera Oracle starszej niż 10gR2, każdy obszar tabel należy przełączyć w tryb archiwizacji, wykonując instrukcję SQL alter tablespace nazwa_obszaru_tabel begin backup. Ponieważ więcej operacji powtórzeń jest wykonywanych, gdy obszary tabel są w trybie archiwizacji, przełączenie w ten tryb całej bazy danych będzie miało niekorzystny wpływ na wydajność. Jeśli ustawienie trybu archiwizacji od razu dla całej bazy spowoduje zbyt duże obciążenie serwera, trybu tego należy użyć tylko dla kilku obszarów tabel jednocześnie i zarchiwizować pliki danych wyłącznie tych obszarów. Oczywiście jest to znacznie bardziej skomplikowane rozwiązanie od tutaj zaprezentowanego.
4. Kopiowanie plików danych każdego obszaru tabel w alternatywne miejsce, takie jak dysk
lub taśma, bądź uruchomienie komercyjnego programu w celu zarchiwizowania na dysku lub taśmie wszystkich systemów plików (i ewentualnie niesformatowanych urządzeń).
5. Dla bazy danych należy wyłączyć tryb archiwizacji. a. Jeśli używa się serwera Oracle 10gR2 lub nowszego, za pomocą instrukcji SQL alter database end backup można dla całej bazy danych wyłączyć tryb archiwizacji. b. Jeżeli korzysta się z wersji serwera Oracle starszej niż 10gR2, należy dla każdego obszaru tabel wyłączyć tryb archiwizacji, wykonując instrukcję SQL alter tablespace nazwa_obszaru_tabel end backup.
6. Po przełączeniu dziennika powtórzeń należy upewnić się, że został zarchiwizowany.
Najlepszą metodą wykonania obu rzeczy jest zastosowanie instrukcji SQL alter system archive log current, która przełącza dziennik, lecz nie wyświetla wiersza poleceń do momentu zarchiwizowania poprzedniego dziennika powtórzeń. Choć można wykonać instrukcję alter system switch logfile, przed wykonaniem następnego kroku nie uzyska się pewności, że został zarchiwizowany najnowszy dziennik powtórzeń.
7. Archiwizowanie pliku kontrolnego za pomocą instrukcji SQL alter database backup controlfile to nazwa_pliku i alter database backup controlfile to trace.
Trzeba korzystać z dwóch metod archiwizowania pliku kontrolnego. W różnych okolicznościach jedna lub druga może okazać się przydatna.
8. Trzeba upewnić się, czy zarchiwizowano wszystkie archiwalne dzienniki powtórzeń istniejące od momentu sporządzenia kopii zapasowej.
Oczywiście jest to ogrom pracy. Do wykonania powyższych zadań niezbędne są duże umiejętności pisania skryptów, a także dobra znajomość odpowiednich instrukcji. W celu objaśnienia całego procesu podzielono go na sekcje.
466 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Określenie struktury Celem kroków 1. i 2. jest stwierdzenie, gdzie wszystko się znajduje. Kroki te trzeba wykonywać każdorazowo podczas tworzenia kopii zapasowej, a nie tylko jednokrotnie lub wtedy, gdy zmieni się struktura bazy danych. W przypadku tej niezbyt wskazanej metody używa się statycznego skryptu, który archiwizuje wyłącznie obszary tabel wykryte ostatnim razem, gdy kroki te wykonano. Coś takiego jest zbyt podatne na błąd człowieka i w związku z tym niezalecane. Znacznie lepiej zautomatyzować te kroki i wykonywać je za każdym razem, gdy instancja jest archiwizowana. W ten sposób zapewni się, że dane konfiguracyjne zawsze będą aktualne, a w kopiach zapasowych niczego nie zabraknie. Ustawienie dla plików trybu archiwizacji i skopiowanie ich Kopiowanie plików aktywnej bazy danych może być wykonywane tylko przez przełączenie jednego lub większej liczby obszarów tabel (bądź całej bazy) w tryb archiwizacji. Gdy to nastąpi, w dowolnej chwili pliki danych powiązane z tymi obszarami tabel lub cała baza mogą zostać przekopiowane lub zarchiwizowane. Ponieważ podczas trwania archiwizacji plików w dalszym ciągu są one zapisywane, firma Oracle uzyskaną kopię zapasową nazywa niespójną kopią. Część osób tego typu kopię określa mianem „niewyraźnej”, to jednak to samo. Chodzi o to, że w czasie archiwizowania pliku jest on cały czas modyfikowany. Bez obaw. Serwer Oracle będzie w stanie podczas przywracania usunąć wszelkie niespójności występujące w pliku. Warto zapoznać się z poniższym punktem, aby nie paść ofiarą częstego i niepoprawnego stwierdzenia, że pliki danych nie są zapisywane, gdy tworzy się dla nich „gorącą” kopię zapasową.
Archiwizowanie dodatkowych plików Pliki danych to tylko jeden z wielu składników serwera Oracle, które muszą zostać zarchiwizowane. Trzeba też utworzyć kopię zapasową pliku kontrolnego, archiwalnych dzienników powtórzeń, plików konfiguracyjnych, pliku haseł (jeśli jest stosowany), katalogu ORACLE_HOME i wszelkich innych katalogów (w przypadku sporządzania „zimnej” kopii zapasowej powinno się również uwzględnić dzienniki powtórzeń online, ponieważ tworzą one pełną kopię bazy danych w danej chwili).
Rozwianie mitów związanych z „gorącymi” kopiami zapasowymi To, co się dzieje w czasie tworzenia „gorącej” kopii zapasowej, jest powszechnie źle rozumiane. Rozwieję dwa następujące podstawowe mity: • Pliki danych nie zmieniają się podczas wykonywania „gorącej” kopii zapasowej. • Serwer Oracle rejestruje pełną kopię każdego bloku każdorazowo, gdy zmieni się on w czasie
tworzenia „gorącej” kopii zapasowej.
Wiele osób wierzy, że gdy obszar tabel znajduje się w trybie archiwizacji, zawarte w tym obszarze pliki danych nie są zapisywane. Osoby te są przekonane, że wszystkie modyfikacje tych plików są utrzymywane w dziennikach powtórzeń do momentu wyłączenia dla obszaru tabel trybu archiwizacji, a następnie są stosowane dla plików danych tak jak w przypadku procesu przywracania nośnika (zagadnienie to omówiono w dalszej części rozdziału w podrozdziale „Przywracanie bazy danych Oracle”). Choć objaśnienie to łatwiej zrozumieć (i zaakceptować) niż to, jak naprawdę wszystko działa, w żadnym razie tworzenie „gorących” kopii zapasowych bazy danych Oracle tak nie wygląda. Tworzen e f zycznych kop zapasowych bez użyc a narzędz a rman
|
467
Wiele osób jest przekonanych, że gdy obszar tabel jest w trybie archiwizacji, serwer Oracle przełącza się z rejestrowania wektora powtórzeń na rejestrowanie pełnych bloków. Nie jest to prawdą. Serwer w dalszym ciągu rejestruje wektory powtórzeń, lecz zapisuje też pełny obraz dowolnego zmienionego bloku — jednak tylko za pierwszym razem, gdy ma miejsce modyfikacja bloku.
Skrypt oraback W książce Unix Backup & Recovery użyto wyłącznie uniksowego skryptu, który za pomocą instrukcji begin backup i end backup tworzył „gorące” i „zimne” kopie zapasowe baz danych Oracle. Choć skrypt ten nadal istnieje i jest dostępny pod adresem http://www.backupcentral.com, z dwóch powodów nie omówiono go szczegółowo w niniejszym rozdziale. Pierwszy powód jest taki, że skrypt nieustannie jest zmieniany. W związku z tym nie chciałem, żeby w książce znalazł się nieaktualny skrypt (obecnie szukamy ochotników, którzy pomogą napisać wersję Perl skryptu zgodną także z systemem Windows; Czytelnik może przyłączyć się do zespołu). Drugim powodem jest objętość książki, która naprawdę się zwiększyła; trzeba było dokonać cięć wszędzie tam, gdzie było to możliwe.
Typową reakcją na powyższe stwierdzenia jest bardzo głośne: „Co takiego?”, po którym następuje skrzyżowanie rąk i naprawdę surowe spojrzenie (gdy usłyszałem o tym po raz pierwszy, tak samo zareagowałem). „Jak mogę bezpiecznie zarchiwizować te pliki, jeśli są modyfikowane w czasie trwania procesu tworzenia kopii zapasowej? Co należy rozumieć przez to, że serwer Oracle rejestruje pełny obraz wyłącznie przy pierwszej zmianie bloku?”. Nie ma powodu do obaw. Serwer Oracle wszystko kontroluje. Trzeba pamiętać, że każdy plik danych bazy danych Oracle ma numer SCN, który jest zmieniany każdorazowo po uaktualnieniu pliku. Ponadto należy pamiętać, że gdy serwer Oracle wprowadza zmianę w pliku danych, zawsze rejestruje w dzienniku powtórzeń wektor tej zmiany. Po przełączeniu obszaru tabel w tryb archiwizacji mają miejsce trzy rzeczy:
1. Serwer Oracle tworzy dla obszaru tabel punkt kontrolny, przenosząc wszystkie zmiany ze wspólnej pamięci na dysk.
2. Bieżące wartości znaczników SCN dla każdego pliku danych powiązanego z tym obszarem tabel są „zamrażane”. Nawet pomimo tego, że kolejne aktualizacje będą wysyłane do plików danych, znaczniki SCN nie zostaną uaktualnione do momentu wyłączenia trybu archiwizacji dla obszaru tabel.
3. Oprócz rejestrowania tego, w jaki sposób zmodyfikowano określony blok (opisuje to wektor powtórzeń), serwer Oracle zapisuje cały obraz każdego bloku za pierwszym razem, gdy zostanie zmieniony.
Gdy wystąpią te trzy zdarzenia, program archiwizujący bez problemów utworzy kopię zapasową pliku danych, archiwizując go blok po bloku. Ponieważ plik jest uaktualniany w czasie wczytywania go, program może czytać bloki tuż przed ich modyfikacją, po wprowadzeniu zmian, a nawet podczas trwania modyfikacji! Załóżmy, że rozmiar bloku systemu plików wynosi 4 kB, a rozmiar bloku bazy danych Oracle równa się 8 kB. Program archiwizujący będzie wczytywał dane w porcjach o rozmiarze 4 kB. Narzędzie mogłoby zarchiwizować pierwsze cztery z ośmiu kilobajtów bloku danych bazy Oracle, zanim blok zostałby zmodyfikowany, a następnie utworzyć kopię zapasową pozostałych czterech kilobajtów tego bloku już po dokonaniu zmiany. W efekcie doszłoby do czegoś, co firma Oracle nazywa podzielonym blokiem. Gdy jednak program
468 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
archiwizujący osiągnie miejsce pliku danych, w którym jest zawarty numer SCN, zarchiwizuje go w takim stanie, jaki miał w momencie rozpoczynania archiwizacji. Wynika to stąd, że numer SCN „zamrożono”. Po wyłączeniu dla obszaru tabel trybu archiwizacji dla znacznika SCN zostanie ustawiona aktualna wartość, a następnie serwer Oracle wznowi rejestrowanie wektorów zmian i nie będzie potrzebował pełnych obrazów zmodyfikowanych bloków. W jaki sposób serwer Oracle radzi sobie z tym w czasie przywracania nośnika? W rzeczywistości wygląda to bardzo prosto. Za pomocą programu archiwizującego odtwarza się plik danych. Gdy spróbuje się uruchomić instancję, serwer Oracle sprawdzi plik danych i ujrzy starą wartość numeru SCN. W rzeczywistości jest to wartość, którą znacznik SCN miał przed rozpoczęciem sporządzania „gorącej” kopii zapasowej. Po wykonaniu instrukcji recovery datafile serwer Oracle zacznie dla tego pliku danych wykonywać operację powtórzenia. Ponieważ dzienniki powtórzeń zawierają kompletny obraz każdego bloku, który zmienił się w czasie archiwizacji, serwer Oracle może przywrócić plik danych do spójnego stanu, niezależnie od tego, kiedy zarchiwizowano określony blok danych. Pierwszą rzeczą, jaką serwer Oracle robi, jest nadpisanie wszelkich bloków, dla których dysponuje pełnym obrazem (czyli tych, które zostały zmodyfikowane podczas archiwizowania). W dalszej kolejności serwer Oracle wykonuje dla pliku danych standardową operację powtórzenia, żeby uwzględnić wszelkie zmiany, które miały miejsce w czasie archiwizacji lub po jej ukończeniu. Właśnie dlatego serwer Oracle wymaga tylko pierwszego obrazu dowolnego bloku zmienionego podczas archiwizacji. Jeden obraz jest potrzebny po prostu po to, aby zapewnić, że blok uzyska znany stan (w przeciwieństwie do podzielonego bloku). Dalej serwer Oracle może dla takiego bloku wykonać operację powtórzenia, żeby ponownie wprowadzić wszelkie pozostałe zmiany. Jeśli Czytelnik przypomina mnie, nie uwierzy w to wszystko za pierwszym razem, gdy o tym przeczyta. Udowodnię więc, że to, co napisałem, jest prawdą. Utwórzmy tabelę tasmy w obszarze tabel test, a następnie wstawmy do tabeli wartość DLT i wymuśmy punkt kontrolny. SQL> create table tasmy (nazwa varchar2(32)) tablespace test; Table created. SQL> insert into tasmy values ('DLT'); 1 row created. SQL> commit; Commit complete. SQL> alter system checkpoint; System altered.
Dalej należy uzyskać od serwera Oracle numer bloku zawierającego nową wartość. SQL> select dbms_rowid.rowid_block_number(rowid) blk, nazwa from tasmy; BLK NAZWA ---- ---------------3 DLT
Wartość DLT zapisano w trzecim bloku danych. Dziewięć bloków jest przeznaczanych na nagłówek pliku danych. Za pomocą polecenia dd można odczytać trzeci blok danych, a następnie jego wynik przekazać programowi strings, aby faktycznie przekonać się, że w bloku tym jest wartość DLT. $ dd if=/db/Oracle/a/oradata/crash/test01.dbf ibs=8192 skip=11 count=1|strings 1+0 records in 16+0 records out DLT
Obszar tabel należy przełączyć w tryb tworzenia „gorącej” kopii zapasowej. SQL> alter tablespace test begin backup; Tablespace altered.
Tworzen e f zycznych kop zapasowych bez użyc a narzędz a rman
| 469
Pora uaktualnić tabelę, zatwierdzić aktualizację i wymusić punkt kontrolny dla całej bazy danych. SQL> update tasmy set nazwa = 'AIT'; 1 row updated. SQL> commit; Commit complete. SQL> alter system checkpoint; System altered.
Ten sam blok danych należy pobrać, aby potwierdzić, że nowa wartość faktycznie została zapisana na dysku. $ dd if=/db/Oracle/a/oradata/crash/test01.dbf ibs=8192 skip=11 count=1|strings 1+0 records in 16+0 records out DLT, AIT
Poniższa instrukcja wyłącza dla obszaru tabel tryb archiwizacji. SQL> alter tablespace test end backup;
Powyższy test udowadnia, że pliki danych naprawdę są zapisywane podczas tworzenia „gorących” kopii zapasowych!
Tworzenie fizycznych kopii zapasowych przy użyciu narzędzia rman W porównaniu z kopiami zapasowymi zarządzanymi przez użytkownika program rman oferuje kilka korzyści. Oto ich krótka lista: Pełne wsparcie firmy Oracle Choć metoda tworzenia kopii zapasowych zarządzanych przez użytkownika jest obsługiwana przez firmę Oracle, łatwo zauważyć, że poziom jej wsparcia zwiększa się jeszcze bardziej, gdy bazę danych przywraca się za pomocą ulubionego narzędzia tego producenta. Automatyczne tworzenie wielu jednoczesnych strumieni archiwizacyjnych Jeśli zarządza się dużą bazą danych, coś takiego okaże się bardzo pomocne. Wszystko, co trzeba zrobić, to określić liczbę wymaganych jednoczesnych kopii zapasowych. Narzędzie rman sporządzi je. Przyrostowe kopie zapasowe dla wszystkich wersji począwszy od wersji 8i Program rman tworzy prawdziwe przyrostowe kopie zapasowe, wysyłając tylko te bloki, które zmieniły się od czasu ostatniej archiwizacji. Mało obciążające przyrostowe kopie zapasowe dla wszystkich wersji począwszy od wersji 10g Wraz z pojawieniem się wersji 10g serwera Oracle przyrostowe kopie zapasowe stały się znacznie lepsze. Przed wersją 10g stwierdzenie, jakie bloki wymagają uwzględnienia w przyrostowej kopii zapasowej, wiązało się z wykonaniem mnóstwa operacji wejściawyjścia. Choć tego typu kopia pozwalała zaoszczędzić wiele miejsca i przepustowości, zdecydowanie nie ograniczała liczby operacji wejścia-wyjścia. Wersja 10g serwera Oracle zapisuje informacje na temat zmienionych bloków w prostej bitmapie, która jest wykorzystywana przez program rman podczas sporządzania przyrostowej kopii zapasowej. Dzięki temu kopia jest tworzona znacznie szybciej i mniej obciąża serwer.
470
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Zastosowanie funkcji obsługi obszaru dyskowego FRA i technologii Flashback Ponieważ narzędzie rman jest zintegrowane z funkcją obsługi obszaru dyskowego FRA i technologią Flashback, gdy użyje się tego programu, będzie można skorzystać z tych znakomitych rozwiązań. Optymalizacja archiwizacji Ponieważ program rman rejestruje wszystkie operacje archiwizacji, można przeprowadzić ich optymalizację. Dzięki temu kolejne archiwizacje nie będą uwzględniały składników bazy danych, w przypadku których wiadomo, że zostały już zarchiwizowane, takich jak obszary tabel tylko do odczytu. Optymalizacja odtwarzania Zamiast być zmuszonym do określania, jakie pliki danych trzeba odtworzyć, i zaznaczania ich w oknie aplikacji archiwizującej, można po prostu nakazać programowi rman odtworzenie bazy danych. Narzędzie to automatycznie stwierdzi, które pliki danych są niezbędne do odtworzenia, a następnie przywróci je. Podczas procesu przywracania nośnika program rman też okazuje się dość przydatny. Zamiast identyfikowania lokalizacji archiwalnych dzienników powtórzeń i przywracania ich wszystkich na dysku na potrzeby procesu odtwarzania, można użyć narzędzia rman, które całkowicie automatyzuje pobieranie tych dzienników, niezbędnych do przywrócenia nośnika. Programowi rman można również nakazać, żeby zajmował określoną przestrzeń dyskową przez automatyczne usuwanie z dysku najstarszych wersji w celu zastąpienia ich nowszymi, pobranymi z taśmy. Jeśli programu rman używa się razem z komercyjnym narzędziem archiwizującym, takim jak omówione w rozdziale 8., można uzyskać całkowicie zintegrowane rozwiązanie archiwizacyjne dla wszystkich baz danych Oracle. Ponieważ w książce skoncentrowano się na metodach opartych na darmowych narzędziach archiwizujących open source, w niniejszym rozdziale nie wyjaśniono, w jaki sposób zintegrować program rman z komercyjnym oprogramowaniem archiwizującym.
Gdy zastosuje się w pełni komercyjne rozwiązanie, oprócz wyżej wymienionych funkcji programu rman można uzyskać następujące korzyści: Pełne wsparcie dostawcy komercyjnego produktu archiwizującego Nie należy oczekiwać, że dostawca oprogramowania wie wszystko na temat metody kopii zapasowych zarządzanych przez użytkownika. Archiwizowanie bezpośrednio na taśmie, wirtualnej taśmie bądź innym dysku serwera archiwizującego (zamiast zapisywania kopii zapasowej w obrębie systemu plików dostępnego dla serwera Oracle) Jeśli korzysta się z programu rman bez menedżera nośników, dane trzeba archiwizować w obrębie systemu plików dostępnego dla serwera bazodanowego. W przypadku niektórych środowisk może to spowodować kilka utrudnień. Menedżer nośników jest najbardziej elastyczny, gdy wybiera się docelową lokalizację kopii zapasowych. Skorzystanie z pełnej oferty dostawcy produktu archiwizującego Komercyjne narzędzia archiwizujące w ciągu kilku ostatnich lat przeszły długą drogę i oferują zestaw funkcji przedstawionych w rozdziale 8. Funkcji tych można też użyć w przypadku kopii zapasowych utworzonych przez program rman.
Tworzen e f zycznych kop zapasowych przy użyc u narzędz a rman
|
471
Kompletna inwentaryzacja kopii zapasowych umożliwiająca odtwarzanie typu „wskaż i kliknij” Proces odtwarzania można przeprowadzać z poziomu interfejsu programu rman, można też użyć do tego interfejsu stosowanego oprogramowania archiwizującego. Jeśli Czytelnik jest zainteresowany wymienionymi możliwościami, lecz przeraził się cenami oprogramowania archiwizującego dla przedsiębiorstw, może rozważyć produkt Secure Backup firmy Oracle. Struktura cen tego narzędzia jest bardzo prosta. Firma Oracle nie żąda opłaty za każdego klienta, każdy serwer lub gigabajt, lecz jedynie za urządzenie archiwizujące.
Gdy zewnętrzny produkt archiwizujący, skrypt programu rman lub oprogramowanie Secure Backup inicjuje tworzenie kopii zapasowej przez narzędzie rman, zajmuje się ono całą wewnętrzną komunikacją niezbędną do dostarczenia programowi archiwizującemu n wątków danych. Na potrzeby przyszłych zastosowań program rman rejestruje czas archiwizacji i przekazuje tę informację produktowi archiwizującemu (jeśli takowy jest używany). Po przeprowadzeniu odpowiednich przygotowań możliwe jest też uruchamianie przez administratora baz danych programu rman z poziomu wiersza poleceń. Wykonane polecenie wywołuje właściwe programy w celu połączenia się z narzędziem archiwizującym lub zarchiwizowania danych bezpośrednio na dysku. Jeśli dane przesłano programowi archiwizującemu, zareaguje na to jak na dowolne inne żądanie archiwizacji, ładując w razie potrzeby woluminy i pobierając kopię zapasową od narzędzie rman. Narzędzie rman jest obsługiwane przez serwer Oracle począwszy od wersji 8i. Można zdecydować się na odtworzenie obszaru tabel, bazy danych, pliku danych, a nawet jego bloku. Dla programu rman wiadome jest, jakie pliki tworzą obszar tabel lub bazę danych, dlatego automatycznie zaznacza i odtwarza najbardziej aktualną wersję tych plików. W ten sposób administrator bazy danych nie musi bawić się w zgadywanie. Program rman wie, co musi zostać odtworzone, zna lokalizację kopii zapasowych i samoczynnie przeprowadza proces przywracania odpowiednich składników, a także może automatycznie wykonać przywracanie nośnika. Jest to znacznie lepsze niż robienie tego wszystkiego samemu. Program rman jest zbyt złożony, aby mógł zostać szczegółowo przedstawiony w rozdziale o takiej objętości. W celu zapoznania się z zasadami działania narzędzia rman należy zajrzeć do dokumentacji firmy Oracle. W tym miejscu można się przyjrzeć liście podstawowych funkcji dodanych do programu rman od momentu dołączenia go do wersji 8i serwera Oracle. W efekcie program ten stał się znacznie bardziej przydatny niż dotąd. Dalej zamieszczono kilka ogólnych wytycznych dotyczących używania programu rman.
Istotne nowe funkcje programu rman Poniżej znajduje się lista ważnych funkcji narzędzia rman, które dodano do niego od chwili udostępnienia jego oryginalnej wersji. Obok każdej funkcji podano wersję serwera Oracle, w której się ona pojawiła. Polecenia crosscheck i delete (8i) Przed pojawieniem się tych poleceń katalog programu rman mógł utracić synchronizację z katalogiem menedżera nośników. Polecenia te automatycznie synchronizują oba katalogi, a także usuwają wpisy katalogu narzędzia rman dla kopii zapasowych, które zostały unieważnione przez menedżera nośników.
472
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Polecenia create catalog, upgrade catalog i drop catalog (8i) Polecenia te automatyzują kilka ważnych operacji na katalogu, zastępując skrypty i inne polecenia. Automatyczne generowanie nazwy kopii zapasowej (8i) Nie trzeba już dla kopii zapasowych stosować parametru formatu. Program rman sam tworzy unikatową nazwę dla każdej kopii. Automatyczne archiwizowanie pliku kontrolnego (9i) Jeśli dla parametru configure controlfile autobackup ustawi się wartość on, narzędzie rman automatycznie zarchiwizuje plik kontrolny i plik parametrów serwera każdorazowo, gdy dokona się zmiany w strukturze bazy danych lub wykona polecenie archiwizacji. Archiwizowanie plików parametrów serwera (9i) Kopie zapasowe plików parametrów serwera są automatycznie tworzone zawsze, gdy wykona się polecenie inicjujące archiwizację. Później można użyć polecenia restore spfile (jeśli włączono parametr controlfile autobackup). Tworzenie kopii zapasowej archiwalnych dzienników wymagających archiwizacji i usuwanie tych dzienników, które kopii nie potrzebują (9i) Starsze metody określania, które archiwalne dzienniki należy zarchiwizować, były trochę niewygodne i wymagały, aby zrobił to użytkownik. Obecnie można zastosować warunek niearchiwizowane n razy. Zarchiwizowane zostaną pliki, dla których nie sporządzono kopii zapasowej określoną ilość razy. Można też zdecydować, że pliki zarchiwizowane odpowiednią ilość razy powinny zostać usunięte. Trwałe konfiguracje programu rman (9i) Zanim pojawiła się taka możliwość, trzeba było określać argumenty programu rman każdorazowo podczas przeprowadzania archiwizacji. Obecnie można ustawić trwałe wartości dla takich rzeczy, jak zautomatyzowane kanały, zrównoleglenie kanałów, zasady dotyczące zatrzymywania i opcje archiwizacji. Przywracanie bloków nośnika (9i) Proces przywracania bloków nośnika polega na odzyskiwaniu pojedynczych bloków wybranego pliku danych, który pozostaje w trybie online. Obszar dyskowy FRA (10g) Można nakazać programowi rman, żeby do przechowywania wszystkich plików związanych z archiwizowaniem i przywracaniem używał jednego miejsca na dysku. Lokalizację taką określa się mianem obszaru dyskowego FRA (Flash Recovery Area). Optymalizacja przyrostowych kopii zapasowych (10g) Poprzednie wersje narzędzia rman wymagały kilku odczytów bazy danych Oracle w celu stwierdzenia, które bloki powinny zostać uwzględnione w przyrostowej kopii zapasowej. W efekcie operacje wejścia-wyjścia powodowały większe obciążenie niż w przypadku tworzenia pełnej kopii zapasowej. W przypadku wersji 10g serwer Oracle rejestruje, jakie bloki poszczególnych plików danych zostały zmodyfikowane (administrator baz danych musi uaktywnić odpowiednią funkcję). Obecnie narzędzie rman po prostu żąda zmienionych bloków, co znacząco zmniejsza obciążenie wywoływane przez operacje wejścia-wyjścia. Przyrostowe aktualizowanie kopii zapasowych (10g) Zmiany znalezione w przyrostowej kopii zapasowej narzędzie rman uwzględnia w poprzedniej kopii pliku danych. Dzięki temu uzyskuje się nową pełną kopię zapasową tego pliku bez konieczności archiwizowania go w całości.
Tworzen e f zycznych kop zapasowych przy użyc u narzędz a rman
|
473
Kompresja kopii zapasowych (10g) Serwer Oracle może skompresować kopie zapasowe, dzięki czemu zapotrzebowanie na przestrzeń dyskową lub przepustowość spada od 50 do 75%. Choć nie jest to domyślna opcja, można sprawić, żeby taka była, używając trwałego parametru programu rman. Przywracanie za pośrednictwem opcji resetlogs (10g) Zanim pojawiła się ta możliwość, trzeba było wykonywać kopię zapasową po otwarciu bazy danych z opcją resetlogs. Wynikało to stąd, że przed wystąpieniem tego zdarzenia nie było możliwe sporządzenie kopii. Obecnie to się zmieniło. Globalnie przechowywane skrypty (10g) Skrypty narzędzia rman mogą być magazynowane w jego katalogu, który jest dostępny dla każdej docelowej bazy danych.
Automatyzowanie narzędzia rman W niniejszym punkcie zawarto kilka wskazówek dotyczących automatyzowania tworzenia kopii zapasowych przez program rman, zwłaszcza w przypadku dużych środowisk. Punkt ten w żadnym razie nie ma zastąpić dokumentacji narzędzia rman. Nie można na kilku stronach zmieścić tego, co zajmuje całą książkę.
Podobnie do innych poleceń serwera Oracle, program rman zakłada, że użytkownik zna nazwę archiwizowanej instancji. A zatem najpierw trzeba uzyskać listę instancji serwera Oracle.
Tworzenie katalogu przywracania Zgadza się, z programu rman można korzystać bez katalogu przywracania. W rzeczywistości, gdy sprawdzi się uwagi dołączone do wersji serwera Oracle, okaże się, że jego producent w dalszym ciągu zwiększa zakres rzeczy, które można zrobić bez katalogu. Jeśli nie zastosuje się katalogu, dane narzędzia rman będą przechowywane w pliku kontrolnym. Zapisywanie informacji związanych z przywracaniem na czymś, co zamierza się odzyskać, nigdy nie będzie dobrym pomysłem. Znacznie lepsze byłoby dysponowanie zcentralizowanym katalogiem przywracania zawierającym wszystkie informacje umożliwiające odzyskanie każdej instancji. Dobrym pomysłem będzie również umieszczenie katalogu na serwerze innym niż dowolny z serwerów z monitorowanymi bazami danych. Obecnie znacznie prostsze jest utworzenie katalogu tylko za pomocą polecenia create catalog narzędzia rman. W dużych środowiskach może być wymagane zastosowanie więcej niż jednego katalogu programu rman i archiwizowanie każdego z nich za pomocą egzemplarza narzędzia rman połączonego z jeszcze innym katalogiem. Pod uwagę można też wziąć utworzenie „gorącej” lub „zimnej” kopii zapasowej katalogu programu rman przy wykorzystaniu metody, która nie używa tego narzędzia. Zawsze należy zapisywać identyfikator bazy danych. Może okazać się bardzo przydatny, jeśli utraci się plik kontrolny, a zwłaszcza wtedy, gdy zarządza się wieloma bazami danych o takiej samej nazwie.
474
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Tworzenie trwałych parametrów Każdy utworzony trwały parametr to o jeden mniej, który trzeba podać w wierszu poleceń. Ostatecznym celem jest po prostu możliwość nakazania zarchiwizowania bazy danych programowi rman, który wszystko, co do tego niezbędne, pobierze z trwałych parametrów. Tego typu parametry można zobaczyć po wykonaniu polecenia show all w obrębie sesji programu rman. Zostanie wyświetlona lista wszystkich parametrów, wyszczególniająca, które z nich zostały zmodyfikowane, a które nadal mają domyślne wartości. Oto przykład zamieszczony w dokumentacji serwera Oracle. RMAN> show all; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # domyślny CONFIGURE BACKUP OPTIMIZATION OFF; # domyślny CONFIGURE DEFAULT DEVICE TYPE TO DISK; # domyślny CONFIGURE CONTROLFILE AUTOBACKUP OFF; # domyślny CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # domyślny CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # domyślny CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # domyślny CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # domyślny CONFIGURE MAXSETSIZE TO UNLIMITED; # domyślny CONFIGURE ENCRYPTION FOR DATABASE OFF; # domyślny CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # domyślny CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # domyślny CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/product/10.2.0/db_1/dbs/snapcf_orcl.f'; # domyślny
Używając trwałych parametrów, można w znaczącym stopniu uprościć skrypty programu rman. W celu utworzenia lub zmodyfikowania tych parametrów po prostu należy połączyć się z narzędziem rman i wykonać poniższe polecenia. RMAN> configure backup optimization on; RMAN> configure device type disk backup type to compressed backupset; RMAN> configure controlfile autobackup on;
Tworzenie skryptów narzędzia rman Skrypty programu rman można tworzyć w celu archiwizowania całej bazy danych, obszaru tabel, pliku danych, pliku kontrolnego lub archiwalnego dziennika. Skrypty te mogą być przechowywane w obrębie systemu plików lub w katalogu programu rman (w tym przypadku ze skryptów mogą korzystać wszystkie instancje mające dostęp do katalogu). Po zapisaniu w katalogu skrypty mogą zostać uruchomione. W tym celu należy połączyć się z katalogiem i wykonać polecenie run nazwa_skryptu narzędzia rman. Ze względu na ograniczoną pojemność zostaną zaprezentowane tylko dwa bardzo proste skrypty programu rman, które tworzą pełną (poziom 0) i przyrostową (poziom 1) kopię zapasową całej instancji. Ponadto skrypty te przełączają pliki dzienników i archiwizują wszystkie archiwalne dzienniki powtórzeń, które utworzono w czasie sporządzania kopii zapasowej. W pełnej kopii zapasowej zostanie uwzględniony każdy bajt bazy danych, natomiast w przyrostowej kopii tylko te bajty, które zmieniły się od czasu ostatniej archiwizacji. W skrypcie przyjęto, że dla parametru controlfile autobackup ustawiono wartość on. Poniżej zamieszczono zawartość skryptu narzędzia rman służącego do utworzenia pełnej kopii zapasowej. Skrypt sporządza pełną kopię (poziomu 0) bazy danych i zapisuje ją na domyślnym urządzeniu. Opcja plus archivelog powoduje przełączenie plików dzienników (korzystających z opcji archivelog current) przed rozpoczęciem archiwizacji. Dalej skrypt sporządza kopię Tworzen e f zycznych kop zapasowych przy użyc u narzędz a rman
|
475
zapasową wszystkich archiwalnych dzienników, których nie zarchiwizowano (jeśli dla opcji backup optimization ustawiono wartość on), a następnie archiwizuje bazę danych, ponownie przełącza plik dziennika i tworzy kopię zapasową wszelkich dzienników powtórzeń wygenerowanych w czasie archiwizowania bazy. connect target identyfikator_użytkownika/hasło@oracle_sid; connect catalog identyfikator_użytkownika/hasło@rman_sid; backup incremental level 0 plus archivelog;
W dokumentacji serwera Oracle nakazuje się wstawianie hasła narzędzia rman w wierszu poleceń. W efekcie hasło będzie dostępne dla każdego, kto może wykonać polecenie ps -ef (choć niżej zamieszczone skrypty nie wymagają podania hasła w ten sposób, można upewnić się, że hasła zostały w nich ręcznie wprowadzone). Jeśli jednak hasło określa się w wierszu poleceń, trzeba się upewnić, że skrypt może być wczytany tylko przez serwer Oracle.
W miejsce łańcuchów identyfikator_użytkownika i hasło należy wstawić odpowiednie wartości. Dodatkowo należy podać identyfikatory SID dla docelowej bazy danych (przeznaczona do archiwizacji) i bazy katalogu.
Skrypt narzędzia rman tworzący przyrostowe kopie zapasowe poziomu 1 Jest to dodatkowy skrypt towarzyszący wyżej przedstawionemu. Skrypt ten sporządza przyrostową kopię zapasową tych bajtów bazy danych, które zmieniły się od chwili wykonania kopii poziomu 0. connect target identyfikator_użytkownika/hasło@oracle_sid; connect catalog identyfikator_użytkownika/hasło@rman_sid; backup incremental level 1 plus archivelog;
Osoby używające od dawna narzędzia rman powinny zauważyć brak polecenia allocate channel, a także instrukcji alter system archive log current i kopii zapasowej archiwalnych dzienników. Funkcje tych poleceń są obsługiwane przez trwałe parametry, z kolei archiwalne dzienniki są archiwizowane za pomocą opcji plus archivelog.
Technologia Flashback Do serwera Oracle 10g dodano zestaw wspaniałych funkcji tworzących razem technologię Flashback. Część funkcji używa obszaru dyskowego FRA zaprezentowanego przy omawianiu architektury bazy danych, a część używa nowego kosza bazodanowego lub obszaru tabel powrotu. Fizyczne kopie zapasowe, którym poświęcono niniejszy rozdział, przede wszystkim są tworzone w celu umożliwienia przywrócenia danych po wystąpieniu awarii dysku lub innego sprzętu. Z kolei technologia Flashback oferuje kilka interesujących metod odzyskiwania danych po błędzie człowieka. Poniżej w skrócie podsumowano funkcje technologii Flashback. Z posiadanej dokumentacji należy dowiedzieć się, jak korzystać z tej technologii. Zapytanie Zapytanie to pozwala użytkownikowi uzyskać dane historyczne niezbędne do odtworzenia danych, które utracono lub przypadkowo usunięto. Dane wymagane przez zapytanie są przechowywane w obszarze tabel powrotu.
476
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Zapytanie dotyczące wersji Zapytanie umożliwia administratorowi baz danych przejrzenie zmian dokonanych w wierszach tabel w danym okresie. Dane wymagane przez zapytanie znajdują się w obszarze tabel powrotu. Zapytanie transakcyjne Zapytanie daje administratorowi bazy danych możliwość sprawdzenia zmian dokonanych w bazie na poziomie transakcyjnym. Dane wymagane przez zapytanie są przechowywane w obszarze tabel powrotu. Przywracanie bazy danych Funkcja umożliwia przywrócenie bazy danych Oracle w sposób podobny jak w przypadku ciągłej ochrony danych. Pozwala ona po prostu przywrócić bazę Oracle do stanu, jaki miała tuż przed wystąpieniem poważnego błędu logicznego uszkodzenia (na przykład usunięcie tabeli). Dane wymagane przez funkcję znajdują się w obszarze dyskowym FRA. Przywracanie tabeli Funkcja pozwala administratorowi baz danych przywrócić tabelę do wcześniejszego stanu. Dane wymagane przez funkcję są przechowywane w obszarze tabel powrotu. Cofnięcie operacji usunięcia tabeli Funkcja zapewnia możliwość odzyskania usuniętych tabel bazy danych Oracle. Dane wymagane przez funkcję znajdują się w koszu bazodanowym.
Inne komercyjne metody archiwizacji Można wyróżnić co najmniej jedno komercyjne narzędzie archiwizujące, które tworzy kopie zapasowe baz danych Oracle bez korzystania z programu rman. Ponieważ produkt ten używa tych samych narzędzi, które zastosowałyby skrypty (zawierające instrukcje begin backup i end backup), dotyczy go wiele identycznych ograniczeń. Przykładem takiego produktu jest oprogramowanie SQL Backtrack firmy BMC. Produkt ten, pierwotnie przeznaczony dla serwera bazodanowego Sybase, dostosowano do serwerów: Oracle, Informix i SQL Server. Gdy ta książka była pisana, narzędzie SQL Backtrack nie zarządzało woluminami. Potrafi jednak współpracować z kilkoma komercyjnymi menedżerami magazynowania, które mogą zapewnić zarządzanie woluminami.
Zarządzanie archiwalnymi dziennikami powtórzeń Niezależnie od tego, jak często stawiane jest następujące pytanie: „Czy powinno się uaktywnić archiwizowanie dzienników?”, zawsze odpowiedź na nie ma być zdecydowanie twierdząca! Gdy pojawiają się wątpliwości, po prostu trzeba włączyć archiwizowanie. Oto rzeczy, które będą możliwe, gdy tylko uaktywni się archiwizowanie: • przywracanie danych do momentu wystąpienia awarii; • przywracanie danych z kopii zapasowej mającej miesiąc lub więcej, gdy są dostępne wszyst-
kie archiwalne dzienniki powtórzeń utworzone od chwili sporządzenia tej kopii;
• przeprowadzenie kompletnej archiwizacji bazy danych nawet bez zamykania jej.
Istnienie archiwalnych dzienników sprawia, że wszystkie powyższe operacje przebiegają bez większych problemów. Jedyna różnica między włączeniem archiwizowania a jego wyłączeniem jest taka, że serwer Oracle będzie bieżący dziennik powtórzeń kopiował na dysk lub nie, gdy Zarządzan e arch walnym dz enn kam powtórzeń
|
477
dokona przełączenia z jednego dziennika na drugi. Nawet przy nieaktywnym archiwizowaniu serwer Oracle w dalszym ciągu rejestruje każdą transakcję w dziennikach powtórzeń trybu online. Oznacza to, że jedyne dodatkowe obciążenie wynikające z archiwizowania dzienników jest związane z kopiowaniem dziennika online w miejsce pełniące rolę archiwum. Z tego powodu w przypadku środowiska z wieloma transakcjami spadek wydajności może wynieść zaledwie od 1 do 3%, a nawet może być niezauważalny. Choć można do woli poeksperymentować, bardzo trudno byłoby usprawiedliwić wyłączenie archiwizowania dzienników powtórzeń dla dowolnej produkcyjnej bazy danych. Trzeba pamiętać, że nie może dojść do przepełnienia miejsca przeznaczonego do magazynowania archiwalnych dzienników powtórzeń. Gdy do tego dojdzie, produkcyjna baza danych przestanie działać.
Według mnie istnieją tylko dwa środowiska, w których dopuszczalne jest wyłączenie archiwizowania dzienników. Pierwszym jest środowisko, w którym dane nie mają dużego znaczenia. Jedynym takim środowiskiem jest prawdziwe środowisko testowe z danymi zmyślonymi lub odtworzonymi z woluminów produkcyjnych. W strukturze takiej testowej bazy danych nie są wprowadzane żadne zmiany, a wszelkie modyfikacje danych są odrzucane. Taka baza danych nie wymaga archiwizowania dzienników i prawdopodobnie w ogóle nie musi być archiwizowana (czy właśnie coś takiego napisałem?). Jednak należy wspomnieć, że jeśli analizuje się bazę danych, która trafi do środowiska produkcyjnego, powinno się tworzyć kopie zapasowe i uaktywnić archiwizowanie dzienników, ponieważ testowanie aplikacji bez tej funkcji nie da wymiernych rezultatów. Testy z włączonym archiwizowaniem są bardziej realistyczne nawet wtedy, gdy archiwalne dzienniki zostały usunięte od razu po ich utworzeniu. Projektowe bazy danych nie zaliczają się do tej kategorii, ponieważ pomimo małej ważności danych ich struktura często jest szczególnie istotna. Jeśli wyłączono archiwizowanie, administrator baz danych nie będzie mógł odtworzyć żadnych wyników prac projektowych uzyskanych od czasu sporządzenia ostatniej kopii zapasowej. W ten sposób można utracić rezultaty pracy z wielu godzin, a nawet dni, a w zamian uzyskać wzrost wydajności projektowej bazy danych wynoszący od 1 do 3%. Przy tak znikomym zysku ryzyko jest zbyt duże. Drugim typem środowiska jest takie, w którym baza danych nie wymaga archiwizowania dzienników, ponieważ można ją jedynie całkowicie lub częściowo odczytywać, a operacja odtwarzania archiwalnego dziennika potrwałaby dłużej niż ponowne wczytanie oryginalnych danych. Taki scenariusz stał się możliwy wraz z pojawieniem się hurtowni danych. Obecnie istnieje kilka baz danych mających obszary tabel wyłącznie do odczytu, w których w żadnym razie nie da się umieścić danych. Tego typu baza może zostać raz zarchiwizowana, a następnie pozostawiona aż do wprowadzenia następnej zmiany. Częściowo zapisywalna baza danych to baza, która przez długie okresy pozostaje w trybie tylko do odczytu i jest aktualizowana przez proces wsadowy uruchamiany co noc, co tydzień, a nawet zawsze, gdy zajdzie taka konieczność. Chodzi o to, aby zamiast zapisywania setek dzienników powtórzeń można było odtworzyć bazę danych z kopii zapasowej utworzonej przed załadowaniem danych. Administrator baz danych mógłby następnie ponownie załadować dane. W tym przypadku możliwe są dwa warianty. Pierwszym jest wyłączenie archiwizowania dzienników i zadbanie o utworzenie poprawnej „zimnej” kopii zapasowej po każdym wczytaniu danych do bazy. Jeśli proces ładowania danych zostanie przerwany lub wystąpi awaria dysku po jego ukończeniu, lecz jeszcze przed sporządzeniem następnej kopii zapasowej, można po prostu użyć starszej kopii i ponownie załadować dane. Choć wykonanie „zimnej” kopii zapasowej 478
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
wymaga zamknięcia bazy danych, wyłączenie archiwizowania dzienników trochę przyspieszy ładowanie danych. Inną opcją byłoby uaktywnienie archiwizowania dzienników. W tym przypadku w dowolnej chwili można sporządzić „gorącą” kopię zapasową, a także, zamiast samemu ponownie ładować dane, wykorzystać w tym celu dzienniki powtórzeń. Ten wariant oferuje większą elastyczność związaną z archiwizowaniem. Jednak zależnie od bazy i typu jej danych operacja odtwarzania archiwalnego dziennika może potrwać dłużej niż ponowne załadowanie oryginalnych danych (zwłaszcza w przypadku wczytywania wielowątkowego). W drugim wariancie kosztem wydajności zyskuje się możliwość przywrócenia danych. Należy sprawdzić oba warianty, aby stwierdzić, który będzie lepszy.
Przywracanie bazy danych Oracle Ponieważ baza danych Oracle składa się z kilku powiązanych ze sobą składników, przywracanie jej przebiega na zasadzie eliminacji. Najpierw należy określić działające elementy, a następnie przywrócić te, które nie funkcjonują. Taka logika jest stosowana w poniższym przewodniku omawiającym proces przywracania. Proces ten zadziała niezależnie od wybranej metody archiwizacji. Składa się on z kilku powiązanych ze sobą kroków, które mogą być wykonywane w podanej kolejności. Jeśli tworzy się kopie zapasowe zarządzane przez użytkownika, większość czynności trzeba będzie wykonać samodzielnie. Gdy używa się narzędzia rman, można pominąć wiele kroków.
Dzięki archiwizowaniu nie straci się dnia Znam firmę, w której używano bazy danych o rozmiarze 250 GB bez włączonego archiwizowania dzienników (w tamtych czasach była to ogromna pojemność!). Największym mankamentem tego był brak możliwości tworzenia „gorących” kopii zapasowych, a wykonanie „zimnej” kopii zapasowej zajęłoby zbyt wiele czasu. W efekcie nie sporządzano żadnych kopii! Administratorzy bazy danych nie uaktywnili archiwizowania dzienników powtórzeń, gdyż uznali, że spowodowałoby to zbytnie wydłużenie czasu trwania operacji wsadowego ładowania danych. Ponadto byli przekonani, że włączenie archiwizowania w jakiś sposób przyczyni się do uszkodzenia bazy danych. To po prostu nie jest możliwe. Trzeba jeszcze raz podkreślić, że jedyna różnica między uaktywnieniem archiwizowania a jego wyłączeniem jest taka, że bieżący dziennik powtórzeń będzie kopiowany w odpowiednie miejsce lub nie. Reszta bazy danych działa dokładnie tak samo. Próbowałem przekonać administratorów do włączenia archiwizowania dzienników powtórzeń. Nawet założyłem się z nimi, że zrobienie tego nie zmniejszy wydajności procesu ładowania danych o więcej niż 3%. Inaczej mówiąc, planowany 5-godzinny proces ładowania zająłby tylko 9 minut więcej. Przegrałem zakład, ponieważ trwało to w sumie 5 godzin i 10 minut. Administratorzy zgodzili się na włączenie archiwizowania i w efekcie po raz pierwszy od pięciu lat dla bazy danych została utworzona pierwsza kopia zapasowa. Można w to wierzyć lub nie, ale dwa tygodnie później popsuło się pięć dysków używanych przez tę bazę danych. Byliśmy w stanie w ciągu jednej nocy przywrócić bazę. Dzięki temu użytkownicy nie zauważyli żadnego przestoju.
Przywracan e bazy danych Oracle
|
479
Zastosowanie przewodnika procesu przywracania Zaprezentowany w kolejnych punktach proces przywracania bazy danych Oracle niczego nie zakłada. Mówiąc dokładniej, nie przyjmuje, że znany jest powód awarii bazy danych. Wykonując poniższe kroki, wykona się zestaw zadań określających, które składniki bazy danych przestały działać. Można następnie uruchomić bazę danych najszybciej jak to możliwe i jednocześnie zyskać możliwość przywrócenia jej uszkodzonych elementów (przez „uszkodzone” można rozumieć, że pliku nie ma lub został uszkodzony). Zacznijmy od kroku 1. Jeśli się powiedzie, należy przejść do kroku 10. Jeżeli nie uda się początkowe podłączenie bazy danych, należy wykonać krok 2. Każdy z kroków jest zgodny z podobnym schematem, w przypadku którego, zależnie od powodzenia lub niepowodzenia bieżącego kroku, Czytelnik jest kierowany do innego, odpowiedniego kroku. Załóżmy, że przed zastosowaniem jakichkolwiek instrukcji SQL wykonano następujące polecenia: $ sqlplus /nolog SQL> connect /as sysdba;
Zanim zostaną wywołane jakiekolwiek polecenia narzędzia rman, należy połączyć się z odpowiednią docelową bazą danych i katalogiem przywracania (jeśli jest stosowany). W celu zapoznania się z dziesiątkami różnych sposobów wykonania tego zadania należy zajrzeć do dokumentacji. W przytoczonych przykładach zrezygnowano z katalogu przywracania i zastosowano logowanie do docelowej bazy danych oparte na uwierzytelnianiu na poziomie systemu operacyjnego. W związku z tym po prostu trzeba wykonać następujące polecenie: $ rman target /
W przypadku każdego polecenia narzędzia sqlplus lub rman opiszę status, jaki musi mieć baza danych przed wykonaniem takiego polecenia. Przykładowo w akapicie będzie zdanie typu: „Poniższą instrukcję SQL należy zastosować do podłączonej i zamkniętej bazy danych”. W celu uzyskania dodatkowych informacji na temat poszczególnych kroków należy zajrzeć do dokumentacji serwera Oracle, a zwłaszcza do sekcji „Backup and Recovery Basics”. Kroki te można wykonać zarówno w przypadku komputera z systemem Windows, jak i uniksowego serwera. W razie potrzeby zwracam uwagę na występujące różnice. Zanim rozpocznie się jakikolwiek proces przywracania, warto wysłać do firmy Oracle zgłoszenie pomocy technicznej, ponieważ jej pracownicy mogą okazać się bardzo przydatni, gdy sprawy się skomplikują.
Poważnie należy pomyśleć o narzędziu rman Można się przekonać, że odtwarzanie i przywracanie bazy danych Oracle może być bardzo złożonym procesem. Jeżeli nie korzysta się jeszcze z programu rman, najwyższa pora pomyśleć o tym. Jeśli tylko dysponuje się plikami kontrolnymi, w przypadku dostępności narzędzia rman poniższy 26-krokowy proces przywracania zostałby zredukowany do następujących sześciu poleceń: connect target. .... connect catalog. .... startup mount; restore database; recover database; alter database open;
480 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Program rman automatycznie stwierdza, co zostało uszkodzone, po czym odtwarza to i przeprowadza proces przywracania nośnika.
Krok 1. — próba podłączenia bazy danych Pierwszym krokiem w procesie weryfikacji stanu bazy danych Oracle jest podjęcie próby jej podłączenia. Jest to możliwe, ponieważ operacja podłączania bazy danych (bez jej otwierania) obejmuje wczytanie plików kontrolnych, lecz nie otwarcie plików danych. Jeśli pliki kontrolne są multipleksowane (powielane), serwer Oracle próbuje otworzyć każdy taki plik wyszczególniony w pliku parametrów. Jeżeli dowolny z tych plików uszkodził się, podłączenie nie powiedzie się. W celu podłączenia odłączonej bazy danych wystarczy zastosować polecenie sqlplus /nolog, a następnie po nawiązaniu połączenia z bazą wykonać instrukcję startup mount. SQL> startup mount;
Jeśli się to uda, uzyska się wynik podobny do poniższego. SQL> startup mount; ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted.
5130648 bytes 44924 bytes 4151836 bytes 409600 bytes 524288 bytes
Jeżeli próba podłączenia bazy nie powiedzie się, zostanie zwrócony wynik podobny do poniższego. SQL> startup mount; Total System Global Area 5130648 bytes Fixed Size 44924 bytes Variable Size 4151836 bytes Database Buffers 409600 bytes Redo Buffers 524288 bytes ORACLE instance started. ORA-00205: error in identyfing controlfile, check alert log for more info
Jeśli próba podłączenia bazy danych zakończy się powodzeniem, należy przejść do kroku 10. W przeciwnym razie należy wykonać krok 2.
Czy można wykonać polecenia narzędzia sqlplus dla niedostępnej bazy danych? Prezentowane kroki wymagają wywołania kilku różnych poleceń narzędzia sqlplus, aby zidentyfikować status określonych składników bazy. Część poleceń żąda podłączenia bazy danych, a część nie. Gdy baza nie jest otwarta, zapytania mogą być wykonywane tylko dla stałych tabel lub widoków. Do widoków takich można zaliczyć V$DATAFILE, V$LOGFILE, V$TABLESPACE i V$LOG. W celu uzyskania kompletnej listy stałych tabel dostępnych po podłączeniu bazy danych należy wykonać poniższe polecenie dla dowolnej bazy Oracle, nawet gdy jest zamknięta. SQL> select * from V$FIXED_TABLE;
Przywracan e bazy danych Oracle
|
481
Krok 2. — czy nie ma żadnego pliku kontrolnego? Nie należy panikować, jeśli nie powiedzie się próba podłączenia bazy danych. Pliki kontrolne można łatwo odtworzyć, gdy były multipleksowane (powielane), a w razie potrzeby można nawet utworzyć je ponownie. Pierwszą ważną informacją jest to, że brakuje jednego lub większej liczby plików kontrolnych. Niestety, ponieważ serwer Oracle przerywa operację podłączania po wystąpieniu pierwszego błędu, brakować może jednego, dwóch lub wszystkich plików kontrolnych. Jednak na tym etapie wiadomo jedynie, że nie ma jednego takiego pliku. W związku z tym przed przejściem do dalszych działań, wykonując niewielką analizę, należy określić skalę problemu. W pierwszej kolejności należy zidentyfikować nazwy wszystkich plików kontrolnych. Można w tym celu sprawdzić stałą tabelę v$parameter, dostępną zarówno wtedy, gdy bazę danych podłączono, jak i wtedy, gdy jej nie podłączono. SQL> select value from v$parameter where name like 'control_files' /db/Oracle/a/oradata/crash/control01.ctl, /db/Oracle/a/oradata/crash/control02.ctl, /db/Oracle/a/oradata/crash/control03.ctl
W przypadku systemu Windows otrzyma się wyniki podobne do poniższych. SQL> select value from v$parameter where name like 'control_files' D:\ORACLE/ORADATA/CRASH/CONTROL01.CTL, E:\ORACLE/ORADATA/CRASH/CONTROL02.CTL, F:\ORACLE/ORADATA/CRASH/CONTROL03.CTL
Ważne jest również uzyskanie nazwy pliku kontrolnego, w związku z którym serwer Oracle zgłosił problem. W tym celu należy poszukać wiersza controlfile: w dzienniku alertów (jego lokalizacja jest określana przez wartość parametru background_dump_dest, też znajdującego się w tabeli v$parameter). Aby uzyskać wartość tego parametru, należy skorzystać z wcześniej zaprezentowanej metody określania lokalizacji plików kontrolnych (zwykle dziennik alertów znajduje się w katalogu /admin//bdump). W katalogu tym powinien też być plik alert_.log. W pliku powinien być umieszczony komunikat o błędzie wyglądający podobnie do poniższego. Sun Jul 23 18:53:19 PDT 2006 alter database mount exclusive Sun Jul 23 18:53:19 PDT 2006 ORA-00202: controlfile: '/db/a/oradata/crash/control01.ctl' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory
W niektórych z dalej zamieszczonych procedur może być nadpisywany potencjalnie uszkodzony plik kontrolny. Ponieważ nigdy nie wiadomo, jaki plik będzie potrzebny, przed zrobieniem czegoś takiego zawsze trzeba utworzyć kopie zapasowe wszystkich plików kontrolnych. Takie rozwiązanie zapewnia „opcję” cofnięcia, co inaczej nie byłoby możliwe (należy również sporządzać kopie dzienników powtórzeń trybu online).
Dysponując nazwami wszystkich plików kontrolnych i nazwą uszkodzonego pliku, łatwo można ocenić wagę problemu. W tym celu należy wyświetlić listę wszystkich plików kontrolnych, a także porównać ich rozmiar i czas modyfikacji (czy Czytelnik pamięta zabawę z programu Ulica Sezamkowa zatytułowaną „Jedno z nich nie jest takie jak pozostałe”?). W poniższych sytuacjach założenie jest takie, że pliki kontrolne były multipleksowane (powielane) w trzech miejscach, co jest bardzo częstą praktyką. Oto możliwe sytuacje:
482 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Pliku brakuje lub jest uszkodzony i istnieje przynajmniej jeden dodatkowy plik Jeśli po prostu brakuje pliku, w związku z którym serwer Oracle zgłosił problem, można sobie łatwo z tym poradzić. W tym przypadku należy przejść do kroku 3. Brakuje wszystkich plików kontrolnych Jeżeli brakuje wszystkich plików kontrolnych lub są uszkodzone, muszą zostać utworzone od nowa lub trzeba będzie odtwarzać całą bazę danych. Można mieć nadzieję, że regularnie za pośrednictwem używanego systemu archiwizującego wykonywano polecenie backup controlfile to trace (wynikiem tego polecenia jest skrypt SQL, który automatycznie ponownie tworzy pliki kontrolne). W tym przypadku należy wykonać kroki od 4. do 7.
Krok 3. — zastąpienie brakującego pliku kontrolnego Jeśli nie dysponuje się wynikiem polecenia backup controlfile to trace, można napisać skrypt ponownie tworzący plik kontrolny. W tym celu należy przeprowadzić proces omówiony w dokumentacji serwera Oracle. W tym przypadku bardzo pomocne będzie wsparcie kogoś bardziej doświadczonego.
Warto zwrócić powyżej uwagę na staranny dobór słów. Plik kontrolny nie ma być odtworzony (oznaczałoby to, że zostanie pobrany z kopii zapasowej). Trzeba pamiętać, że odtworzenie tego pliku wymagałoby wykonania polecenia alter database open resetlogs, co nie jest normalnie wskazane. Plik kontrolny zostanie zastąpiony przez skopiowanie jednej z jego innych kopii, które multipleksowano (powielano). Przekonajmy się, czy będzie to możliwe przed faktycznym odtworzeniem pliku kontrolnego z kopii zapasowej. Krok ten dotyczy zarówno kopii zapasowych zarządzanych przez użytkownika, jak i kopii sporządzonych przez program rman. Zawsze lepiej naprawić plik kontrolny przy użyciu multipleksowanej (powielonej) kopii niż przez odtworzenie go z kopii zapasowej.
Jeśli ma się możliwość stwierdzenia, że dobra jest co najmniej jedna z multipleksowanych (powielonych) kopii pliku kontrolnego, zadanie staje się proste. Wystarczy skopiować inną multipleksowaną (powieloną) kopię pliku kontrolnego w miejsce uszkodzonej kopii z zachowaniem jej nazwy (szczegóły tej operacji zamieszczono dalej). Po tym można ponownie spróbować podłączyć bazę danych. Zanim wypróbuje się tę procedurę, trzeba pamiętać o zarchiwizowaniu wszystkich plików kontrolnych!
Najpierw trzeba uzyskać nazwę uszkodzonego pliku kontrolnego. Jest to dość proste. Wystarczy w pliku alertów poszukać sekcji podobnej do następującej: Sun Jul 23 18:53:19 PDT 2006 alter database mount exclusive Sun Jul 23 18:53:19 PDT 2006 ORA-00202: controlfile: '/db/a/oradata/crash/control01.ctl' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory
Następnym krokiem będzie skopiowanie sprawdzonego pliku kontrolnego w miejsce uszkodzonego.
Przywracan e bazy danych Oracle
| 483
„Ale nie mam poprawnego pliku kontrolnego!” Możliwe jest, że nie będzie znana żadna kopia bieżącego pliku kontrolnego. Jeśli przydarzy się to komuś, kto nie przechowywał w pliku kontrolnym historii operacji archiwizacji wykonywanych przez program rman, prawdopodobnie najlepszym rozwiązaniem będzie próba użycia skryptu zawierającego instrukcję create controlfile. Jeżeli w pliku kontrolnym znajduje się historia operacji archiwizacji wykonanych przez narzędzie rman, prawdopodobnie najlepsze będzie odtworzenie tego pliku z kopii zapasowej. W celu zastosowania skryptu z instrukcją create controlfile należy wykonać kroki od 4. do 7. Aby odtworzyć plik kontrolny z kopii zapasowej, należy przejść do kroku 8. Jeśli nie jest to możliwe lub prawdopodobne, należy spróbować poniższej procedury. Najpierw należy sporządzić kopię zapasową wszystkich plików kontrolnych. Dalej należy spróbować skopiować kolejno każdą wersję każdego pliku kontrolnego do wszystkich pozostałych lokalizacji (z pominięciem pliku, w przypadku którego serwer Oracle zgłosił już problem, ponieważ oczywiście uszkodził się). Każdorazowo, gdy nowy plik kontrolny zostanie skopiowany w wiele miejsc, należy powrócić do kroku 1.
Dla przykładu załóżmy, że istnieją trzy pliki kontrolne: /a/control1.ctl, /b/control2.ctl i /c/control3.ctl. Dziennik alertów stwierdza uszkodzenie pliku /c/control3.ctl. Ponieważ pliki /a/control1.ctl i /b/control2.ctl mają różne czasy modyfikacji, nie można stwierdzić, który z nich jest poprawny. W tym przypadku należy spróbować wykonać poniższe kroki. W pierwszej kolejności należy utworzyć kopię wszystkich plików kontrolnych. $ cp /a/control1.ctl /a/control1.ctl.sav $ cp /b/control2.ctl /a/control2.ctl.sav $ cp /c/control3.ctl /a/control3.ctl.sav
W przypadku systemu Windows należy zastosować następujące polecenia: C:\ copy C:\CONTROL01.CTL C:\CONTROL01.SAV C:\ copy D:\CONTROL02.CTL D:\CONTROL02.SAV C:\ copy E:\CONTROL03.CTL E:\CONTROL03.SAV
Dalej należy spróbować skopiować jeden plik we wszystkie miejsca. Nie ma sensu kopiować pliku control3.ctl, ponieważ oczywiście jest uszkodzony. Zacznijmy od pliku control1.ctl. $ cp /a/control1.ctl /b/control2.ctl $ cp /a/control1.ctl /c/control3.ctl
Gdy korzysta się z systemu Windows, należy wykonać poniższe polecenia. C:\ copy C:\CONTROL01.CTL D:\CONTROL02.CTL C:\ copy C:\CONTROL01.CTL E:\CONTROL03.CTL
Pora podjąć próbę podłączenia bazy danych. SQL> startup mount; Sun Jul 23 18:53:19 PDT 2006 alter database mount exclusive Sun Jul 23 18:53:19 PDT 2006 ORA-00202: controlfile: '/a/control3.ctl' ORA-27037: unable to obtain file status
Powyższy komunikat o błędzie informuje, że plik skopiowany we wszystkie miejsca też jest uszkodzony. W takiej sytuacji należy wypróbować drugi plik, control2.ctl. Tym razem plik trzeba skopiować z kopii zapasowej, gdyż w ostatnim kroku nadpisano jego oryginalną wersję.
484 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
$ cp /b/control2.ctl.sav /a/control1.ctl $ cp /b/control2.ctl.sav /a/control3.ctl
W przypadku systemu Windows należy zastosować poniższe polecenia. C:\ copy D:\CONTROL02.SAV C:\CONTROL01.SAV C:\ copy D:\CONTROL02.SAV E:\CONTROL03.SAV
Pora spróbować podłączyć bazę danych. SQL> startup mount; ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted.
5130648 bytes 44924 bytes 4151836 bytes 409600 bytes 524288 bytes
Okazuje się, że plik control2.ctl był dobrą kopią pliku kontrolnego. Jeśli z powodzeniem udało się podłączyć bazę danych, należy przejść do kroku 10. Gdy nie można było zidentyfikować poprawnej kopii pliku kontrolnego, należy wykonać krok 4.
Krok 4. — czy wszystkie pliki danych i dzienniki powtórzeń są poprawne? Kroki od 4. do 7. powinny być wykonywane tylko po nieudanym wykonaniu kroków od 1. do 3. Celem kroków od 4. do 7. jest przygotowanie do odbudowania pliku kontrolnego przy użyciu skryptu z instrukcją create controlfile. Kroki 4. i 5. są wymagane tylko przed zastosowaniem kroku 6.
W wersji 10g serwera Oracle rozszerzono wynik polecenia backup controlfile to trace, aby uwzględnić opcje noresetlogs i resetlogs. Jeśli zamierza się zastosować opcję noresetlogs, wszystkie pliki danych i dzienniki powtórzeń trybu online muszą być nienaruszone. Dopuszczalne są starsze wersje plików danych odtworzone z kopii zapasowej, ponieważ zostaną uaktualnione przez proces przywracania nośnika. Dzienniki powtórzeń online muszą być aktualne i nienaruszone, aby zadziałał skrypt z instrukcją create controlfile przeznaczony dla opcji noresetlogs. Jeżeli jakaś grupa dzienników powtórzeń online całkowicie się uszkodziła, trzeba będzie użyć opcji resetlogs. Z jakiego powodu? Wynika to stąd, że proces odbudowywania korzysta z dzienników powtórzeń trybu online, żeby zidentyfikować aktualny numer SCN, a następnie poszukać go w pliku kontrolnym. Nie stanowi to problemu, gdy jeden lub więcej plików danych ma starsze numery SCN. Jeśli jednak okaże się, że plik danych ma numer SCN, który jest nowszy od dostępnych dzienników powtórzeń online, będzie to oznaczać, że nie ma się do czynienia z aktualnymi dziennikami. W efekcie proces odbudowywania pliku kontrolnego zostanie przerwany. Jeżeli prawdopodobne jest, że jeden lub więcej plików danych bądź dzienników powtórzeń trybu online uszkodziło się, należy przejść do kroku 5. Gdy bardziej prawdopodobne jest, że wszystkie te pliki są nienaruszone, należy wykonać krok 6.
Przywracan e bazy danych Oracle
| 485
Multipleksowanie plików kontrolnych i dzienników powtórzeń! Utrata wszystkich członków aktywnej grupy dzienników, której nie zarchiwizowano, to sytuacja, w której przepadnięcie danych jest niemal pewne. Z kolei przywracanie po utracie pliku kontrolnego jest prawdziwą udręką. Dlatego za wszelką cenę trzeba zabezpieczyć się przed takimi sytuacjami. Trzeba zadbać o to, aby pliki kontrolne i dzienniki powtórzeń online były multipleksowane (powielane)! Zapewnienie tego nie jest trudne. Najpierw należy określić lokalizację multipleksowanych (powielanych) dzienników powtórzeń. Należy pamiętać, że jeśli dzienniki takie są trzykrotnie multipleksowane (powielane), oznacza to, że serwer Oracle musi każdą zmianę zapisać we wszystkich trzech dziennikach. Skutkuje to tym, że wszystkie trzy multipleksowane (powielane) kopie powinny znaleźć się na najszybszych dostępnych dyskach. Konieczne jest również zapewnienie, że poszczególne multipleksowane (powielane) kopie są zlokalizowane na różnych dyskach! Na potrzeby przykładu przyjmijmy, że istnieją trzy grupy dzienników, z których każda ma jednego członka. Oto wynik zapytania select group#, member from v$logfile: 1 /logs1/redolog01.log 2 /logs1/redolog02.log 3 /logs1/redolog03.log
W przykładzie te trzy dzienniki zostaną zmultipleksowane (powielone) w katalogach /logs2 i /logs3. Wolę pozostawiać takie same nazwy plików członków grupy dzienników. W związku z tym w przykładzie plik redolog01.log jest multipleksowany (powielany) w katalogach: /logs1, /logs2 i /logs3. Aby tak było, wykonano następujące instrukcje: SQL> alter database Selection processed SQL> alter database Selection processed SQL> alter database Selection processed SQL> alter database Selection processed SQL> alter database Selection processed SQL> alter database Selection processed
add logfile member '/logs2/redolog01.log' to group 1; add logfile member '/logs3/redolog01.log' to group 1; add logfile member '/logs2/redolog02.log' to group 2; add logfile member '/logs3/redolog02.log' to group 2; add logfile member '/logs2/redolog03.log' to group 3; add logfile member '/logs3/redolog03.log' to group 3;
Polecenia dla każdej grupy dzienników tworzą trzy zmultipleksowane (powielone) kopie. Dzięki temu w znaczący sposób zmniejsza się ryzyko tego, że mogą się uszkodzić wszyscy członkowie jednej grupy dzienników.
Krok 5. — odtwarzanie uszkodzonych plików danych lub dzienników powtórzeń Jeśli zupełnie zostanie uszkodzony jeden lub więcej plików danych bądź dzienników powtórzeń online, należy wykonać wszystkie poniższe instrukcje, żeby przekonać się, czy uszkodziły się jeszcze jakieś inne pliki (trochę więcej starań na tym etapie pozwala oszczędzić sobie wielu zmartwień). Jeżeli jest możliwe, że wszystkie pliki danych i dzienniki powtórzeń online są poprawne, innym wariantem będzie pominięcie tego kroku i podjęcie próby ponownego utworzenia pliku kontrolnego (gdy się to nie uda, nie będzie żadnych szkód). Jeśli próba zakończy
486 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
się niepowodzeniem, należy powrócić do tego kroku. Gdy czasu jest mnóstwo, w pierwszej kolejności należy wykonać ten krok. Aby spróbować odbudować plik kontrolny, należy przejść do kroku 6. W pierwszej kolejności trzeba określić lokalizację wszystkich plików danych i dzienników powtórzeń. W tym celu dla podłączonej i zamkniętej bazy danych należy wykonać poniższe polecenia. SQL> select name from v$datafile; /db/Oracle/a/oradata/crash/system01.dbf /db/Oracle/a/oradata/crash/rbs01.dbf /db/Oracle/a/oradata/crash/temp01.dbf /db/Oracle/a/oradata/crash/tools01.dbf /db/Oracle/a/oradata/crash/users01.dbf /db/Oracle/a/oradata/crash/test01.dbf SQL> select group#, member from v$logfile; 1 /db/Oracle/a/oradata/crash/redocrash01.log 3 /db/Oracle/c/oradata/crash/redocrash03.log 2 /db/Oracle/b/oradata/crash/redocrash02.log 1 /db/Oracle/b/oradata/crash/redocrash01.log 2 /db/Oracle/a/oradata/crash/redocrash03.log 3 /db/Oracle/c/oradata/crash/redocrash02.log
W przypadku systemu Windows wynik tych poleceń będzie wyglądał bardzo podobnie. Oczywiście ścieżki będą inne. Sprawdźmy każdy z plików zwróconych przez powyższe zapytanie. Najpierw przyjrzyjmy się plikom danych. Większość z nich prawdopodobnie ma identyczny czas modyfikacji. Może też istnieć grupa plików danych z jednym czasem modyfikacji i grupa z innym czasem. Jeśli w bazie są obszary tabel tylko do odczytu, kilka plików danych może być z czasem modyfikacji znacznie wcześniejszym niż czas modyfikacji pozostałych plików tego typu. Nie stanowi to problemu. Podstawową rzeczą do sprawdzenia jest brakujący plik lub plik o zerowym rozmiarze. Ponadto należy stwierdzić, czy nie ma jednego lub większej liczby plików, których czas modyfikacji jest późniejszy od najnowszego dziennika powtórzeń trybu online. Jeśli plik danych spełnia dowolne z tych kryteriów, musi zostać odtworzony z kopii zapasowej. Jednak dzienniki powtórzeń trochę się różnią. Każdy taki plik wchodzący w skład grupy dzienników powinien mieć jednakowy czas modyfikacji. Przykładowo wynik powyższego polecenia pokazuje, że pliki /db/Oracle/a/oradata/crash/redocrash01.log i /db/Oracle/b/oradata/crash/redocrash01.log są w grupie dzienników 1. Pliki te powinny mieć jednakowy czas modyfikacji i rozmiar. To samo powinno mieć miejsce w przypadku grup 2 i 3. Istnieje kilka możliwych scenariuszy. Jedna lub więcej grup dzienników zawiera co najmniej jeden dobry i jeden uszkodzony dziennik. Właśnie z tego powodu dzienniki powtórzeń są multipleksowane (powielane)! Poprawny dziennik powtórzeń należy skopiować w miejsce przechowywania uszkodzonego dziennika. Jeśli na przykład brakuje pliku /db/Oracle/b/oradata/crash/redocrash01.log, lecz dysponuje się nienaruszonym plikiem /db/Oracle/a/oradata/crash/redocrash01.log, należy wykonać następujące polecenie: $ cp /db/Oracle/b/oradata/crash/redocrash01.log \ /db/Oracle/a/oradata/crash/redocrash01.log
Jeśli komunikaty o błędach informują, że plik D:\ORACLE\ORADATA\CRASH\REDO ¦CRASH01.LOG jest w porządku, natomiast pliku E:\ORACLE\ORADATA\CRASH\REDO ¦CRASH01.LOG nie ma lub został uszkodzony, w przypadku systemu Windows należy zastosować poniższe polecenie.
Przywracan e bazy danych Oracle
|
487
C:\ COPY D:\ORACLE\ORADATA\CRASH\REDOCRASH01.LOG \ E:\ORACLE\ORADATA\CRASH\REDOCRASH01.LOG
Wszystkie dzienniki powtórzeń są uszkodzone w przynajmniej jednej grupie dzienników. Nie jest to zbyt ciekawa sytuacja. W celu zastosowania opcji noresetlogs skrypt z instrukcją create controlfile użyty w kroku 6. wymaga, aby były dostępne wszystkie dzienniki powtórzeń trybu online. Jeśli całkowicie uszkodziła się tylko jedna grupa dzienników, trzeba będzie skorzystać z części skryptu z opcją resetlogs. Jeżeli dostępne są wszystkie pliki danych, lecz brakuje wszystkich plików kontrolnych, należy przejść do kroku 6. Jeśli z jakiegoś innego powodu baza danych nie zostanie otwarta, należy wykonać krok 10.
Krok 6. — czy kopię pliku kontrolnego zapisano w pliku śladu? Przed tym krokiem trzeba wykonać kroki 4. i 5.
Konieczny jest wynik polecenia alter database backup controlfile to trace narzędzia sqlplus. Instrukcja ta tworzy plik śladu zawierający dwa skrypty z poleceniem create controlfile. Polecenie powinno być regularnie wykonywane (w przypadku systemów Unix i Linux za pośrednictwem programu cron, a w systemie Windows za pomocą zaplanowanego zadania lub narzędzia harmonogramującego systemu bazodanowego). W celu stwierdzenia, czy jest dostępny taki skrypt, należy wykonać poniższe instrukcje. Pierwszą rzeczą jest identyfikacja lokalizacji plików śladu. Informację taką można uzyskać przy użyciu parametru user_ ¦dump_dest tabeli v$parameter (zwykle dla parametru tego ustawia się ścieżkę katalogu $ORACLE_BASE/admin/$ORACLE_SID/udump). Najpierw za pomocą polecenia cd należy przejść do tego katalogu, a następnie przy użyciu programu grep (system Unix) lub find (system Windows) poszukać łańcucha CREATE CONTROLFILE (listing 16.1). Listing 16.1. Lokalizowanie najbardziej aktualnego skryptu z instrukcją create controlfile SQL> select value from v$parameter where name like 'user_dump_dest'; /db/Oracle/admin/crash/dump $ cd /db/Oracle/admin/crash/udump ; grep 'CREATE CONTROLFILE' * \ |awk -F: '{print $1}'|xargs ls -ltr -rw-r---- 1 Oracle dba 3399 Oct 26 11:25 crash_ora_617.trc -rw-r---- 1 Oracle dba 3399 Oct 26 11:25 crash_ora_617.trc -rw-r---- 1 Oracle dba 1179 Oct 26 11:29 crash_ora_661.trc
W systemie Windows należy wykonać następujące polecenia: D:\ cd D:\Oracle\admin\crash\udump D:\ type *.TRC|find 'CREATE CONTROLFILE'
Na listingu 16.1 plik crash_ora_661.trc jest najbardziej aktualnym plikiem zawierającym skrypt z instrukcją create controlfile. Jeśli istnieje taki skrypt, należy przejść do kroku 7. Gdy skryptu nie ma, a ponadto brakuje wszystkich plików kontrolnych, należy wykonać krok 8.
488 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Krok 7. — uruchamianie skryptu z instrukcją create controlfile Najpierw należy znaleźć plik śladu ze skryptem. Odpowiednie instrukcje zamieszczono w kroku 6. Po odszukaniu pliku należy go skopiować pod inną nazwą, taką jak rebuild.sql. Jeśli dzienniki powtórzeń online są nienaruszone, można skorzystać z sekcji opcji noresetlogs. Gdy dowolna grupa tego typu dzienników została całkowicie uszkodzona, trzeba zastosować sekcję opcji resetlogs. Po przyjrzeniu się wynikowi należy wybrać odpowiednią sekcję i usunąć wszystkie pozostałe znaki komentarza znajdujące się powyżej i poniżej tej sekcji. Plik powinien wyglądać podobnie do przedstawionego na listingu 16.2. Listing 16.2. Przykładowy skrypt z instrukcją create controlfile STARTUP MOUNT CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292 LOGFILE GROUP 1 '/oracle/product/10.2.0/oradata/orcl/redo01.log' SIZE 50M, GROUP 2 '/oracle/product/10.2.0/oradata/orcl/redo02.log' SIZE 50M, GROUP 3 '/oracle/product/10.2.0/oradata/orcl/redo03.log' SIZE 50M DATAFILE '/oracle/product/10.2.0/oradata/orcl/system01.dbf', '/oracle/product/10.2.0/oradata/orcl/undotbs01.dbf', '/oracle/product/10.2.0/oradata/orcl/sysaux01.dbf', '/oracle/product/10.2.0/oradata/orcl/users01.dbf', '/oracle/product/10.2.0/oradata/orcl/example01.dbf' CHARACTER SET WE8ISO8859P1 ; RECOVER DATABASE ALTER SYSTEM ARCHIVE LOG ALL; ALTER DATABASE OPEN; ALTER TABLESPACE TEMP ADD TEMPFILE '/oracle/product/10.2.0/oradata/orcl/temp01.dbf' SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
Gdy plik wygląda jak na listingu 16.2, powyżej wiersza STARTUP NOMOUNT należy dodać następującą instrukcję: CONNECT /AS SYSDBA;
W dalszej kolejności dla nieaktywnej instancji należy wykonać poniższe polecenie, wstawiając odpowiednią nazwę w miejsce łańcucha rebuild.sql. $ sqlplus /nolog < rebuild.sql
Polecenie powinno zadziałać bez interwencji administratora, całkowicie odbudowując pliki kontrolne. Gdy operacja zostanie ukończona, należy otworzyć bazę danych. Jeśli wszystko zadziałało i zastosowano opcję resetlogs, najlepszym rozwiązaniem będzie jak najszybsze zarchiwizowanie bazy danych. W przeciwnym razie można spróbować wykonać krok 8. Najprawdopodobniej ostatnimi krokami będą kroki 21. i 23.
Przywracan e bazy danych Oracle
| 489
Krok 8. — odtwarzanie plików kontrolnych i przygotowywanie bazy danych do przywracania Krok jest niezbędny tylko wtedy, gdy nie udało się wykonać kroków od 2. do 7.
Jeśli zastosowano środki zapobiegawcze, o których wspomniano w rozdziale, w rzeczywistości tylko jedno zdarzenie może zmusić do wykonania tego kroku. Mowa o utracie całego komputera na skutek jakiegoś kataklizmu. Z utratą napędu dyskowego (a nawet wielu dysków) można sobie z łatwością poradzić, gdy pliki kontrolne są multipleksowane (powielane). Jeśli nawet przepadły wszystkie pliki kontrolne, można je odbudować za pomocą pliku śladu utworzonego za pomocą instrukcji backup controlfile to trace. Począwszy od odtworzenia plików kontrolnych z kopii zapasowej, należy postępować zgodnie z poniższymi krokami. Może się okazać konieczne odtworzenie również plików danych bazy. Wynika to stąd, że trudno użyć pliku kontrolnego starszego od najnowszego pliku danych bazy (w takiej sytuacji serwer Oracle wygeneruje komunikat i przerwie proces). W celu stwierdzenia, czy plik kontrolny jest nowszy niż pliki danych, należy spróbować wykonać poniższe kroki bez nadpisywania plików danych bazy.
1. Odtwarzanie plików kontrolnych z kopii zapasowej Pierwszym krokiem procesu jest odnalezienie najnowszej kopii zapasowej i odtworzenie z niej pliku kontrolnego. Jeśli korzysta się z narzędzia rman z katalogiem i plik kontrolny archiwizuje się oddzielnie, można wykonać następujące polecenie: RMAN> restore controlfile
Jeżeli dla parametru controlfile autobackup ustawiono wartość on, należy połączyć się z programem rman i wywołać poniższe polecenie. RMAN> restore controlfile from autobackup
Jeśli tworzy się kopie zapasowe zarządzane przez użytkownika, trzeba wykonać polecenie backup controlfile to nazwa_pliku narzędzia sqlplus. Po znalezieniu zarchiwizowanego pliku kontrolnego należy skopiować go w każde miejsce uzyskane po zastosowaniu zapytania select value from v$parameter where name like control_files . Kopia pliku kontrolnego powinna być nowsza od najnowszego pliku danych bazy znajdującego się w obrębie instancji. Jeśli tak nie będzie, serwer Oracle wygeneruje komunikat.
2. Uruchamianie bazy danych Aby stwierdzić, czy plik kontrolny jest poprawny i został skopiowany we wszystkie odpowiednie miejsca, należy podjąć próbę uruchomienia bazy danych za pomocą opcji mount (poniższe polecenie zastosowano też w kroku 1.). Jeśli używa się narzędzia rman, po poleceniu restore controlfile można po prostu wykonać następującą instrukcję: RMAN> startup mount
490 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Ten krok należy omijać z daleka! Mam nadzieję, że zawartość tego punktu posłuży wyłącznie do celów edukacyjnych, ponieważ nie przedstawia on sytuacji, w której warto się znaleźć. Przywracanie po utracie wszystkich plików kontrolnych (bez użycia skryptu z instrukcją create controlfile) wymaga otwarcia bazy danych za pomocą opcji resetlogs. Gdy pojawi się taka konieczność, w przypadku zastosowania wersji serwera Oracle starszej niż wersja 10g wystąpi spory problem, polegający na tym, że serwer nie może skorzystać z dzienników powtórzeń. Przyjrzyjmy się poniższemu schematowi. T1 T2 T3 | --------------------------- | --------------------------- |
Załóżmy, że kopię zapasową sporządzono w chwili T1, a w chwili T2 wykonano polecenie open database resetlogs. Dodatkowo przyjmijmy, że kopia zapasowa nie została utworzona od
razu po ukończeniu procesu przywracania i jest chwila T3. Można pomyśleć, że za pomocą kopii zapasowej z chwili T1 i dzienników powtórzeń będzie można przywrócić bazę do stanu z chwili T3. Jednak nie będzie to możliwe, jeśli polecenie alter database open resetlogs wykonano w chwili T2. Właśnie dlatego trzeba kopię zapasową sporządzić od razu po otwarciu bazy danych przy użyciu opcji resetlogs. Jest to jeszcze jeden powód, dla którego powinno się uaktualnić serwer Oracle do obecnej wersji!
Jeżeli tworzy się kopie zapasowe zarządzane przez użytkownika, dla podłączonej i zamkniętej bazy danych należy zastosować poniższe polecenie. SQL> startup mount;
Po ukończeniu tego kroku należy przejść do kroku 9.
Krok 9. — przywracanie bazy danych Krok jest wymagany tylko wtedy, gdy nie udało się wykonać kroków od 2. do 7.
Po odtworzeniu pliku kontrolnego z kopii zapasowej przy jego użyciu należy spróbować przywrócić bazę danych.
Przywracanie i otwieranie bazy danych za pomocą narzędzia rman Jeśli używa się programu rman, krok ten będzie prosty do wykonania. Jako następne wystarczy wykonać polecenie recover database. To jedno polecenie zajmuje się przywróceniem bazy danych nawet wtedy, gdy korzysta się z zapasowego pliku kontrolnego. RMAN> recover database;
Właśnie w tym przypadku narzędzie rman naprawdę się przydaje. Jeśli proces przywracania wymaga użycia archiwalnych plików dzienników powtórzeń, dla których sporządzono kopię zapasową, program rman automatycznie odtworzy je z odpowiedniej lokalizacji, a następnie zastosuje i na końcu usunie. Cały proces przebiega samoczynnie niezależnie od miejsca przechowywania archiwalnych dzienników powtórzeń.
Przywracan e bazy danych Oracle
|
491
Jeżeli nie użyto zapasowego pliku kontrolnego, wystarczy otworzyć bazę danych. RMAN> alter database open;
Jeśli zastosowano zapasowy plik kontrolny, trzeba otworzyć bazę przy wykorzystaniu opcji resetlogs. RMAN> alter database open resetlogs;
Próba ręcznego przywrócenia bazy danych Ponieważ przywracanie bazy danych przy użyciu zapasowego pliku kontrolnego wymaga wykonania instrukcji alter database open resetlogs, niczym złym nie będzie podjęcie najpierw próby przywrócenia bazy w standardowy sposób. SQL> recover database;
Gdy okaże się konieczne zastosowanie zapasowego pliku kontrolnego, serwer Oracle wygeneruje poniższy komunikat o błędzie. ORA-00283: Recover session cancelled due to errors ... ORA-01207: file is more recent than controlfile - old controlfile
Jeżeli polecenie recover database da oczekiwane rezultaty, należy przejść do kroku 10. W przeciwnym razie należy podjąć próbę przywrócenia bazy danych za pomocą zapasowego pliku kontrolnego (zostało to opisane poniżej).
Gdy serwer Oracle wyświetli komunikat o błędzie, bazę danych trzeba przywrócić, korzystając z opcji backup controlfile. Dla podłączonej i zamkniętej bazy należy wykonać następujące polecenie: SQL> recover database using backup controlfile
Jeśli polecenie zadziała, uzyska się wynik podobny do zaprezentowanego na listingu 16.3. Listing 16.3. Przykładowy wynik polecenia recover database ORA-00279: change 38666 generated at 03/14/06 21:19:05 needed for thread 1 ORA-00289: suggestion : /db/Oracle/admin/crash/arch/arch.log1_494.dbf ORA-00280: change 38666 for thread 1 is in sequence #494
Jeśli serwer Oracle wygeneruje komunikat, prawdopodobnie będzie to oznaczać, że brakuje niektórych plików danych lub zostały uszkodzone. Gdy tak jest, należy cofnąć się do kroków 4. i 5. Po odtworzeniu wszelkich brakujących lub uszkodzonych plików danych należy powrócić do tego kroku i ponownie spróbować przywrócić bazę danych. Czasami podczas przywracania baz danych można mieć do czynienia z sytuacją, w której serwer Oracle informuje, że pliki danych są nowsze od pliku kontrolnego. Jedynym sposobem uniknięcia tego jest użycie zapasowej wersji plików danych starszych od zarchiwizowanej wersji pliku kontrolnego. Jeśli taka sytuacja ma miejsce, należy przejść do kroków 21. i 23. Proces przywracania nośnika uwzględni dla starszego pliku wszelkie zmiany, których w nim brakuje.
Serwer Oracle żąda wszystkich archiwalnych dzienników powtórzeń z okresu sięgającego aż do momentu utworzenia najstarszego odtworzonego pliku danych. Jeśli na przykład kopia zapasowa, z której odtworzono pliki danych, została sporządzona trzy dni wcześniej, serwer Oracle będzie wymagał wszystkich archiwalnych dzienników powtórzeń utworzonych od tego czasu. Pierwszy plik dziennika żądany przez serwer jest najstarszy. 492 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Jeśli wykonuje się kopie zapasowe zarządzane przez użytkownika i niezbędne są starsze archiwalne dzienniki powtórzeń, trzeba będzie odtworzyć je samemu. Gdy okaże się konieczne samodzielne odszukanie i zastosowanie dzienników, najbardziej efektywną metodą korzystania z archiwalnych dzienników powtórzeń będzie umieszczenie ich wszystkich bez kompresji w katalogu, który serwer Oracle zaproponuje jako lokalizację pierwszego pliku (oczywiście wymagana będzie znacznie większa przestrzeń dyskowa niż w przypadku metody bazującej na programie rman). Jeżeli Czytelnik musi tak postąpić, wystarczy, że w wierszu poleceń wprowadzi auto. W przeciwnym razie należy określić alternatywne lokalizacje lub wcisnąć klawisz Enter, gdy serwer Oracle zapyta o kolejne miejsca, umożliwiając skompresowanie plików lub ich usunięcie, gdy staną się zbędne. Jeśli będzie to możliwe, serwer Oracle automatycznie zastosuje wszystkie archiwalne dzienniki powtórzeń i dziennik trybu online, a na końcu wyświetli komunikat Media recovery complete. Gdy jednak serwer Oracle wczyta wszystkie archiwalne dzienniki powtórzeń, może poprosić o dziennik trybu online. W tym przypadku serwer żąda archiwalnego dziennika powtórzeń z numerem sekwencyjnym wyższym od numeru najnowszego dostępnego dziennika tego typu. Oznacza to, że serwer szuka dziennika powtórzeń trybu online. W odpowiedzi na żądanie należy spróbować podać nazwy dzienników powtórzeń online, którymi się dysponuje. Niestety, od razu po wpisaniu niewłaściwej nazwy serwer Oracle nakaże ponowne wykonanie polecenia recover database using backup controlfile. Załóżmy, że dostępne są następujące trzy dzienniki powtórzeń trybu online: /oracle/data/redolog01.dbf /oracle/data/redolog02.dbf /oracle/data/redolog03.dbf
Gdy pojawi się prośba o archiwalny dziennik powtórzeń z numerem sekwencyjnym wyższym od najwyższego numeru istniejącego dziennika tego typu, w odpowiedzi należy podać jeden z powyższych plików (na przykład /oracle/data/redolog01.dbf). Jeśli wprowadzony plik nie ma numeru szukanego przez serwer Oracle, pojawi się poniższy komunikat. ORA-00310: archived log contains sequence 2; sequence 3 required ORA-00334: archived log: '/oracle/data/redolog01.dbf'
Serwer Oracle anuluje proces przywracania bazy danych, żądając rozpoczęcia go od nowa. Po wyświetleniu jeszcze raz tego samego wiersza poleceń należy podać inną nazwę pliku, taką jak /oracle/data/redolog02.dbf. Jeśli plik zawiera szukany numer sekwencyjny, zostanie wygenerowany następujący komunikat: Log applied. Media recovery complete.
Gdy po wypróbowaniu wszystkich dzienników powtórzeń online serwer Oracle nadal będzie żądał dziennika, którym użytkownik nie dysponuje, po prostu należy wpisać cancel.
Instrukcja alter database open resetlogs Po ukończeniu procesu przywracania nośnika następnym krokiem jest otwarcie bazy danych. Jak już wspomniano, gdy bazę przywraca się przy użyciu zapasowego pliku kontrolnego, trzeba ją otworzyć z wykorzystaniem opcji resetlogs. W tym celu dla podłączonej i zamkniętej bazy danych należy wywołać następującą instrukcję SQL: SQL> alter database open resetlogs;
Przywracan e bazy danych Oracle
| 493
Nowsze wersje serwera Oracle pozwalają na utworzenie pliku kontrolnego za pomocą opcji resetlogs. Jeśli tak się postąpi, można po prostu otworzyć bazę bez konieczności stosowania opcji resetlogs. Jeżeli używa się wersji serwera Oracle starszej niż 10g, trzeba sporządzić kopię zapasową od razu po przywróceniu bazy danych z wykorzystaniem opcji resetlogs! Jeśli nawet stosuje się wersję 10g serwera Oracle, byłoby wskazane jak najszybsze utworzenie kopii zapasowej bazy danych. Choć najlepsze byłoby utworzenie „zimnej” kopii zapasowej po zamknięciu bazy danych, wykonanie „gorącej” kopii jest lepsze niż nic. Trzeba jedynie pamiętać, że jeśli zezwoli się na funkcjonowanie bazy danych podczas jej archiwizowania i coś złego stanie się przed ukończeniem tej operacji, ryzykuje się, że: • Może być konieczne ponowne przeprowadzenie całego procesu przywracania. • W przypadku używania wersji serwera Oracle starszej niż 10g przepadną wszystkie zmiany
dokonane po zastosowaniu opcji resetlogs. Jeśli nie udało się otworzyć bazy danych, należy powrócić do kroku 1. i zacząć cały proces od nowa. Jeżeli otwarto bazę danych, należy od razu wykonać kopię zapasową całej jej zawartości (preferowana jest „zimna” kopia). Gratulacje! Udało się!
Krok 10. — czy działa polecenie alter database open? Jeśli przed wykonaniem tego kroku zamknięto bazę danych, trzeba ponownie wywołać polecenie startup mount.
Gdy polecenie startup mount zadziała, w rzeczywistości będzie to dopiero drugi wykonywany krok. Operacja podłączania bazy danych sprawdza jedynie obecność i spójność plików kontrolnych. Jeśli wszystko jest w porządku, następnym krokiem będzie otwarcie bazy. W ramach tej operacji sprawdza się dostępność i spójność wszystkich plików danych, dzienników powtórzeń trybu online, a także wszelkich segmentów wycofywania lub powrotu. Aby otworzyć bazę danych, gdy jest podłączona i zamknięta, należy wykonać następującą instrukcję: SQL> alter database open;
Jeśli powiedzie się próba otwarcia bazy danych, serwer Oracle po prostu wyświetli komunikat Database Altered. Jeżeli przy pierwszej próbie otwarcia bazy żaden plik danych ani segment wycofywania nie został przełączony w tryb offline, oznacza to całkowity sukces! Gdy trzeba było przejść do kroku 23. (uszkodzone grupy dzienników) i nie powiodła się próba otwarcia bazy danych, w celu przywrócenia całej bazy należy powrócić do kroku 21. Jeśli baza danych została otwarta, należy wykonać krok 15.
494 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Duże uproszczenie dla użytkowników narzędzia rman Jeżeli korzysta się z programu rman i nie udało się otworzyć bazy danych, można podjąć poważną decyzję. Można kontynuować tę procedurę, aby stwierdzić, co jest nie tak, i usunąć po kolei problemy, lub po prostu wykonać dwa polecenia. Jeśli drugi wariant wydaje się bardziej interesujący, należy spróbować wywołać następujące polecenia: RMAN> restore database; RMAN> recover database;
Kopie zapasowe zarządzane przez użytkownika Jeśli tworzy się kopie zarządzane przez użytkownika lub chciałoby się resztę kroków wykonać ręcznie za pomocą narzędzia rman, trzeba stwierdzić, dlaczego baza danych nie została otwarta. Wynik zmienia się w zależności od warunku. Poniżej zamieszczono listę kilku możliwych warunków wraz z komunikatem o błędzie, który może pojawić się po wystąpieniu konkretnego warunku. Brakujący plik danych ORA-01157: cannot identify datafile 1 - file not found ORA-01110: datafile 1: '/db/Oracle/a/oradata/crash/system01.dbf'
Uszkodzony plik danych Uszkodzony plik danych może wygenerować kilka różnych błędów. Przykładowo może to być komunikat taki jak w przypadku brakującego pliku danych. ORA-01157: cannot identify datafile 1 - file not found ORA-01110: datafile 1: '/db/Oracle/a/oradata/crash/system01.dbf'
Uszkodzony plik danych może również spowodować, że serwer Oracle wyświetli zupełnie niewłaściwy komunikat. Oto przykład: ORA-00600: internal error code, arguments: [kfhcfh1_01], [0], [], [], [],
Uszkodzony plik danych może też spowodować wygenerowanie następującego komunikatu o błędzie nieudanej weryfikacji: ORA-01122: database file 1 failed verification check ORA-01110: datafile 1: '/db/Oracle/a/oradata/crash/system01.dbf' ORA-01200: actual file size of 1279 is smaller than correct size of 40960 blocks
To tylko kilka przykładów typów błędów, które serwer Oracle może wyświetlić, gdy plik danych jest uszkodzony. Brak członka dowolnej grupy dzienników online Jeżeli dzienniki powtórzeń są multipleksowane (powielane) i przepadnie jedna lub więcej uzyskanych w ten sposób kopii, lecz pozostanie co najmniej jedna poprawna kopia każdego dziennika powtórzeń online, serwer Oracle otworzy bazę danych bez wyświetlania w terminalu żadnych błędów. Bez wątpienia firma Oracle uważa to za korzystne rozwiązanie. Jednak byłoby dobrze, gdyby przynajmniej w takiej sytuacji pojawił się odpowiedni komunikat. Nie ma nic złego w tym, że serwer Oracle otwiera bazę danych. Po prostu życzyłbym sobie, żeby ta niebezpieczna sytuacja była trochę bardziej wyraźnie sygnalizowana. Jedyne, co jest generowane, to poniższy komunikat o błędzie zapisywany w dzienniku alertów. Errors in file /db/Oracle/admin/crash/bdump/crash_lgwr_10302.trc: ORA-00313: open failed for members of log group 2 of thread 1
Przywracan e bazy danych Oracle
| 495
Wszyscy członkowie dowolnej grupy dzienników online zostali uszkodzeni Jeśli jednak zostaną uszkodzeni wszyscy członkowie dowolnej grupy dzienników online, serwer Oracle wygeneruje komunikat o błędzie i baza danych nie będzie otwarta. Komunikat może wyglądać podobnie do poniższego. ORA-00327: log 2 of thread 1, physical size less than needed ORA-00312: online log 2 thread 1: '/db/Oracle/b/oradata/crash/redocrash02.log' ORA-00312: online log 2 thread 1: '/db/Oracle/a/oradata/crash/redocrash03.log'
Brakuje wszystkich członków dowolnej grupy dzienników online Podobny problem występuje, gdy brakuje wszystkich członków dowolnej grupy dzienników online. W takiej sytuacji serwer Oracle wyświetli komunikat o błędzie i nie otworzy bazy danych. Komunikat wygląda podobnie do następującego: ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/db/Oracle/b/oradata/crash/redocrash02.log' ORA-00312: online log 2 thread 1: '/db/Oracle/a/oradata/crash/redocrash03.log'
Uszkodzony obszar tabel powrotu ORA-01122: database file 1 failed verification check ORA-01110: datafile 1: '/oracle/product/10.2.0/oradata/orcl/undotbs01.dbf' ORA-01200: actual file size of 1279 is smaller than correct size of 40960 blocks
Uszkodzony segment wycofywania W przypadku uszkodzenia segmentu wycofywania pojawi się poniższy komunikat o błędzie. ORA-01545: rollback segment 'USERS_RS' specified not available Cannot open database if all rollback segments are not available.
Uszkodzony plik danych W rzeczywistości bardzo łatwo można sobie poradzić z uszkodzonym plikiem danych. Jest to dobra wiadomość, ponieważ taka sytuacja ma miejsce znacznie częściej niż każdy innym problem. Trzeba pamiętać, że w przeciwieństwie do dzienników powtórzeń online i plików kontrolnych, które mogą być multipleksowane (powielane), dla każdego pliku danych istnieje tylko jedna kopia. W związku z tym, statystycznie rzecz ujmując, łatwiej stracić jeden plik danych niż wszystkie multipleksowane (powielane) kopie grupy dzienników lub pliku kontrolnego. Serwer Oracle jest w stanie przywrócić wybrane elementy bazy danych, gdy jej pozostała część jest aktywna. Niestety, będzie to przydatne tylko wtedy, gdy częściowo funkcjonująca baza danych może być w ogóle wykorzystywana przez użytkowników zarządzanego środowiska. A zatem baza danych, która jest zupełnie bezużyteczna do momentu udostępnienia wszystkich tabel, nie skorzysta z możliwości częściowego odtwarzania bazy w trybie online. Jeśli jednak użytkownicy mogą używać części bazy danych, gdy są przywracane uszkodzone pliki, ta funkcja może pomóc w poprawieniu trudnej sytuacji, w jakiej znalazł się administrator, przez zapewnienie przynajmniej częściowej funkcjonalności bazy. Ponieważ proces częściowego odtwarzania bazy w trybie online w rzeczywistości jest bardziej pracochłonny, na poważnie powinno się przeanalizować, czy okaże się pomocny, jeszcze zanim faktycznie trzeba będzie go przeprowadzić. Dzięki temu, gdy pojawi się konieczność wykonania dużej operacji odtwarzania, ta kwestia będzie już wyjaśniona. Jeśli mowa o procesie przywracania, można wyróżnić następujące trzy typy plików danych: • Pierwszy rodzaj pliku danych to plik, który nie jest wymagany do uruchomienia bazy
danych. Dawniej niezbędny do tego był systemowy obszar tabel. W obecnych wersjach serwera Oracle wymagane obszary tabel to: systemowy, sysaux i powrotu. Jeśli plik danych stanowi
496 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
część obszaru tabel, która nie jest potrzebna do uruchomienia bazy danych, przywrócenie takiego pliku (bazy danych w trybie online lub offline) nie stanowi większego problemu. • Drugim typem pliku danych jest plik tymczasowego obszaru tabel. Jest to plik tymczasowy.
Przywrócenie takiego pliku jest łatwe, ponieważ serwer Oracle po prostu sam ponownie tworzy ten plik po otwarciu bazy danych. • Trzecim typem pliku danych też jest niesystemowy plik. Jednak plik ten zawiera segment
wycofywania. Ponieważ tego rodzaju segmenty są wymagane do otwarcia bazy danych, przywracanie takiego pliku danych, gdy uaktywniono bazę, jest trudną operacją. Również w tym miejscu należy powtórzyć, że powinno się jak najszybciej dokonać migracji do obszaru tabel powrotu i segmentów powrotu.
Trzeba jeszcze wspomnieć o dodatkowym typie pliku danych znajdującym się w wymaganym obszarze tabel (systemowy, sysaux lub powrotu w przypadku wersji 10g serwera Oracle i systemowy w poprzednich wersjach). Plik ten nie może zostać przywrócony w trybie online bazy danych, gdyż bez tego pliku bazy nie da się uaktywnić.
Uszkodzona grupa dzienników Jeśli są uszkodzeni wszyscy członkowie grupy dzienników, istnieje duże ryzyko utraty danych. To, czy trzeba będzie odtwarzać całą bazę danych, zależy od stanu uszkodzonej grupy dzienników i rezultatów prób podjętych w celu naprawienia grupy. Choć problemem może być tylko uszkodzony rekord, pokazuje to, jak ważne jest multipleksowanie (powielanie) grup dzienników. Jeżeli błędy odwołują się do uszkodzonej grupy dzienników, jednym z wariantów jest przejście bezpośrednio do kroku 17. Aby jednak sprawdzić, że nic innego złego się nie stało, należy się zapoznać z resztą opisu tego kroku, a następnie wykonać następny.
Uszkodzony niezbędny obszar tabel Jeśli uszkodził się dowolny plik danych należący do wymaganego obszaru tabel, trzeba będzie odtworzyć go w trybie offline. Bez takiego pliku nie jest możliwe otwarcie bazy danych. Jeżeli błędy wskazują na wymagany obszar tabel, jednym z rozwiązań jest przejście bezpośrednio do kroku 11. Aby jednak sprawdzić, że nic innego złego się nie stało, należy się zapoznać z resztą opisu tego kroku, a potem wykonać następny.
Uszkodzony segment wycofywania Jeśli w dalszym ciągu używa się segmentów wycofywania, trzeba przeczytać ten podpunkt opisu niniejszego kroku. Gdy korzysta się z funkcji automatycznego zarządzania segmentami powrotu, podpunkt można pominąć.
Ponieważ serwer Oracle musi otworzyć pliki danych zawierające uszkodzony segment wycofywania, zanim będzie w stanie sprawdzić, czy segment jest dostępny, komunikat o błędzie nie zostanie wygenerowany do momentu przełączenia pliku danych w tryb offline. Jeśli serwer Oracle natrafi na uszkodzony plik danych (przechowujący segment wycofywania lub nie), wyświetli związany z nim komunikat o błędzie i przerwie próbę otwarcia bazy danych.
Przywracan e bazy danych Oracle
|
497
Trzeba pamiętać, że segment wycofywania jest specjalnym składnikiem obszaru tabel, który przechowuje informacje związane z wycofywaniem. Informacje te są niezbędne do odwołania (cofnięcia) niezatwierdzonej transakcji. Ze względu na to, że baza danych po awarii prawie zawsze ma niezatwierdzone transakcje, przywracanie bazy z uszkodzonym segmentem wycofywania jest trochę utrudnione. Jak już wspomniano, uszkodzony plik danych można przełączyć w tryb offline. Jednak serwer Oracle nie otworzy bazy danych bez segmentu wycofywania. Jeśli błąd wskazuje na uszkodzony segment wycofywania, należy wykonać krok 18.
Zanim będzie się kontynuować… Trzeba wiedzieć, że serwer Oracle przerwie próbę otwarcia bazy danych od razu po stwierdzeniu błędu związanego z jednym plikiem. Oczywiście oznacza to, że mogą też być uszkodzone inne pliki. Jeśli uszkodzony jest co najmniej jeden plik danych, warto przekonać się, czy inne pliki też są uszkodzone. Jak to zrobić, dokładnie objaśniono w kroku 5. Gdy są już znane nazwy wszystkich uszkodzonych plików, można je przywrócić w sposób omówiony poniżej.
Działanie procesu przywracania nośnika Jeżeli z kopii zapasowej zamierza się odtworzyć dowolny plik danych, trzeba skorzystać z polecenia recover narzędzia sqlplus lub rman. Polecenie to używa archiwalnych dzienników powtórzeń i trybu online, aby ponownie wykonać wszelkie transakcje, które miały miejsce od czasu sporządzenia kopii zapasowej pliku danych. Wykonując polecenia: recover database, recover tablespace nazwa_obszaru_tabel lub recover datafile nazwa_pliku_danych, można odpowiednio przywrócić całą bazę danych, obszar tabel lub plik danych. W przypadku kopii zapasowych zarządzanych przez użytkownika lub tworzonych za pomocą programu rman wystarczy wykonać polecenie recover database. W obu wariantach automatycznie jest stwierdzane, co wymaga przywracania nośnika, a następnie jest przeprowadzany odpowiedni proces przywracania. Różnica między kopiami zarządzanymi przez użytkownika i sporządzanymi przy użyciu narzędzia rman staje się widoczna, gdy potrzebny jest archiwalny dziennik dostępny wyłącznie w kopii zapasowej. Jeśli program rman musi pobrać z kopii zapasowej jakiekolwiek archiwalne dzienniki powtórzeń, automatyzuje ich odtwarzanie, a w razie potrzeby także usuwanie. Jeżeli wykonuje się kopie zapasowe zarządzane przez użytkownika, krok ten trzeba wykonać samemu. Proces przywracania nośnika można też przeprowadzić dla pojedynczego pliku danych. W tym celu dla podłączonej i zamkniętej bazy danych należy wykonać następującą instrukcję SQL: SQL> recover datafile '/db/Oracle/a/oradata/crash/datafile01.dbf'
Polecenie umożliwia odtworzenie starszej wersji pliku danych i zastosowanie dziennika powtórzeń do przywrócenia pliku danych do stanu z chwili wystąpienia awarii. Jeśli na przykład kopię zapasową pliku danych sporządzono w środę wieczorem, a plik ten uszkodził się w czwartek wieczorem, odtworzony plik będzie miał stan ze środowego wieczoru. Oczywiście od tego czasu mogło mieć miejsce wiele transakcji, które dokonały zmian w uszkodzonych plikach danych. Polecenie recover [database|tablespace|datafile] ponownie wykonuje te transakcje dla odtworzonego pliku danych, przywracając go do stanu z czwartkowego wieczoru. Proces przywracania może przebiegać na kilka różnych sposobów. Po wykonaniu polecenia recover serwer Oracle żąda nazwy i lokalizacji pierwszego wymaganego archiwalnego dziennika powtórzeń. Jeśli ten i wszystkie inne dzienniki utworzone po tym dzienniku są w trybie online, 498 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
bez kompresji i w swojej oryginalnej lokalizacji, należy wpisać słowo auto. Spowoduje ono, że serwer Oracle przyjmie, że wszystkie wymagane przez niego pliki znajdują się w trybie online. W związku z tym może automatycznie wczytać każdy dziennik. Aby tak było, wszystkie pliki, które są niezbędne dla serwera Oracle, muszą być w trybie online. Najpierw należy uzyskać nazwę najstarszego pliku, ponieważ jako pierwszy będzie wymagany przez serwer Oracle. Nazwa tego pliku jest wyświetlana od razu po wykonaniu polecenia recover. ORA-00279: change 18499 generated at 02/21/06 11:49:56 needed for thread 1 ORA-00289: suggestion : /db/Oracle/admin/crash/arch/arch.log1_481.dbf ORA-00280: change 18499 for thread 1 is in sequence #481 Specify log: {=suggested | filename | AUTO | CANCEL}
W poprzednim przykładzie pierwszy plik wymagany przez serwer Oracle ma ścieżkę /db/Oracle/ ¦admin/crash/arch/arch.log1_481.dbf. Trzeba upewnić się, że plik ten znajduje się w trybie online i nie został skompresowany lub usunięty. Jeśli plik usunięto, należy odtworzyć go z kopii zapasowej. Gdy plik poddano kompresji, należy go zdekompresować, podobnie jak wszelkie archiwalne dzienniki powtórzeń zawarte w tym samym katalogu, które są nowsze od tego pliku. Wynika to stąd, że serwer Oracle może wymagać wszystkich tych dzienników do ukończenia procesu przywracania nośnika. Jeśli nie korzysta się z narzędzia rman, być może będzie trzeba usunąć część starszych archiwalnych dzienników powtórzeń, aby zapewnić wystarczającą ilość miejsca dla plików wymagających dekompresji. Gdy wszystkie archiwalne dzienniki powtórzeń nowsze od pliku żądanego przez serwer Oracle zostaną odtworzone i poddane dekompresji, w wierszu Specify log należy wpisać auto. Program rman można tak skonfigurować, żeby w danej chwili odtwarzał z taśmy tylko jeden dziennik powtórzeń, a następnie stosował ten plik i usuwał go w celu zwolnienia miejsca. Za pomocą parametru maxsize można spowodować, że narzędzie rman będzie wykorzystywać na dysku określoną ilość miejsca. Oczywiście ta cała część procesu odtwarzania powiedzie się tylko wtedy, gdy zastosuje się tryb archivelog. Z trybu tego trzeba korzystać zawsze, gdy jest to możliwe.
Jeśli brakuje miejsca na dekompresję wszystkich archiwalnych dzienników powtórzeń, może być niezbędna odrobina kreatywności. Po zdekompresowaniu tak wielu dzienników, jak jest to tylko możliwe, należy wcisnąć klawisz Enter każdorazowo, gdy pojawi się propozycja dekompresji następnego pliku (wciśnięcie tego klawisza spowoduje, że serwer Oracle uzna sugerowany przez siebie plik za dostępny; jeśli serwer stwierdzi, że plik nie jest dostępny, ponownie go zażąda). Gdy serwer Oracle skończy korzystać z jednego archiwalnego dziennika, należy go skompresować, po czym poddać dekompresji nowszy dziennik, ponieważ będzie wkrótce potrzebny (oczywiście jest niezbędne otwarcie drugiego okna, a nie zaszkodzi też uaktywnienie trzeciego!). W pewnym momencie serwer Oracle może poprosić o archiwalny dziennik powtórzeń, który nie jest dostępny. Może to oznaczać, że uszkodziły się jakieś archiwalne dzienniki powtórzeń lub trybu online. Jeśli pliku nie można odnaleźć lub odtworzyć, należy wprowadzić cancel. Więcej szczegółów dotyczących procesu przywracania nośnika zamieszczono w dokumentacji serwera Oracle. Jeżeli jakiś uszkodzony plik danych jest członkiem dowolnego wymaganego obszaru tabel, należy zastosować krok 12. Gdy żaden z tych plików nie wchodzi w skład wymaganego obszaru tabel, należy przejść do kroku 13. Przywracan e bazy danych Oracle
| 499
Krok 11. — czy są uszkodzone pliki danych wymaganych obszarów tabel? Jeśli uszkodzony plik danych stanowi część niezbędnego obszaru tabel (systemowy, sysaux, powrotu i tymczasowy w przypadku wersji 10g serwera Oracle lub systemowy w poprzednich wersjach), trzeba będzie przeprowadzić proces przywracania w trybie offline. Niestety, serwer Oracle informuje jedynie o braku pliku danych. Nie podaje szczegółów dotyczących typu pliku danych. Jeśli jednak nawet baza danych Oracle jest niedostępna, w prosty sposób można stwierdzić, jakie pliki danych należą do wymaganych obszarów tabel. Określenie, czy plik danych zawiera segment wycofywania, jest trochę trudniejsze, lecz w dalszym ciągu możliwe. Jeżeli używa się narzędzia rman z katalogiem przywracania, można się z nim połączyć, a następnie ustawić identyfikator bazy danych i wykonać polecenie report schema. Polecenie zwraca lokalizacje i pliki, a także informuje, czy znajdują się w nich segmenty wycofywania. RMAN> report schema; Report of database schema File Size(MB) Tablespace RB segs Datafile Name ---- ---------- ----------------------------------------------1 307200 SYSTEM NO /oracle/oradata/trgt/system01.dbf 2 20480 UNDOTBS YES /oracle/oradata/trgt/undotbs.dbf 3 10240 CWMLITE NO /oracle/oradata/trgt/cwmlite01.dbf 4 10240 DRSYS NO /oracle/oradata/trgt/drsys01.dbf 5 10240 EXAMPLE NO /oracle/oradata/trgt/example01.dbf 6 10240 INDX NO /oracle/oradata/trgt/indx01.dbf 7 10240 TOOLS NO /oracle/oradata/trgt/tools01.dbf 8 10240 USERS NO /oracle/oradata/trgt/users01.dbf
W celu stwierdzenia, które pliki danych należą do systemowego obszaru tabel, trzeba skierować zapytanie do perspektywy sys.dba_data_files. SQL> select file_name, tablespace_name from sys.dba_data_files; /oracle/oradata/trgt/system01.dbf SYSTEM /oracle/oradata/trgt/undotbs01.dbf UNDOTBS /oracle/oradata/trgt/cwmlite01.dbf CWMLITE /oracle/oradata/trgt/drsys01.dbf DRSYS /oracle/oradata/trgt/example01.dbf EXAMPLE /oracle/oradata/trgt/indx01.dbf INDX /oracle/oradata/trgt/tools01.dbf TOOLS /oracle/oradata/trgt/users01.dbf USERS
W tym przykładowym wyniku widać trzy pliki danych będące członkami obszaru tabel systemowego, sysaux i powrotu. Jednakże w konfiguracji używanej bazy danych z tymi obszarami tabel może być powiązanych wiele plików danych. Jeśli dowolny z uszkodzonych plików danych jest członkiem wymaganego obszaru tabel, należy przejść do kroku 12. Gdy żaden z tych plików nie należy do niezbędnych obszarów tabel, należy wykonać krok 13.
Krok 12. — odtwarzanie wszystkich plików danych żądanych obszarów tabel W przeciwieństwie do innych obszarów tabel, wymagane obszary tabel (systemowy, sysaux, powrotu i tymczasowy w przypadku wersji 10g serwera Oracle lub systemowy w poprzednich wersjach) muszą być dostępne, aby można było otworzyć bazę danych. A zatem, jeśli uszkodzi się jakikolwiek plik danych wchodzący w skład tych obszarów tabel, trzeba go odtworzyć. 500 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Przedtem należy sprawdzić, czy baza danych nie jest otwarta (wszystko jest w porządku, gdy jest tylko podłączona). W tym celu dla podłączonej i zamkniętej bazy danych należy wykonać poniższą instrukcję. SQL> select status from v$instance; STATUS ------MOUNTED 1 row selected.
W powyższym przykładzie widać, że instancja jest podłączona, lecz nie otwarta. Jeśli baza danych nie została otwarta, uszkodzone pliki należy odtworzyć z najnowszej dostępnej kopii zapasowej. Jeżeli tworzy się kopie zapasowe zarządzane przez użytkownika, trzeba określić miejsce ich składowania, a następnie odtworzyć ich zawartość. Gdy używa się narzędzia rman, wystarczy wykonać następujące polecenie: RMAN> restore database;
Program rman automatycznie stwierdzi, które pliki muszą zostać odtworzone, po czym przywróci je z najnowszej kopii zapasowej. Nie będą odtwarzane pliki, które wyglądają na poprawne. Po odtworzeniu wszystkich uszkodzonych plików wymaganego obszaru tabel należy dla podłączonej i zamkniętej bazy danych wywołać poniższe polecenie. Jeśli zamierza się udostępnić wyłącznie takie obszary tabel, a następnie naprawić pozostałe obszary, proces przywracania nośnika trzeba będzie zastosować tylko dla wybranych obszarów. W porównaniu z odtwarzaniem wszystkich uszkodzonych plików danych i wykonaniem jednego polecenia recover database taka operacja może być bardziej złożona i czasochłonna. Aby przywrócić wyłącznie wymagane obszary tabel, dla każdego z nich należy wywołać instrukcję recover. Poniższe przykładowe polecenia umożliwiają przeprowadzenie procesu przywracania nośnika dla systemowego obszaru tabel. RMAN> recover tablespace system;
W przypadku narzędzia sqlplus polecenie wygląda tak: SQL> recover tablespace system;
Jeśli przywraca się wiele obszarów tabel, prawdopodobnie najlepszym rozwiązaniem będzie po prostu zastosowanie polecenia recover database, które przeprowadza proces przywracania nośnika dla całej bazy danych. Gdy polecenie to zakończy działanie, niezbędne obszary tabel zostaną przywrócone do stanu z chwili wystąpienia awarii. Jeżeli zakończy się to całkowitym powodzeniem i nie będzie uszkodzony żaden inny plik danych, należy powrócić do kroku 10. Więcej informacji na temat polecenia recover tablespace można znaleźć w podpunkcie „Działanie procesu przywracania nośnika” zamieszczonym na końcu opisu kroku 10. Jeśli są inne pliki danych do przywrócenia, należy wykonać krok 13.
Krok 13. — czy uszkodził się plik danych niewymaganego obszaru tabel? Dotąd podłączano bazę danych, co potwierdza, że pliki kontrolne są w porządku. Być może trochę więcej trzeba było się napracować, gdy uszkodził się jeden lub więcej plików kontrolnych, lecz ostatecznie udało się osiągnąć sukces. Dodatkowo stwierdzono, że wszelkie wymagane obszary tabel są nienaruszone, nawet gdy w tym celu trzeba było przeprowadzić operacje Przywracan e bazy danych Oracle
|
501
odtwarzania i przywracania. Większa część reszty omawianej procedury koncentruje się na wyłączeniu uszkodzonych składników bazy danych, tak aby można ją było jak najszybciej udostępnić. Proces eliminowania identyfikuje wszystkie uszkodzone pliki danych po udanym otwarciu bazy danych. W dalszej kolejności pliki te można z łatwością odtworzyć. Jeśli istnieją uszkodzone pliki danych niewchodzące w skład niezbędnych obszarów tabel, należy przejść do kroku 14. Gdy nie ma już żadnych uszkodzonych plików danych, należy wykonać krok 17.
Krok 14. — przełączenie uszkodzonego pliku danych w tryb offline W celu otwarcia bazy danych z uszkodzonym plikiem danych niewymaganego obszaru tabel plik ten należy przełączyć w tryb offline. Krok ten nie powinien być wykonywany w przypadku plików danych zawierających segmenty wycofywania. Pliki te należy odtworzyć przed uaktywnieniem bazy.
Jeśli instancja działa w trybie archivelog, wystarczy plik danych przełączyć w tryb offline. Taki plik można odtworzyć w późniejszym czasie po uaktywnieniu instancji. Umożliwia to następujące polecenie: SQL> alter database datafile 'nazwa_pliku' offline;
Jeżeli instancja funkcjonuje w trybie noarchivelog, ma się do czynienia z odmiennym problemem. Serwer Oracle nie pozwoli na przełączenie pliku danych w tryb offline, gdyż wie, że bez procesu przywracania nośnika nie będzie mógł go z powrotem udostępnić. Gdy nie zastosowano trybu archivelog, przywracanie nośnika nie jest możliwe. Jeśli nie użyto tego trybu, trzeba potraktować wszystkie uszkodzone pliki danych jako niezbędne i powrócić do kroku 12. Po przełączeniu w tryb offline wszelkich uszkodzonych plików danych należy cofnąć się do kroku 10. i ponownie spróbować otworzyć bazę danych.
Krok 15. — czy jakieś pliki danych przełączono w tryb offline? Niniejszy krok należy wykonać tylko wtedy, gdy baza danych została otwarta.
Pytanie w tytule jest naprawdę proste. Jeśli bazę danych udało się otworzyć bez przełączania w tryb offline żadnego pliku danych, oznacza to zakończenie procedury. Jeżeli w celu otwarcia bazy trzeba było kilka plików danych przełączyć w tryb offline, pora je odtworzyć i przywrócić. Aby sprawdzić, czy jakieś pliki danych znajdują się w trybie offline, należy wywołać poniższe polecenie. SQL> select name from v$datafile where status = 'OFFLINE'; NAME ---------------/db/oracle/a/oradata/crash/tools01.dbf /db/oracle/a/oradata/crash/users01.dbf
502
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Jeśli w celu otwarcia bazy danych jakieś pliki danych przełączono w tryb offline, należy przejść do kroku 16. Gdy nie jest się tego pewnym, też należy wykonać krok 16.
Krok 16. — odtwarzanie i przywracanie plików danych w trybie offline Jeżeli jakieś pliki danych przełączono w tryb offline, trzeba je odtworzyć i ponownie udostępnić.
Odtwarzanie uszkodzonych plików danych W tym celu po określeniu nazw plików danych, które trzeba odtworzyć, należy użyć najnowszej dostępnej kopii zapasowej. Jeśli tworzy się kopie zapasowe zarządzane przez użytkownika, trzeba będzie zdecydować, jakie pliki odtworzyć i z jakiego źródła. Gdy korzysta się z narzędzia rman, trzeba jedynie wywołać następujące polecenie: RMAN> restore database;
Po odtworzeniu plików danych w przypadku serwera Oracle przywracanie można wykonać na trzy odmienne sposoby. Różnią się one znacząco pod względem złożoności i elastyczności. Po przeanalizowaniu niżej omówionych metod przywracania nośnika należy wybrać najbardziej odpowiednią.
Przywracanie pliku danych Jeśli do przywrócenia jest niewielka liczba plików danych, może to być najprostsza metoda. Po odtworzeniu plików należy dla każdego z nich wykonać instrukcję recover datafile, a następnie pliki udostępnić. Poniższe polecenia można wykonać w oknie narzędzia rman lub sqlplus. recover datafile 'nazwa_pliku_danych'; alter database datafile 'nazwa_pliku_danych' online;
Wadą tej metody jest to, że proces przywracania nośnika przeprowadzany dla każdego pliku danych może trochę potrwać. Jeśli dla pojedynczego obszaru tabel zamierza się przywrócić wiele plików danych, prawdopodobnie będzie to strata czasu.
Przywracanie obszaru tabel Choć jest to najtrudniejsza z wszystkich trzech metod, może okazać się szybsza od poprzedniej, gdy w jednym obszarze tabel znajduje się kilka uszkodzonych plików danych. Jeśli w czasie przywracania uszkodzonych plików danych trzeba pozostawić otwartą częściowo funkcjonalną bazę danych i plików jest kilka, prawdopodobnie będzie to najlepsza metoda. Najpierw należy określić nazwy wszystkich plików danych i obszary tabel, w których skład wchodzą. Ponieważ baza danych pozostaje otwarta, można to zrobić w jednym kroku (listing 16.4). Listing 16.4. Zawartość perspektywy dba_data_files SQL> select file_name, tablespace_name from dba_data_files; Statement processed. FILE_NAME TABLESPACE_NAME -----------------------------------------------------------------------------------------
Przywracan e bazy danych Oracle
| 503
/db/oracle/a/oradata/crash/users01.dbf USERS /db/oracle/a/oradata/crash/tools01.dbf TOOLS /db/oracle/a/oradata/crash/temp01.dbf TEMP /db/oracle/a/oradata/crash/rbs01.dbf RBS /db/oracle/a/oradata/crash/system01.dbf SYSTEM /db/oracle/a/oradata/crash/test01.dbf TEST
Po odtworzeniu wszystkich plików danych i zidentyfikowaniu każdego obszaru tabel zawierającego te pliki należy dla każdego obszaru wykonać polecenie recover tablespace. Jednak wcześniej każdy obszar tabel trzeba przełączyć w tryb offline (listing 16.5). Polecenia na listingu 16.5 można zastosować zarówno w przypadku narzędzia rman, jak i sqlplus. Listing 16.5. Przywracanie obszaru tabel alter tablespace nazwa_obszaru_tabel_1 offline; recover tablespace nazwa_obszaru_tabel_1; alter tablespace nazwa_obszaru_tabel_1 online; alter tablespace nazwa_obszaru_tabel_2 offline; recover tablespace nazwa_obszaru_tabel_2; alter tablespace nazwa_obszaru_tabel_2 online;
Oczywiście metoda ta jest dość pracochłonna! Choć nie jest elegancka i prosta, umożliwia przywrócenie wielu obszarów tabel, gdy instancja cały czas jest aktywna. Jeśli częściowo funkcjonująca baza danych przedstawia dla użytkowników jakąkolwiek wartość, z ich punktu widzenia metoda ta może okazać się najlepsza.
Przywracanie bazy danych Choć w rzeczywistości jest to najłatwiejsza metoda, wymaga wyłączenia bazy danych. Po odtworzeniu wszystkich plików danych, które przełączono w tryb offline, należy zamknąć bazę i wykonać polecenie recover database. Gdy zostaną odtworzone wszystkie pliki bazy danych, należy wywołać polecenia na listingu 16.6, które są zgodne zarówno z narzędziem rman, jak i sqlplus. Listing 16.6. Standardowe przywracanie bazy danych shutdown immediate; startup mount; recover database; alter database open;
Aby mieć pewność, że wszystkie obszary tabel i pliki danych przywrócono do poprawnego stanu, należy zastosować instrukcje z listingu 16.7. Zależnie od używanej wersji serwera Oracle niektóre z poniższych poleceń mogą wyświetlić status tylko wtedy, gdy jest to coś „interesującego”.
Listing 16.7. Uzyskanie nazw wszystkich plików danych, plików kontrolnych i dzienników SQL> select name, status from v$datafile NAME STATUS
504 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
----------------------------------------------------------------------/db/oracle/a/oradata/crash/system01.dbf SYSTEM /db/oracle/a/oradata/crash/rbs01.dbf ONLINE /db/oracle/a/oradata/crash/temp01.dbf ONLINE /db/oracle/a/oradata/crash/tools01.dbf ONLINE /db/oracle/a/oradata/crash/users01.dbf ONLINE /db/oracle/a/oradata/crash/test01.dbf ONLINE 6 rows selected. SQL> select member, status from v$logfile /oracle/product/10.2.0/oradata/orcl/redo03.log /oracle/product/10.2.0/oradata/orcl/redo02.log /oracle/product/10.2.0/oradata/orcl/redo01.log SQL> select name, status from v$controlfile /oracle/product/10.2.0/oradata/orcl/control01.ctl /oracle/product/10.2.0/oradata/orcl/control02.ctl /oracle/product/10.2.0/oradata/orcl/control03.ctl
Listing 16.7 pokazuje, że wszystkie pliki danych, pliki kontrolne i dzienniki są w dobrym stanie (w przypadku dzienników i plików kontrolnych brak statusu oznacza brak problemów). Gdy odtworzy się i przywróci wszelkie pliki danych przełączone w tryb offline, procedurę można uznać za ukończoną.
Krok 17. — czy została uszkodzona grupa dzienników online? Posługując się stwierdzeniem „uszkodzona grupa dzienników online”, mamy na myśli to, że są uszkodzeni wszyscy członkowie grupy dzienników. Jeśli co najmniej jeden członek multipleksowanej (powielanej) grupy dzienników pozostał nienaruszony, serwer Oracle otworzy bazę danych i po prostu w dzienniku alertów zapisze komunikat o błędzie. Jeżeli jednak zostali uszkodzeni wszyscy członkowie takiej grupy, baza nie będzie otwarta, a wygenerowany komunikat o błędzie będzie wyglądał podobnie do poniższego. ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/db/Oracle/b/oradata/crash/redocrash02.log' ORA-00312: online log 2 thread 1: '/db/Oracle/a/oradata/crash/redocrash03.log'
Jeśli nie pojawi się tego typu komunikat o błędzie, będzie to oznaczać, że nie ma uszkodzonej grupy dzienników. W związku z tym należy przejść do kroku 18.
Pierwszą rzeczą, którą trzeba zrobić, jest określenie statusu uszkodzonej grupy dzienników. Godne uwagi są trzy statusy: CURRENT, ACTIVE i INACTIVE. W celu identyfikacji statusu uszkodzonej grupy należy dla podłączonej i zamkniętej bazy danych zastosować następujące zapytanie: SQL> select group#, status from v$log;
Uzyskany wynik będzie podobny do poniższego. GROUP# STATUS ------- --------------1 INACTIVE 2 CURRENT 3 ACTIVE 3 rows selected.
Przywracan e bazy danych Oracle
| 505
W powyższym przykładzie widać, że grupa dzienników 1 jest nieaktywna (INACTIVE), grupa 2 — obecnie zapisywana (CURRENT), a 3 — aktywna (ACTIVE). Oto objaśnienie tych statusów, uwzględniające ich wpływ na proces przywracania: CURRENT
Grupa dzienników serwera Oracle o tym statusie zwykle jest właśnie zapisywana. W przypadku awarii będzie to grupa, dla której w momencie wystąpienia tego zdarzenia serwer Oracle wykonywał operację zapisu. Grupa będzie miała taki status do momentu udostępnienia serwera i przełączenia dzienników. ACTIVE
Aktywną grupą dzienników zazwyczaj jest ta, dla której serwer Oracle ukończył właśnie operację zapisu. Jednak do momentu wystąpienia punktu kontrolnego grupa taka jest w dalszym ciągu wymagana przez proces przywracania nośnika. Ponieważ przełączenie dzienników zawsze wymusza punkt kontrolny, status ACTIVE występuje bardzo rzadko. W rzeczywistości można go zobaczyć (przed wystąpieniem awarii systemu) tylko wtedy, gdy powyższe zapytanie wykona się w czasie trwania operacji tworzenia punktu kontrolnego (w przypadku poprawnie dostrojonej bazy danych trwa to bardzo krótko). INACTIVE
Nieaktywną grupą dzienników jest grupa, która w danej chwili nie jest używana przez serwer Oracle. Grupa taka została zarchiwizowana. Aby stwierdzić, jaką czynność wykonać jako następną, należy najpierw uzyskać numer grupy z uszkodzonymi dziennikami. W poprzednim przykładzie został wygenerowany wiersz komunikatu o błędzie open failed for members of log group 2. Numer zawarty w tym wierszu należy porównać z numerami grup dzienników zwróconych przez zapytanie select * from v$log. W powyższym przykładzie w chwili wystąpienia awarii bazy danych status CURRENT miała grupa dzienników 2. Jeśli uszkodzona grupa dzienników miała status CURRENT, należy przejść do kroku 20. Jeżeli był to status ACTIVE, należy wykonać krok 23. W przypadku statusu INACTIVE należy zastosować krok 25.
Krok 18. — czy są niedostępne jakiekolwiek segmenty wycofywania? Jak już wielokrotnie wspomniano, segmenty wycofywania reprezentują starszy mechanizm obsługi cofanych danych. Jeśli zaczęto korzystać z segmentów powrotu, krok ten można pominąć. Tego typu segmentów dotyczy krok 12.
Jeżeli segment wycofywania uszkodził się, serwer Oracle wygeneruje błąd przy próbie otwarcia bazy danych. Komunikat o błędzie będzie wyglądać podobnie do poniższego. ORA-01545: rollback segment 'USERS_RS' specified not available Cannot open database if all rollback segments are not available.
Jeśli komunikat ten pojawi się przy próbie otwarcia bazy danych, należy przejść do kroku 19. W przeciwnym razie należy powrócić do kroku 10.
506
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Krok 19. — przywracanie obszaru tabel przechowującego niedostępny segment wycofywania Krok ten należy wykonać tylko wtedy, gdy wcześniej wykonano krok 18.
W pierwszej kolejności trzeba stwierdzić, w jakim obszarze tabel znajduje się uszkodzony segment wycofywania. Niestety, nie istnieje stały widok z tego typu informacją. Oznacza to, że trzeba będzie ją uzyskać, kierując się zdrowym rozsądkiem i dedukcją. Właśnie z tego powodu bardzo pomocne jest umieszczanie segmentów wycofywania w dedykowanych obszarach tabel o nazwach łatwych do zidentyfikowania (na przykład SW1). Jeszcze bardziej przydatne będzie nadanie plikom danych nazw prostych do zapamiętania. Przykładowo można utworzyć specjalny obszar tabel o nazwie SW1, a jego plikom danych nadać nazwy: wycofywanie01.dbf, wycofywanie02.dbf itd. Dzięki temu każdy, kto będzie miał do czynienia z taką bazą danych, będzie dokładnie wiedział, które pliki danych zawierają dane segmentów wycofywania.
Przede wszystkim trzeba zapamiętać, że powyższy komunikat o błędzie nie zostanie wygenerowany, dopóki plik danych nie zostanie przełączony w tryb offline. W celu uzyskania kompletnej listy plików przełączonych w ten tryb należy dla podłączonej i zamkniętej bazy danych wykonać następujące polecenie: SQL> select TS#, name from v$datafile where status = 'OFFLINE'; NAME -----------------------------------------------------------------------5 /db/oracle/a/oradata/crash/test01.dbf 1 row selected.
Pora określić nazwę obszaru tabel zawierającego ten plik danych. SQL> select name from v$tablespace where TS# = '5'; NAME -----------------------------------------------------------------------TEST 1 row selected.
Trzeba przyznać, że poprzedni przykład był prosty. Użyto w nim tylko jednego pliku danych przełączonego w tryb offline. W efekcie odnalezienie obszaru tabel dla tego pliku było naprawdę łatwe. Co będzie, jeśli w wielu obszarach tabel znajduje się wiele plików danych? Jak stwierdzić, który z tych plików zawiera segment wycofywania? Niestety, nie można tego zrobić w żaden sposób, gdy baza danych jest zamknięta. Pozostała część niniejszego kroku jest prosta. Po odtworzeniu wszelkich plików danych znajdujących się w trybie offline należy wykonać polecenie recover datafile lub recover tablespace, aby w plikach uwzględnić wszystkie modyfikacje dokonane od momentu sporządzenia kopii zapasowej. Jeśli uszkodzony jest tylko jeden lub dwa pliki danych, prawdopodobnie szybsze będzie użycie instrukcji recover datafile. Jeżeli uszkodzonych zostało kilka plików, najprostsze będzie chyba zastosowanie polecenia recover tablespace (zwłaszcza w sytuacji, gdy wszystkie pliki danych należą do jednego obszaru tabel). Oba polecenia zadziałają.
Przywracan e bazy danych Oracle
|
507
Po odtworzeniu wszystkich plików danych z segmentami wycofywania należy powrócić do kroku 10. i ponownie podjąć próbę otwarcia bazy danych.
Krok 20. — czy uszkodzony jest bieżący dziennik online? Krok ten należy wykonać tylko wtedy, gdy wcześniej wykonano krok 17. W przeciwnym razie należy powrócić do kroku 17.
Jeżeli uszkodzona jest bieżąca grupa dzienników online, przy próbie otwarcia bazy danych pojawi się komunikat o błędzie podobny do następującego: ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/db/Oracle/b/oradata/crash/redocrash02.log' ORA-00312: online log 2 thread 1: '/db/Oracle/a/oradata/crash/redocrash03.log'
W poprzednim przykładzie zapytanie select group#, status from v$log poinformowało, że w chwili wystąpienia awarii grupa dzienników 2 miała status CURRENT. Jest to najgorszy rodzaj awarii, jaki może się przytrafić, ponieważ zdecydowanie dojdzie do utraty danych. Wynika to stąd, że bieżący dziennik online może być niezbędny do ponownego uruchomienia nawet w pełni sprawnej bazy danych. Jeśli bieżący dziennik zawiera informacje odtwarzania wymagane do uaktywnienia instancji, bez przeprowadzenia procesu pełnego odtwarzania i częściowego przywracania nie będzie możliwe otwarcie bazy danych. Najpierw należy spróbować otworzyć bazę za pomocą instrukcji alter database open resetlogs, która nakazuje serwerowi Oracle ponowne utworzenie dzienników powtórzeń trybu online. Jeśli się to uda, problem z głowy. Jeżeli przy użyciu opcji resetlogs nie udało się otworzyć bazy danych, jedynym możliwym rozwiązaniem jest odtworzenie starszej wersji pliku kontrolnego. Niestety, nie można odtworzyć samego pliku kontrolnego, ponieważ wtedy pliki kontrolne byłyby nowsze. W związku z tym pozostaje jedynie odtworzenie całej bazy danych. Jeśli bieżący dziennik powtórzeń jest uszkodzony, należy przejść do kroku 22. W przeciwnym razie należy wykonać krok 24.
Krok 21. — odtwarzanie z kopii zapasowej i przywracanie wszystkich plików danych Są tylko dwa powody, dla których należy wykonać ten krok. Pierwszym jest informacja, aby to zrobić zamieszczona w kroku 20. Drugim powodem jest sytuacja, gdy po wykonaniu kroku 25. lub 27. nie powiodła się próba otwarcia bazy danych. Niniejszy krok jest bardziej drastyczną metodą przywracania i nie powinien być stosowany, jeśli nie jest to absolutnie konieczne.
508 |
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Krok ten należy wykonać wyłącznie po zweryfikowaniu (bądź ponownym utworzeniu lub odtworzeniu) plików kontrolnych, a także sprawdzeniu, czy uszkodzeni są wszyscy członkowie bieżącej grupy dzienników online. Procedura ta jest dość prosta. Wystarczy określić nazwy i lokalizacje wszystkich plików danych, a następnie odtworzyć je z najnowszej kopii zapasowej. Odtworzyć należy tylko pliki danych, a nie pliki kontrolne. Jeśli w kroku 9. nie było odpowiedniej instrukcji, nie wolno odtwarzać lub nadpisywać plików kontrolnych!
Jeżeli korzysta się z narzędzia rman, całą procedurę wykona się za pomocą następujących dwóch poleceń: RMAN> restore database; RMAN> recover database;
Jeśli tworzy się kopie zapasowe zarządzane przez użytkownika, do odtworzenia wszystkich plików danych trzeba zastosować używany system archiwizujący. W celu określenia nazw plików danych należy dla podłączonej i zamkniętej bazy danych wykonać poniższą instrukcję. SQL> select name from v$datafile;
Po odtworzeniu wszystkich plików danych powinno się dla nich przeprowadzić proces przywracania nośnika. SQL> recover database;
Gdy zostaną odtworzone i przywrócone wszystkie pliki danych, należy przejść do kroku 22.
Krok 22. — wykonanie instrukcji alter database open resetlogs Krok ten należy wykonać tylko wtedy, gdy nakazała tak instrukcja zamieszczona w opisie kroku 21. Jest to następny drastyczny krok, który powinien być stosowany wyłącznie, gdy jest to konieczne!
Polecenie alter database open resetlogs nakazuje serwerowi Oracle otwarcie bazy danych po usunięciu całej zawartości plików dzienników powtórzeń online. Ponieważ nie można cofnąć tego kroku, dobrym pomysłem będzie sporządzenie kopii dzienników powtórzeń online. W celu identyfikacji nazw wszystkich tych plików należy dla podłączonej i zamkniętej bazy danych wykonać poniższą instrukcję. SQL> select member from v$logfile;
Aby móc dysponować opcją „cofania”, każdy plik dziennika należy skopiować jako plik .bak. Po utworzeniu kopii zapasowej plików dzienników powtórzeń online należy dla podłączonej i zamkniętej bazy danych zastosować następujące polecenie: SQL> alter database open resetlogs; Statement processed.
Jeśli udało się otworzyć bazę danych, gratuluję! Po sporządzeniu kopii zapasowej bazy danych procedurę można uznać za zakończoną!
Przywracan e bazy danych Oracle
| 509
Jeżeli korzysta się z wersji serwera Oracle starszej niż 10g, należy natychmiast sporządzić kopię bazy danych (preferowane jest jej uprzednie zamknięcie). Wynika to stąd, że przed pojawieniem się wersji 10g serwer Oracle nie był w stanie przy użyciu dzienników powtórzeń przywrócić bazy danych (otwartej za pomocą polecenia open resetlogs) do stanu z chwili wykonania jej kopii zapasowej. W przypadku wersji serwera Oracle starszych niż 10g po zastosowaniu polecenia open resetlogs trzeba dysponować pełną kopią zapasową bazy danych, aby można było przeprowadzić dla niej proces przywracania nośnika przy użyciu dzienników powtórzeń utworzonych po wywołaniu instrukcji open resetlogs. Kopię zapasową bazy danych warto jak najszybciej wykonać również wtedy, gdy korzysta się z serwera Oracle 10g. Wystarczająca będzie „gorąca” kopia zapasowa.
Krok 23. — czy uszkodzony jest aktywny dziennik powtórzeń trybu online? Krok ten należy wykonać tylko wtedy, gdy nakazała tak instrukcja zawarta w kroku 17. W przeciwnym razie należy od razu powrócić do kroku 17.
Jeśli została uszkodzona aktywna grupa dzienników trybu online, przy próbie otwarcia bazy danych pojawi się komunikat o błędzie podobny do poniższego. ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/db/Oracle/b/oradata/crash/redocrash02.log' ORA-00312: online log 2 thread 1: '/db/Oracle/a/oradata/crash/redocrash03.log'
W poprzednim przykładzie wynik zapytania select group#, status from v$log potwierdził, że w chwili wystąpienia awarii aktywna była grupa dzienników 2. Trzeba pamiętać, że aktywny dziennik jest wymagany przez proces przywracania. Zależnie od typu awarii bazy danych po jej wystąpieniu w buforach w dalszym ciągu mogą być dane. Jeżeli przy użyciu punktu kontrolnego da się te dane zapisać na dysku, ten aktywny dziennik można zamienić na nieaktywny i usunąć. W celu utworzenia punktu kontrolnego należy przejść do kroku 24. Jeśli nie został uszkodzony żaden aktywny dziennik powtórzeń trybu online, należy wykonać krok 25.
Krok 24. — punkt kontrolny Sposobem na poradzenie sobie z sytuacją przedstawioną w kroku 23. jest użycie punktu kontrolnego. Jeśli operacja się powiedzie, baza danych powinna zostać poprawnie otwarta. Aby zastosować punkt kontrolny, dla podłączonej i zamkniętej bazy danych należy wykonać poniższe polecenie. SQL> alter system checkpoint local; Statement processed.
Trzeba zachować cierpliwość. Jedna z grup dzienników jest aktywna najprawdopodobniej dlatego, że długo była wykonywana operacja tworzenia punktu kontrolnego i w czasie jej trwania baza danych uszkodziła się. Należy poczekać, aż serwer Oracle poinformuje, że punkt kontrolny
510
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
udało się uzyskać lub nie. Jeśli tak, serwer Oracle po prostu wyświetli komunikat Statement processed. W przeciwnym razie może pojawić się dowolna liczba komunikatów o błędzie. Jeśli nawet nie powiedzie się polecenie tworzące punkt kontrolny, należy przejść do kroku 10. i spróbować otworzyć bazę danych. Gdy próba się nie uda, należy powrócić do kroku 21. i przywrócić całą bazę danych.
Krok 25. — czy uszkodzony jest nieaktywny dziennik powtórzeń trybu online? Krok ten należy zastosować tylko wtedy, gdy nakazała tak instrukcja zamieszczona w kroku 17. W przeciwnym razie należy od razu powrócić do kroku 17.
Jeśli została uszkodzona nieaktywna grupa dzienników powtórzeń trybu online, przy próbie otwarcia bazy danych zostanie wyświetlony komunikat o błędzie podobny do następującego: ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/db/Oracle/b/oradata/crash/redocrash02.log' ORA-00312: online log 2 thread 1: '/db/Oracle/a/oradata/crash/redocrash03.log'
W poprzednim przykładzie rezultat zwrócony przez zapytanie select group#, status from v$log potwierdził, że w chwili wystąpienia awarii nieaktywna była grupa dzienników 2. Z kolei ten przypadek powinien być niewielkim problemem. Nieaktywny dziennik nie jest wymagany przez serwer Oracle. Jeśli grupa dzienników nie jest potrzebna, po prostu należy ją usunąć i w jej miejsce utworzyć nową. W celu usunięcia i dodania nieaktywnej grupy dzienników należy przejść do kroku 26.
Krok 26. — usuwanie i dodawanie uszkodzonej, nieaktywnej grupy dzienników Krok ten należy wykonać tylko wtedy, gdy nakazała tak instrukcja zawarta w kroku 25.
We wszystkich poprzednich przykładach uszkodzoną grupą dzienników była grupa 2. Zanim zostanie usunięta, należy się upewnić, czy można ją z łatwością ponownie utworzyć. Trzeba sprawdzić, czy nadal są aktualne wszystkie lokalizacje oryginalnego dziennika powtórzeń. W tym celu należy uzyskać nazwę każdego członka tej grupy dzienników. SQL> select member from v$logfile where GROUP# = 2;
W tym przypadku serwer Oracle zwrócił następujące wartości: /logs1/redolog01.dbf /logs2/redolog01.dbf /logs3/redolog01.dbf
Przywracan e bazy danych Oracle
|
511
Dalej należy stwierdzić, czy nadal są poprawne miejsca przechowywania wszystkich tych plików. Na potrzeby tego przykładu przyjmijmy, że katalog /logs3 został całkowicie uszkodzony i całą jego zawartość umieszczono w katalogu /logs4. W związku z tym członkami grupy dzienników 2 będą pliki: /logs1/redolog01.dbf, /logs2/redolog01.dbf i /logs4/redolog01.dbf. W celu usunięcia grupy dzienników 2 należy dla podłączonej i zamkniętej bazy danych wykonać następującą instrukcję: SQL> alter database drop logfile group 2;
Gdy polecenie to zakończy się powodzeniem, do bazy danych należy dodać jeszcze raz grupę dzienników 2. Umożliwia to poniższe polecenie (należy pamiętać, że plik /logs3/redolog01.dbf zastąpiono plikiem /logs4/redolog01.dbf). SQL> alter database add logfile group 2 ('/logs1/redolog01.dbf', '/logs2/redolog01.dbf', '/logs4/redolog01.dbf') size 500K; Statement processed.
Gdy polecenie to zakończy się powodzeniem, należy powrócić do kroku 10. i podjąć próbę otwarcia bazy danych.
Gotowe! Jeśli Czytelnik dotarł aż do tego miejsca, oznacza to, że wykonał procedurę! Powinny być dostępne wszystkie pliki danych, pliki kontrolne i pliki dzienników. Natychmiast należy sporządzić kopię zapasową całej bazy danych. Preferowana jest „zimna” kopia zapasowa tworzona po zamknięciu bazy. Jeśli nie jest to możliwe, należy wykonać „gorącą” kopię.
Logiczne kopie zapasowe Fizyczne kopie zapasowe chronią przed skutkami fizycznego uszkodzenia tak jak w przypadku awarii sprzętowej napędu dyskowego. Z kolei logiczna kopia zapasowa zabezpiecza przed logicznym uszkodzeniem, mającym miejsce na przykład wtedy, gdy administrator baz danych omyłkowo usunie ważną tabelę. Tego typu kopie są tworzone przez narzędzie Oracle Data Pump lub program eksportujący dane. Dane są przechowywane w pliku binarnym przydatnym tylko dla serwera Oracle. Oba narzędzia w rzeczywistości są używane wyłącznie w celu wymiany danych między bazami danych. Gdy zastosuje się je na potrzeby kopii zapasowych, pojawiają się następujące mankamenty: Brak możliwości przywracania transakcji Bardzo ważne jest zwrócenie uwagi na to, że wyeksportowane dane stanowią obraz bazy z określonej chwili i mogą posłużyć do przywrócenia tabeli maksymalnie do tego momentu. Nie da się zastosować dzienników transakcji (powtórzeń) dla zaimportowanej tabeli, żeby ją uaktualnić. A zatem, choć metodą importowania można szybciej odzyskać tabelę, po prostu lepsze może być odtworzenie całego obszaru tabel. Opcja recover until change może być użyta do powtórzenia wszystkich transakcji z wyjątkiem tej, która usunęła tabelę.
512
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
Dłuższy czas trwania operacji niż w przypadku fizycznych kopii zapasowych Operacje eksportowania zwykle zajmują więcej czasu niż w przypadku fizycznych kopii zapasowych, ponieważ muszą dokonać wielu sprawdzeń. Zależnie od wydajności komputera operacja może trwać tylko trochę lub znacznie dłużej! Pełne eksportowanie wymaga trybu restrict lub opcji consistent=y Trzeba zadbać o to, aby wyeksportowane dane były spójne. Jedna z metod, które to zapewniają, polega na zamknięciu bazy danych, a następnie jej otwarciu w trybie restrict. Tym sposobem nikt nie będzie mógł zmodyfikować bazy w czasie trwania operacji eksportowania (oczywiście oznacza to, że również nikt nie uzyska do bazy dostępu). Inną metodą jest zastosowanie podczas eksportowania opcji consistent=y. Spowoduje ona, że cała baza danych zostanie wyeksportowana w stanie, jaki miała w momencie rozpoczęcia operacji.
Tworzenie logicznej kopii zapasowej W tym punkcie omówiono eksportowanie całej bazy danych, określane też mianem pełnego eksportowania. Polecenia wykonujące tę operację można znaleźć na listingu 16.8. W miejsce łańcuchów: nazwa_użytkownika, hasło i nazwa_pliku należy wstawić odpowiednie informacje (aby można było wykonać operację eksportowania, trzeba użyć konta użytkownika i hasła dającego wymagane uprawnienia). Listing 16.8. Eksportowanie bazy danych $ exp userid=nazwa_użytkownika/hasło full=Y consistent=Y constraints=Y file=nazwa_pliku
Polecenie wykonuje pełne eksportowanie zawartości bazy danych ORACLE_SID do pliku nazwa_pliku. W celu uzyskania dodatkowych informacji na temat polecenia exp należy zajrzeć do dokumentacji.
Przywracanie przy użyciu logicznej kopii zapasowej Jeżeli sporządzono logiczne kopie zapasowe lub za pomocą narzędzia exp serwera Oracle wyeksportowano dane, można je zaimportować, korzystając z programu imp. Aby użyć tego polecenia, w miejsce łańcuchów: nazwa_użytkownika, hasło i nazwa_pliku trzeba wstawić odpowiednie informacje. Zamiast łańcucha poziom należy zastosować system lub restore (dalej wyjaśniono, kiedy używać poziomów). $ imp nazwa_użytkownika/hasło inctype=poziom full=Y file=nazwa_pliku
Powtórka W niniejszym rozdziale przedstawiono kilka typowych zagadnień. Oto one: Multipleksowanie (powielanie) dzienników powtórzeń Jeśli przepadnie każdy (lub jedyny) członek aktywnej lub bieżącej grupy dzienników, dojdzie do utraty danych. Jeżeli dzienniki powtórzeń nie są multipleksowane (powielane), ryzyko takiego scenariusza staje się znacznie większe niż wtedy, gdy operację taką się wykonuje. Gdy dzienniki multipleksuje się (powiela), ryzyko tego, że wszyscy członkowie grupy dzienników zostaną uszkodzeni, jest znikome. Przeprowadzając na początku drobną analizę, niewielkim nakładem pracy można znacznie zmniejszyć ryzyko utraty danych.
Powtórka
|
513
Monitorowanie dziennika alertów Jeśli nawet dzienniki powtórzeń są multipleksowane (powielane), w czasie działania bazy danych może się uszkodzić jeden lub więcej członków grupy dzienników. Jedynym powiadomieniem o tym fakcie będzie wpis umieszczony w dzienniku alertów. Należy zautomatyzować sprawdzanie tego dziennika pod kątem komunikatów o błędzie. Jeśli się tego nie zrobi, może być tak, że funkcjonalny będzie tylko jeden członek grupy dzienników i nawet nie będzie się o tym wiedziało. Multipleksowanie (powielanie) plików kontrolnych Znacząca część procedury przywracania została poświęcona radzeniu sobie po utracie wszystkich plików kontrolnych. Jeśli nie są one multipleksowane (powielane), należy to zmienić (jest to kolejna sytuacja, która powoduje, że przed rozpoczęciem właściwego planowania z obowiązku wykonywania trudnych procedur należy zwolnić jeszcze jedną osobę). Zastosowanie trybu archivelog Gdyby nie tryb archivelog, kroki 21. i 23. mogłyby zastąpić całą procedurę przywracania. Jeśli przepadnie jeden plik danych, należy odtworzyć wszystkie tego typu pliki i otworzyć bazę danych przy użyciu opcji resetlogs. Zostaną utracone wszystkie zmiany dokonane od momentu utworzenia ostatniej „zimnej” kopii zapasowej. Jest to jedyny możliwy typ kopii zapasowej, gdyż „gorące” kopie wymagają trybu archivelog. Witryna BackupCentral.com oferuje dla każdego rozdziału książki stronę umożliwiającą internautom zamieszczanie własnych uwag i opinii. Pod adresem http://www. ¦backupcentral.com można przeczytać aktualizowane informacje lub dodać do nich własne.
514
|
Rozdz ał 16. Arch w zowan e odtwarzan e bazy danych Oracle
ROZDZIAŁ 17.
Wykonywanie i odtwarzanie kopii serwera Sybase
System zarządzania bazami danych Sybase Adaptive Server Enterprise, znany jako ASE, oferuje zestaw narzędzi administratorskich o wspaniałych możliwościach, przy jednoczesnym zachowaniu odpowiedniego poziomu intuicyjności. Niestety, nie istnieje zintegrowany system zarządzania serwerem w połączeniu z wykonywaniem i odtwarzaniem kopii zapasowych oraz alarmowaniem. Tego typu system należy zbudować samodzielnie za pomocą powłoki lub skryptów, na przykład w Perlu. Na szczęście to zadanie nie należy do szczególnie skomplikowanych. System wykonywania kopii zapasowych może wykorzystywać mechanizm planowania zadań (ang. scheduler) wbudowany w system Sybase, bez przeszkód można też wykorzystać systemowe mechanizmy planowania zadań. W tym rozdziale opisuję sposób samodzielnego przygotowania systemu wykonywania i odtwarzania kopii zapasowych, wykorzystując do tego celu proste przykłady. Przy przygotowaniu tego rozdziału pomagał mi Ed Barlow. Ed od 15 lat udzielał się w społeczności Sybase i na swojej stronie http://www.edbarlow.com udostępnia wiele narzędzi przydatnych administratorom tego systemu.
Układ tematyczny tego rozdziału jest w przybliżeniu zgodny z układem pozostałych rozdziałów poświęconych bazom danych. Moim celem nie było zastąpienie dokumentacji Sybase, lecz omówienie w przystępny sposób zadań administratora związanych z utrzymaniem, wykonywaniem i odtwarzaniem kopii zapasowych. Funkcje stosowane rzadko lub przestarzałe nie są w ogóle wspomniane, aby więcej miejsca poświęcić omówieniu kluczowych zagadnień. Podobnie jak w innych rozdziałach na początku opisuję architekturę bazy danych, następnie definiuję podstawowe terminy. W dalszej części rozdziału opisuję podstawowe narzędzia, polecenia i procedury, po czym przechodzę do analizy podstawowych zadań związanych z utrzymaniem, wykonywaniem i odtwarzaniem kopii zapasowych, podpierając się przykładami skryptów wykonujących te zadania. Na końcu krok po kroku opisuję procedurę odtwarzania systemu po katastrofie. Dokumentacja serwera Sybase jest doskonała. Została podzielona na kilka „książek”, z których każda opisuje jedno konkretne zadanie. Koniecznie należy zapoznać się z trzema z nich: Adaptive Server Enterprise Reference Manual: Commands, która szczegółowo opisuje składnię poleceń
515
dialektu Sybase SQL, System Administration Guide, która jest doskonałym podręcznikiem administracji serwerem, oraz Troubleshooting and Error Messages Guide, opisującą krok po kroku działania, które należy podjąć w przypadku wystąpienia błędów. Te podręczniki można pobrać ze strony http://sybooks.sybase.com. Warto wypracować sobie taki odruch, aby w pierwszej kolejności zawsze zaglądać do tych podręczników, czy to w przypadku pojawienia się komunikatu o błędzie, czy w celu uzyskania informacji na temat zadania, którego się nie rozumie. Podręczniki online są doskonale zorganizowane i łatwo się w nich wyszukuje informacje. Szczególnie użyteczny jest podręcznik zawierający procedury rozwiązywania problemów (ang. troubleshooting), w którym można zapoznać się z opisem przyczyny pojawiania się danego błędu, jak również znaleźć szczegółową procedurę usunięcia błędu, krok po kroku. Na potrzeby tego rozdziału wykorzystuję uogólnione pojęcie skryptu administracyjnego, które odnosi się do wszelkich skryptów wykonujących zadania administratora bazy danych. Chodzi tu o wykonywanie kopii zapasowych bazy danych, przeprowadzanie audytów bazy danych, kontrolę spójności bazy danych, wykonywanie kopii zapasowych na poziomie obiektów czy generowanie statystyk dotyczących działania bazy danych. Opiszę też sposoby odtwarzania bazy z wykonanych wcześniej kopii.
Architektura baz Sybase Jak wspominałem w poprzednich rozdziałach dotyczących baz danych, bardzo ważne jest, aby zrozumieć architekturę bazy danych, której dane chce się zabezpieczać. Z tego powodu ten rozdział rozpocznę od omówienia stosownych szczegółów architektury Sybase. Informacje te są zbliżone do przedstawionych w rozdziale 15., ale zawierają zagadnienia specyficzne dla baz Sybase. Podobnie jak w rozdziale zawierającym przegląd zagadnień wykonywania i odtwarzania kopii zapasowych, na początek przeanalizujemy zagadnienia bazy Sybase z punktu widzenia zaawansowanego użytkownika, po czym będziemy kontynuować analizę z punktu widzenia administratora. Na końcu rozdziału omówię procedurę diagnostyki i odtwarzania bazy z kopii zapasowej.
Przegląd architektury Sybase Bazy danych Sybase działają w sposób zbliżony zarówno na platformie Windows, jak i Unix. Mamy tu do czynienia z wyraźnym podziałem na część kliencką i część serwerową bazy. Aplikacje wykorzystują biblioteki klienckie, za pomocą których łączą się z serwerem. Biblioteki klienckie są dystrybuowane w różnych formatach i najczęściej są po prostu konsolidowane z aplikacjami. Każdy system zawierający aplikację wykorzystującą bazę Sybase wymaga instalacji części klienckiej. Serwery natomiast z reguły mają zainstalowane wyłącznie oprogramowanie systemu bazy danych: Sybase ASE. Serwer Sybase cechuje się wysoką wydajnością działania i wykorzystuje zarówno technologie wieloprocesowego (zoptymalizowanego pod kątem większej liczby procesorów), jak i wielowątkowego wykonywania operacji. Ponadto system Sybase z reguły uruchamia dodatkowe procesy serwera, jak również serwery kopii zapasowych (jeden dla każdego systemu), serwery replikacji i serwery monitoringu. Architektura serwera Sybase jest bardzo zbliżona do architektury flagowego serwera baz danych firmy Microsoft, ponieważ w 1998 roku Microsoft nabył licencję na kod źródłowy bazy Sybase i na jego podstawie opracował system bazy danych pod nazwą MS SQL Server. Z tego 516
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
powodu architektura, struktura, jak i wewnętrzne polecenia w obydwu tych systemach są zbliżone. W Sybase do wykonywania kopii zapasowych oraz do zadań administracyjnych wykorzystuje się skrypty, ewentualnie z wykorzystaniem planera zadań ASE Job Scheduler. Siła rozwiązania Sybase polega na tym, że doskonale się skaluje zarówno w środowiskach Windows, jak i Unix, oraz na zasłużonej reputacji systemu o dużej wydajności.
Polecenia wiersza poleceń Sybase Istnieje kilka znanych poleceń uruchamianych z konsoli, które powinien znać każdy administrator. Te aplikacje są dostępne zarówno w katalogu OCS-VERSION, jak i ASE-VERSION. Nie ma większego znaczenia, jaka wersja tych aplikacji zostanie użyta, pod warunkiem że nie będzie bardzo przestarzała. Bardzo stare wersje tych narzędzi nie obsługują bowiem niektórych istotnych typów danych obsługiwanych przez nowsze wersje serwera.
isql Program isql służy do wywoływania poleceń SQL w serwerze bazy danych. Składnia wywołania jest następująca: isql –iużytkownik –Phasło –iserwer. Po uruchomieniu program isql wyświetla wiersz zachęty (znak >), po którym można wpisywać polecenia SQL do wykonania przez serwer. Sybase wykorzystuje dialekt języka SQL pod nazwą Transact-SQL (T-SQL). Polecenia są wysyłane do serwera przy każdym przejściu do nowego wiersza. Programu isql można używać do testowania połączeń z serwerem oraz do wykonywania podstawowych działań administratorskich. Interesujące są też opcje -iplik i -oplik, za pomocą których określa się odpowiednio plik wejściowy i wyjściowy polecenia. Często stosuje się również znaną z systemów Unix składnię wywołania z przekazaniem poleceń bezpośrednio na wejściu polecenia, na przykład: isql -Usa -SSERVERNAME -Ppassword << EOF exec sp_who go exit EOF
bcp Polecenie bcp służy do importowania i eksportowania pojedynczych tabel lub perspektyw (do lub z plików). To polecenie jest wykorzystywane przede wszystkim w celu masowego ładowania danych oraz do wydobywania danych z bazy. Polecenie bcp działa na poziomie systemu operacyjnego, podobnie jak isql. Składnia jego wywołania jest następująca: bcp [[nazwa_bazy.]właściciel.]nazwa_tabeli {in / out} nazwa_pliku [-c|-n] -S serwer -U użytkownik -P hasło -t{separator_pól} -i{separator_wierszy}
W pierwszym parametrze polecenia bcp należy podać nazwę kopiowanej tabeli lub perspektywy. Parametr in służy do kopiowania danych z pliku do tabeli, natomiast out — z tabeli do pliku. Polecenie bsp może działać w dwóch trybach: natywnym i znakowym. Tryb natywny (ustawiany za pomocą opcji -n) odczytuje i zapisuje pliki w wewnętrznym trybie systemu Sybase (to znaczy liczby całkowite są zapisane binarnie jako wartości liczb całkowitych, a liczby zmiennoprzecinkowe — jako binarna reprezentacja liczb zmiennoprzecinkowych). Tryb natywny jest nieczytelny dla człowieka, a pliki zapisane w tym trybie bywają wielokrotnie mniejszych Arch tektura baz Sybase
|
517
rozmiarów w porównaniu z plikami reprezentującymi dokładnie te same dane, zapisanymi w trybie znakowym (ASCII). W trybie znakowym pliki są zapisane w formacie tekstowym (czytelnym dla człowieka). W przypadku kopiowania danych w trybie znakowym należy określić separator pól (parametr -t). Do tego celu najlepiej nadają się znaki rzadko występujące w wartości pól, jak ~ (tylda) czy & (znak and). Jednak w przypadku zapisywania w bazie danych w formacie XML, w charakterze separatorów należy zastosować inne znaki. Sybase pozwala zastosować separatory wieloznakowe, jak \t (znak tabulacji) w charakterze separatora pól i \r\n (sekwencja powrotu karetki i przejścia do nowego wiersza) w charakterze separatora wierszy. W przypadku zastosowania znaku przecinka jako separatora pól powstanie plik csv, ale jeśli dane tekstowe w tabeli zawierają znaki przecinka, plik ten będzie uszkodzony. Pliki skopiowane w trybie znakowym mogą być używane w różnych systemach operacyjnych, natomiast pliki zapisane w trybie natywnym mogą być wykorzystane wyłącznie w systemach operacyjnych wykorzystujących kompatybilne binarne formaty danych.
dsedit Program dsedit jest graficznym edytorem pliku interfaces bazy Sybase. Plik interfaces odwzorowuje nazwy serwerów na nazwy hostów, numer portu i protokół sieciowy. Definicja protokołu sieciowego może również zawierać informacje określające zachowanie w przypadku błędu (ang. fail over) i może zawierać odwzorowanie dla serwera nasłuchującego na większej liczbie interfejsów sieciowych lub portów. Plik interfaces można edytować bezpośrednio, lecz administratorzy wykorzystują program dsedit, ponieważ w niektórych systemach operacyjnych składnia pliku dsedit może wykorzystywać notację skróconą, mało czytelną dla człowieka. W systemach Windows plik interfaces znajduje się w ścieżce $SYBASE/ini/sql.ini.
Przykładowo ciąg znaków tli w pliku interfaces w systemie Solaris definiuje ciąg znaków reprezentujący liczbę szesnastkową określającą adres IP i numer portu. Weźmy na przykład następującą definicję: SYBSRVR master tli tcp /dev/tcp \x000204018196c4510000000000000000
Możemy ją zinterpretować w następujący sposób: x0002 0401 81 96 c4 51
nagłówek numer portu (1025) pierwszy fragment adresu IP (129) drugi fragment adresu IP (150) trzeci fragment adresu IP (196) czwarty fragment adresu IP (81)
Ta definicja adresu w formacie tli w systemie innym niż Solaris będzie wyglądać tak (dla hosta sybhost o adresie 129.150.196.81): SYBSRVR master tcp ether sybhost 1025
518
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Wymagane zmienne środowiska Poniższa lista opisuje zmienne środowiska typowo wykorzystywane przez Sybase: SYBASE
Wartość tej zmiennej powinna zawierać ścieżkę do instalacji systemu Sybase. Ścieżka nie powinna uwzględniać wersji ASE, do tego celu służy zmienna SYBASE_ASE. DSQUERY
Wartość tej zmiennej należy ustawić na adres domyślnego serwera, z którym będzie nawiązywane połączenie. SYBASE_ASE
W tej zmiennej należy określić nazwę podkatalogu, w którym jest zapisana wykorzystywana wersja Sybase. Na przykład w przypadku wersji 15.0 wartość zmiennej SYBASE_ASE należy ustawić na ASE-15_0, w przypadku wersji 12.5 — na ASE-12_5. Oprogramowanie serwera znajduje się zatem w ścieżce zdefiniowanej jako $SYBASE/$SYBASE_ASE. PATH
Do zmiennej systemowej PATH należy dopisać ścieżkę do odpowiednich plików wykonywalnych systemu Sybase. LD_LIBRARY_PATH
Ta zmienna systemowa wskazuje ścieżkę do bibliotek wykorzystywanych przy kompilacji programów.
SYBASE_OCS
W przypadku gdy oprogramowanie klienckie jest w wersji 15.0, wartość tej zmiennej należy ustawić na OCS-15_0, a w przypadku wersji 12.5 — na OCS-12_5. Oprogramowanie klienckie znajduje się zatem w ścieżce $SYBASE/$SYBASE_OCS.
Nie ma konieczności samodzielnego definiowania tych zmiennych po zalogowaniu się do systemu, ponieważ Sybase przy instalacji generuje odpowiednie skrypty definiujące te zmienne. Są to pliki SYBASE.sh i SYBASE.csh, znajdujące się w katalogu $SYBASE. Przed wykonaniem operacji wykorzystujących bazę Sybase należy po prostu załadować odpowiedni z tych plików (w zależności od wykorzystywanej powłoki). Programy klienckie muszą znać wartość zmiennej $SYBASE, która pozwala im odnaleźć plik interfaces; programy wykorzystujące biblioteki współdzielone muszą dodatkowo mieć dostęp do odpowiednio zdefiniowanej zmiennej $LD_LIBRARY_PATH.
Perspektywa zaawansowanego użytkownika Zaawansowani użytkownicy baz danych do pracy mogą potrzebować wiedzy omówionej w tym podrozdziale. Prawdopodobnie wymagana od nich wiedza nie będzie wybiegać poza jego zakres.
Serwer Określenie serwer stosowane w kontekście Sybase odnosi się najczęściej do serwera bazy danych, noszącego nazwę Sybase Adaptive Server Enterprise, w skrócie Sybase ASE. Każda instalacja Sybase zawiera ponadto Sybase Backup Server, może też zawierać inne produkty serwerowe Perspektywa zaawansowanego użytkown ka
|
519
z rodziny Sybase, jak Sybase Monitor Server czy Sybase Replication Server. Wszystkie te serwery wykorzystują ten sam protokół komunikacyjny i są skonstruowane z wykorzystaniem tych samych bibliotek (API tych bibliotek jest opublikowane, można zatem na jego podstawie stworzyć własne rozszerzenia i serwery). Sybase ASE Database Server wykorzystuje mechanizm przetwarzania symetrycznego (symmetric multiprocessing). Innymi słowy, może tworzyć większą liczbę procesów komunikujących się wzajemnie z użyciem pamięci współdzielonej i żaden z procesów nie otrzymuje priorytetu nad pozostałymi. Gdy uruchamiany jest serwer baz danych, uruchamiany jest jeden lub większa liczba procesów serwera danych. Liczba uruchamianych procesów jest uzależniona od opcji konfiguracyjnej max online engines. Standardowa konfiguracja zawiera również jeden proces backupserver, odpowiedzialny za operacje wejściawyjścia procedury zapisywania i odtwarzania kopii zapasowych. Proces backupserver jest procesem systemowym przeznaczonym do wykonywania szybkich procedur wykonywania i odtwarzania kopii zapasowych. Na jednym komputerze można uruchamiać taką liczbę serwerów, na jaką pozwolą zasoby. Każdy proces serwera danych wykorzystuje duży, wstępnie zaalokowany blok pamięci, ale pozostałe serwery nie wymagają dużej ilości zasobów. Ze względów wydajności i dostępności zdarzają się konfiguracje wykorzystujące kilka serwerów Sybase ASE uruchamianych na tej samej maszynie fizycznej, ale najczęściej na każdej maszynie uruchamiany jest pojedynczy serwer Sybase ASE. Zasada jest tu prosta: w przypadku dwóch osobnych serwerów łatwiej jest izolować aplikacje i chronić dane użytkowników przed błędnie działającymi aplikacjami i zapytaniami. Z drugiej jednak strony pojedynczy, czteroprocesorowy serwer ASE wyposażony w 16 GB pamięci RAM z pewnością będzie wydajniejszy od dwóch dwuprocesorowych serwerów ASE wyposażonych w 8 GB RAM każdy.
Silnik Gdy uruchamiany jest serwer ASE, uruchamianych jest kilka egzemplarzy serwera danych. Każdy z tych działających egzemplarzy określa się jako silnik (ang. engine). Jeśli mamy do czynienia z systemem wieloprocesorowym wyposażonym w N procesorów, często uruchamianych jest N lub N – 1 silników. Liczba silników jest określana zmienną konfiguracyjną max online engines.
Baza danych Schematem bazy danych (ang. schema) określa się zgrupowaną kolekcję tabel, indeksów, procedur składowanych i innych obiektów baz danych. Baza danych to kolekcja schematów (co najmniej jednego). Nowy serwer bazy danych od swojego pierwszego uruchomienia ma zdefiniowanych kilka systemowych baz danych. Administrator systemu tworzy jedną lub większą liczbę aplikacyjnych baz danych, w których są przechowywane dane i schematy aplikacji biznesowych. Mechanizm wykonywania i odtwarzania kopii zapasowych baz Sybase działa niezależnie dla każdej bazy danych, dlatego systemy należy zaprojektować w taki sposób, aby wszystkie powiązane wzajemnie obiekty baz danych znajdowały się w tej samej bazie danych. Innymi słowy, baza danych z reguły reprezentuje dane aplikacji, choć każda aplikacja może korzystać z większej liczby baz danych, podzielonych w sposób logiczny na grupy obiektów. Po zalogowaniu się do serwera użytkownik automatycznie łączy się z domyślną bazą danych (tę domyślną bazę można konfigurować indywidualnie dla każdego konta). Każdemu z kont można nadawać lub odbierać uprawnienia dostępu do każdego obiektu w bazie. Do obiektów 520
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Sybase można odwoływać się z zastosowaniem notacji nazwa_bazy.właściciel.nazwa_obiektu. Z reguły właściciel każdego obiektu jest jednocześnie właścicielem bazy; w takim wypadku można ominąć element właściciel. Skrócona forma odwołania do obiektu w bieżącej bazie danych to właściciel.nazwa_obiektu lub (w przypadku gdy właściciel bieżącej bazy danych jest również właścicielem obiektu) po prostu nazwa_obiektu. Wszystkie instalacje zawierają następujące systemowe bazy danych: master Baza danych master zawiera informacje konfiguracyjne systemu, jak nazwy kont użytkowników czy mapowania plików dyskowych. model Szablon baz danych; wszystkie nowo tworzone bazy danych są kopiowane z tego modelu. tempdb Baza danych wykorzystywana do zapisywania tymczasowych danych na potrzeby operacji sortowania, składowania tabel tymczasowych i wykonywania złączeń. sybsystemprocs Ta baza danych zawiera systemowe procedury składowane. sybsystemdb Ta baza jest wykorzystywana w ASE 15 do przechowywania transakcji w trakcie wykonywania i jest wykorzystywana do odtwarzania danych z kopii zapasowej. Serwery zawierają dodatkowo jedną lub większą liczbę baz danych zawierających dane aplikacji, które mogą mieć dowolne nazwy. Stosowana jest konwencja używania małych liter w nazwach baz danych; dla większej czytelności stosuje się znak podkreślnika. Często też stosuje się ciąg znaków db na końcu nazwy, na przykład riskdb, logininfo_db czy tracedb.
Transakcje Sybase obsługuje standardowy mechanizm transakcji języka SQL, co gwarantuje, że wywołana sekwencja poleceń SQL pozostawi bazę w spójnym stanie, ponieważ w życie wejdą wszystkie zmiany wprowadzane w transakcji lub, w przypadku problemu, wszystkie zmiany zostaną anulowane. Każda operacja INSERT, UPDATE i DELETE również jest traktowana jako transakcja. Typowym przykładem transakcji jest przeniesienie kwoty 100 zł z jednego konta na inne. Najpierw o 100 zł musi zostać pomniejszone saldo jednego konta, następnie o tę kwotę należy powiększyć saldo drugiego. Jeśli w trakcie tej transakcji nastąpi awaria serwera baz danych, powinny zostać odwołane obie te operacje, w przeciwnym razie może dojść do utraty pieniędzy.
Tabela Tabela to kolekcja wierszy danych o tym samym zbiorze atrybutów. Tabele w Sybase mogą być partycjonowane, to znaczy rozbijane na niezależne łańcuchy stron danych. W takim przypadku istnieje możliwość przyspieszania operacji, na przykład wstawiania danych do tabeli.
Perspektywa zaawansowanego użytkown ka
|
521
Powszechnie stosowana jest konwencja używania małych liter lub kombinacji małych i wielkich liter w nazwach tabel; dla zwiększenia czytelności stosuje się znak podkreślnika. Rzeczowniki stosuje się w liczbie pojedynczej, to znaczy w przypadku tabeli zamówień stosuje się nazwę order zamiast orders.
Tabele systemowe Tabela systemowa zawiera informacje systemowe, jak loginy użytkowników i informacje o lokalizacji obiektów na dyskach czy o aktywności systemu. W systemach Sybase ASE Architecture wszelkie informacje konfiguracyjne są zapisane w tych tabelach i można z nich korzystać na takich samych zasadach jak w przypadku innych tabel. Do odczytu i modyfikacji tych danych w systemach Sybase wykorzystuje się przeznaczone do tego celu procedury składowane. Informacje konfiguracyjne systemu są zapisane w bazie danych master. Informacje konfiguracyjne baz danych są zapisane w tabelach systemowych w każdej z baz danych. Tabele systemowe noszą nazwy rozpoczynające się przedrostkiem sys. W domyślnej konfiguracji na tabelach systemowych nie można wykonywać modyfikacji z użyciem języka manipulowania danymi (Data Manipulation Language, DML), czyli SQL-a i jego operacji: INSERT, UPDATE i DELETE. Sytuację tę można jednak zmienić, modyfikując odpowiedni parametr konfiguracyjny. W tym celu należy posłużyć się systemową procedurą składowaną sp_configure. Należy jednak pamiętać, że tego typu ręcznych modyfikacji powinny dokonywać jedynie osoby doskonale orientujące się w konsekwencjach takiego działania. Tabele systemowe Sybase noszą nazwy rozpoczynające się przedrostkiem sys, na przykład syslogins, sysdatabases czy sysdevices.
Indeksy Indeksy w bazach danych mają funkcję zbliżoną do funkcji indeksów w książkach: chodzi o umożliwienie szybkiego wyszukiwania informacji w bazie. Sybase obsługuje dwa typy indeksów: klastrowe i nieklastrowe. Indeks klastrowy (ang. clustered index) reprezentuje fizyczną kolejność danych w stronach danych (wyjątek stanowią tu tabele stron typu data-only locked, w skrócie DOL), indeksy nieklastrowe (ang. nonclustered index) reprezentują sposób logicznego uporządkowania, co przyspiesza przeszukiwanie danych w tabeli, ale nie ma związku z ich fizycznym uporządkowaniem na nośniku.
Procedury składowane Procedura składowana to wstępnie skompilowany zestaw poleceń SQL. Procedury składowane pozwalają na znaczne przyspieszenie wykonywania zadań administratorskich, zapytań i innych zadań.
522
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Punkt widzenia administratora baz danych W niniejszym punkcie omawiam terminy dotyczące baz danych, które mają szczególne znaczenie z punktu widzenia ich administratora.
Strona Strona to najmniejszy fragment danych, jaki może być zmodyfikowany w bazie danych. Rozmiar strony w Sybase jest definiowany na etapie instalacji serwera i nie można go zmodyfikować. Większość instalacji Sybase wykorzystuje stronę o rozmiarze 2 kB, ale spotyka się większe rozmiary strony, co należy dostosować do zastosowań. Strona może zawierać jeden lub większą liczbę wierszy.
Ekstent Określenie ekstent dotyczy kolekcji ośmiu stron traktowanych przez Sybase jako jednostka operacji wejścia-wyjścia. Odczyty odbywają się właśnie całymi ekstentami; gdy tabela lub indeks potrzebuje więcej miejsca, baza alokuje dodatkowe miejsce właśnie o rozmiarze jednego ekstentu.
Pliki danych i urządzenia Sybase przechowuje dane w plikach danych (ang. datafile), które mogą występować w postaci surowej partycji (ang. raw partition) lub plików na sformatowanej partycji (z istniejącym systemem plików). Pliki danych są mapowane w systemie Sybase w postaci wirtualnych urządzeń (ang. device). Po utworzeniu system traktuje surowe partycje i pliki w systemach plików w taki sam sposób. Przed wersją 12.5 Sybase nie gwarantował spójności danych zapisanych w plikach z powodu buforowania stosowanego w systemie plików. Wersja 12.5 wykorzystuje mechanizm urządzeń dsync, które są zwykłymi plikami, ale z gwarantowaną spójnością zapisu. Opcja dsync jest ustawiana w momencie mapowania urządzenia z pliku. W systemach Unix stosuje się jeszcze jeden typ plików danych w postaci pliku w systemie plików tmpfs, który jest tworzony w pamięci RAM komputera. Operacje wejścia-wyjścia w przypadku urządzeń wykorzystujących pliki są z reguły szybsze od ich odpowiedników przy zastosowaniu surowych partycji. Różnica wydajności jest jednak ściśle zależna od mechanizmu zastosowanego w systemie plików. W systemie plików występuje co prawda pewien narzut związany z jego obsługą, ale operacje wejścia-wyjścia są najczęściej wykonywane w trybie asynchronicznym. Dlatego można w uproszczeniu przyjąć, że operacje wejścia-wyjścia przy zastosowaniu urządzeń plikowych są szybsze niż w przypadku zastosowania surowych partycji, ale z powodu większego prawdopodobieństwa awarii (i uszkodzenia danych) w przeszłości firma Sybase zalecała stosowanie właśnie surowych partycji, a stosowanie plików jedynie wówczas, gdy zapewni się mechanizm pełnego odtworzenia danych. Po wprowadzeniu mechanizmu dsync ryzyko awarii i utraty danych znacznie się zmniejszyło, ale asynchroniczna natura zapisu do plików może oznaczać, że wydajność tej operacji jest niższa niż w przypadku surowych partycji. Aby zatem ocenić całkowitą wydajność operacji wejściawyjścia, należy przeprowadzić testy na danej platformie i porównać wyniki dla urządzeń plikowych i surowych partycji.
Punkt w dzen a adm n stratora baz danych
|
523
Sybase bezpośrednio kontroluje wszystkie operacje wejścia i wyjścia do i z urządzenia surowego lub pliku z zastosowaniem mechanizmu dsync; unika się pozostawienia systemowi operacyjnemu kontroli nad tymi operacjami. Większość systemów operacyjnych ma zaimplementowany mechanizm przyspieszający wydajność operacji wejścia-wyjścia z użyciem bufora dyskowego, którego zawartość jest zrzucana na fizyczny nośnik w trybie asynchronicznym. Problem z taką konfiguracją polega na tym, że Sybase przyjmuje założenie, iż dane znajdują się fizycznie na dysku twardym w momencie zakończenia operacji wejścia-wyjścia. Jeśli w tym momencie nastąpi awaria, a dane będą nadal zapisane jedynie w buforze dysku, nie zaś na fizycznym nośniku, baza danych znajdzie się w niespójnym stanie. Jak już wspomniałem, operacje wejścia-wyjścia przy zastosowaniu plików są generalnie wydajniejsze od operacji na surowych partycjach. Do zapisu tymczasowych danych wykorzystywana jest baza tempdb: zapisuje się tu tabele tymczasowe i wyniki pośrednich operacji sortowania. Baza tempdb nie zapisuje danych na stałe, a w rzeczywistości przy każdym uruchomieniu serwera jest zakładana od zera. Z tego powodu można przyspieszyć operacje wykorzystujące bazę tempdb, tworząc ją w postaci pliku na dysku. W domyślnej konfiguracji tempdb ma rozmiar jedynie 2 MB i w trakcie działania jej rozmiar jest zwiększany. Dzięki temu, że ta baza jest za każdym razem tworzona od początku, nie ma obawy, że zapisane w niej dane zostaną utracone, więc umieszczenie jej w pliku na dysku jest w pełni bezpieczną praktyką przyspieszającą wydajność. Jeśli wykorzystywany system operacyjny obsługuje mechanizm tempfs (system plików w pamięci RAM), jednym z mechanizmów przyspieszających działanie może być umieszczenie tempdb w systemie plików tempfs. Dzięki temu tabele tymczasowe będą zapisywane w pamięci, nie na dysku, co znacząco przyspieszy wydajność operacji na nich.
Segment Segment to nazwana kolekcja urządzeń bazy danych dostępnych dla danej bazy. To odpowiednik przestrzeni tabel (ang. tablespace) w bazach Oracle i może być wykorzystany do wymuszenia zapisu określonych obiektów na wskazanych urządzeniach. Przy tworzeniu bazy danych automatycznie tworzone są trzy segmenty: system, default i logsegment. Segment default zawiera dane i indeksy użytkownika, logsegment zawiera dziennik transakcyjny, a system zawiera tabele systemowe. Oprócz tych segmentów można tworzyć dodatkowe, wykorzystując do tego procedurę składowaną sp_addsegment. Baza danych może zawierać wiele segmentów, które z kolei mogą zawierać wiele obiektów, takich jak tabele, indeksy i procedury składowane. Prosty sposób użycia segmentów do przyspieszenia operacji wejścia-wyjścia polega na umieszczeniu segmentu default (zawierającego dane) na jednym fizycznym dysku twardym, a logsegment na drugim dysku oraz stworzeniu dodatkowego segmentu zawierającego indeksy i zapisaniu go na trzecim dysku. Typowa operacja INSERT, UPDATE lub DELETE powoduje zapis na wszystkich tych trzech dyskach, dlatego separacja poszczególnych operacji zapisu pozwala je przyspieszyć. Zaleca się umieszczanie produkcyjnych baz danych na dyskach RAID z mechanizmem stripping. To znacznie zwiększa przepustowość systemu, a sam RAID jest niezbędny do zabezpieczenia systemu przed awariami dysków. Opisana wyżej technika rozpraszania segmentów na osobnych dyskach jest stosowana wówczas, gdy system nie obsługuje mechanizmu RAID stripping.
524 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Plik konfiguracyjny Baza danych master ma niewielkie rozmiary i służy do zapisu informacji konfiguracyjnych, takich jak układ dysków, informacje o użytkownikach i opcje konfiguracyjne bazy danych, na przykład ilość pamięci alokowanej przy starcie systemu. Opcje konfiguracyjne definiuje się za pomocą procedury składowanej sp_configure. Opcje konfiguracyjne są automatycznie zapisywane w pliku konfiguracyjnym, znajdującym się w katalogu $SYBASE/$SYBASE_ASE/.cfg. Przy każdym zapisie pliku konfiguracyjnego jego poprzednia wersja jest archiwizowana. Dzięki temu administratorzy mogą analizować parametry systemu i uzyskują dodatkowy poziom kopii zapasowej (to znaczy istnieje możliwość odczytania poprzednich wartości zmiennych i ich modyfikacji na poziomie systemu operacyjnego).
Dziennik transakcyjny Dziennik transakcyjny to specjalna tabela systemowa (syslogs) zapisana w segmencie logsegment każdej bazy danych. Ta tabela zawiera wszelkie zmiany w stronach bazy danych. Zapisywanie dziennika transakcji jest funkcją, której nie można wyłączyć w bazach Sybase. Dziennik transakcyjny jest mechanizmem służącym do zagwarantowania spójności transakcji, spójności baz i możliwości odtwarzania systemu po awariach. Domyślnie dzienniki transakcyjne zawierają wszystkie informacje od momentu uruchomienia serwera niezbędne do odtworzenia bazy danych. W tym dzienniku zapisywane są obrazy bloków przed i po modyfikacji. Oczywiście w przypadku dużej liczby modyfikacji rozmiary tych dzienników mogą być pokaźne, a po jakimś czasie większość tych danych nie jest potrzebna, dlatego administratorzy powinni przyjąć strategię czyszczenia dzienników transakcyjnych, których zawartość została już zapisana we właściwej bazie. Pierwsza z tych strategii polega na zastosowaniu mechanizmu automatycznego przycinania dzienników, druga — na archiwizowaniu dzienników transakcyjnych w plikach na dysku. Systemy deweloperskie i systemy, w których nie są potrzebne kopie zapasowe zmian danych w trakcie dnia, mogą wykorzystywać opcję automatycznego przycinania dzienników transakcyjnych. Tę funkcję definiuje się za pomocą opcji truncate log on checkpoint, a polega ona na usuwaniu co kilka minut zbędnych rekordów z dziennika transakcyjnego. Aby ustawić tę opcję dla bazy my_db, należy wykonać następujące polecenie: $ isql -Usa -Ppassword -SMYSERVER «E0F sp_dboption 'mydb,' 'truncate log on checkpoint,' true go use mydb go checkpoint go exit EOF
Taka prosta strategia sprawdza się dla systemów deweloperskich i w sytuacjach, gdy wystarcza odtworzenie kopii zapasowej z poprzedniego dnia. Jednak dziennik transakcyjny jest czyszczony, co powoduje, że mogą zostać utracone zmiany wprowadzone w systemie od ostatniej pełnej kopii zapasowej.
Punkt w dzen a adm n stratora baz danych
|
525
Z tego powodu przycinanie dzienników transakcyjnych nie jest akceptowalną praktyką w większości systemów produkcyjnych. W systemach, w których znaczenie ma możliwość odtworzenia danych nie tylko w stanie z poprzedniego dnia, ale też z jednego z kilku ostatnich dni, dzienniki transakcyjne zapisuje się na dysku przed przycięciem. Te kopie plików dzienników transakcyjnych mogą być wykorzystane do odtworzenia danych w przypadku awarii uszkadzającej dane. W przypadku zwykłej awarii baza po ponownym uruchomieniu odtwarza wszystkie zatwierdzone transakcje. Dziennik transakcyjny (nawet przycięty) gwarantuje, że wszystkie zbuforowane w nim zapisy zostaną przeniesione do właściwego zasobu składowania. Przy ponownym uruchomieniu serwer sprawdza dziennik transakcyjny w poszukiwaniu zatwierdzonych i niezatwierdzonych transakcji, które nie zostały przeniesione do zasobu składowania bazy. Następnie kolejno przenosi do bazy transakcje zatwierdzone i wycofuje niezatwierdzone. Dzięki temu baza danych jest w stanie przywrócić dane do spójnego stanu. W systemach produkcyjnych należy wziąć pod uwagę sytuację, gdy awaria serwera spowoduje, że baza danych nie będzie w stanie przywrócić spójnego stanu danych. W takim przypadku (dość rzadkim) jest konieczne przywrócenie danych z kopii zapasowej. W systemach deweloperskich z reguły wystarczy odtworzenie danych z nocnej kopii zapasowej; utrata danych z jednego dnia nie stanowi zwykle problemu w takich systemach. Jednak w systemach produkcyjnych z reguły taka sytuacja jest nie do przyjęcia. Strategia przywracania dla systemu Sybase polega na odtworzeniu pełnej kopii zapasowej i uzupełnieniu tych danych przy wykorzystaniu dzienników transakcyjnych, których zawartość jest kolejno odtwarzana na danych z kopii. Ta metoda pozwala przywrócić dane do stanu odbiegającego maksymalnie o kilkanaście minut od momentu wystąpienia awarii. Jeśli na przykład dzienniki transakcyjne są archiwizowane co 15 minut, maksymalny okres, z którego dane zostaną utracone, wynosi 15 minut. W systemach produkcyjnych dzienniki transakcyjne są archiwizowane typowo w odstępach od 5 do 15 minut (w zależności od przyjętego ryzyka biznesowego). Kopie zapasowe dzienników transakcyjnych zawierają jedynie zmiany w bazie danych, dzięki czemu ich przywracanie z reguły odbywa się bardzo szybko (pojedyncze sekundy). Oczywiście przy wykonywaniu kopii zapasowych dzienników transakcyjnych należy zachować ostrożność. Z oczywistych powodów nie zaleca się wykonywać kopii dzienników transakcyjnych na tym samym dysku, na którym zapisany jest właściwy dziennik transakcyjny. Dyski twarde należą do tych elementów komputera, które psują się najczęściej, dlatego nie warto ryzykować utraty danych, umieszczając ich kopię na tym samym dysku. Z podobnych powodów warto dane i dzienniki transakcyjne umieszczać na osobnych dyskach twardych. Głównym powodem jest tu co prawda wydajność, ale również w przypadku awarii jednego z tych dysków odtwarzanie danych jest znacznie prostsze.
Co się stanie, gdy dziennik transakcyjny zapełni się? Jeśli wykonywana jest transakcja dokonująca znacznych modyfikacji w bazie lub w tym samym czasie wykonywana jest duża liczba transakcji, przestrzeń dyskowa przeznaczona na dziennik transakcyjny może się zapełnić. Gdy tak się stanie, wszystkie procesy związane z bazą danych są zatrzymywane. Aktywne transakcje są wstrzymywane lub anulowane na podstawie opcji konfiguracyjnych bazy danych. Dodatkowo do użytkowników wysyłany jest komunikat ostrzegawczy z informacją o wyczerpaniu miejsca na dysku w segmencie default lub logsegment. Należy przeanalizować ten komunikat, aby upewnić się, którego segmentu dotyczy problem. Jeśli chodzi o segment default, oznacza to, że wyczerpało się miejsce w głównej bazie danych i należy usunąć zbędne pliki lub dodać miejsce. Jeśli zabrakło miejsca w segmencie logsegment, oznacza to, że zapełnił się dziennik transakcyjny. 526
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Zachowanie serwera baz danych w takiej sytuacji jest uzależnione od opcji konfiguracyjnych truncate log on checkpoint i abort transaction on log full. Opcja truncate log on checkpoint powoduje, że dziennik transakcyjny jest oczyszczany co kilka minut, ale to oczyszczenie następuje tylko do miejsca, w którym baza napotka pierwszą aktywną transakcję. Może się jednak okazać, że pojedyncza duża transakcja lub większa liczba mniejszych, ale rozciągniętych w czasie transakcji spowoduje zapełnienie dziennika transakcyjnego. Gdy tak się stanie i opcja abort transaction on log full jest ustawiona na wartość true, niezakończone transakcje, które zapełniły dziennik transakcyjny, są wycofywane. Użytkownicy z pewnością nie będą zachwyceni, ale system wróci do stanu używalności. W takim przypadku warto wziąć pod uwagę zwiększenie miejsca na dysku na dziennik transakcyjny, pod warunkiem że transakcje, które spowodowały problem, są prawidłowe. Jeśli opcja abort transaction on log full ma ustawioną wartość false, działająca transakcja jest wstrzymywana w stanie LOG SUSPEND aż do momentu, gdy zostanie zwolnione nieco miejsca, co pozwoli na kontynuację jej działania. Stan transakcji można sprawdzić za pomocą procedury składowanej sp_who, która pokazuje zablokowane procesy. Ta sytuacja jest poważna: procesy użytkowników zostają wstrzymane, co gorsza, użytkownik nie uzyska żadnej informacji o tym, że musi cierpliwie czekać. Warto podkreślić, że komunikat o zapełnieniu przestrzeni dyskowej dziennika transakcyjnego to poważna sytuacja i należy jak najszybciej zająć się jej rozwiązaniem. W tym miejscu administrator może podjąć jedno z następujących działań: • Jeśli miejsce skończyło się w segmencie default, można usunąć dane z tabel, zwalniając w ten
sposób nieco miejsca. To „rozwiązanie” jest najgorszym z możliwych i należy traktować je jako ostateczność.
• Można zwiększyć ilość miejsca dla dziennika transakcyjnego przez wywołanie polecenia
ALTER DATABASE. Należy pamiętać, że przydzielenie miejsca bazie danych to stosunkowo
proste zadanie, natomiast odebranie tego miejsca wymaga znacznie więcej pracy.
• Jeśli miejsce wyczerpało się w segmencie logsegment, należy ręcznie zrzucić zawartość tego
dziennika i odtworzyć go w zmniejszonej postaci. Procedura w tym przypadku jest zależna od zastosowanego rozwiązania związanego z wykonywaniem kopii zapasowej. Jedna z koncepcji wykorzystuje polecenie DUMP TRANSACTION WITH TRUNCATE_ONLY, którego wywołanie spowoduje zwolnienie miejsca. Nie należy jednak często stosować tego polecenia, ponieważ powoduje utratę dzienników transakcyjnych, które mogłyby posłużyć do odtworzenia danych w przypadku awarii. To polecenie powoduje w zasadzie wyrzucenie zawartości dziennika transakcji.
Jeśli dziennik transakcyjny ma skłonność do zapełniania się, oznacza to, że jego rozmiar jest zbyt mały i trzeba go zwiększyć. Ten przypadek jest poważny i można go z reguły rozwiązać przez alokację dodatkowego miejsca. Polecenie dump transaction with truncate_only usuwa elementy zakończonych transakcji z dziennika, co powoduje, że nie nadaje się on do odtworzenia danych po awarii (uzupełnienia zmian dokonanych od ostatniej pełnej kopii zapasowej). Oznacza to w praktyce, że aby zapewnić funkcjonalną kopię zapasową, należy niezwłocznie wykonać pełną kopię zapasową bazy.
Zmiana rozmiaru dziennika transakcyjnego Podstawowa reguła mówi, że dziennik transakcyjny powinien mieć rozmiar od 20 do 25% rozmiaru całej bazy danych. Jednak należy pamiętać, że to nie jest złota reguła. Rozmiar dziennika transakcyjnego powinien wynosić dwa razy więcej od maksymalnego rozmiaru operacji wstawiania, aktualizacji lub usuwania, które mogą wystąpić w okresie między operacjami archiwizacji
Punkt w dzen a adm n stratora baz danych
|
527
dzienników transakcyjnych. To oznacza w praktyce, że w przypadku dużych baz danych zawierających duże ilości danych historycznych, w których liczba zmian jest niewielka, wystarczy znacznie mniejszy rozmiar dziennika transakcyjnego niż w przypadku znacznie mniejszej bazy danych o bardzo dużej liczbie zmian. W tym przypadku można przyjąć następującą złotą regułę: jeśli w przypadku jakiejś standardowej operacji zabraknie miejsca w dzienniku transakcyjnym, to znak, że należy znacząco go zwiększyć. Miejsce na dyskach jest bardzo tanie, a czas i praca administratora (i użytkowników aplikacji) są bardzo kosztowne. Przeanalizujmy kilka praktycznych przykładów ustalania rozmiaru dzienników transakcyjnych. Pierwsza baza danych zawiera 1000 GB danych historycznych aktualizowanych w ciągu dnia; jej dziennik transakcyjny ma rozmiar 5 GB. Inna baza danych zawiera 1 GB danych, które są całkowicie zmieniane w każdej dużej operacji (usuwanie wszystkich rekordów, wstawianie kopii wszystkich danych oraz, na końcu, kilka masowych modyfikacji danych). W tym przypadku dziennik transakcyjny ma rozmiar 1,2 GB. Jeszcze inna baza danych zawiera 200 MB danych, a jej dzienniki transakcyjne mają rozmiar 50 MB. Należy zwrócić uwagę na to, że w każdym z tych przypadków procentowe proporcje rozmiaru dzienników transakcyjnych do danych znacząco się różnią.
Plik interfejsów Plik interfaces zawiera informację niezbędną procesom klienckim bazy Sybase do połączenia z procesem serwera. Plik ten zawiera nazwę hosta (lub jego adres IP), numer portu oraz nazwę protokołu (najczęściej TCP). Dodatkowe wpisy do tego pliku można dopisywać za pomocą programu dsedit, można też modyfikować go ręcznie. Główne utrudnienie przy ręcznych modyfikacjach w systemie Solaris polega na tym, że stosowane jest adresowanie w formacie TLI TCP, gdzie kombinacja adresu IP i portu podawana jest w postaci binarnego ciągu znaków. Poniżej przedstawiam przykładową zawartość tego pliku w jednym z systemów uniksowych: $ cat interfaces SYBPROD master tcp ether sybprod 5555 query tcp ether sybprod 5555 PINKY query tli tcp /dev/tcp \x0002d6d8c06899l50000000000000000 master tli tcp /dev/tcp \x0002d6d8c06899l50000000000000000
Pliki SYBASE.sh i SYBASE.csh Katalog instalacyjny serwera Sybase w systemach uniksowych zawiera dwa pliki definiujące ustawienia środowiska (SYBASE.sh i SYBASE.csh), które można wykorzystać do ustawienia zmiennych niezbędnych do działania serwerowi Sybase. Gdy administrator loguje się do konta Sybase, powinien w pierwszej kolejności uruchamiać jeden z tych skryptów.
Backup Server Serwer Sybase wykorzystuje dodatkowy proces o nazwie backup server, przeznaczony do wykonywania szybkich operacji zapisu i odtwarzania kopii zapasowych. To element niezbędny dla wszystkich administratorów planujących wykonywanie kopii zapasowych.
528
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Serwer ten potrafi stosować technikę rozdzielania kopii zapasowych na urządzenia nośników i wykonywać kopie na wielu taśmach i plikach. Serwer kopii zapasowej potrafi wykonywać dwa typy kopii: pełny zrzut bazy danych i przyrostowy zrzut dziennika transakcyjnego. Gdy serwer kopii zapasowej wykonuje pełną kopię, wszystkie strony bazy danych zawierające dane są kopiowane wraz z aktualnych dziennikiem transakcyjnym. Wykorzystując tę kopię, można wykonać pełne odtworzenie bazy danych, z uwzględnieniem zmian aż do momentu zakończenia wykonywania kopii zapasowej. Program backup server wykonuje kompresję kopii zapasowych w trakcie zapisu. Ta kompresja jest szybka i efektywna. Strony danych serwera są w większości puste, dzięki czemu kompresja rzeczywiście daje bardzo dobre rezultaty. W rzeczywistości nawet przy zastosowaniu poziomu kompresji 1 (najniższy poziom kompresji w skali od 1 do 10) kopie zapasowe mają niewielkie rozmiary i zapisują się znacznie szybciej niż bez stosowania kompresji.
Urządzenie zrzutu Wczesne wersje Sybase wykorzystywały logiczne urządzenia do wykonywania zrzutów (ang. dump) kopii zapasowej. Polecenia wykonujące i odtwarzające kopie wykorzystywały te urządzenia logiczne. W nowszych wydaniach Sybase koncepcja urządzeń zrzutu nie jest już wykorzystywana, zamiast tego kopie zapisuje się bezpośrednio do plików.
Kopie gorące i zimne Istnieje możliwość zapisu plików baz danych Sybase (na przykład za pomocą polecenia dd); w tym celu należy zatrzymać serwer. Jednak tego typu praktyka należy do rzadkości. Kopie zapasowe serwera Sybase z reguły wykonuje się na działającym serwerze, a mimo to nie ma obawy, że z takich kopii uda się prawidłowo odtworzyć dane. Około 20 lat temu, gdy powstawał serwer baz danych Sybase, tego typu obawy były na porządku dziennym. Obecnie nie ma potrzeby zatrzymywania serwera Sybase w celu wykonania kopii zapasowej. Nawet w systemach wymagających działania 24 godziny na dobę siedem dni w tygodniu użytkownicy baz Sybase nie zauważą, że wykonuje się kopię zapasową bazy. Z oczywistych względów nadal jednak zaleca się wykonywanie kopii zapasowych w okresie najmniejszego obciążenia systemów.
Zabezpieczanie bazy danych Przy pracy z bazami danych szczególnie sprawdza się stare powiedzenie: lepiej zapobiegać, niż leczyć. Zatem zanim zajmę się omawianiem zagadnień związanych z wykonywaniem kopii zapasowych serwera Sybase, omówię zadania związane z utrzymaniem bazy danych w jak najlepszym stanie. Zadania te wykonuje się z reguły w nocy lub w czasie weekendu. Najważniejsze działania związane z utrzymaniem baz Sybase wykonuje się przez wywołanie poleceń dbcc oraz update statistics. Polecenie dbcc sprawdza stan sprawności serwera, update statistics aktualizuje zawartość statystyk wykorzystywanych przez Sybase do sporządzania planów wykonawczych zapytań. To ostatnie polecenie jest bardzo ważnym elementem optymalizacji działania aplikacji. Właśnie te dwa polecenia to najważniejszy element „zapobiegania” problemom w przypadku baz Sybase. Dodatkowo do tej kategorii zagadnień należy opracowanie optymalnej strategii archiwizacji dzienników transakcyjnych. Prawidłowe wykonywanie tych zadań pozwoli utrzymać bazę danych w optymalnym stanie i zapewnić Zabezp eczan e bazy danych
|
529
efektywność jej działania. Tak utrzymana baza jest gotowa do wykonywania prawidłowych kopii zapasowych.
dbcc — Database Consistency Checker Mimo że serwery baz danych Sybase są bardzo odporne na awarie i wiele wysiłku włożono w mechanizmy zabezpieczenia danych przed błędami, zawsze istnieje większe od zera prawdopodobieństwo wystąpienia takiego błędu. W przypadku bardzo dużych tabel niektóre z tych problemów mogą nie ujawniać się aż do wywołania określonych zapytań. Program dbcc służy do tego, aby takie problemy wykrywać już na wczesnym etapie ich występowania. To narzędzie jest skonstruowane jako zestaw poleceń języka SQL, które sprawdzają alokację stron danych bazy, związki między danymi oraz wskaźniki danych. Narzędzie wyszukuje problemy, jak również usuwa niektóre z nich. Gorąco polecam wywoływanie polecenia dbcc w ramach conocnej procedury administracyjnej na bazie danych. Dodatkowo dbcc warto uruchamiać (o ile to możliwe) przed wykonaniem kopii zapasowej bazy danych, co pozwoli zapewnić kopiom wysoki poziom wiarygodności. Jeśli baza danych jest uszkodzona przed wykonaniem kopii, to uszkodzona będzie ta kopia, co może spowodować, że nie uda się jej odtworzyć. Należy pamiętać jednak, że uruchomienie dbcc bywa bardzo czasochłonnym procesem, zajmującym wielokrotnie więcej czasu od procedury wykonania kopii zapasowej. Kopia bazy danych o rozmiarze 200 GB wykonuje się około 15 minut, natomiast polecenie dbcc na tej samej bazie może trwać nawet do trzech godzin. Jeśli polecenie dbcc jest uruchomione w trakcie normalnej pracy bazy, może spowodować znaczące obniżenie jej wydajności. Z tego powodu zaleca się wywoływanie polecenia dbcc w nocy. Alternatywnie można zdecydować się na wykonywanie tej procedury w cyklu tygodniowym, na przykład podczas weekendu. Operacje sprawdzające stan bazy wykonywane w ramach dbcc bywają bardzo obciążające; w dużych bazach danych (na przykład powyżej 500 GB objętości) warto rozważyć możliwość wykonywania procedur sprawdzających na wybranych obiektach bazy. Jednego dnia można wykonywać polecenia dbcc checktable i dbcc tablealloc na wybranych tabelach bazy, następnego dnia na innych. W określonym okresie zadanie kontroli spójności bazy zostanie wykonane dla wszystkich obiektów w bazie. Jeśli baza danych zawiera na przykład 200 tabel użytkownika (niesystemowych), pierwszej nocy można wykonać polecenie dbcc na tabelach systemowych, drugiego dnia — na 50 tabelach, trzeciego — na następnych 50, i tak dalej, aż piątego dnia zostaną zweryfikowane wszystkie tabele w bazie. Szóstego dnia cały cykl można rozpocząć od początku. Uwzględnienie sprawdzających bazę procedur wykorzystujących polecenie dbcc w regularnym procesie wykonywania kopii zapasowej i utrzymania bazy pozwala uzyskać spójną, efektywną bazę danych również w przypadku konieczności odtworzenia jej zawartości z kopii zapasowej. Należy pamiętać, że dbcc to nie jest opcjonalne narzędzie wykorzystywane w przypadku problemów. Wywoływanie polecenia dbcc powinno stać się rutynową czynnością. Jednak samo jego wywoływanie nie wystarczy. Należy analizować wyniki działania tego polecenia z punktu widzenia występowania komunikatów o błędach (do tego często wystarczy użycie uniksowego polecenia grep lub odpowiednika dla systemu Windows).
530
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Standardowe, conocne wywołania dbcc Program dbcc wykonuje różnego typu sprawdzenia bazy, różniące się czasami wykonania, stosowanymi poziomami blokad i szczegółowością badania. Niektóre sprawdzają jedynie strony danych, inne sprawdzają spójność indeksów i kolejność sortowania. Rodzaj zalecanego sprawdzenia zależy od rozmiaru bazy, wymogów dostępu oraz wymaganej kompletności testu. Tabela 17.1 zawiera opis operacji wykonywanych zwykle w ramach conocnej procedury utrzymania bazy Sybase. Tabela 17.1. Rodzaje operacji wykonywanych z użyciem programu dbcc Słowo kluczowe
Funkcja
Kto może wykonać
dbcc checkalloc
Sp awdzenie alokacji st on wszystkich tabel i indeksów Pot afi nap awić niektó e z napotkanych p oblemów Ba dzo powolne działanie dużo ope acji wejścia wyjścia ale niewielki zak es zakładanych blokad
Właściciel bazy
dbcc checkstorage
Sp awdzenie składowania st on
Właściciel bazy
dbcc checkcatalog
Sp awdzenie spójności tabel w bazie Ba dzo szybkie wypisuje info mację o segmentach zdefiniowanych w bazie
Właściciel bazy
dbcc checkdb
Wykonuje te same sp awdzenia co checktable ale dla wszystkich tabel w bazie
Właściciel bazy
O ile to możliwe, w bazie danych należy wykonywać wszystkie polecenia wymienione w tabeli 17.1. Polecenie dbcc stanowi specyficzne dla Sybase rozszerzenie języka SQL i z reguły wywołuje się je z poziomu programu isql. Składnia wywołań polecenia dbcc jest następująca: $ dbcc checkdb $ dbcc checkalloc [(nazwa_bazy)] [, fix]]) $ dbcc checkcatalog [(nazwa_bazy)]
Parametr fix polecenia dbcc checkalloc służy do określenia, czy dbcc ma naprawiać napotkane problemy. Aby wykorzystać opcję fix, należy przełączyć bazę w tryb pojedynczego użytkownika, dlatego z reguły jest stosowana w przypadku, gdy poprzednie wywołania dbcc wykryły problemy (lub gdy w dzienniku błędów Sybase pojawiły się komunikaty o błędach alokacji). W rzeczywistości opcji fix nie należy używać w rutynowych wywołaniach dbcc, a jedynie na polecenie pomocy technicznej lub w przypadku wystąpienia komunikatu o błędzie, którego dokumentacja w podręcznikach Sybase wyraźnie sugeruje zastosowanie tej opcji. Przed wywołaniem polecenia dbcc checkalloc, fix należy ustawić opcję konfiguracyjną bazy danych single user mode na wartość true. Baza uruchomiona z tą opcją pozwala na połączenie tylko jednego użytkownika jednocześnie. Polecenie dbcc checkstorage to nowszy mechanizm weryfikujący spójność bazy danych. To polecenie wymaga nieco przygotowań: musi istnieć baza o nazwie dbccdb wykorzystywana do przechowywania wyników testów spójności. Polecenie dbcc checkstorage ma działanie zbliżone do polecenia dbcc checkalloc i dbcc checkdb, ale swoje operacje wykonuje bez zakładania blokad na sprawdzanych tabelach.
Zabezp eczan e bazy danych
|
531
Zmiana organizacji Zmiana organizacji danych w tabelach baz Sybase to opcjonalny element, który może wpłynąć na znaczące przyspieszenie wydajności aplikacji. Sybase może pozostawiać w tabelach puste miejsca w przypadku wykonywania niektórych operacji, jak aktualizacja wartości w kolumnie o zmiennej długości danych (oryginalna zawartość musi zostać zachowana na wypadek wycofania transakcji). Dodatkowo serie operacji wstawiania i usuwania wierszy na tej samej stronie danych mogą skutkować nieoptymalnym rozłożeniem wierszy. Na przykład, jeśli na stronie mieści się 10 wierszy i zostanie usuniętych dziewięć z nich, na stronie danych będzie zapisany tylko jeden wiersz. Strona nie zostanie ponownie zaalokowana aż do momentu, gdy usunięty zostanie ostatni zapisany na niej wiersz. Tego typu nieoptymalne alokacje z reguły nie stanowią większego problemu, ponieważ wiersze są do tabeli wstawiane, odbywały się też operacje łączenia stron, ale jeśli fizyczny rozmiar tabeli jest znaczny, może to mieć niekorzystny wpływ na wydajność operacji odczytu. Dane są zapisywane w drzewach typu b-tree, co może spowodować, że większa liczba stron wymusza dodatkowe operacje wejścia-wyjścia w każdym z zapytań. Może okazać się, że to samo zapytanie jednego dnia będzie wykonywało się 20 minut, a innego dnia, przy danych o porównywalnych rozmiarach, 35 minut tylko dlatego, że w międzyczasie została wykonana większa liczba operacji usuwania lub modyfikowania danych. Polecenie reorg kompaktuje strony do ich optymalnego rozmiaru. Polecenie reorg optymalizuje wykorzystanie stron danych przez przesunięcia wierszy w seriach niewielkich transakcji. Ta procedura jest zwykle dość szybka i nie wymaga stosowania blokad na poziomie tabel, zatem można ją wykonywać na działającym systemie. W Sybase mamy do dyspozycji cztery polecenia reorg: reorg [with reorg [with reorg [with reorg
reclaim_space nazwa_tabeli [nazwa_indeksu] {resume, time = liczba_minut}] forwarded_rows nazwa_tabeli [nazwa_indeksu] {resume, time = liczba_minut}] compact nazwa_tabeli {resume, time = liczba_minut}] rebuild nazwa_tabeli [nazwa_indeksu]
Polecenie reorg compact stanowi kombinację poleceń reorg reclaim_space i reorg forwarded_rows. Za pomocą tych poleceń można określić maksymalny czas wywołania w celu zmieszczenia procedur utrzymania bazy w określonym oknie czasu. Polecenie reorg rebuild porządkuje i optymalizuje wszystkie dane. Nie można jednak uruchamiać go w dowolnym momencie. Zaleca się wywoływanie poleceń reorg rebuild lub reorg compact na wszystkich tabelach bazy przynajmniej raz w miesiącu. Operacje reorg powinny być wykonywane jedynie na tabelach typu DOL.
Aktualizacja statystyk Polecenie języka SQL update statistics nazwa_tabeli aktualizuje statystyki dystrybucji wartości we wskazanej tabeli. Informacja o dystrybucji wartości jest wykorzystywana przez optymalizator zapytań przy wyborze indeksów do każdego z zapytań. Informacje te są przechowywane dla każdego indeksu klastrowego i nieklastrowego. Po zaktualizowaniu statystyk przyszłe zapytania wykorzystują je do wyboru indeksów. Istniejące procedury składowane nie wykorzystują jednak tych zaktualizowanych informacji. Aby to umożliwić, należy wywołać polecenie sp_recompile nazwa_tabeli dla każdej z tabel w bazie. Polecenie sp_recompile informuje system o tym, że przy następnym wywołaniu procedury składowanej musi ona
532
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
zostać ponownie skompilowana z wykorzystaniem najnowszych statystyk odczytywanych tabel. Polecenie sp_recompile najczęściej wywołuje się na tabeli od razu po poleceniu update statistics. Polecenia update statistics, reorg rebuild i sp_recompile należy wykonywać na wszystkich tabelach w bazie danych, co więcej, nie da się ich wywołać na poziomie całej bazy danych. Aby sprawdzić listę wszystkich tabel w bazie, można posłużyć się zapytaniem select name from sysobjects where type='U'.
Weryfikacja konfiguracji Jednym z istotnych elementów kopii zapasowych baz danych jest konfiguracja systemu. Taka kopia zapasowa może znacząco zmniejszyć czasochłonność i pracochłonność procesu przywracania danych bazy z kopii po dużych awariach systemu. Warto zachować kopię poleceń wywołanych przy konfiguracji bazy danych, kopię wyników wywołania procedur składowanych sp_helpdb i sp_helpdevice oraz wynik polecenia bcp wywołanego na najważniejszych tabelach systemowych z bazy danych master: sysusages sysremotelogins syssrvroles sysdevices sysconfigures sysremotelogins systimeranges
syslogins sysloginroles sysdatabases syscharsets sysservers sysresourcelimits
Dodatkowo warto wykonać kopię wyniku wywołania następujących poleceń: $ cat backup_systemtables.sql exec sp_helpdb go exec sp_helpdevice go select * from sysusages order by vstart select * from sysusages order by dbid, lstart select * from syslogins select * from sysloginroles select * from sysdatabases select * from sysdevices select * from syscharsets select * from sysconfigures select * from sysservers select * from sysremotelogins select * from sysresourcelimits select * from systimeranges go
Te zapytania można wywołać (lub można zaplanować ich wykonanie) za pomocą następującego polecenia: $ XSOL backup_systemtables.sql
Polecenie XSOL zostanie szczegółowo omówione w dalszej części rozdziału. Oprócz tego należy zachować kopię całego oprogramowania bazy Sybase. W tej kopii znajdzie się też kopia pliku konfiguracyjnego.
Zabezp eczan e bazy danych
|
533
Implementacja mechanizmów mirroring i stripping Mechanizm kopii lustrzanych (ang. mirroring) może być realizowany na poziomie bazy danych lub systemu operacyjnego. Jego rola polega na zachowaniu identycznej kopii online w przypadku fizycznej awarii nośnika. Zalecam stosowanie tej techniki na poziomie systemu operacyjnego. Serwer Sybase obsługuje również mechanizm programowego mirroringu. Jeśli nie ma możliwości wykorzystania mirroringu sprzętowego, warto zapoznać się z rozdziałem „Mirroring Database Devices” podręcznika Sybase System Administration Guide. W przypadku wykorzystania konfiguracji RAID warto zastosować mechanizm disk striping. W bazach danych z reguły wąskim gardłem są operacje wejścia-wyjścia, a mechanizm disk striping optymalizuje operacje wejścia-wyjścia przez rozłożenie danych na różne dyski fizyczne.
Wykonywanie kopii serwerów Kopie zapasowe serwera Sybase z reguły wykonuje się w czasie normalnej aktywności bazy danych. Mechanizm dzienników transakcyjnych bazy Sybase gwarantuje spójność systemu. W Sybase kopię bazy danych online wykonuje się za pomocą polecenia języka SQL dump database, a kopię dziennika transakcyjnego — dump transaction. Polecenie dump wykonuje kopię bajt po bajcie zajętych stron plików danych. Polecenia dump i restore są wykonywane na poziomie bazy danych. Istnieją dwa „zwykłe” tryby wykonywania kopii zapasowej bazy danych. Pierwszy z nich polega na wykonywaniu kopii w nocy z ustawieniem opcji truncate log on checkpoint. W tym przypadku nie należy wykonywać zrzutów dzienników transakcyjnych. Ten tryb jest stosowany najczęściej w przypadku deweloperskich baz danych, to znaczy takich, których dane nie są kluczowe i utrata zmian z jednego dnia nie będzie katastrofą. Drugi tryb wykonywania kopii zapasowych polega na wykonywaniu pełnych nocnych kopii zapasowych oraz przyrostowych co 5 do 15 minut. W tym przypadku nie należy ustawiać opcji truncate log on checkpoint. Przyrostowe kopie zapasowe są wykonywane przez wywołanie polecenia dump transaction to /dat/plik . To polecenie utworzy plik (w tym przypadku /dat/plik) zawierający zrzuty transakcji. W zrzucie nie są uwzględniane rekordy oznaczone w dzienniku transakcyjnym jako zapisane w bazie. Kopiom danych warto nadawać nazwy, dzięki którym da się je sortować w kolejności alfabetycznej. Na przykład można stosować konwencję rrrrmmdd.ggmmss (rok, miesiąc, dzień, godzina, minuta, sekunda). Dzięki zastosowaniu tego formatu łatwiej będzie pracować z kopiami i wybierać odpowiednie z nich do odtworzenia.
Polecenia dump i load nie są wykonywane przez sam serwer danych, a przez dodatkowy proces o nazwie backup server. Dlatego należy zadbać o to, aby backup server działał przez cały czas działania bazy.
Składnia polecenia dump Najprostsza forma polecenia wykonującego pełną kopię bazy danych jest następująca: >
dump database nazwa_bazy to "nazwa_pliku"
A to najprostsza forma polecenia wykonującego kopię dziennika transakcyjnego: >
534 |
dump transaction nazwa_bazy to "nazwa_pliku"
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Pliki utworzone w efekcie wywołania tych poleceń można zapisać na taśmie, osobnym dysku lub innym urządzeniu określonym w Sybase za pomocą polecenia sp_adddumpdevice (obecnie istnieje tendencja do zapisu kopii zapasowych na urządzeniach logicznych zapisanych na dyskach twardych, zamiast na taśmach). Listing 17.1 przedstawia przykładowe polecenia wykonujące kopię zapasową. Listing 17.1. Przykładowe wywołanie polecenia dump 1> dump database mydb to '/sybase/backups/mydb.990312.bck' 2> go Backup Server session id is: 20. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 4.41.1.1: Creating new disk file /sybase/backups/mydb.990312 .bck. Backup Server: 6.28.1.1: Dumpfile name 'mydb9909106EF4 ' section number 0001 mounted on disk file '/sybase/backups/mydb.990312.bck' Backup Server: 4.58.1.1: Database mydb: 338 kilobytes DUMPed. Backup Server: 4.58.1.1: Database mydb: 344 kilobytes DUMPed. Backup Server: 3.43.1.1: Dump phase number 1 completed. Backup Server: 3.43.1.1: Dump phase number 2 completed. Backup Server: 3.43.1.1: Dump phase number 3 completed. Backup Server: 4.58.1.1: Database mydb: 352 kilobytes DUMPed. Backup Server: 3.42.1.1: DUMP is complete (database mydb). 1> dump transaction mydb to '/sybase/backups/mydb.tlogdmp' 2> go Backup Server session id is: 23. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 6.28.1.1: Dumpfile name 'mydb9909106F49 ' section number 0001 mounted on disk file '/sybase/backups/mydb.tlogdmp' Backup Server: 4.58.1.1: Database mydb: 16 kilobytes DUMPed. Backup Server: 4.58.1.1: Database mydb: 20 kilobytes DUMPed. Backup Server: 3.43.1.1: Dump phase number 3 completed. Backup Server: 4.58.1.1: Database mydb: 24 kilobytes DUMPed. Backup Server: 3.42.1.1: DUMP is complete (database mydb).
Podział i kompresja kopii zapasowej Polecenie dump potrafi dzielić pliki kopii zapasowych na mniejsze części; ten proces określa się jako stripping. Ponadto polecenie dump obsługuje kompresję. Zaleca się stosowanie tej kompresji, ponieważ po jej zastosowaniu kopie wykonują się szybciej i zajmują znacznie mniej miejsca. Oto składnia wykorzystania opcji stripping: > dump database nazwa_bazy to "nazwa_pliku" > stripe on "nazwa_pliku" > go
Kompresję stosuje się w następujący sposób: dump transaction nazwa_bazy to "compress::poziom_kompresji::nazwa_pliku" go
Parametr liczbowy poziom_kompresji przyjmuje wartość z przedziału od 0 do 9 (0 to brak kompresji). Proponuję stosowanie kompresji na poziomie 1, która wykorzystuje najszybszy algorytm. Korzyści ze zwiększenia wydajności dzięki zastosowaniu poziomu kompresji 1 są znaczące w porównaniu do wykonywania kopii zapasowych bez kompresji. W surowych plikach baz danych zawsze znajduje się dużo pustych miejsc, które są bardzo podatne na kompresję.
Zabezp eczan e bazy danych
|
535
W przypadku zastosowania funkcji stripping i kompresji (co jest zalecane) składnia polecenia będzie następująca: dump database mydb to "compress::1::/dumps/mydump-stripe1" stripe on " compress::1::/dumps/mydump-stripe2" stripe on " compress::1::/dumps/mydump-stripe3" stripe on " compress::1::/dumps/mydump-stripe4" go
Podręczniki systemowe systemu Sybase to doskonałe źródło informacji w przypadkach, gdy nie jesteśmy pewni składni albo zastosowań poszczególnych poleceń.
Książka operacyjna Większość centrów danych wykorzystuje więcej niż jedną bazę danych, dlatego posiadanie solidnej dokumentacji pozwala uniknąć błędów. Zalecam prowadzenie książki operacyjnej zawierającej informacje dotyczące konfiguracji wszystkich serwerów i zadań wykonywanych na nich w sposób zautomatyzowany. Ta księga nie musi być papierową kopią konfiguracji, lepszym pomysłem będzie oczywiście elektroniczna postać. Wystarczy zrzucić zawartość procedur systemowych (sp_helpdevice, sp_helpdb) do plików tekstowych i odświeżać je w kilkutygodniowym cyklu. Posiadanie historycznych informacji na temat systemów pozwoli zaoszczędzić sporo czasu w przypadku wystąpienia problemu (mamy więcej danych pomocnych w poszukiwaniu przyczyn problemów) i może okazać się kluczowe w sytuacjach katastrof dotykających dane.
Automatyzacja kopii zapasowych z użyciem skryptów W tym podrozdziale omówię prosty mechanizm wykonywania kopii zapasowych serwera Sybase. Przykłady są napisane w powłoce Bourne’a i zawierają minimalny zbiór funkcji niezbędnych w zarządzaniu serwerem baz danych. Stanowią jedynie ilustrację możliwości, ale mogą z powodzeniem służyć jako narzędzia do sporządzania kopii zapasowych rzeczywistych systemów.
Podstawowe zagadnienia automatyzacji kopii zapasowych Na każdym serwerze warto utworzyć katalog zawierający skrypty administratora. Na przykład można utworzyć zasób /export/home/sybase-scripts. Pierwszy z tych skryptów nazywa się XSQL i ma następującą zawartość: $ cd /export/home/sybase-scripts $ cat XSQL #!/bin/ksh . /export/home/sybase/SYBASE.sh /export/home/sybase/OCS-12_5/bin/isql -Usa -SMYSERVER -Psecret -i/export/home/sybase-scripts/$l -o/export/home/sybase-scripts/$l.out echo "Koniec pracy" >> $l.out date >> $l.out
Zadanie tego skryptu powinno być oczywiste. Na początku ładowana jest zawartość pliku SYBASE.sh w celu zainicjowania zmiennych środowiska Sybase, co stanowi niezbędny element w przypadku wywołania skryptu z poziomu programu cron. Skrypt XSQL przyjmuje jeden argument, którym jest plik skryptu. XSQL wykonuje wskazany skrypt, a jego komunikaty zapisuje w pliku o takiej samej nazwie co nazwa skryptu, z rozszerzeniem .out. 536
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Załóżmy, że chcemy wykonać kopie zapasowe bazy danych mydb. Utworzymy skrypt o nazwie backupmydb4way.sql z następującą zawartością: $ cat backupmydb4way.sql set nocount on select getdate() go DUMP DATABASE mydb to "compress::1::/dumps/mydump-stripe1" STRIPE ON " compress::1::/dumps/mydump-stripe2" STRIPE ON " compress::1::/dumps/mydump-stripe3" STRIPE ON " compress::1::/dumps/mydump-stripe4" go select getdate() go
Ten skrypt zapisuje w katalogu /dumps pliki zawierające kopie zapasowe. Wywołanie /export/
¦home/sybase-scripts/XSQL /export/home/sybase-scripts/backupmydb4way.sql warto umieścić w zadaniach programu cron do conocnego wykonywania kopii zapasowych.
Prosty skrypt aktualizujący statystyki Polecenie update statistics może być dość kłopotliwe w wywołaniu, ponieważ należy je wykonywać z parametrem odpowiadającym nazwie tabeli w bazie, osobno dla każdej tabeli. Poniższy skrypt to przykład wykorzystania wyniku polecenia SQL do wywołania sekwencji innych poleceń SQL. Skrypt ten wykonuje polecenie index statistics nazwa_tabeli oraz exec sp_recompile nazwa_tabeli na wszystkich tabelach w bazie. $ cat updstatsmydb.sh #!/bin/sh . /export/home/sybase/SYBASE.sh ISQL="$SYBASE/$SYBASE_OCS/bin/isql -Usa -Psecret -SMYSERVER -wl60" SQLFILE=/tmp/updstats.sql LOGFILE=`date '+updstats2_%Y%m%d'` cat << EOF | $ISQL | sed -e 's/-//g' -e 's/([o-9]* [rows affected]*)//g' > $ SOLFILE select "select convert(varchar,getdate())+ ' upd stats "+name+. ...........+char(10)+"go"+char(10)+"update index statistics mydb.dbo. "+name+char(10)+"go"+"exec sp_recompile +name+char(lo)+"go" from mydb.dbo.sysobjects where type = 'IT' go EOF $ISQL -i$SQLFILE -o$LOGFILE
Ten skrypt powłoki Bourne’a wykonuje polecenia update index statistics i sp_recompile na wszystkich tabelach w bazie mydb. Tworzony jest tymczasowy skrypt /tmp/updstats.sql, a następnie jest on wywoływany w ostatnim wierszu skryptu głównego. Plik /tmp/updstats.sql zawiera polecenia print wypisujące dla każdej tabeli czas wywołania i jej nazwę oraz polecenia update stats. Wyrażenie char(10) określa znak przejścia do nowego wiersza. Tabela sysobjects w każdej bazie zawiera listę obiektów bazy. Obiekty typu U to tabele. Oto przykład zawartości skryptu /tmp/updstats.sql utworzonego przez skrypt updstatsmydb.sh: select convert(varchar,getdate())+ ' upd stats tbl1' go update index statistics mydb.dbo.tbl1 go exec sp_recompile mydb.dbo.tbl1 go
Automatyzacja kop zapasowych z użyc em skryptów
|
537
select convert(varchar,getdate())+ ' upd stats tbl2' go update index statistics mydb.dbo.tbl2 go exec sp_recompile mydb.dbo.tbl2 go
Przykładowy skrypt wykonujący kopię plików dzienników transakcyjnych Pliki dzienników transakcyjnych należy zrzucać z zastosowaniem kompresji oraz strippingu. Zaleca się również, aby zapisywać te pliki z nazwami zawierającymi 24-godzinny znacznik czasu. Innymi słowy, nazwy plików powinny mieć postać rrrrmmdd.ggmmss (rok, miesiąc, dzień, godzina, minuta, sekunda). Dzięki temu standardowy listing zawartości katalogu będzie uwzględniał kolejność chronologiczną plików. Oto przykładowe polecenie wykonujące tego typu kopie zapasowe: DTIME=`date "+Y%m%d.%H%M%S"` echo "dump transaction somedb to">> /tmp/dfile.sql echo "\"/export/home/sybase-dumps/somedb.$DTIME.trn\"" >> /tmp/dfile.sql echo go >> /tmp/dfile.sql XSOL /tmp/dfile.sql
Automatyzacja wykonywania kopii Wykonywanie kopii zapasowych można z łatwością zautomatyzować za pomocą mechanizmu cron (systemy Unix) lub terminarza zadań (Windows). Oto przykładowy wpis konfiguracyjny w pliku crontab: 0 2 * * * /export/home/sybase-scripts/XSOL backupmydb4way.sql
Ten wpis spowoduje, że o godzinie 2:00 każdego dnia zostanie wykonana kopia zapasowa (za pomocą skryptów omówionych wcześniej w tym rozdziale). Dziennik z ostatniego wykonania zapisze się w pliku /export/home/sybase-scripts/backupmydb4way.sql.out. W taki sposób należy wykonywać kopie zapasowe wszystkich baz danych, z wyjątkiem systemowych baz model i tempdb. Listę baz danych można uzyskać za pomocą procedury składowanej sp_helpdb.
Wysyłanie e-mailem wyniku poleceń crontab W katalogu domowym serwera Sybase warto umieścić plik .forward zawierający adres e-mail administratora. Dzięki temu komunikaty z wywołania poleceń crontab będą automatycznie wysyłane na odpowiedni adres. Ten plik może zawierać większą liczbę adresów, po jednym w wierszu.
Logiczne kopie zapasowe Polecenie dump serwera Sybase wykonuje kopie pojedynczych baz danych. Jeśli konieczne jest wykonanie kopii tylko jednej tabeli, nie można użyć tego polecenia. Polecenia dump nie można użyć również do przenoszenia kopii baz danych z jednej architektury serwera na inną. Istnieje jednak narzędzie wykonujące kopie zapasowe na poziomie logicznym (czyli na poziomie tabel) o nazwie bcp, za pomocą którego można wykonać kopię fragmentu bazy; takie kopie można z powodzeniem przenosić między różnymi architekturami systemów. Polecenie bcp ma jeszcze jedną cenną funkcję. Program odnosi się do wewnętrznej struktury bazy danych, zatem jest doskonałym narzędziem weryfikującym wewnętrzną spójność bazy 538 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
danych w ramach procedury wykonywania kopii zapasowej. Polecenie bcp wyświetla komunikaty o błędach w przypadku jakichkolwiek problemów z odczytem danych. Program bcp ma jednak dwie wady: • wykonanie pełnej kopii bazy danych za pomocą bcp trwa znacznie dłużej; • bcp potrafi wykonać kopię zapasową tylko tabel i perspektyw; inne obiekty bazy danych (pro-
cedury składowane, wyzwalacze itp.) muszą być eksportowane z użyciem innych metod.
Wykonanie logicznej kopii zapasowej Program bcp potrafi eksportować całe bazy danych lub ich wybrane elementy. Oto kilka przykładów. Następujące polecenie wykonuje wczytanie danych z kopii zapasowej całej bazy danych (parametr in): # bcp mydb.dbo.zyx in /sybackups/zyx.bcp -c -S SERVER -U sa -P mypassword Starting copy... 192 rows copied. Clock Time (ms.): total = 1000 Avg = 5 (192.00 rows per sec.)
Następujące polecenie zapisuje w pliku zewnętrznym kopię zapasową bazy (parametr out): # bcp master.dbo.sysusages out /sybackups/sysusages.bcp -c -S SERVER -U sa -P mypassword Starting copy... 9 rows copied. Clock Time (ms.): total = 1000 Avg = 111 (9.00 rows per sec.)
Odtwarzanie logicznej kopii zapasowej Odtwarzanie kopii zapasowej za pomocą bcp może działać w trybie szybkim lub powolnym. Jeśli tabela nie ma indeksów lub wyzwalaczy, bcp wykorzystuje tryb szybki. Ten tryb działa szybciej, ponieważ zmiany nie są zapisywane w dzienniku transakcyjnym. W rzeczywistości po takiej operacji dziennik transakcyjny staje się bezużyteczny aż do wykonania pełnego zrzutu bazy danych (dump). Tryb szybki jest wykorzystywany do odtwarzania dużych porcji danych i do importowania danych do tabel. Dlatego po zakończeniu działania polecenia bcp należy wykonać pełny zrzut bazy. Jeśli tabela ma indeksy lub wyzwalacze, wykorzystywany jest wolniejszy tryb (wykorzystujący dziennik transakcyjny). Należy zachować ostrożność przy importowaniu w tym trybie dużych ilości danych. Jednym z wymogów przy ładowaniu danych do tabeli za pomocą polecenia bcp jest istnienie tabeli, ponieważ bcp nie tworzy obiektów, a jedynie potrafi przesyłać dane z i do bazy. Polecenie bcp doskonale sprawdza się w przypadku importowania danych z plików tekstowych w formacie przecinkowym (CSV). To zagadnienie wykracza poza tematykę tej książki; więcej informacji można znaleźć w podręczniku Sybase. W tym punkcie zajmiemy się natomiast zagadnieniem zapisu danych tabeli w pliku i ponownego wczytania ich do bazy. Główna różnica w składni polecenia bcp, jeśli chodzi o zrzucenie danych do pliku i wczytanie ich z pliku, polega na zastosowaniu odpowiednio słowa kluczowego out lub in. Wszystkie pozostałe parametry wywołania są dokładnie takie same. Istnieją dodatkowe parametry, które warto stosować z poleceniem bcp: -e plik_błędów oraz -m max_błędów. Opcja -m służy do określenia liczby błędów niekrytycznych, które mogą wystąpić, zanim operacja zostanie uznana za zakończoną niepowodzeniem. Opcja -e pozwala określić plik, do którego będą zapisywane komunikaty o błędach niekrytycznych, co może być przydatne przy analizie poprawności operacji (komunikaty będą również wypisywane na terminalu). Dzięki tym parametrom program bcp może kontynuować operację mimo napotkania błędów uznanych za niekrytyczne. Automatyzacja kop zapasowych z użyc em skryptów
|
539
Przy zapisie danych za pomocą polecenia bcp (w pliku wskazanym w parametrze -c) rekordy są zapisywane w formacie tekstowym, niezależnym od platformy systemowej. To bardzo przydatna cecha, szczególnie gdy trzeba wprowadzić zmiany w kopii danych przed ich załadowaniem z powrotem do bazy. Dzięki zastosowanemu formatowi dane mogą być bez problemu zmodyfikowane w dowolnym edytorze tekstu. Jeśli na przykład w jednej z kolumn tabeli zapisane są nazwy działów firmy i jedna z nich zmieniła się, można otworzyć ten plik i wykonać operację „znajdź i zamień”, po czym zapisać plik pod inną nazwą. Jeśli załadowanie niektórych wierszy z kopii nie powiedzie się, można odszukać te wiersze w kopii, poprawić ich składnię lub naprawić inny problem, który uniemożliwia ich załadowanie. W przypadku zastosowania opcji -c warto również określić separator kolumn (za pomocą opcji -t). W przypadku wykorzystania polecenia bcp do odtwarzania tabel systemowych należy mieć na uwadze to, że z reguły znajdują się w nich pewne wartości domyślne, na przykład w tabeli syslogins znajduje się wpis dotyczący konta sa (system administrator). Przy próbie odtworzenia tej tabeli za pomocą polecenia bcp wystąpi błąd duplikatu wartości indeksu. Aby temu zapobiec, należy z kopii zapasowej tabeli syslogins usunąć wpisy już występujące w tej tabeli. Po ich usunięciu operacja załadowania danych tej tabeli za pomocą polecenia bcp zakończy się powodzeniem. Alternatywnie można ustawić rozmiar transakcji na jeden wiersz (opcja -b1), co spowoduje po prostu, że duplikaty zostaną zignorowane.
Przygotowanie danych do audytu za pomocą bcp Kopie tabel systemowych, które powinny być dostępne do audytu, najczęściej wykonuje się raz w tygodniu i zapisuje w miejscu oddalonym od serwera. Dzięki opcji -c polecenia bcp istnieje możliwość zapoznania się z zawartością tych tabel nawet w przypadku awarii serwera. $ cat sysaudit_bcp.ksh cd /sysbackups bcp master.dbo.sysusages out sysusages.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.syslogins out syslogins.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysloginroles out sysloginroles.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysdevices out sysdevices.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysdatabases out sysdatabases.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.syscharsets out syscharsets.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysconfigures out sysconfigures.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysservers out sysservers.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysremotelogins out sysremotelogins.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.sysresourcelimits out sysresourcelimits.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword bcp master.dbo.systimeranges out systimeranges.bcp -c -T~ -SSYB_MYDB -Usa -Pmypassword
Wykonywanie fizycznych kopii zapasowych za pomocą programu Storage Manager Wiele komercyjnych programów do wykonywania kopii zapasowych ma wbudowane mechanizmy obsługi baz danych Sybase. Wykorzystywany jest w nich interfejs komunikujący się bezpośrednio z procesem backup server serwera Sybase. Ten interfejs pozwala na definiowanie, planowanie i wykonywanie kopii zapasowych z wykorzystaniem graficznego interfejsu użytkownika. Kopie zapasowe można wykonywać i odtwarzać zaledwie kilkoma kliknięciami myszą.
540 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Czasem te narzędzia są umieszczane w tym samym systemie co serwer danych, ale możliwe jest, że tylko część kliencka aplikacji jest instalowana w systemie serwera danych, a sama aplikacja jest instalowana w innym systemie w ramach tej samej sieci. Niezależnie od szczegółów konfiguracji aplikacje tego typu stanowią najłatwiejsze i najbardziej niezawodne rozwiązania związane z kopiami zapasowymi serwera Sybase. Niektóre narzędzia komercyjne omówione w rozdziale 8., wykorzystywane przede wszystkim do wykonywania fizycznych kopii zapasowych, potrafią również wykonywać kopie na poziomie logicznym. Pod tym względem stanowią uzupełnienie takich możliwości programu bcp, jak planowanie wykonania kopii czy graficzny interfejs użytkownika; pozwalają też na automatyczne zapisywanie wykonanych kopii na zewnętrznych nośnikach danych. Z powodu ścisłej integracji mechanizmów wykonywania kopii zapasowych z serwerem Sybase, po stronie tego serwera jedyna zasadnicza różnica między narzędziami do wykonywania kopii zapasowej polega na dostępności różnych typów źródłowego lub docelowego urządzenia składowania. Dzięki temu możliwa jest duża elastyczność w łączeniu nowych mechanizmów wykonywania kopii zapasowych z istniejącymi wcześniej procedurami. Załóżmy, że fizycznym urządzeniem taśmowym wykorzystywanym do zapisu kopii zapasowych jest /dev/rmt0, a nowe urządzenie może być zdefiniowane jako: "3rdPartybackup::'99.3.10.04.00.master.full'
"
Ciąg znaków 3rdPartybackup informuje backup server o tym, że to urządzenie jest obsługiwane przez oprogramowanie firmy trzeciej. Ciąg znaków 99.3.10.04.00.master.full reprezentuje czas wykonania, nazwę bazy danych oraz typ kopii zapasowej. Dzięki temu do oprogramowania wykonującego kopię zapasową wysyłana jest informacja o tym, co ma być skopiowane i w jaki sposób. Ta wartość jest wykorzystywana zarówno przy wykonywaniu, jak i przy odtwarzaniu kopii zapasowych serwera baz danych Sybase.
Odtwarzanie danych baz Sybase Składnia poleceń odtwarzających kopie zapasowe jest praktycznie identyczna ze składnią poleceń wykonujących kopie. Jedynie słowo kluczowe backup jest zastępowane słowem kluczowym restore, a słowo kluczowe to jest zastępowane słowem kluczowym from.
Odtwarzanie danych w przypadku katastrofy Pełne odtwarzanie danych, wykonywane w przypadku katastrofy, różni się od zwykłego odtwarzania danych do istniejącej bazy. Należy opracować odpowiedni plan działania w przypadku tego typu katastrofy. Należy zaplanować działania w przypadku przerwy w funkcjonowaniu całej lokalizacji, systemu i elementów systemu lub uszkodzenia bazy danych. Należy opracować działania związane z pełnym odtworzeniem systemu oraz wszystkich zapisanych w nim baz danych. Podstawowe zagadnienia związane z odtwarzaniem danych z kopii w przypadku katastrofy nie zostaną opisane w tym rozdziale (poświęcony jest im fragment rozdziału 24.). Należy upewnić się, że w systemie, na którym będzie odtwarzana baza danych, będzie dostęp do kopii bazy oraz plików konfiguracyjnych. Należy opracować istotne szczegóły procedury wykonywania i odtwarzania kopii systemu i danych, na przykład to, że zapis kopii zapasowych na taśmie powinien rozpocząć się dopiero po zakończeniu zrzutu danych z bazy do kopii zapasowej na dysku twardym. Odtwarzan e danych baz Sybase
|
541
Najczęstszym typem awarii jest awaria dysku twardego. Najbardziej oczywisty sposób zabezpieczenia systemu przed tego typu problemami polega na wykorzystaniu mechanizmów RAID. W największych organizacjach wykorzystanie RAID jest obowiązkowe w przypadku wszystkich systemów, a powód jest prosty: awarie dysków twardych są zbyt powszechne, aby zignorować to zagrożenie, a koszty administracji i przestojów w przypadku takich awarii są znaczące, nawet gdy nie zostały utracone jakiekolwiek dane. Przypadki katastrof prowadzących do całkowitej utraty systemu i danych są bardzo rzadkie, ale możliwe. Aby poradzić sobie z tego typu sytuacją, należy opracować procedurę odtworzenia systemu od zera. Do tego celu niezbędne jest posiadanie istotnych informacji oraz odpowiedniego oprogramowania.
Odtwarzanie danych z kopii Ładowanie bazy danych Sybase z kopii nie jest szybkim procesem. Można przyjąć założenie, że ten proces zajmuje od godziny do dwóch na każdych 100 GB danych, dlatego należy przygotować odpowiednie plany działania. Konieczne będzie również zaplanowanie budżetu czasowego na załadowanie dziennika transakcyjnego. Baza danych, do której będą odtwarzane dane, musi zostać utworzona w tej samej kolejności i przy tych samych rozmiarach, co oryginalna. Trudność polega na tym, że Sybase nie oferuje narzędzia (np. procedury składowanej), które wyświetlałoby tego typu szczegóły na temat bazy, ale najważniejsze narzędzia serwera Sybase (jak Sybase Central — podstawowe narzędzie administratora instalowane wraz z systemem Sybase) pomagają w odtworzeniu instrukcji wykorzystanych przy tworzeniu bazy danych. Jeśli baza jest odtwarzana do innego systemu lub do systemu, w którym nie zostały odtworzone bazy danych o odpowiednich nazwach, należy odtworzyć bazę danych, wywołując następujące polecenia: C:\> create database mydb on mydefseg = 40, mydefseg = 40 log on mylogseg = 10 C:\> alter database mydb on mydefseg = 40
Na mojej stronie (http://www.edbarlow.com) można znaleźć kilka darmowych narzędzi i składowanych procedur dla serwera Sybase. Na przykład do odtworzenia układu bazy danych może być użyta jedna z dostępnych tam procedur, sp_revdb nazwa_bazy.
Po odtworzeniu układu bazy danych należy odtworzyć pełną kopię bazy przez wywołanie polecenia load, co prezentuje listing 17.2. Polecenie load ma identyczną składnię z poleceniem dump. Listing 17.2. Przykład wywołania polecenia load 1> load database mydb from '/sybase/backups/mydb.990312.bck' 2> go Backup Server session id is: 26. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 6.28.1.1: Dumpfile name 'mydb9909106EF4 ' section number 0001 mounted on disk file '/sybase/backups/mydb.990312.bck' Backup Server: 4.58.1.1: Database mydb: 17926 kilobytes LOADed. Backup Server: 4.58.1.1: Database mydb: 19462 kilobytes LOADed. Backup Server: 4.58.1.1: Database mydb: 19470 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database mydb). Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically.
542 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
W wyniku tego wywołania znajduje się informacja o tym, że w celu aktywacji bazy należy wywołać polecenie online database baza_danych. Jeśli nie ma dzienników transakcyjnych do odtworzenia na tej bazie, można ją aktywować już w tym momencie. Jeśli dzienniki transakcyjne mają być załadowane, polecenie online database należy wywołać dopiero po zakończeniu tej operacji. Dzienniki transakcyjne ładuje się do odtworzonej bazy danych poleceniem load transaction. Listing 17.3 przedstawia przykład załadowania dzienników transakcyjnych do bazy mydb, odtworzonej w powyższym przykładzie (listing 17.2). Listing 17.3. Przykład wywołania polecenia load transaction 1> load transaction mydb from '/sybase/backups/mydb.tlogdmp' 2> go Backup Server session id is: 28. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 6.28.1.1: Dumpfile name 'mydb9909106F49 ' section number 0001 mounted on disk file '/sybase/backups/mydb.tlogdmp' Backup Server: 4.58.1.1: Database mydb: 24 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database mydb). Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically.
Polecenie load transaction należy wywołać indywidualnie dla każdego dziennika transakcyjnego. Jak wspominałem wcześniej w tym rozdziale, zaleca się, aby dzienniki transakcyjne były zapisywane do plików o nazwach w formacie rrrrmmdd. ggmmss (rok, miesiąc, dzień, godzina, minuta, sekunda). Pozwoli to na łatwe uporządkowanie dzienników transakcyjnych w kolejności chronologicznej, co znacząco upraszcza procedurę ich odtwarzania we właściwej kolejności.
Polecenie online database Po zakończeniu tego procesu odtworzenie bazy danych jest zakończone i można ją ustawić w tryb online, wykorzystując polecenie online database nazwa_bazy.
Odtworzenie danych do określonego punktu czasu Dzienniki transakcyjne można wykorzystać również do odtworzenia danych do określonego punktu czasu. Dzięki temu w sytuacji, gdy o godzinie 12:00 zostały dodane bardzo ważne dane, które zostały omyłkowo usunięte o godzinie 14:00, można je odtworzyć, wykorzystując kopię zapasową i dzienniki transakcyjne, które zostaną odtworzone dokładnie do godziny 13:59. Aby odtworzyć usunięte dane produkcyjne bez zatrzymywania produkcyjnej bazy danych, można załadować dane bazy do bazy tymczasowej, odtworzyć dzienniki transakcyjne, po czym przekopiować dane z bazy tymczasowej do produkcyjnej za pomocą polecenia bcp.
Aby określić datę, do której mają być odtworzone dane, należy zastosować parametr until_ ¦time polecenia load transaction. W tym parametrze należy określić czas i datę w formacie domyślnym dla serwera danych. Na przykład, aby odtworzyć dane aż do godziny 12:34:32:650 1 kwietnia 2007 roku, należy odtworzyć pełną kopię bazy danych, po czym odtworzyć dane z dzienników transakcyjnych za pomocą następującego polecenia:
Odtwarzan e danych baz Sybase
| 543
load transaction mydb from '/sybase/backups/mydb.tlogdmp' with untiltime = 'April 1, 2007 at 12:34:32:650AH'
Odtwarzanie danych ze skompresowanych kopii Jak wspomniałem w podrozdziale poświęconym wykonywaniu kopii, dane można zapisywać w skompresowanych kopiach, wykorzystując parametr compress::poziom_kompresji:: ¦nazwa_pliku. Polecenie load nie wymaga określenia parametru poziom_kompresji (co stanowi kolejną różnicę między poleceniami dump i load), ponieważ jest w stanie wykryć go w sposób automatyczny. Dlatego składnia parametru kompresji dla polecenia load jest następująca: compress::::nazwa_pliku.
Procedury dla serwera Sybase W tym podrozdziale omówię kilka kompletnych procedur stosowanych w serwerze Sybase. Na początek omówię podstawowe z nich, następnie — nieco bardziej skomplikowane. Jako pierwszą zajmiemy się podstawową procedurą, wykorzystywaną przez pozostałe.
Procedura 1. — uruchamianie serwera Sybase W katalogu $SYBASE/$SYBASE_ASE/install znajdują się pliki służące do uruchamiania serwera. To zwykłe skrypty powłoki o nazwach rozpoczynających się ciągiem znaków run_, najczęściej o postaci run_. W tych skryptach zapisane są polecenia powłoki służące do uruchomienia serwerów Sybase z odpowiednimi argumentami wywołania. Pliki uruchomieniowe serwera backup server najczęściej noszą nazwy run__BACK, a pliki serwera monitorującego (ang. monitor server) — run__MON. W domyślnej instalacji można znaleźć kilka skryptów tego typu, po jednym dla każdego serwera, serwera kopii zapasowych i innych serwerów wchodzących w skład systemu Sybase. Listing 17.4 zawiera przykładowy skrypt uruchomieniowy dla systemów uniksowych. Listing 17.4. Przykładowy skrypt uruchamiania serwera Sybase #!/bin/sh # # SQL Server Information # Name SYBJITANIA # Master device /sybdata/master.dbf # Master device size 10752 # Errorlog /opt/sybase/logs/SYB_MYDB.errorlog # Interfaces /opt/sybase # /opt/sybase/bin/dataserver -d/sybdata/master.dbf -sSYB_MYDB \ e/opt/sybase/logs/SYB_MYDB.errorlog -i/opt/sybase
W systemach Unix serwery uruchamia się poleceniem startserver -f run_NAZWA. Polecenie start server to prosty program służący do uruchamiania w tle programów wskazanych w parametrze -f. W systemach Unix serwer Sybase powinien działać z poziomu konta przeznaczonego dla systemu Sybase. Nie należy uruchamiać serwerów z poziomu konta root.
544 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Procedura 2. — sprawdzenie, czy serwer działa Najprostszy sposób sprawdzenia sprawności serwera polega na podłączeniu się do niego za pomocą jakiegoś narzędzia, na przykład programu isql. Polecenie isql pozwala podłączyć się zarówno do serwera danych Sybase, jak i do serwera kopii zapasowych (backup server). Oto przykład tego typu procesu; zostaje nawiązane połączenie z serwerem SYB_MYDB oraz serwerem kopii SYB_BACKUP: # isql -S SYB_MYDB -U sa -P passwd 1> quit # isql -S SYB_BACKUP -U sa -P passwd 1> quit
Jeśli dowolny z tych procesów nie działa (lub podane hasło jest nieprawidłowe), pojawi się następujący komunikat o błędzie: Operating-system error: Connection refused DB-LIBRARY error: Unable to connect: SQL Server is unavailable or does not exist.
Jeśli podejrzewa się problem z serwerem, warto sprawdzić, czy działają wszystkie procesy systemowe. Procesy Sybase można sprawdzić za pomocą standardowego polecenia ps lub wykorzystując skrypt $SYBASE/$SYBASE_ASE/install/showserver. Skrypt showserver w rzeczywistości również wykorzystuje polecenie ps. Działający system powinien mieć uruchomione co najmniej dwa serwery danych (proces dataserver) oraz jeden proces serwera kopii (backupserver). Wyniki wywołania obydwu tych poleceń w systemie Linux przedstawia listing 17.5. Listing 17.5. Przykład sprawdzenia procesów serwera — polecenia ps i showserver # ps ax # lub ps auxww | grep Sybase 191 ? S 0:00 in.telnetd 94 ? S 0:00 /usr/sbin/portmap 114 ? S 0:00 /usr/sbin/atd 157 ? S 0:00 sh /opt/sybase/install/run_SYB_BACKUP 160 ? S 0:00 sh /opt/sybase/install/run_SYB_TITANIA 164 ? S 0:00 /opt/sybase/bin/dataserver -d/sybdata/master.dbf sSYB_MYDB 168 ? S 0:00 /opt/sybase/bin/backupserver -SSYB_BACKUP e/opt/sybase/logs # $SYBASE/$SYBASE_ASE/install/showserver Sybase 164 0.1 10.4 16224 6592 ? S 22:18 0:00 /opt/sybase/bin/dataserver d/sybdata/master.dbf -sSYB_MYDB e/opt/Sybase/logs/SYB_MYDB.errorlog -i/opt/Sybase Sybase 168 0.0 6.4 6660 4092 ? S 22:18 0:00 /opt/sybase/bin/backupserver -SSYB_BACKUP -e/opt/sybase/logs/SYB_BACKUP.errorlog -I/opt/sybase/interfaces M/opt/sybase/bin/sybmultbuf -Lus_english -Jiso_l -c/opt/sybase/backup_tape
Jeśli procesy backupserver lub showserver nie działają, należy je uruchomić za pomocą odpowiedniego skryptu uruchamiającego. W systemie Windows Sybase wykorzystuje usługi systemowe. Ich stan można sprawdzić w Panelu sterowania, w folderze Narzędzia administracyjne.
Procedury dla serwera Sybase
| 545
Procedura 3. — zamykanie serwera Istnieje kilka sposobów zamykania serwera Sybase. Podstawowy mechanizm wykorzystuje polecenie shutdown języka T_SQL. Po wywołaniu tego polecenia baza danych blokuje możliwość logowania się każdemu z wyjątkiem administratora, wykonuje punkt przywracania dla każdej z baz i czeka na zakończenie działania wszystkich uruchomionych zapytań i procedur. Aby nie czekać na zakończenie tych zadań, można spróbować wywołać polecenie shutdown nowait. Opcja with nowait powoduje, że serwer zamknie się natychmiast bez oczekiwania na zakończenie działających operacji, ale z tego powodu procedura ponownego uruchomienia będzie wydłużona, ponieważ serwer będzie musiał wykonać działania naprawcze. Przed wywołaniem polecenia shutdown nowait warto sprawdzić, czy nie są wykonywane istotne operacje na danych (w przeciwnym razie liczba administratorów baz danych może zmniejszyć się o jednego, gdy użytkownicy wyśledzą winnego utraty ważnych informacji). Od wersji Sybase 12.5.4 dostępny jest dodatkowy parametr, pozwalający określić czas oczekiwania procedury shutdown na zakończenie wykonywanych operacji. Po tym czasie oczekiwania wykonywana jest instrukcja shutdown with nowait.
Po pierwsze: zwykłe zamknięcie Zwykłe zamknięcie serwera za pomocą polecenia shutdown to najlepszy sposób, zapewniający bezpieczeństwo danych. Baza danych zamknięta w ten sposób uruchomi się w najkrótszym możliwym czasie, ponieważ wszystkie transakcje będą prawidłowo zakończone, a strony danych będą prawidłowo przepisane z pamięci podręcznej na dysk przez wykonanie punktu przywracania dla każdej z baz. Większość transakcji wykonuje się w krótkim czasie, więc z reguły polecenie shutdown działa dość szybko. Wszystkie transakcje zapisane na dysku są oznaczane jako zatwierdzone (ang. committed), dzięki czemu serwer przy uruchamianiu się nie musi wykonywać działań naprawczych (ang. recovery). l> shutdown Server SHUTDOWN by request. The SQL Server is terminating this process. DB-LIBRARY error: Unexpected EOF from SQL Server.
Po drugie: zamknięcie bez oczekiwania Polecenie shutdown z opcją nowait powoduje natychmiastowe zakończenie wszystkich procesów i zamknięcie serwera baz danych. Niezakończone transakcje zostaną wycofane przy następnym uruchomieniu serwera w ramach procedury naprawczej. To wydłuża czas uruchomienia serwera, ponieważ nie zostały wywołane punkty przywracania, a dane nie zostały zapisane na dysku, zatem serwer musi odtworzyć spójny stan danych na podstawie dzienników transakcyjnych. Serwer przegląda wszystkie transakcje i zapisuje w stronach danych te z nich, które zostały zatwierdzone. Metoda shutdown z opcją nowait jest stosowana najczęściej wówczas, gdy polecenie shutdown nie daje rezultatu przez dłuższy czas lub gdy trzeba natychmiast zamknąć serwer. l> shutdown with nowait Server SHUTDOWN by request. The SQL Server is terminating this process. DB-LIBRARY error: Unexpected EOF from SQL Server.
546 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Po trzecie: sygnał kill -15 wysłany do procesu dataserver Sporadycznie zdarzają się sytuacje, gdy nie ma możliwości podłączenia się do serwera w celu wykonania polecenia shutdown. Proces dataserver ma zaimplementowaną obsługę sygnału 15. (wysyłanego za pomocą polecenia kill -15 identyfikator_procesu_dataserver), która działa tak samo jak polecenie shutdown nowait. Ten sposób można zatem uznać za tak samo bezpieczny jak wywołanie polecenia shutwown nowait, oczywiście ze wszelkimi tego konsekwencjami, jak wycofanie niezatwierdzonych transakcji i wydłużony czas ponownego uruchomienia serwera.
Nigdy nie używać: sygnał kill -9 wysłany do procesu dataserver Współczesne komercyjne bazy danych są dość odporne na uszkodzenia. Dlatego istnieje duże prawdopodobieństwo, że serwer przetrwa wywołanie polecenia kill -9 identyfikator_ ¦procesu_dataserver. Jednak to wywołanie nie daje gwarancji, że wszystko zakończy się dobrze. Dlatego tego typu operację należy uznać za absolutnie ostateczny środek, gdy wszystkie inne nie dają rezultatu. Polecenie kill -9 po prostu bezwarunkowo usuwa proces z tablicy procesów, nie pozwalając mu na jakąkolwiek reakcję, na przykład wykonanie działań porządkujących dane. Strony danych są wyrzucane z pamięci, zatem to wywołanie można z powodzeniem porównać do wyjęcia wtyczki zasilania z gniazdka. Zawsze powinniśmy sprawdzić inne metody, zanim zdecydujemy się na to wywołanie.
W systemie Windows W systemach Windows należy spróbować wywołać polecenie shutdown. Jeśli to nie zadziała, można spróbować zatrzymać serwer, zatrzymując odpowiednią usługę systemu Windows przy użyciu odpowiedniej funkcji Panelu sterowania.
Procedura 4. — ustawianie opcji serwera Opcje konfiguracyjne serwera modyfikuje się za pomocą procedury składowanej sp_configure. Wywołanie sp_configure bez parametrów spowoduje wypisanie aktualnej listy parametrów. Aby zmodyfikować wartość parametru, należy wywołać polecenie sp_configure opcja, wartość. Większość opcji konfiguracyjnych serwera Sybase jest wykorzystywana w sposób dynamiczny, dzięki czemu zmiany ich wartości wchodzą w życie z momentem ich ustawienia (niektóre zmiany jednak wymagają ponownego uruchomienia serwera).
Procedura 5. — ustawianie opcji bazy danych Każda baza danych ma własne, lokalne opcje konfiguracyjne. Przykładem może tu być opcja truncate log on checkpoint (powodująca usuwanie co kilka minut niewykorzystanych części dzienników transakcyjnych), abort transaction on log full (która powoduje przerwanie działających transakcji w przypadku zapełnienia dziennika transakcyjnego; domyślnie operacje te są wstrzymywane w oczekiwaniu na zwolnienie miejsca), select into/bulkcopy (która powoduje, że niektóre operacje działają szybciej, ponieważ nie jest w ich przypadku wykorzystywany dziennik transakcyjny), single user mode czy dbo use only. Poniższy przykład ustawia wartość opcji nazwa_opcji w bazie mydbname na wartość true:
Procedury dla serwera Sybase
|
547
sp_dboption mydbname, "nazwa_opcji", true go use baddbname go checkpoint go
Procedura 6. — wywoływanie zapytań Jak już wspomniałem, polecenie isql nie zachwyca bogactwem opcji. Jedną z brakujących opcji jest prosty sposób zapisu wyniku zapytania w pliku. Istnieją jednak dwie możliwości rozwiązania tego problemu. Pierwsza z nich polega na wykorzystaniu polecenia sqsh (stworzonego przez Scotta Graya i utrzymywanego przez Michaela Peppiera), które jest w zasadzie zaawansowaną wersją programu isql, uzupełnioną o obsługę historii poleceń i możliwość przekierowania do pliku wyniku zapytania. Drugie rozwiązanie polega na użyciu programu ASEisql, darmowego narzędzia działającego w trybie graficznym. Można oczywiście wykorzystać również SQL Advantage, graficzne narzędzie do komponowania zapytań, wchodzące w skład produktów SYbase. Przeglądanie wyników poleceń, na przykład sp_helpdb, jest znacznie łatwiejsze w graficznym interfejsie użytkownika. Adresy stron, z których można pobrać programy ASEisql i sqsh, można znaleźć na stronie WWW autora: http://www.edbarlow.com.
Procedura naprawcza dla baz Sybase Pierwszym etapem naprawy bazy danych jest diagnoza przyczyny problemów. W tym podrozdziale omówię zalecenia dotyczące diagnostyki problemów z serwerem Sybase. Przy pracy z serwerem Sybase (i każdym innym) warto wziąć pod uwagę, że: • Kontakt ze wsparciem technicznym może zająć dłuższą chwilę. Jeśli ma się podpisaną
umowę wsparcia, z konsultantem technicznym Sybase należy skontaktować się jak najszybciej po stwierdzeniu kłopotów z serwerem. Pracownik techniczny firmy Sybase oddzwania w ciągu godziny od zgłoszenia problemu o priorytecie 1. • Przed rozpoczęciem działań należy opanować nerwy. Błędy popełniane w trakcie procedury
odtwarzania systemów po katastrofach mogą mieć nie mniej dramatyczne konsekwencje niż pierwotna przyczyna problemów.
• Bardzo pomocne bywają podręczniki dla administratorów Sybase, w szczególności Tro-
ubleshooting Guide.
Etap 1. — czy można połączyć się z serwerem za pomocą isql? W pierwszej kolejności po otrzymaniu zgłoszenia o problemie należy sprawdzić, czy z bazą danych uda się połączyć za pomocą polecenia isql. Jeśli ta operacja się powiedzie, należy przejść do etapu 2., jeśli nie — do etapu 5.
548 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Etap 2. — wywołanie procedury składowanej sp_who Po zalogowaniu się do bazy za pomocą polecenia isql należy uruchomić procedurę składowaną sp_who. Ta procedura wypisuje informacje o użytkownikach przyłączonych do serwera i pozwala zidentyfikować procesy, które mogą być przyczyną problemów. Stworzyłem własną bibliotekę procedur składowanych, która zawiera procedurę sp_whodo, użyteczną w tej sytuacji. Procedura sp_whodo nie tylko wypisuje procesy, ale też wyraźnie oznacza procesy zablokowane. Procedura sp_who wypisuje jeden wiersz dla każdego użytkownika przyłączonego do bazy, co w dużych systemach może stanowić sporo informacji.
Jeśli na liście procesów znajdują się zablokowane, należy przejść do etapu 3. Jeśli pojawiły się procesy w stanie LOG SUSPEND, należy przejść do etapu 4. Jeśli wszystko wygląda prawidłowo, można uruchomić procedurę sp_lock, która pozwoli na wykonanie dalszej diagnostyki, oraz sp_helplogin nazwa_użytkownika, która pozwoli stwierdzić, czy sesja użytkownika została zablokowana z powodu naruszenia polityki bezpieczeństwa (na przykład za duża liczba prób podania hasła). Jeśli wynik procedury sp_who nie pozwoli zidentyfikować przyczyn problemów lub administrator uzna, że problem leży w innych obszarach działania serwera, należy przejść do etapu 6. i sprawdzić zawartość dziennika błędów.
Etap 3. — odblokowanie procesów Jeśli w etapie 2. stwierdzono, że niektóre z procesów serwera zostały zablokowane, należy zdecydować, czy problem wymaga ich zakończenia. Jeśli jedno zapytanie blokuje pozostałe, można je zakończyć, zamykając program klienta, który wywołał zapytanie, lub wywołując polecenie kill języka T-SQL.
Etap 4. — zatrzymanie tworzenia dziennika Jeśli procedura sp_who ujawni proces w stanie LOG SUSPEND, będzie to oznaczać, że zapełnił się dziennik transakcyjny bazy danych. Należy ręcznie przyciąć (ang. truncate) lub zwiększyć (ang. extend) dziennik transakcyjny albo zamknąć proces , który spowodował jego zapełnienie. Szczegóły postępowania zostały opisane w podrozdziale „Dziennik transakcyjny”.
Etap 5. — nie można połączyć się z serwerem za pomocą isql Jeśli do serwera nie można zalogować się za pomocą zdalnego narzędzia, np. isql, należy zalogować się w systemie operacyjnym (np. za pomocą usługi terminali lub telnet) i przejść do etapu 6.
Procedura naprawcza dla baz Sybase
| 549
Etap 6. — sprawdzenie zawartości dziennika błędów serwera Sybase Zawsze w przypadku poważniejszych problemów należy sprawdzać komunikaty w dzienniku błędów serwera. Dziennik ten może znajdować się w różnych miejscach; dokładna ścieżka jest określona w skrypcie uruchamiającym serwer. Najczęściej jest wykorzystywana ścieżka $SYBASE/$SYBASE_ASE/install/.log. W tym pliku należy szukać informacji o przyczynie problemów. Błędy serwera Sybase z reguły mają przypisane numery. W przypadku wystąpienia błędu należy odszukać jego numer w dzienniku błędów, po czym sprawdzić go w podręczniku Sybase Troubleshooting Guide, dostępnym na stronie http://sybooks.sybase.com. Ten podręcznik zawiera dobre objaśnienia każdego z błędów i zawiera porady, jeśli chodzi o ich rozwiązywanie.
Etap 7. — sprawdzenie, czy serwer działa Zastosować procedurę 2., aby sprawdzić, czy serwer działa. Jeśli tak, ale nie można się z nim połączyć za pomocą zdalnego klienta (etap 5.), należy przejść do punktu 8., w przeciwnym razie należy przejść do etapu 9.
Etap 8. — serwer działa, ale nie pozwala na zdalne połączenia Spróbować połączyć się z serwerem Sybase z tego samego komputera, na którym uruchomiony jest serwer. Jeśli to się nie uda, należy upewnić się, że zmienne środowiska są skonfigurowane prawidłowo. W tym celu należy sprawdzić zawartość pliku SYBASE.sh w katalogu $SYBASE. Jeśli nie uda się połączyć z serwerem, ale istnieje możliwość jego zamknięcia, należy to zrobić, po czym przejść do etapu 9.
Etap 9. — ponowne uruchomienie serwera Pełny opis procedury ponownego uruchomienia serwera można znaleźć w punkcie „Procedura 1. — uruchamianie serwera Sybase”. Dla przypomnienia: $ cd $SYBASE/$SYBASE_ASE/install $ ./startserver -f run HYSYBASESERVER
Jeśli serwer uruchomi się bez problemów, to koniec pracy. Jeśli nie, należy przejść do etapu 10.
Etap 10. — problem z uruchomieniem Jeśli serwer się nie uruchomił, oznacza to, że mamy poważny problem. W takim przypadku należy spróbować następnych etapów, w nadziei, że znajdzie się proste rozwiązanie tego problemu.
550
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Etap 11. — kontakt ze wsparciem firmy Sybase Jeśli firma ma umowę na wsparcie od firmy Sybase, należy zadzwonić do wsparcia już w momencie, gdy problem okazuje się niebanalny. Wsparcie firmy Sybase jest doskonałe i nie należy traktować go jako zła koniecznego, szczególnie w przypadku, gdy zagrożone są istotne dane. Należy jednak mieć na uwadze, że pracownik wsparcia technicznego oddzwania do zgłaszającego z reguły nie wcześniej niż 30 minut od zgłoszenia, nawet w przypadku wysokiego priorytetu zgłoszenia. Dlatego należy dzwonić jak najwcześniej.
Etap 12. — problem z alokacją pamięci współdzielonej Sybase wykorzystuje pamięć współdzieloną do komunikacji międzyprocesowej oraz buforowania stron danych. Jeśli serwer nie może zaalokować pamięci niezbędnej mu do realizacji zadań, wypisuje komunikat następującej treści: 00:2006/03/21 23:39:02.78 kernel 00:2006/03/21 23:39:02.80 kernel 00:2006/03/21 23:39:02.80 kernel
os_create_region: can't allocate 2147479552 bytes kbcreate: couldn't create kernel region. kistartup: could not create shared memory
Jeśli serwer nie uruchamia się, a zamiast tego wypisuje taki komunikat, to znak, że nie był w stanie zaalokować niezbędnej pamięci. Może być kilka przyczyn takiej sytuacji. Najbardziej oczywistą przyczyną jest to, że system nie zwolnił pamięci po poprzednim zamknięciu serwera. Aby to naprawić, należy usunąć plik .krg, znajdujący się w $SYBASE/$SYBASE_ASE. Po usunięciu pliku .krg należy ponowić próbę uruchomienia serwera. Jeśli to nie pomoże, należy upewnić się, że nikt nie zmodyfikował konfiguracji pamięci w systemie lub nie zmienił ilości pamięci skonfigurowanej do alokacji przy starcie serwera. Należy sprawdzić, ile pamięci jest fizycznie dostępne w systemie oraz ile próbuje jej zaalokować serwer (w powyższym przykładzie to jest 2 147 479 552 bajtów). Jeśli serwer usiłuje zaalokować za dużo pamięci, należy to zmodyfikować w pliku konfiguracyjnym .cfg. Serwer Sybase wymaga ustawienia pewnych opcji w pliku /etc/system. Te opcje określają maksymalną ilość pamięci współdzielonej, jaką może zaalokować serwer. Jeśli te wartości nie są ustawione (co może mieć miejsce w nowo zainstalowanym serwerze), należy skonsultować się z podręcznikiem instalacji dla danej platformy. Jeśli została zmieniona ilość pamięci systemowej, należy odpowiednio zmodyfikować plik /etc/system. Ilość wykorzystanej pamięci współdzielonej można sprawdzić za pomocą polecenia ipcs. Szczegóły dotyczące parametrów wywołania należy sprawdzić w podręczniku polecenia, ale jego wynik powinien mieć następującą postać: --------- Shared Memory Segments ------------shmid owner perms bytes 129 Sybase 600 11964416 2 Sybase 666 1024 56 curtis 606 33334342
nattch 1 3 3
status
W tym przykładzie proces użytkownika curtis zajął sporą część pamięci współdzielonej. Po zakończeniu tego procesu pamięć powinna zostać zwrócona do puli. Jeśli zamknięcie procesu nie zwalnia pamięci, można to zrobić za pomocą polecenia ipcrm. W tym przypadku również warto zapoznać się z podręcznikiem systemowym tego polecenia.
Procedura naprawcza dla baz Sybase
|
551
O ile to możliwe, należy stosować się do zasady, aby zawsze modyfikować tylko jedną opcję konfiguracyjną naraz. Opcje konfiguracyjne Sybase mają wzajemny wpływ na siebie; niektóre z nich powodują zwiększenie zapotrzebowania na pamięć, inne wręcz przeciwnie. Wprowadzając za każdym razem tylko jedną zmianę, łatwiej jest spostrzec, która opcja powoduje problem z uruchamianiem serwera, dzięki czemu można szybko naprawić błąd. Po poprawieniu problemów należy wrócić do etapu 1.
Etap 13. — błąd podstawowego urządzenia master Jeśli serwer nie uruchamia się z powodu problemu z główną bazą danych, podczas próby uruchomienia pojawi się następujący komunikat: 00:2006/03/22 00:53:48.44 kernel 00:2006/03/22 00:53:48.44 kernel
kdconfig: unable to read primary master device kiconfig: read of config block failed
Podstawowe urządzenie master (primary master device) zawiera właśnie bazę danych master, a komunikat oznacza, że serwer danych (dataserver) nie może odczytać pliku głównej bazy. Należy sprawdzić uprawnienia dostępu do pliku dla użytkownika Sybase (jak również upewnić się, że serwer jest uruchamiany z poziomu użytkownika Sybase). Ścieżkę podstawowego urządzenia master można znaleźć, zaglądając do pliku run_FILE. Program dataserver wymaga podania ścieżki do tego urządzenia w ramach parametru -d. Jeśli problem nie polega na braku uprawnień dostępu do urządzenia, przyczyną kłopotów może być uszkodzenie bazy. To jest jeden z mniej prawdopodobnych scenariuszy, a jednocześnie jeden z najgorszych: serwer nie uruchomi się przy uszkodzeniu bazy danych master. Uszkodzenie tej bazy należy do sytuacji traktowanych w specjalny sposób w procedurach naprawy baz Sybase. W takim wypadku należy jak najszybciej skontaktować się ze wsparciem technicznym Sybase (jeśli firma ma odpowiednią umowę). Należy też skorzystać z dokumentacji online i zapoznać się z punktami dotyczącymi odtwarzania uszkodzonej bazy master z kopii zapasowych. Można tam znaleźć szczegółową instrukcję „krok po kroku”. Jednym z najważniejszych powodów niewykorzystywania bazy master do zapisu danych użytkownika jest wysoce krytyczne znaczenie tej bazy danych. W bazie master nie zapisuje się tabel transakcyjnych, dzięki czemu ta baza jest dość statyczna i powinna być jak najstabilniejsza. Baza master jest też z reguły bardzo małych rozmiarów. Dostępny online podręcznik Sybase Troubleshooting Guide zawiera opis procedury naprawczej bazy danych master. Procedura ta obejmuje w zasadzie odtworzenie bazy master z kopii zapasowej; alternatywnie sugeruje się utworzenie zupełnie pustej bazy Sybase i odtworzenie danych do niej. Pierwsza z tych procedur jest znacznie efektywniejsza, ponieważ nie wymaga odtwarzania danych użytkownika.
Etap 14. — awaria urządzenia dyskowego Jak już wspomniałem, awaria dysku to jeden z najbardziej powszechnych problemów, na jakie można natrafić. Należy w miarę możliwości stosować mechanizmy kopii lustrzanych dysków twardych (mirroring) na poziomie systemu operacyjnego (co jest preferowane) lub na poziomie bazy danych. Jeśli dziennik procesu dataserver zgłasza awarię jednego z lustrzanych dysków twardych, należy sprawdzić, czy problem nie występuje na poziomie systemu operacyjnego, 552
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
i naprawić ten problem, ewentualnie wymienić zepsuty dysk. Należy sprawdzić uprawnienia dostępu do urządzeń. Konto Sybase powinno mieć prawo odczytu i zapisu do wszystkich urządzeń dyskowych i surowych partycji wykorzystywanych przez bazę. Jeśli w dzienniku błędów jest wymieniona nazwa konkretnego pliku, należy sprawdzić uprawnienia dostępu do niego. Należy również sprawdzić, czy w dzienniku systemowym nie pojawiają się komunikaty o sprzętowych błędach urządzenia. Czasem z powodu zmiany w konfiguracji system operacyjny nie „widzi” urządzenia. Przyczyną problemów mogą być awarie sprzętowe lub błędy w konfiguracji. Aby sprawdzić rzeczywistą przyczynę problemów, należy sprawdzić status urządzenia i przejrzeć dzienniki błędów. Jeśli zepsuł się jedyny dysk, na którym zapisana była baza, nie mamy innego wyjścia, jak tylko odtworzyć przechowywaną przez niego bazę z kopii zapasowych. Do tego celu będą również niezbędne zapisane informacje konfiguracyjne.
Lista baz danych, które nie załadowały się W pierwszej kolejności będzie potrzebna lista uszkodzonych urządzeń. Komunikaty rozruchowe serwera wymieniają urządzenia, których nie udało się uruchomić. Znajdą się tam również nazwy baz danych, których nie udało się załadować. Listing 17.6 przedstawia przykład zapytania w języku T-SQL, wypisującego listę baz danych oraz urządzeń, na których są zapisane. Listing 17.6. Lokalizacja baz danych wykorzystujących określone urządzenie select sysdevices.name as DevName, sysdatabases.name as DBName, sysusages.size/512 as Size from sysdatabases, sysusages, sysdevices where sysdevices.name="BadDeviceName" and sysdevices.low <= sysusages.vstart and sysdevices.high >= sysusages.vstart and sysusages.dbid = sysdatabases.dbid
Przykładowy wynik tego zapytania: DevName BusDev1 BusDev1
DBName BillingDB ClientDB
Size 3 2
Sprawdzenie wolnego miejsca na dysku Jeśli zepsuje się urządzenie dyskowe o pojemności 32 GB, należy upewnić się, że serwer ma dostęp do co najmniej 32 GB wolnego miejsca na dysku. Miejsce to należy przydzielić serwerowi za pomocą procedury sp_helpdevice. Jeśli na dyskach nie ma odpowiedniej ilości wolnego miejsca, należy dołożyć dysk twardy i zainicjować go za pomocą polecenia disk init. Aby usunąć urządzenie bazy, należy zastosować procedurę sp_dropdevice. Jeśli na dysku jest wystarczająco wolnego miejsca, można pominąć ten etap. W przeciwnym razie będzie potrzebne urządzenie, które zastąpi uszkodzony dysk. Do tego służy polecenie disk init. Jeśli urządzeniem uszkodzonego dysku było /dev/dsk/c0t2dls0, posłużymy się poleceniem: disk init name="BusDev1," physname="/dev/dsk/c0t2d1s0," vdevno=6, size=2048
Procedura naprawcza dla baz Sybase
|
553
To polecenie przy zastosowaniu urządzenia /dev/dsk/clt3d0s1 będzie miało następującą postać: disk init name="BusDev1," physname="/dev/dsk/c1t3d0s1," vdevno=10, size=2048
Po utworzeniu urządzenia należy odtworzyć z kopii zapasowych wszystkie bazy, które były zapisane na uszkodzonym dysku.
Uzyskanie informacji niezbędnych do odtworzenia bazy W tym miejscu należy pozyskać informacje niezbędne do odtworzenia bazy. Polecenie przedstawione na listingu 17.7 wypisze alokacje plików wykorzystywanych przez wskazaną bazę danych. Listing 17.7. Alokacja baz danych select sysdevices.name, size as Blocks, size/512 as Mbytes from sysusages, sysdevices, sysdatabases where sysdatabases.name = "dbname" and sysusages.dbid = sysdatabases.dbid and sysdevices.low <= sysusages.vstart and sysdevices.high >= sysusages.vstart and sysdevices.cntrltype = 0 order by vstart Example Output: name Blocks devicel 1536 logdevl 1024 device3 2048
Mbytes 3 2 4
Do uzyskania niezbędnych poleceń SQL odtwarzających bazę danych można wykorzystać większość dostępnych narzędzi do zarządzania bazami danych. Należy wykazać się tu odrobiną umiejętności inżynierii wstecznej. Jeśli nie mamy dostępu do odpowiednich narzędzi, przydatna może okazać się procedura sp_revdb, dostępna na stronie http://www.edbarlow.com.
Usunięcie uszkodzonej bazy Jeśli baza ma błędy krytyczne, konieczne może okazać się jej usunięcie: $ drop database nazwa_bazy
W przypadku fizycznych uszkodzeń plików bazy to polecenie może zakończyć się niepowodzeniem. W takim przypadku należy usunąć bazę za pomocą polecenia dbcc: $ dbcc repairdb(dropdb, nazwa_bazy)
Aby sprawdzić, czy baza rzeczywiście została usunięta, można posłużyć się procedurą składowaną sp_helpdb.
Odtworzenie bazy danych Pliki bazy danych należy odtworzyć do tych samych alokacji, które zostały zastosowane poprzednio. Oto przykład wykorzystujący alokacje z powyższego przykładu: create database baddbname on device1 = 3 log on logdevl = 2 alter database baddbname on device3 = 4
554 |
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
Załadowanie bazy danych W tym momencie należy załadować dane do bazy, wykorzystując najświeższe kopie bazy i dzienników transakcyjnych. Po pierwsze, należy odtworzyć pełną kopię bazy. Oto przykład dla naszej przykładowej bazy danych, której kopia znajduje się w from /dumps/baddbname.dmp: $ load database baddbname from '/dumps/baddbname.dmp'
Po zakończeniu tego polecenia należy załadować wszystkie dzienniki transakcyjne, począwszy od najstarszego. System nie pozwoli załadować dzienników transakcyjnych w niewłaściwej kolejności. Jeśli okaże się, że jeden z dzienników został zagubiony lub uszkodzony, nie będzie możliwości odtworzenia żadnych nowszych transakcji. Kontynuując przykład — transakcje naszej odtwarzanej bazy załadujemy w następujący sposób: $ load transaction baddbname from '/dumps/baddbname_trn.dmp'
Więcej informacji na temat ładowania danych z kopii można znaleźć w podrozdziale „Odtwarzanie danych z kopii”.
Uruchomienie bazy System nie uruchomi bazy danych, nawet gdy zostanie w pełni odtworzona. System po prostu nie wie, czy zostały już odtworzone wszystkie dostępne pliki transakcyjne. W naszym przykładzie bazę danych uruchomimy za pomocą polecenia: online database baddbname
Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
Procedura naprawcza dla baz Sybase
|
555
556
|
Rozdz ał 17. Wykonywan e odtwarzan e kop serwera Sybase
ROZDZIAŁ 18.
Wykonywanie i odtwarzanie kopii zapasowych baz IBM DB2
IBM DB2® Universal Database™ (DB2 UDB) nie jest nowicjuszem na rynku systemów relacyjnych baz danych (relational database management system, RDBMS). Historia DB2 sięga momentu pojawienia się samej koncepcji systemu RDBMS, zaproponowanego w 1970 roku przez E.F. Cobba, pracownika IBM Research. Od tamtej pory firma IBM stworzyła całą rodzinę oprogramowania RDBMS, pod wspólną nazwą DB2 UDB. Baza DB2 na rynku pojawiła się w 1983 roku. Mechanizm zarządzający bazami danych w systemie OS/2®Extended Edition w 1987 roku był pierwszym rozproszonym systemem baz danych. DB2 UDB jest obecnie dostępny dla systemów: Linux, Unix (AIX, Solaris i HP-UX) oraz Windows. Narzędzia do wykonywania i odtwarzania baz danych dla poszczególnych systemów są praktycznie identyczne i można je uznać za niezależne od platformy systemowej. Przy tworzeniu tego rozdziału pomocą służyli mi: Jeff Richardson, Kondal Yennaram i Kulvir S. Bhogal. Jeff pracuje z DB2 od 24 lat i jest certyfikowanym administratorem DB2 UDB LUW, instruktorem sztuk walki, ogrodnikiem, a w wolnym czasie zajmuje się stolarką. Kondal pracuje dla firmy IBM jako Senior Software Specialist systemu DB2 UDB LUW. Kulvir Singh Bhogal pracuje jako konsultant WebSphere, implementując w całych Stanach Zjednoczonych strategie e-businessowe firmy IBM. Kulvir złożył ponad sto wniosków patentowych w U.S. Patent Office i ma przyznanych 14 patentów.
Wykonywanie i odtwarzanie kopii zapasowych były integralnymi elementami IBM DB2 UDB od samego początku istnienia tego systemu. DB2 UDB oferuje polecenia wykonywania i odtwarzania kopii zapasowych, narzędzia, kreatory i interfejsy programistyczne (API). Kopie zapasowe można wykonywać i odtwarzać w trybie offline („na zimno”, cold) oraz online („na gorąco”, hot), co pozwala uzyskać pełną dostępność danych. Kopie zapasowe mogą być wykonywane automatycznie. Jeśli DB2 stwierdzi, że nie trzeba wykonywać kopii, procedura jej wykonania nie zostanie uruchomiona. Ten rozdział omawia architekturę DB2 UDB na wysokim poziomie abstrakcji oraz jej elementy niezbędne administratorowi do wykonywania kopii zapasowych i ich odtwarzania. Zostaną również przedstawione przykłady wykonywania i odtwarzania kopii zapasowych. Szczegółowe informacje na temat architektury DB2 UDB i jej narzędzi można znaleźć w podręcznikach administratora DB2: Command Reference, Data Recovery and High Availability Guide and Reference i innych. Te dokumenty są dostępne do pobrania na stronie http://www.ibm.com/, można je też przejrzeć online pod adresem http://publib.boulder.ibm.com/infocenter/db2help/index.jsp. 557
Architektura DB2 DB2 UDB to system rozproszonych baz danych zaimplementowany w architekturze klientserwer. Klient DB2 UDB może być zainstalowany na osobnej maszynie fizycznej. Kod kliencki jest jednak domyślnie instalowany wraz z serwerem. Kody klienta i serwera są na serwerze odseparowane w osobnych przestrzeniach adresowych, to znaczy nie współdzielą pamięci fizycznej. Kod aplikacji działa w procesie klienckim, natomiast kod serwera działa w zupełnie niezależnych procesach. Niezależne jednostki pamięci alokowane są dla menedżerów bazy (egzemplarzy), baz danych i aplikacji.
Perspektywa zaawansowanego użytkownika Przed zapoznaniem się z materiałem tego rozdziału warto poznać kilka kluczowych pojęć, które powinny być znane zaawansowanym użytkownikom DB2.
Egzemplarze Zestaw procesów zarządzających danymi określa się w DB2 mianem egzemplarza (ang. instance). Każdy egzemplarz stanowi kompletne, niezależne środowisko oraz konfigurację zabezpieczeń niezależną od pozostałych egzemplarzy w tym samym systemie, obsługuje niezależne bazy danych i partycje, niedostępne dla pozostałych egzemplarzy. Egzemplarz kontroluje operacje wykonywane na danych i zarządza przydzielonymi mu zasobami. Zawiera wszystkie partycje baz danych określone dla danego systemu baz danych. Proces egzemplarza DB2 jest uruchamiany za pomocą polecenia db2start. Proces egzemplarza DB2 jest uruchamiany na serwerze i jest odpowiedzialny za udostępnianie określonej bazy danych. Przy uruchamianiu egzemplarza jest uruchamianych kilka procesów. Procesy te wzajemnie się komunikują i zajmują się utrzymaniem bazy danych i powiązanych aplikacji. Niektóre z tych procesów są uruchamiane od razu, inne — w zależności od potrzeb.
Bazy danych Każda baza danych DB2 jest kolekcją wzajemnie skorelowanych danych i każda zawiera zestaw tabel katalogowych opisujących logiczną i fizyczną strukturę obiektów w bazie. Inne aspekty struktury bazy danych są zdefiniowane w pliku konfiguracyjnym bazy danych oraz w dzienniku odtwarzania (ang. recovery log).
Schematy Schemat (ang. schema) to identyfikator określonego zbioru tabel i obiektów bazy danych. Nazwa schematu stanowi pierwszy człon w dwuczłonowym identyfikatorze obiektu. Na przykład tabela payroll w schemacie smith ma identyfikator smith.payroll.
Tabele Relacyjna baza danych porządkuje dane w formie kolekcji tabel. Dane w tabelach są uporządkowane w kolumnach i wierszach. Dane w jednej tabeli są podobnego typu (z logicznego punktu widzenia). Dane mogą zawierać powiązania, czego reprezentacją są związki między tabelami. 558 |
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Perspektywy Perspektywa stanowi odmienny sposób postrzegania danych jednej lub większej liczby tabel. Perspektywa to nazwana specyfikacja wyniku zapytania na tabelach (tabela wynikowa zapytania); zawiera kolumny i wiersze, tak samo jak tabela bazowa (czyli tabela utworzona za pomocą polecenia create table). W zakresie odczytu danych wszystkie perspektywy mogą być używane tak samo jak tabele bazowe.
Indeksy Indeks to zestaw kluczy wskazujących wiersze w tabeli. Indeksy przyspieszają dostęp do danych w przypadku wyboru podzbiorów wierszy w tabeli, tworząc ścieżkę dostępu do danych. DB2 SQL Optimizer to mechanizm wykorzystujący indeksy do określania najbardziej efektywnego (najszybszego) sposobu uzyskania dostępu do danych. DB2 SQL Optimizer jest jednym z elementów kompilatora języka SQL w DB2. Jego działanie polega na analizie statystyk danych (tworzonych za pomocą polecenia runstats) i wyborze planu dostępu do danych dla danego zapytania charakteryzującego się jak najmniejszym oszacowanym kosztem wykonania. Polecenie runstats powinno być wykonywane po wykonaniu poleceń: reorg, restore oraz recover.
Engine dispatch units Różne systemy operacyjne uruchamiają zadania, wątki lub procesy. W serwerze DB2 UDB działania serwera są realizowane przez engine dispatch units (EDU), zaimplementowane w formie procesów lub wątków. DB2 wykorzystuje termin EDU w celu zachowania spójnej nomenklatury niezależnie od platformy systemowej. Niektóre procesy DB2 działające w tle są uruchamiane na starcie egzemplarza, inne są uruchamiane na przykład w reakcji na nawiązanie połączenia z bazą. EDU bazy DB2 można zidentyfikować dzięki przedrostkowi db2 w nazwie, na przykład procesy o takich nazwach, jak db2gds, db2sysc czy db2wdog, są właśnie EDU bazy DB2.
Perspektywa administratora baz danych Administrator baz danych jest z reguły zainteresowany następującymi elementami architektury, które w większości dotyczą fizycznych elementów bazy danych.
Połączenie z bazą DB2 W celu rozpoczęcia pracy z bazą danych DB2 administrator musi uruchomić proces zarządcy bazy (database manager), po czym z bazą może połączyć się aplikacja lub sesja. Do połączenia z bazą należy wywołać następujące polecenie (użytkownik musi mieć uprawnienia konta sysadm lub sysctrl): % db2 connect to baza user login using hasło
Tabele katalogu systemowego Tabele katalogu systemowego opisują logiczną i fizyczną strukturę danych i zawierają informacje o uprawnieniach dostępu do obiektów bazy danych. Tabele katalogu są tworzone wraz z bazą danych i są modyfikowane w ramach operacji na tabelach. Nie można ich usunąć ani tworzyć niezależnie od baz danych, ale można wykonywać na nich zapytania.
Arch tektura DB2
|
559
Partycja bazy danych Partycja bazy danych jest częścią bazy danych zawierającą własne dane, indeksy, pliki konfiguracyjne i dzienniki transakcyjne. Baza podzielona na partycje to taka baza, która ma zdefiniowaną więcej niż jedną partycję. Tabele mogą być zapisywane w jednej lub większej liczbie partycji. Partycje bazy danych mogą być zapisane na pojedynczym serwerze fizycznym, w takim przypadku partycje określa się jako logiczne. Partycje baz danych mogą być ponadto obsługiwane przez różne maszyny (z tego powodu partycje w DB2 nazywa się również węzłami bazy, ang. database node). Grupa partycji bazy danych to zestaw złożony z jednej lub większej liczby partycji. Można stworzyć własną grupę partycji, można też wykorzystywać grupę domyślną. Domyślnie baza danych wykorzystuje pojedynczą partycję. Nawet pojedyncza partycja jest zapisana w ramach grupy partycji, choć dane bazy są zapisane tylko w jednej partycji. Baza danych podzielona na partycje (inaczej: klaster) wykorzystuje dwie lub więcej partycji. Również tabele mogą być zapisane w większej liczbie partycji. Gdy tabela jest podzielona na partycje, część jej wierszy jest zapisana w jednej, a część w innej partycji (lub partycjach). W pojedynczym systemie fizycznym można utworzyć większą liczbę partycji. Aby optymalnie wykorzystać możliwości sprzętowe systemu, przy podziale na partycje należy wziąć pod uwagę liczbę procesorów oraz ilość dostępnej pamięci RAM. Baza danych podzielona na partycje jest w terminologii DB2 nazywana klastrem (ang. cluster). W przypadku bazy podzielonej na partycje informacje o tym podziale są zapisane w pliku konfiguracyjnym węzła, db2nodes.cfg. Domyślną lokalizacją tego pliku jest /home//sqllib (Linux) lub \Program Files\IBM\SQLLIB\ (Windows). Każdy egzemplarz DB2 ma własny plik db2nodes.cfg. Gdy w egzemplarzu jest tworzona nowa baza danych, zostaje automatycznie podzielona na partycje zgodnie z definicją w pliku dblnodes.cjg. Domyślnie przy tworzeniu bazy danych są automatycznie tworzone następujące trzy grupy partycji: ibmcatgroup, ibmtempgroup i ibmdefaultgroup. Grupa partycji ibmcatgroup zawiera przestrzeń tabel katalogu DB2 (np. syscatspace). Ta grupa partycji zawiera tylko jedną partycję. Grupa partycji ibmtempgroup zawiera systemową przestrzeń tabel tymczasowych tablespace (np. tempspace1), a ibmdefaultgroup zawiera przestrzeń tabel użytkownika (np. userspace1). Grupy partycji ibmtempgroup i ibmdefaultgroup zawierają wszystkie domyślne partycje bazy. Aby wywołać polecenie na wszystkich partycjach bazy, można wykorzystać polecenie db2_all.
Polecenia służące do wykonywania i odtwarzania kopii zapasowych (opisane w dalszej części rozdziału) działają w trybie pojedynczej partycji, przez co bazy danych podzielone na partycje wymagają nieco uwagi przy wykonywaniu kopii. DB2 wymaga, aby kopia partycji katalogów (zawierająca tabele katalogu, czyli ta partycja, na której zostało wykonane polecenie create database) została wykonana przed kopiami pozostałych partycji. W tym celu należy wywołać polecenie: C:\> db2_all '<<+0< db2 backup db sample to backup_path'
560
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Ciąg znaków <<+0< spowoduje, że zostanie wykonana kopia zapasowa wyłącznie partycji zerowej. Po zakończeniu przetwarzania partycji katalogu można wykonać kopie zapasowe pozostałych partycji w trybie równoległym. Tego typu procedurę wywołuje się za pomocą następującego polecenia: C:\> db2_all '||<<-0< db2 backup db sample to backup_path'
Ciąg znaków ||<<-0< powoduje, że zostanie wykonana kopia zapasowa wszystkich partycji oprócz zerowej.
Kontenery Kontener to fizyczne urządzenie nośnika danych (ang. storage device). Kontener jest identyfikowany za pomocą ścieżki do katalogu, nazwy urządzenia lub nazwy pliku. Każdy kontener może należeć tylko do jednej przestrzeni tabel (które zostaną omówione w następnym podpunkcie). Aby sprawdzić przyporządkowanie kontenerów do przestrzeni tabel, należy wywołać następujące polecenie: C:\> db2 list tablespace containers for numer_przestrzeni_tabel
W tym przykładzie numer_przestrzeni_tabel to liczba reprezentująca jedną z przestrzeni tabel, którą można uzyskać w wyniku wykonania polecenia list tablespaces. Na przykład w celu sprawdzenia kontenerów dla przestrzeni tabel userspace1 (o identyfikatorze równym 2) należy wywołać następujące polecenie: C:\> db2 list tablespace containers for 2 Tablespace Containers for Tablespace 2 Container ID =0 Name = C:\DB2\NODE0000\SQL00002\SQLT0002.0 Type = Path
Przestrzenie nazw Baza danych jest podzielona na przestrzenie tabel (ang. tablespace), zapisane na jednym lub większej liczbie fizycznych urządzeń składowania przez określenie kontenerów na tych urządzeniach. Każda tabela w bazie DB2 jest przypisana do przestrzeni tabel i w każdej przestrzeni tabel może być zapisana większa liczba tabel. W zależności od projektu i typu przestrzeni tabel do tej przestrzeni tabel można przydzielić indeksy tabeli, jak również jej obiekty LOB (tekstowe, czyli CLOB, i binarne, czyli BLOB). Jeśli przestrzeń tabel zawiera większą liczbę kontenerów, DB2 rozdziela dane zapisywane w przestrzeni tabel równomiernie między wszystkimi kontenerami. Do zapisywania danych najczęściej wykorzystywanych tabel powszechnie używa się najszybszych kontenerów, a do zapisywania danych rzadziej odczytywanych tabel — wolniejszych. W DB23 przestrzenie tabel dzieli się na dwa typy: system managed spaces (SMS) i database managed spaces (DMS). Baza danych może wykorzystywać różne kombinacje przestrzeni tabel typu SMS i DMS. Każdy kontener przestrzeni SMS jest katalogiem zawierającym pliki, a kontener przestrzeni tabel DMS może być plikiem o ustalonym z góry rozmiarze lub fizycznym urządzeniem dyskowym. W praktyce przestrzenie tabel SMS są wykorzystywane w niewielkich i średnich bazach danych. Przestrzenie tabel DMS są trudniejsze w konfiguracji, ale dają większą elastyczność. Na przykład w przypadku przestrzeni tabel DMS kontener można dodać do przestrzeni tabel w trakcie pracy systemu, czego nie da się zrobić w przypadku przestrzeni Arch tektura DB2
|
561
tabel typu SMS. W przypadku przestrzeni tabel DMS dane, tabele, indeksy i obiekty LOB można przydzielić do osobnych przestrzeni tabel. W przypadku przestrzeni tabel SMS wszystkie dane tabel muszą być zapisane w przestrzeni tabel SMS. Przy tworzeniu pierwszej bazy danych są automatycznie tworzone trzy przestrzenie tabel: syscatspace, tempspace1 i userspace1. Przestrzeń tabel syscatspace zawiera informacje systemowe na temat obiektów zapisanych w bazie. Te informacje są zapisane w katalogu DB2. Przestrzeń tabel tempspace1 jest wykorzystywana przez DB2 do zapisu tabel tymczasowych na potrzeby operacji wymagających takiej postaci pośredniej, na przykład złączeń. Domyślnie tabela zostanie utworzona w przestrzeni userspace1 (o ile nie zostanie jawnie wskazana nazwa przestrzeni tabel). Informacja na temat tego, jakie przestrzenie tabel są wykorzystywane przez bazę danych, jest bardzo istotna. Jak to szczegółowo omówię za chwilę, przy włączeniu funkcji archiwizacji dzienników (ang. archive logging) kopie zapasowe można wykonywać na poziomie szczegółowości poszczególnych przestrzeni tabel. Aby uzyskać listę przestrzeni tabel bazy danych, należy wywołać następujące polecenie (przykład jest w wersji dla systemów Windows): C:\> db2 list tablespaces Tablespaces for Current Database Tablespace ID = 0 Name = SYSCATSPACE Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Tablespace ID = 1 Name = TEMPSPACE1 Type = System managed space Contents = System Temporary data State = 0x0000 Detailed explanation: Normal Tablespace ID = 2 Name = USERSPACE1 Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal
Obiekty LOB DB2 obsługuje dodatkowy typ przestrzeni tabel DMS o nazwie large tablespace, spotyka się też nazwę long tablespace, przeznaczoną specjalnie do zapisu obiektów o dużych rozmiarach (ang. large objects, LOB), binarnych, tekstowych lub graficznych. Dane typu LOB są uwzględniane w standardowych kopiach zapasowych.
Dzienniki transakcyjne W DB2 dzienniki transakcyjne przechowują zmiany wprowadzone w bazie danych, zawierają też informacje o tym, w jaki sposób zestawy zmian są grupowane w formie transakcji. Transakcje należy traktować jako zestawy instrukcji SQL wykonywanych jako pojedyncze (to znaczy atomowe) operacje. Dzienniki transakcyjne zawierają informacje o tym, w jaki sposób transakcje są zatwierdzane (ang. commit) lub wycofywane (ang. rollback). Dzienniki transakcyjne odgrywają kluczową rolę w procedurze odtwarzania bazy po zatrzymaniu awaryjnym (crash 562
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
recovery i rollforward recovery), co będzie szczegółowo omówione w podrozdziale „Typy odtwarzania”. DB2 wykorzystuje technikę znaną pod nazwą zapisu dziennika z wyprzedzeniem (write ahead logging), w której transakcje są zapisywane w dzienniku na bieżąco, zanim dane zostaną zapisane w bazie. Dzienniki transakcyjne mogą być zapisywane w plikach lub na surowych urządzeniach. Dzienniki transakcyjne dzieli się na podstawowe (primary) i drugorzędne (secondary). Podstawowe dzienniki transakcyjne są alokowane przy pierwszym połączeniu z bazą danych lub na etapie aktywacji bazy (za pomocą polecenia activate database). Liczba podstawowych plików dziennika jest określana w pliku konfiguracyjnym bazy danych. Podstawowe pliki dziennika są tworzone natychmiast, natomiast drugorzędne są tworzone dynamicznie w zależności od potrzeb. Drugorzędne pliki dziennika są tworzone w przypadku, gdy potrzeba więcej miejsca dla dzienników (np. gdy zostają zapełnione wszystkie dzienniki podstawowe i nie ma możliwości nadpisania żadnego z nich, ponieważ zawierają dane aktywnych transakcji). W takich przypadkach potrzeba zaalokowania dodatkowego miejsca dla dzienników jest zaspokajana przez utworzenie drugorzędnych plików dziennika. Liczbę drugorzędnych plików dziennika określa wartość parametru logsecond. Rozmiar pliku dziennika jest określony w parametrze logfilsiz w jednostkach stron o rozmiarze 4 kB. Jeśli zatem w pliku konfiguracyjnym zostanie ustawiony parametr logprimary o wartości 2 oraz parametr logfilsiz o wartości 300, baza danych będzie wykorzystywała dwa pliki dziennika o rozmiarze 300 stron po 4 kB. Jeśli dziennik zawiera informacje o transakcjach, które nie zostały zatwierdzone ani wycofane, lub zawiera informacje zatwierdzone, ale niezapisane w plikach danych, określa się go jako aktywny. Jeśli dziennik zawiera informacje zatwierdzone i zapisane w plikach danych (to znaczy transakcje te zostały utrwalone, ang. persisted) i pozostają one na tym samym dysku co dzienniki aktywne, określa się go jako dziennik archiwalny online. Jeśli taki dziennik został przeniesiony na inny dysk, określa się go jako dziennik archiwalny offline. Dzienniki archiwalne można przenieść z katalogu dzienników aktywnych do innej lokalizacji w sposób ręczny lub automatyczny, przez odpowiednie ustawienie parametru userexit (w DB2 UDB V8.1 i wersjach wcześniejszych) lub parametrów logarchmethl i logarchmeth2 (w DB2 UDB V8.2 i nowszych wersjach). Zastosowanie tych parametrów jest omówione w punkcie „Zarządzanie dziennikami”. Ścieżkę do plików bazy DB2 można odczytać z plików konfiguracyjnych bazy danych. Z tych plików można również uzyskać informacje o konfiguracji dzienników, jak liczba podstawowych dzienników (parametr logprimary) czy ich rozmiary (parametr logfilsiz). Aby odczytać wartości tych parametrów, wystarczy wywołać następujące polecenie: C:\> db2 get db cfg for sample | find /I "log"
W systemach Unix do odfiltrowania wartości można wykorzystać polecenie grep. Na przykład poniższe polecenie wyświetli parametry konfiguracyjne związane z lokalizacją plików dziennika (polecenie find systemu Windows zwraca zbliżony wynik): % db2 get db cfg for sample | grep -i log Number of primary logfiles (LOGPRIMARY) = 3 Number of secondary logfiles (LOGSECOND) = 2 Changed path to logfiles (NEWLOGPATH) = Path to logfiles = /home/db2inst1/NODE0000/SQL00002/ SQLOGDIR/ Overflow log path (OVERFLOWLOGPATH) = Mirror log path (MIRRORLOGPATH) =
Arch tektura DB2
|
563
Aby zminimalizować ryzyko uszkodzeń danych w wyniku awarii dysku twardego, dzienniki transakcyjne należy zapisywać na innym dysku fizycznym niż pliki danych.
Zarządzanie dziennikami W domyślnej konfiguracji każda nowo utworzona baza danych wykorzystuje technikę dzienników pierścieniowych (ang. circular logging). W tym przypadku po zapełnieniu dziennika zapis danych jest rozpoczynany od początku dziennika (w kółko, stąd nazwa), co powoduje nadpisanie wcześniejszych wpisów. Dane nie są jednak nadpisywane w przypadku, gdy dany dziennik jest niezbędny do odtworzenia danych po awarii. Taka sytuacja prowadzi do zapełnienia dziennika. Z tego powodu liczbę plików dziennika należy dobrać w taki sposób, aby uniknąć tego typu problemów, czyli tak, aby w każdej chwili był dostępny co najmniej jeden nieaktywny plik dziennika transakcyjnego. Dzienniki pierścieniowe nie pozwalają na odtwarzanie danych typu rollforward (co zostanie szczegółowo omówione w punkcie „Typy odtwarzania”). Załóżmy, że w chwili T0 wykonujemy kopię zapasową bazy danych. Baza uszkodziła się w chwili T1. Aby odtworzyć dane po tej awarii, odtwarzamy je z kopii wykonanej w chwili T0. Jeśli jest aktywna opcja dzienników pierścieniowych (co oznacza, że nie jest możliwe odtwarzanie typu rollforward), nie będzie możliwości odtworzenia danych, które zostały zapisane w bazie między chwilą T0 a T1. W terminologii DB2 dzienniki pierścieniowe pozwalają zatem jedynie na odtwarzanie typu crash i version (zobacz punkt „Typy odtwarzania”). Jeśli baza danych wykorzystuje dzienniki pierścieniowe, można wykonać jej kopię zapasową wyłącznie w trybie offline (gdy nikt nie jest do niej przyłączony). W przypadku tego typu dzienników kopię zapasową wykonuje się na całej bazie danych; nie ma możliwości wykonywania kopii na poziomie przestrzeni tabel. Jeśli zamierza się wykonywać odtwarzanie danych typu rollforward, należy przełączyć dzienniki transakcyjne w tryb archiwizacji dzienników (ang. archive logging). Gdy baza danych wykorzystuje ten typ dzienników, można wykonywać jej kopie zapasowe również w trybie online (oczywiście nic nie stoi na przeszkodzie, aby wykonywać kopie zapasowe offline). Oprócz możliwości wykonywania kopii bazy danych na poziomie całej bazy, archive logging pozwala na wykonywanie kopii zapasowych na poziomie przestrzeni tabel. Dzięki temu można wybrać przestrzeń tabel przeznaczoną do skopiowania (i odtworzenia), co pozwala na skonstruowanie precyzyjnej strategii kopii zapasowych, w której bardziej aktywne (częściej modyfikowane) przestrzenie tabel są zabezpieczane w kopii zapasowej częściej od mniej aktywnych (zmieniających się sporadycznie). Oprócz wykonywania kopii zapasowych na gorąco, archive logging pozwala na odtwarzanie kopii zapasowych do momentu wystąpienia błędu przez odtworzenie zatwierdzonych transakcji, przechowywanych w dzienniku transakcyjnym. Wracając do poprzedniego przykładu, załóżmy, że mamy kopię zapasową bazy wykonaną w chwili T0, a awaria bazy danych występuje w chwili T1. Aby odtworzyć dane, należy odtworzyć je z kopii zapasowej, dzięki czemu uzyskujemy stan bazy z chwili T0. Jeśli aktywna była archiwizacja dzienników, możemy odtworzyć zmiany od chwili T0 do T1. W dalszej części rozdziału Czytelnik przekona się, że nie jest jednak ograniczony do odtwarzania danych dokładnie do stanu z punktu T1 (ostatnia chwila zapisu dzienników). Istnieje bowiem możliwość odtworzenia danych do stanu z dowolnego momentu między T0 a T1.
564 |
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Istnieją dwa sposoby archiwizowania dzienników: zapisywanie dzienników w oryginalnej lokalizacji aż do momentu, gdy są potrzebne do odtworzenia danych, lub przenoszenie ich do osobnej lokalizacji, skąd zostaną odtworzone. Jeśli dzienniki mają pozostawać w oryginalnej lokalizacji, należy parametr logretain ustawić na wartość recovery. Można to zrobić za pomocą parametru logretain polecenia db2 update db. Poniższa sekwencja poleceń demonstruje sposób uaktywnienia tego parametru. Znajdziemy w niej również polecenie wykonujące kopię zapasową, ponieważ efektem ubocznym zmiany trybu zapisu dzienników na archive logging jest ustawienie bazy danych w trybie oczekiwania na kopię zapasową (ang. backup pending). % % % % % %
db2 update db cfg for sample using logretain on db2 force applications all db2 terminate db2stop db2 backup db sample db2start
Ustawienie parametru logretain na wartość recovery przynosi dodatkową komplikację, polegającą na tym, że dziennik transakcyjny przyrasta, co może doprowadzić do zapełnienia dysku twardego. Im większa aktywność bazy danych, tym szybciej będzie przyrastać rozmiar dzienników. Z tego powodu bardzo istotne jest, aby archiwalne pliki dzienników przenosić do innej lokalizacji (najlepiej fizycznie oddalonej od bazy danych), aby uniknąć zapełnienia dysku twardego. Jak już wspominałem, aby zapobiec skutkom awarii nośnika, pliki dziennika należy zapisywać na innym urządzeniu fizycznym niż pliki danych. W przypadku bardziej aktywnych baz danych należy rozważyć większą częstotliwość wykonywania kopii zapasowych online. Dzięki temu bazę danych można odtworzyć w większej części z kopii plików danych, zamiast odtwarzać ją z dzienników transakcyjnych, co jest znacznie bardziej czasochłonne. Alternatywą dla zachowywania plików dziennika w katalogu bazy danych jest przenoszenie ich do osobnej lokalizacji. W wersjach poprzedzających 8.2 można było zautomatyzować ten proces, ustawiając odpowiednią wartość parametru userexit. Od wersji 8.2 ten parametr został zastąpiony parametrami logarchmeth1 i logarchmeth2. W przypadku bazy DB2 8.2 lub nowszej wykorzystuje się parametry logarchmeth1 i logarchmeth2. Ich wykorzystanie jest znacznie łatwiejsze niż parametru userexit. Nazwa tych parametrów to skrót od określenia log archive method (metoda archiwizacji dzienników). Istnieje kilka sposobów ustawiania tych parametrów: Ustawienie logarchmeth1 na wartość userexit Na tę wartość można ustawić tylko parametr logarchmeth1, co stanowi odpowiednik ustawienia parametru userexit na wartość on. Po tym ustawieniu wartość userexit jest modyfikowana w sposób automatyczny. Ustawienie logarchmeth1 na wartość DISK Po ustawieniu parametru logarchmeth1 na wartość DISK:/ścieżka/katalog dzienniki archiwalne będą automatycznie kopiowane do wskazanego katalogu. Ta metoda jest znacznie prostsza w użyciu od samodzielnego tworzenia skryptu userexit, który w zasadzie wykonuje to samo zadanie. Ustawienie logarchmeth1 na wartość TSM lub VENDOR Te argumenty służą do przekazywania dzienników archiwalnych do komercyjnych produktów wykonujących kopie zapasowe. TSM to skrót od Tivoli Storage Manager.
Arch tektura DB2
|
565
Opcjonalne ustawienie wartości logarchmeth1 W przypadku ustawienia wartości logarchmeth1 można również ustawić wartość logarchmeth2. Jeśli zostaną ustawione obydwa te parametry, dzienniki archiwalne zostaną skopiowane dwukrotnie. Tę możliwość można wykorzystać do archiwizacji dzienników do katalogu na dysku i do użycia narzędzia TSM lub oprogramowania do wykonywania kopii zapasowych innego producenta. Użytkownicy wersji 8.1 i starszych lub zwolennicy własnych skryptów wykonujących kopie zapasowe mogą wykorzystywać skrypt userexit. W tym przypadku całą procedurą wykonania kopii dziennika archiwalnego zajmuje się program użytkownika (uerexit). Tego typu skrypty mają również zastosowanie przy odtwarzaniu danych z obrazu kopii zapasowej. Skrypt userexit jest również odpowiedzialny za odzyskiwanie kopii zapasowych offline na etapie odtwarzania danych z kopii. W systemach Unix skrypt userexit może być dowolnym programem wykonywalnym, na przykład skryptem powłoki lub skryptem w Perlu, może to też być skompilowany program binarny. Powinien nosić nazwę dbluextl (bez rozszerzenia) i powinien być zapisany w podkatalogu sqllib/bin w instalacji DB2. W Windows musi to być program skompilowany o nazwie db2uext2.exe i musi być on zapisany w sqllib\bin w instalacji DB2. Standardowo wraz z systemem DB2 jest dostarczanych kilka przykładowych programów userexit, umieszczonych w katalogu sqllib/samples/c. Jeśli planuje się wykorzystać parametr userexit, można ustawić go na wartość aktywną (on) za pomocą następującego polecenia (w wersji 8.1 i wcześniejszych): C:\> db2 update db cfg for sample using userexit on
W przypadku wersji 8.2 i nowszych należy zastosować następujące polecenie, które ustawia tę wartość na on w sposób automatyczny: C:\> db2 update db cfg for sample using logarchmeth1 userexit
Jeśli zostanie zmodyfikowana wartość parametru logretain, userexit, logarchmeth1 lub logarchmeth2, baza danych zostanie automatycznie ustawiona w trybie oczekiwania na wykonanie kopii zapasowej (ang. backup pending). W tym momencie przed dalszym użyciem bazy danych należy wykonać jej kopię zapasową (co jest opisane w dalszej części rozdziału).
Polecenia: backup, restore, rollforward i recover Aby odtworzyć bazę danych DB2 po poważnej awarii, należy opracować solidny plan wykonywania i odtwarzania kopii zapasowych. Taki plan buduje się na podstawie poleceń backup i restore, które umożliwiają kilka rodzajów odtwarzania.
Polecenie backup Polecenie backup bazy DB2 wykonuje kopię bazy danych lub przestrzeni tabel na jednym z urządzeń lub katalogów serwera z zainstalowaną bazą DB2.
566
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Aby wykonać polecenie, trzeba mieć uprawnienia konta bazy danych: sysadm, sysctrl lub sysmaint.
Jeśli została uaktywniona opcja archiwizacji dzienników transakcyjnych w bazie, której kopia zapasowa jest wykonywana, istnieje możliwość wykonania kopii zapasowej online (to znaczy istnieje możliwość wykonania kopii zapasowej bazy bez konieczności odłączania sesji użytkowników). Przy aktywnej opcji archiwizacji dzienników nie ma również konieczności wykonywania kopii całej bazy danych, można ją bowiem wykonać na poziomie przestrzeni tabel. Jeśli baza danych powinna mieć wysoki poziom dostępności i nie można pozwolić sobie na długotrwałe okresy przestoju z powodu wykonywania kopii zapasowych, należy poważnie rozważyć opcję kopii zapasowych online. Przy wykonywaniu kopii bazy danych wykorzystywane są następujące informacje: • nazwa lub alias kopiowanej bazy danych (wymagane); • nazwa urządzeń lub katalogów, w których będzie wykonana kopia; jeśli nie zostaną
podane, kopia zostanie wykonana w bieżącym katalogu na komputerze klienta;
• nazwa przestrzeni tabel, które mają być skopiowane (ma zastosowanie wyłącznie w przy-
padku uaktywnienia funkcji archiwizacji dziennika); • nazwa użytkownika i hasło wykorzystywane przy wykonywaniu kopii. • wskazanie, czy kopia ma się wykonać w trybie online czy offline. Tryb offline jest trybem
domyślnym. Tryb online jest dostępny wyłącznie wówczas, gdy została uaktywniona opcja archiwizacji dziennika. należy pamiętać, że po uaktywnieniu opcji logretain należy wykonać co najmniej jedną kopię zapasową offline, aby móc wykonywać kopie zapasowe online. Istnieje kilka przydatnych narzędzi, między innymi list applications i force applications all. Pierwsze polecenie generuje listę aplikacji przyłączonych do bazy danych, drugie zrywa połączenia wszystkich przyłączonych aplikacji. • typ kopii zapasowej (incremental lub delta; szczegóły w punkcie „Poziomy kopii zapaso-
wych” w dalszej części rozdziału); • poziom zrównoleglenia operacji, określający liczbę przestrzeni tabel, które DB2 będzie
kopiować jednocześnie. Domyślnie przyjęta jest wartość jeden. • kompresja kopii zapasowej, pozwalająca na oszczędność miejsca na urządzeniu kopii.
Oto przykładowe wywołanie kopii zapasowej: C:\> db2 backup db sample userid db2admin using password to c:\backup
To polecenie utworzy pełną kopię zapasową bazy danych o nazwie sample w katalogu c:\backup. Polecenie zostanie wykonane z poziomu konta db2admin z zastosowaniem hasła password. Jak już wspomniałem, zakłada się, że użytkownik db2admin ma uprawnienia: sysadm, sysctrl lub sysmaint. Kopia zapasowa zostanie wykonana w trybie offline (domyślny tryb). Tryb online można wymusić, stosując słowo kluczowe online po określeniu hasła (do tego niezbędne jest wcześniejsze uaktywnienie funkcji archiwizacji dziennika).
Polecen a: backup, restore, rollforward recover
|
567
Inny przykład: C:\> db2 backup db sample user db2admin using password tablespace(userspacel) online to c:\backup
To polecenie wykona kopię zapasową przestrzeni tabel userspace1 bazy danych sample, co demonstruje możliwość wykonywania kopii wybranych przestrzeni tabel. Taka możliwość jest szczególnie użyteczna w przypadku, gdy baza danych ma przestrzenie tabel, których zawartość zmienia się znacznie częściej od innych. Należy zauważyć, że w ten sposób nie można wykonywać kopii zapasowych przestrzeni tabel tymczasowych. Do dobrych praktyk należy wspólne wykonywanie kopii zapasowych wzajemnie powiązanych przestrzeni tabel. Zalicza się tu przestrzenie tabel zawierające tabele ze zdefiniowanymi związkami integralności. Innym przykładem powiązanych przestrzeni tabel jest przypadek zachowywania indeksów lub obiektów LOB w innej przestrzeni tabel niż zawierająca podstawowe dane tabeli. Wracając do przykładu: kopia zapasowa zostanie wykonana w trybie online, zatem zakłada się, że dla bazy sample aktywna jest funkcja archiwizacji dziennika. Po wywołaniu tego polecenia powinien pojawić się następujący komunikat, informujący o poprawnym wykonaniu operacji: Backup successful. The timestamp for this backup image is: 20061119181253.
Poziomy kopii zapasowych Kopia zapasowa może być wykonana na jednym z trzech poziomów: full (pełna), incremental (przyrostowa) lub delta (różnicowa). Pełna kopia zapasowa, jak wskazuje nazwa, zawiera wszystkie dane kopiowanej bazy danych lub przestrzeni tabel. Kopia przyrostowa (określana również jako kumulatywna) zawiera jedynie te dane, które zmieniły się od ostatniego prawidłowego wykonania pełnej kopii. Kopia różnicowa (delta) zawiera dane, które zmieniły się od wykonania dowolnej ostatniej prawidłowej kopii (niekoniecznie pełnej). Z tego powodu kopie przyrostowe i różnicowe do działania wymagają poprzednich kopii i nie mogą być użyte samodzielnie do odtworzenia danych bazy. Ta zależność od poprzednich kopii zapasowych sprawia, że trzeba przechowywać kilka poprzednich kopii, żeby zapewnić powodzenie operacji odtwarzania.
Ścieżka kopii zapasowej i konwencje nazewnictwa DB2 nazwy kopii zapasowych określa według ściśle ustalonej zasady. Znajomość tej zasady jest pomocna przy rozpoznawaniu szczegółów dotyczących kopii zapasowej. W ścieżce i nazwie pliku kopii można znaleźć następujące informacje: Alias bazy danych Alias bazy danych. Typ kopii 0 w przypadku pełnej kopii, 3 dla kopii przestrzeni tabel, 4 w przypadku kopii wierszy wykonanej za pomocą polecenia load. Egzemplarz UDB Nazwa egzemplarza UDB.
568 |
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Numer węzła bazy W przypadku bazy danych niepodzielonej na partycje jest to zawsze NODE0000. Numer węzła katalogu W przypadku bazy danych niepodzielonej na partycje jest to zawsze CATN0000. Znacznik czasu kopii Znacznik czasu zapisany jest w postaci rrrrmmdd\ggmmss, czyli jest to kolejno: rok (cztery cyfry), miesiąc (od 01 do 12), dzień (od 01 do 31), godzina (od 00 do 23), minuta (od 00 do 59) i sekunda (od 00 do 59). Numer kolejny Trzycyfrowy numer wykorzystywany jako rozszerzenie nazwy pliku kopii. W Windows ta konwencja nazewnictwa jest stosowana w elementach ścieżki i nazwy pliku. W systemach Unix — tylko w nazwie pliku. Na przykład w Windows stosowana jest następująca konwencja ścieżek i nazw plików kopii: alias_bazy.typ\nazwa_egzemplarza\NODEnnnn\CI\TNnnnn\rrrrmmdd\ggmmss.numer_kolejny
Oto przykładowa ścieżka i nazwa pliku kopii w systemie Windows: SAMPLE.0\DB2INST\NODE0000\CATN0000\20060227\145655.001
W systemach Linux i Unix nie stosuje się ścieżek, ale długie nazwy plików, w których zakodowane są wszystkie informacje: alias_bazy.type.nazwa_egzemplarza.NODEnnnn.CATtinnnn.znacznik_czasu.numer_kolejny
Ten sam plik co w powyższym przykładzie dla systemu Windows, w Linuksie i Uniksach będzie miał następującą nazwę: SAMPLE.0.DB2INST.NODE0000.CATN0000.20060227.145655.001
Nie warto lekceważyć niepełnych kopii Oprogramowanie do wykonywania kopii zapasowych, które stosowaliśmy w naszej firmie ubezpieczeniowej, wykonywało kilka niepełnych kopii zapasowych każdej nocy (niepełna kopia to taka, w której brakuje kilku plików). Takich przypadków było wiele, a administrator baz danych nie przejmował się specjalnie problemem. W przypadku bazy danych DB2 okresowo wykonywane były pełne kopie zapasowe, jak również kopie przyrostowe na podstawie tych pełnych kopii. Niestety, to właśnie te kopie przyrostowe sprawiały problem, co mogło spowodować poważne problemy z odtworzeniem bazy danych w przypadku awarii. Na szczęście w porę zorientowaliśmy się, przeprowadziliśmy pełne dochodzenie i usunęliśmy przyczynę usterki. O włos uniknęliśmy katastrofy. — Hywel Matthews
Analiza historii kopii zapasowych Operacje: backup, restore i rollforward wykonywane na bazie danych są odnotowywane w pliku historii o nazwie db2rhist.asc. Każda baza danych ma własny plik historii odtwarzania, znajdujący się w tym samym katalogu co pliki bazy.
Polecen a: backup, restore, rollforward recover
| 569
Polecenie list history pokazuje listę poleceń: backup, restore i rollforward, wykonanych na bazie danych. Na przykład w celu wyświetlenia listy operacji backup i restore na bazie sample należy wykonać następujące polecenie: C:\> db2 list history backup all for db sample
Raport wygenerowany przez to polecenie zawiera symbol informujący o typie operacji (B oznacza backup, R oznacza restore). Oto przykład wyniku tego polecenia db2 list history: List History File for sample Number of matching file entries = 1 Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ -------------B D 20060409190953001 F D S0000000.LOG S0000000.LOG ----------------------------------------------------------------------------
Jeśli operacja była typu B (wykonanie kopii), symbol w kolumnie Type określa jej typ: • F — kopia w trybie offline; • N — kopia w trybie online; • I — przyrostowa kopia w trybie offline; • O — przyrostowa kopia w trybie online; • D — kopia typu delta w trybie offline; • E — kopia typu delta w trybie online.
Raport historii kopii zapasowych informuje również o tym, które przestrzenie tabel zostały skopiowane i gdzie są zlokalizowane pliki kopii. Te informacje mogą okazać się bardzo użyteczne przy próbie odtworzenia kopii. Aby poznać listę operacji rollforward wykonywanych na bazie sample, należy wykonać następujące polecenie: C:\> db2 list history rollforward all for db sample
Ten raport w kolumnie Op zawiera symbol F, oznaczający właśnie operację rollforward. Kolumna Type informuje o tym, czy operacja rollforward była wykonywana do końca dzienników (symbol E) czy do wskazanego punktu w czasie (symbol P).
Automatyzacja utrzymania Baza danych DB2 zawiera elementy pozwalające na automatyzację operacji, między innymi wykonywania kopii zapasowych. Do tych elementów zalicza się parametry konfiguracyjne bazy, monitor bazy oraz kilka interfejsów GUI (między innymi Health Center, Web Health Center, Task Center i kreator Configure Automatic Maintenance). W przypadku zaawansowanych użytkowników można pominąć narzędzia GUI i skonfigurować automatyczne kopie zapasowe z poziomu narzędzi wiersza poleceń (command-line processor, CLP). Szczegóły na temat tych narzędzi można znaleźć w IBM DB2 Universal Database System Monitor Guide and Reference. W tym podrozdziale omówię narzędzia wysokiego poziomu. Monitor bazy danych DB2 (ang. health monitor) działa na serwerze bazy danych. To narzędzie oferuje funkcje niezbędne do wykonywania automatycznych kopii zapasowych bazy danych i innych funkcji utrzymania. Monitor bazy gromadzi informacje o systemie, wykorzystując wskaźniki stanu zdrowia. Wykorzystanie tych wskaźników nie wprowadza dodatkowego obciążenia bazy danych. 570
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Wskaźniki stanu zdrowia bazy są dostępne na poziomie egzemplarza silnika, bazy danych, przestrzeni tabel i pojemnika przestrzeni tabel. Administrator baz danych konfiguruje wskaźniki zdrowia, wykorzystując narzędzia: Health Center, Web Health Center, CLP lub biblioteki API. DB2 monitoruje te wskaźniki i może wywoływać określone działania w reakcji na przekroczenia wartości. Do tych działań zalicza się: • wysyłkę ostrzeżenia (e-mailem lub na pager) do administratora bazy o wystąpieniu poten-
cjalnego problemu; • wywołanie ustalonej procedury, takiej jak zwiększenie przestrzeni tabel lub określenie
dodatkowych ograniczeń; • zapis ostrzeżenia w dzienniku.
Wskaźniki stanu zdrowia dzieli się na cztery kategorie. Mierniki z ustalonym górnym progiem Ten typ wskaźników (ang. upperbounded threshold-based) występuje w postaci wartości bezwzględnej lub procentowej. Jeśli na przykład chcemy monitorować wykorzystanie przestrzeni tablic, możemy ustawić wysłanie ostrzeżenia po przekroczeniu poziomu 70 (procent), a wywołanie alarmu — po przekroczeniu wartości 90. W przypadku tych wskaźników można ustawić trzy stany: normalny (normal), ostrzegawczy (warning) i alarmowy (alarm). Mierniki z ustalonym dolnym progiem Ten typ wskaźników (ang. lowerbounded threshold-based) występuje w postaci wartości bezwzględnej lub procentowej. Aby monitorować poziom rzeczywistego wykorzystania pamięci zaalokowanej na potrzeby sortowania, można określić działanie w reakcji na osiągnięcie przez wskaźnik db.max_sort_shrmem_ut.il wartości poniżej 20 (procent). Wskaźniki stanu Ten typ wskaźników reprezentuje ograniczony zbiór stanów (najczęściej dwa, czasem więcej) obiektu. Jeden z tych stanów odpowiada sytuacji normalnej, pozostałe wskazują na sytuacje odchylenia od normy, co wymaga sprawdzenia. Na przykład wskaźnik stanowy db.db_backup_req jest wykorzystywany do określenia sytuacji, gdy wymagane jest wykonanie automatycznej kopii zapasowej bazy. Kolekcje stanu Te wskaźniki są miernikami na poziomie bazy danych i reprezentują zagregowany stan większej liczby obiektów w bazie. Kolekcje stanu mają stan normalny (normal) oraz wymagający zwrócenia uwagi (attention). Przykładami tego typu wskaźników mogą być db.tb_reorg_req (wymóg reorganizacji) i db.tb_runstats_req (wymóg ponownego zgromadzenia statystyk). Wskaźnik db.db_backup_req to stanowy wskaźnik na poziomie bazy danych. Ten wskaźnik informuje o tym, czy wymagane jest wykonanie kopii zapasowej bazy, na podstawie czasu, który upłynął od wykonania ostatniej pełnej kopii, oraz ilości zmodyfikowanych danych. Aby automatyczne kopie zapasowe były wykonywane, musi być ustawiony parametr konfiguracyjny auto_db_backup. Automatyczne kopie zapasowe można wykonywać w trybie offline (cold) lub online (hot). Wskaźniki db.tb_reorg_req i db.tb_runstats_req są ustawione natychmiast po odtworzeniu bazy danych. Zalecana procedura odtwarzania baz DB2 jest następująca:
Polecen a: backup, restore, rollforward recover
|
571
1. Odtworzyć bazę danych. 2. Wykonać reorganizację (reorg) tabel i indeksów. 3. Zgromadzić statystyki (runstats) tabel i indeksów. Stosowanie się do tej procedury pozwala zwiększyć wydajność działania aplikacji wykorzystujących bazę danych. Operacje reorg i runstats mogą być wykonane w trybie offline (cold) i online (hot) i nie wymagają odtworzenia bazy danych (pierwszego punktu powyższej procedury). Jednak w przypadku odtwarzania bazy danych wykonanie operacji reorg i runstats jest bardzo zalecane. Polityka wykonywania i odtwarzania kopii zapasowych powinna wymuszać regularne wykonywanie kopii zapasowych bazy. Polityka wykonywania kopii zapasowych baz danych DB2 jest określana w sposób automatyczny przy pierwszym uruchomieniu aplikacji DB2 Health Monitor. Mimo ustalenia automatycznej procedury wykonywania kopii zapasowych nadal możliwe jest ręczne wykonanie kopii. DB2 wykonuje automatyczne kopie zapasowe wyłącznie w sytuacji, gdy są niezbędne. Do wykonywania automatycznych kopii zapasowych (online i offline) określa się okna czasowe; służy do tego program DB2 Health Center. DB2 określa, czy trzeba wykonać kopię zapasową, stosując następujące kryteria: • nie została wykonana pełna kopia zapasowa bazy; • czas od wykonania ostatniej pełnej kopii zapasowej jest dłuższy od określonego; • przestrzeń dziennika transakcji jest wykorzystana na poziomie przekraczającym określony
pułap (tylko w trybie archiwizacji dziennika).
Czas między wykonaniem dwóch kolejnych kopii zapasowych, pułap wykorzystania dziennika transakcyjnego oraz nośnik kopii i jej typ (online lub offline) określa się za pomocą kreatora Configure Automatic Maintenance w programie Control Center lub Health Center. Automatyczną kopię zapasową bazy można wykonać zarówno w trybie online (hot), jak i offline (cold) wyłącznie w przypadku, gdy aktywny jest tryb odtwarzania rollforward (tryb archiwizacji dzienników), w przeciwnym razie dostępny jest tylko tryb wykonywania kopii offline. Automatyczne kopie zapasowe obsługują zapis kopii na dysku, taśmie, z użyciem Tivoli® Storage Manager (TSM) oraz na nośnikach określonych za pomocą bibliotek zainstalowanych przez dostawców oprogramowania do wykonywania kopii zapasowych. W przypadku wybrania opcji Backup to Disk funkcja automatycznej kopii zapasowej wykasuje zawartość katalogu określonego za pomocą kreatora Configure Automatic Maintenance. Automat gwarantuje zachowanie wyłącznie ostatniej kopii zapasowej. Z tego powodu wskazany katalog powinien być przeznaczony do wykonywania automatycznych kopii zapasowych i nie należy wykonywać w nim ręcznych kopii zapasowych. Wykonywanie w trybie offline kopii zapasowych, odtwarzania kopii oraz operacji reorg i runstats powoduje znaczne ograniczenie dostępu do bazy danych. Podobna sytuacja ma miejsce w przypadku wykonywanych w trybie online operacji reorg, jak również odtwarzania danych z kopii. Kopie zapasowe w trybie offline oraz reorganizacja tabel i indeksów są wykonywane w okresie wskazanym przez administratora. Rozpoczęte procedury będą działały aż do zakończenia, również w przypadku przekroczenia limitu czasu określonego długością okna. Wewnętrzny mechanizm zarządzający bazy DB2 z czasem gromadzi informacje o rzeczywistych czasach wykonania poszczególnych zadań. Jeśli podane okno czasowe jest za krótkie, dane 572
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
zadanie nie zostanie uruchomione następnym razem. Zamiast tego monitor stanu bazy poinformuje administratora o pominięciu zadania z powodu za krótkiego okna czasowego. Automatyczne kopie zapasowe reorg i runstats można zaplanować za pomocą DB2 Health Center. W tym celu należy:
1. Uruchomić Health Center: a. w systemach Linux i Unix zalogować się do konta egzemplarza DB2, uruchomić sesję terminala i uruchomić polecenie db2hc; b. w Windows wywołać funkcję Start/Programy/IBM DB2/Monitoring Tools/Health Center.
2. Rozwinąć ikonę egzemplarza w lewej ramce i kliknąć prawym przyciskiem myszy ikonę bazy danych. Dostępne są trzy opcje: Configure Health Monitor Settings (w której ustawia się pułapy mierników), Configure Automatic Maintenance i Manage Utilities.
3. Kliknąć Configure Automatic Maintenance. Pojawi się okno kreatora z sześcioma ekranami, których spis znajduje się w lewej ramce. Należy dwukrotnie kliknąć przycisk Next, aby przejść do okna Timing.
4. Ustawić okna czasowe dla zadań administracyjnych wykonywanych w trybie online i offline.
Każdy typ okna ma niezależny przycisk Change. Po kliknięciu jednego z nich można ustawić czas początku i końca, czas trwania oraz dni tygodnia dla danego okna czasowego. Po zakończeniu konfiguracji należy kliknąć przycisk Next.
5. Ustawić adres e-mail dla powiadomień. Na tym ekranie można również znaleźć funkcje przydatne w przypadku problemów z docieraniem powiadomień do adresatów.
6. Kliknąć Next, aby przejść do ekranu Activities, gdzie ustawia się opcje dla kopii zapaso-
wej oraz operacji reorg i runstats. Należy zaznaczyć myszą jedno z tych zadań, zaznaczyć opcję Automate, po czym kliknąć przycisk Configure Settings. W przypadku kopii zapasowych pojawi się okno Backup Database (BACKUP) z trzema kartami: Backup criteria (kryteria wykonania kopii), Backup location (lokalizacja kopii) i Backup mode (tryb kopii). Domyślny tryb to offline. Po kliknięciu przycisku Next w głównym oknie kreatora pojawi się ostatni ekran, Summary (podsumowanie). W tym oknie należy kliknąć przycisk Finish, co zatwierdzi konfigurację automatycznego zadania administracyjnego.
W głównym oknie programu Health Center pojawią się dwa wskaźniki stanu bazy: Database backup required (wymagane wykonanie kopii zapasowej bazy) oraz Update statistics required (wymagane wykonanie aktualizacji statystyk bazy). Należy upewnić się, że ustawienia automatycznego uruchomienia zadań są aktywne (w miejsce nazwa_bazy należy wpisać nazwę bazy, dla której będą uruchamiane automatyczne zadania): • W systemach Unix i Linux należy przejść do systemowego wiersza poleceń i wywołać
następujące polecenie: % db2 get db cfg for nazwa_bazy | grep -i auto_
• W systemach Windows należy uruchomić okno poleceń DB2 (Start/Programy/ IBM DB2/
¦Command Line Tools/Command Window) i wywołać następujące polecenie: C:\> db2 get db cfg for nazwa_bazy | find /I "auto_"
Jeśli parametry automatycznego wykonywania zadań są ustawione na wartość off, należy je uaktywnić, wywołując następujące polecenia (została przedstawiona wersja dla Windows, ale te polecenia działają na wszystkich platformach):
Polecen a: backup, restore, rollforward recover
|
573
C:\> C:\> C:\> C:\> C:\> C:\> C:\>
db2 db2 db2 db2 db2 db2 db2
connect to nazwa_bazy update db cfg using autojnaint on update db cfg using auto_db_backup on update db cfg using auto_tbl_maint on update db cfg using auto_runstats on update db cfg using auto_reorg on connect reset
Aby wymusić automatyczne wykonanie kopii zapasowej bazy (ustawić znacznik Database Backup Required Indicator), należy wywołać następujące polecenie: C:\> db2 backup db nazwa_bazy
W ten sposób wskazana baza została ustawiona w tryb wykonania automatycznych zadań. Informacje na temat ustawiania innych znaczników stanu zdrowia można znaleźć w podręczniku IBM DB2 Universal Database System Monitor Guide and Reference.
Wykorzystanie polecenia db2look Oprócz wykonywania kopii zapasowych warto wykonywać polecenie db2look i zapisywać jego wyniki na potrzeby późniejszej analizy. Program db2look wypisuje instrukcje niezbędne do odtworzenia obiektów bazy danych. Poniższe polecenie tworzy tego typu wynik i zapisuje je w ścieżce ścieżka/plik. db2look -d sample -a - m -1 -x -xd -f -o ścieżka/plik
Wynik zapisany w ścieżka/plik może być przydatny przy odtwarzaniu bazy DB2. Dobrym pomysłem jest uruchomienie tego polecenia natychmiast po utworzeniu bazy danych oraz po dokonaniu znaczących modyfikacji struktury bazy danych. Wynik tego polecenia należy zachować na potrzeby operacji odtwarzania.
Typy odtwarzania Przed omówieniem poleceń wykorzystywanych do odtwarzania baz DB2 z kopii należy zrozumieć różnice między typami odtwarzania. DB2 UDB wyróżnia następujące typy odtwarzania: • odtwarzanie po awarii, • odtwarzanie wersji, • odtwarzanie rollforward.
Odtwarzanie po awarii Odtwarzanie po awarii (ang. crash recovery) to procedura przywracania bazy do spójnego stanu po awarii programowej lub zaniku zasilania. Na szczęście odtwarzanie po awarii w DB2 to prosta procedura i nie ma konieczności wykonywania jakichkolwiek działań na bazie w celu przygotowania jej do tego typu odtwarzania. Jeśli administrator życzy sobie, aby baza danych nie uruchamiała się w sposób automatyczny po awarii, tylko oczekiwała na jego interwencję, należy wyłączyć funkcje automatycznego odtwarzania po awarii, ustawiając na wartość off parametr autorestart database configuration. W takim przypadku po awarii bazę danych należy uruchomić ręcznie za pomocą następującego polecenia: % db2 restart db sample
574
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Polecenie to nawiązuje połączenie z bazą danych. Do przywrócenia bazy do spójnego stanu wykorzystywane są dzienniki bazy danych. Wszystkie transakcje zmodyfikowane w bazie, a niezapisane na dysku, zostaną ponownie wprowadzone. Wszystkie wycofane transakcje również są wycofywane z bazy danych, podobnie jak transakcje, które w chwili awarii nie były jeszcze zatwierdzone. Na końcu procedury odtwarzania po awarii baza DB2 jest przywracana do spójnego stanu.
Odtwarzanie wersji Jeśli baza danych jest uszkodzona w stopniu uniemożliwiającym odtworzenie po awarii (na przykład w wyniku utraty pojemnika), należy odtworzyć ją z kopii zapasowej. Ta procedura przywraca bazę do poprzedniej wersji, stąd nazwa tego typu odtwarzania.
Odtwarzanie rollforward Odtwarzanie wersji przywraca bazę do stanu z chwili wykonania kopii zapasowej. Zmiany dokonane w bazie po wykonaniu tej kopii będą zatem utracone, chyba że przed wystąpieniem awarii (i przed wykonaniem kopii zapasowej) została uaktywniona opcja odtwarzania tego typu; wówczas po odtworzeniu wersji można wykonać odtwarzanie rollforward (zobacz punkt „Odtwarzanie transakcji” w dalszej części rozdziału). W praktyce odtwarzanie wersji zwykle wykonuje się w połączeniu z odtwarzaniem rollforward. W wersji DB2 8.2 zostało wprowadzone polecenie recover, które w sposób automatyczny odtwarza wersję w połączeniu z odtworzeniem rollforward.
Polecenie restore Odtwarzanie danych można wykonywać na poziomie całej bazy lub przestrzeni tabel. Należy zauważyć, że odtworzenie bazy danych musi być wykonywane w trybie offline, natomiast odtworzenie przestrzeni tabel (dla dowolnej przestrzeni tabel niezawierającej tabel katalogu systemowego) może być wykonywane w trybie online lub offline. Jak już wspomniałem, odtwarzanie przestrzeni tabel online jest bardziej zalecane w środowiskach korporacyjnych, w których kluczowa jest minimalizacja (a wręcz eliminacja) przestojów spowodowanych awarią bazy i odtwarzaniem jej danych. Aby wywołać polecenie restore dla istniejącej bazy danych, trzeba mieć uprawnienia konta sysadm, sysctrl lub sysmaint. Do wykonania odtworzenia przekierowanego (co będzie omówione w dalszej części rozdziału) konieczne będą uprawnienia sysadm lub sysctrl.
Z poleceniem restore stosuje się następujące informacje: • nazwa kopii zapasowej jako źródło odtworzenia (wymagane); • nazwy urządzeń lub ścieżki do katalogów, w których zapisane są kopie; • Jeśli na wskazanym urządzeniu kopii zapasowej zapisanych jest kilka kopii zapasowych,
można podać znacznik czasu, który wyznaczy wersję kopii zapasowej. Jak Czytelnik pamięta, znacznik czasu wchodzi w skład nazwy lub ścieżki do pliku kopii zapasowej.
Polecen a: backup, restore, rollforward recover
|
575
• parametr określający, czy odtworzenie ma nastąpić do bazy danych o innej nazwie niż
oryginalna nazwa kopiowanej bazy. Ten typ odtworzenia określa się jako przekierowany i będzie bardziej szczegółowo omówiony w dalszej części rozdziału. Jeśli w momencie odtwarzania w bazie danych była uaktywniona opcja archiwizacji dzienników, po zakończeniu odtwarzania baza jest ustawiona w trybie oczekiwania na operację rollforward (rollforward pending). Baza danych lub przestrzeń tabel znajdująca się w tym stanie nie może być użyta aż do momentu, gdy zostanie zastosowana operacja rollforward, co jest opisane w dalszej części rozdziału. Polecenie rollforward odzyskuje zatwierdzone transakcje wykonane na bazie po wykonaniu kopii zapasowej. Polecenie restore można wykonać z parametrem without rolling forward. W takim wypadku baza danych nadaje się do użytku natychmiast po zakończeniu działania polecenia restore. Należy jednak pamiętać o tym, że wszystkie transakcje zatwierdzone po wykonaniu kopii zapasowej zostaną utracone.
Polecenie rollforward Po odtworzeniu bazy danych za pomocą polecenia restore można uzupełnić jej dane o transakcje zapisane w dzienniku transakcyjnym. Służy do tego polecenie db2 rollforward. Polecenie to pozwala również przywrócić stan bazy do wskazanego punktu w czasie (między wykonaniem kopii zapasowej bazy a wykonaniem ostatniej transakcji). Aby wywołać polecenie rollforward na istniejącej bazie danych, trzeba mieć uprawnienia konta sysadm, sysctrl lub sysmaint. Aby wykonać odtworzenie przekierowane (co będzie omówione w dalszej części rozdziału), trzeba mieć uprawnienia konta sysadm lub sysctrl.
Polecenie recover W wersji DB2 8.2 zostało wprowadzone polecenie recover. To polecenie stanowi połączenie poleceń restore i rollforward, ponieważ bardzo często te polecenia są wykonywane w sekwencji. Jednak należy mieć świadomość pewnych ograniczeń tego polecenia: • może być użyte wyłącznie do wykonania obydwu operacji: restore i rollforward; • nie można go użyć do wykonania tylko operacji restore lub tylko operacji rollforward.
Jeśli istnieje potrzeba odtworzenia bazy bez wykonania operacji rollforward, należy zastosować polecenie restore;
• nie ma możliwości odtwarzania danych na poziomie przestrzeni tabel; • nie obsługuje odtwarzania z kopii przyrostowych; • polecenie recover nie obsługuje opcji: buffer, dlreport, without datalink, paralle-
lism i without prompting polecenia restore;
• polecenie recover nie pozwala określić wersji kopii zapasowej, a jedynie punkt w czasie,
z którego dane mają zostać odtworzone. Program automatycznie określa, którą kopię ma wykorzystać (należy pamiętać, że przy odtwarzaniu w punkcie czasu należy wykorzystać kopię zapasową wykonaną przed tym punktem, a następnie wykonać operację rollforward do tego punktu).
576
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
Aby wywołać polecenie recover na istniejącej bazie danych, trzeba mieć uprawnienia konta sysadm, sysctrl lub sysmaint. Aby wykonać odtworzenie przekierowane (co będzie omówione w dalszej części rozdziału), trzeba mieć uprawnienia konta sysadm lub sysctrl.
W przypadku polecenia recover stosuje się następującą składnię: C:\> db2 recover db nazwa_lub_alias_bazy
To wywołanie spowoduje automatyczne wykorzystanie najbardziej odpowiedniej kopii bazy danych z kopii uwzględnionych w pliku historii polecenia recovery (co zostanie omówione w następnym punkcie) i odtworzy bazę danych do ostatniej transakcji zapisanej w dzienniku transakcyjnym. Aby odtworzyć dane w punkcie czasu (zamiast do ostatniej transakcji zapisanej w dzienniku), należy zastosować następującą składnię wywołania: recover DB NAZWA_LUB ALIAS_BAZY TO punkt_w_czasie
Na przykład, aby odtworzyć dane do punktu w czasie 2006-04-10-00.16.52, posłużymy się następującym wywołaniem: C:\> db2 recover db sample to 2006-04-10-00.16.52
Punkt w czasie określa się w czasie lokalnym, nie UTC. W tym wywołaniu punkt w czasie musi być ujęty w bieżącym dzienniku transakcyjnym. Jeśli ma być zastosowany punkt w czasie wybiegający poza zakres transakcji zapisanych w dzienniku transakcyjnym, należy jawnie wskazać plik historii. Na przykład w przypadku, gdy dzienniki transakcyjne są zarchiwizowane w katalogu /home/user/archives/, zastosujemy następujące polecenie: C:\> db2 recover db sample to 2006-04-10-00.16.52 using history file (/home/user/archives/db2rhist.asc)
Odtwarzanie bazy danych Jak już wspomniałem, baza danych DB2 jest odtwarzana w dwóch etapach: pierwszy to odtworzenie wersji, to znaczy kopii zapasowej bazy, a drugi to odtworzenie rollforward, to znaczy odtworzenie transakcji od danej wersji do wskazanego punktu w czasie. W tym podrozdziale przeanalizujemy dwa scenariusze wykonywania odtwarzania wersji oraz zastosowania odtwarzania rollforward dla takiej odtworzonej bazy danych.
Odtwarzanie wersji w miejscu Jeśli baza danych jest odtwarzana do oryginalnej lokalizacji, takie odtworzenie nazywa się odtworzeniem w miejscu (ang. in-place), a gdy do innej, nazywamy je odtworzeniem z przekierowaniem (ang. redirected). Odtwarzanie z przekierowaniem jest omówione w następnym podrozdziale.
Etap 1. — zgromadzenie kopii zapasowych Aby odtworzyć bazę danych lub jedną z jej przestrzeni tabel, należy uzyskać dostęp do kopii zapasowych. To może zabrzmieć banalnie, ale w praktyce okazuje się dość skomplikowanym zadaniem, szczególnie w przypadku stosowania przyrostowych i różnicowych kopii zapasowych
Odtwarzan e bazy danych
|
577
(zobacz punkt „Poziomy kopii zapasowych”). W skrócie: musimy zgromadzić wszystkie kopie zapasowe, które mają wziąć udział w procedurze odtwarzania bazy lub przestrzeni tabel. Jeśli pliki zostały przeniesione na inną maszynę lub dysk, przed rozpoczęciem procedury odtwarzania należy je zgromadzić w jednym miejscu. Jeśli wystąpią problemy z ich odszukaniem, warto przejrzeć plik historii kopii zapasowych (zobacz punkt „Analiza historii kopii zapasowych”). W tym pliku można znaleźć informacje o plikach kopii zapasowych oraz ich lokalizacji na dysku. W miarę możliwości znalezione pliki należy zgromadzić w jednej lokalizacji. Załóżmy, że to będzie katalog C:\backups.
Etap 2. — upewnić się, że istnieją kontenery istniejące w trakcie wykonywania kopii Jeśli nie ma być wykonywane przekierowane odtworzenie bazy danych, czyli baza ma być odtworzona do swojej pierwotnej lokalizacji, należy upewnić się, że nadal istnieją kontenery bazy istniejące w chwili wykonywania kopii. W przypadku przenoszenia bazy danych na nową maszynę (po awarii starej) taka sytuacja z reguły nie ma miejsca. Jeśli kontenery przestrzeni tabel, które istniały w trakcie wykonywania kopii, już nie istnieją, podczas próby odtworzenia danych pojawi się błąd. Aby tego uniknąć, można zastosować przekierowane odtworzenie (co zostało opisane w dalszej części rozdziału).
Etap 3. — wywołać polecenie restore lub recover Nadszedł czas, aby wywołać polecenie odtworzenia bazy danych. W przypadku wersji wcześniejszej od 8.2 należy zastosować następującą składnię: C:\> restore DB nazwa_lub_alias_bazy from lokalizacja_kopii taken at rrrrmmddggmmss
Na przykład poniższe polecenie spowoduje odtworzenie bazy danych o nazwie sample z kopii identyfikowanej znacznikiem czasu 20060227145655: C:\> db2 restore db sample from c:\backups taken at 20060227145655 replace existing
Jak już wspomniałem, znacznik czasu kopii wchodzi w skład ścieżki lub nazwy pliku. Parametr replace existing informuje, że istniejące dane zostaną usunięte i zastąpione zawartością kopii. Na końcu wywołania można dodać klauzulę without rolling forward, która spowoduje, że transakcje wykonane po utworzeniu kopii zapasowej zostaną utracone, ale baza danych będzie aktywna od razu po zakończeniu działania polecenia restore. Z tego powodu należy rozważyć konsekwencje: zastosowanie wspomnianej klauzuli spowoduje szybsze przywrócenie bazy danych w tryb online, ale w większości przypadków będzie wiązać się z utratą części danych.
Można również odtworzyć przestrzeń tabel. Przestrzenie tabel mogą być odtwarzane w trybie online i offline (z wyjątkiem przestrzeni tabel zawierających tabele systemowe, które mogą być odtworzone wyłącznie w trybie offline). Przestrzenie tabel mogą być odtworzone z kopii zapasowych wykonanych na poziomie szczegółowości przestrzeni tabel. W celu odtworzenia przestrzeni tabel wykorzystuje się następującą składnię polecenia restore: restore database nazwa_lub_alias_bazy tablespace (nazwa_przestrzeni_tabel, nazwa_innej_przestrzeni_tabel,...) online from lokalizacja_kopii taken at rrrrmmddggmmss replace existing
Na przykład poniższe polecenie wykona odtworzenie przestrzeni tabel userspace1 bazy danych sample z kopii zapasowej identyfikowanej znacznikiem czasu 20060227145655, zapisanej w katalogu C:\backups. 578
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
C:\> db2 restore db sample tablespace(userspace1) online from c:\backups taken at 20060227145655 replace existing
W przypadku wersji 8.2 lub nowszej w celu odtworzenia całej bazy danych można wykorzystać polecenie recover: C:\> db2 recover db sample to punkt_w_czasie
To polecenie w automatyczny sposób wybierze odpowiednią kopię zapasową wykonaną przed wskazanym punktem czasu, odtworzy ją, a następnie wykona operację rollforward do tego punktu.
Etap 4. — odtworzenie transakcji (rollforward) Jeśli zostało wykorzystane polecenie recover (wersja 8.2 i nowsze), ten etap należy pominąć.
Jeśli przy wywołaniu polecenia restore nie została użyta opcja without rolling forward, baza danych będzie w stanie oczekiwania na rollforward. Odtwarzanie przestrzeni tabel zawsze pozostawia bazę w stanie oczekiwania na rollforward. Baza danych nie może być użyta do czasu, gdy zostanie wykonane polecenie rollforward. Szczegóły tej operacji można znaleźć w punkcie „Odtwarzanie transakcji” w dalszej części rozdziału.
Etap 5. — reorganizacja danych i zgromadzenie statystyk Ten etap został szczegółowo opisany w punkcie „Reorganizacja danych i gromadzenie statystyk” w dalszej części rozdziału.
Odtwarzanie bazy z przekierowaniem Ścieżki do plików bazy danych zapisane w kopii zapasowej są wykorzystywane przy odtwarzaniu bazy z tych kopii. Z tego powodu w przypadku odtwarzania bazy danych w systemie niemającym odpowiednich katalogów lub urządzeń pojawi się błąd. Aby tego uniknąć, należy zastosować technikę odtwarzania bazy z przekierowaniem. Procedura składa się z trzech etapów.
Etap 1. — odtworzenie kopii zapasowej z opcją redirect Załóżmy, że mamy prawidłową kopię zapasową bazy danych, którą chcemy odtworzyć. Wykorzystajmy wcześniejszy przykład z procedury odtwarzania, ale tym razem zastosujemy opcję redirect: C:\> db2 restore db sample from c:\backups taken at 20060227145655 redirect
Po zastosowaniu tej opcji DB2 automatycznie zatrzyma proces, dając użytkownikowi możliwość wskazania kontenerów, w których będą zapisane przestrzenie tabel. Polecenie recover nie obsługuje możliwości odtwarzania z przekierowaniem, zatem konieczne jest osobne wywoływanie poleceń restore i rollforward.
Odtwarzan e bazy danych
|
579
Etap 2. — określenie odpowiednich kontenerów na potrzeby docelowej bazy danych W tym momencie należy określić kontenery właściwe dla przestrzeni tabel odtwarzanej bazy danych. Zasadnicze pytanie brzmi: skąd uzyskać informacje na temat wymaganych kontenerów przestrzeni tabel? W tym miejscu przyda się polecenie list tablespaces show detail lub list tablespace containers for numer_przestrzeni_tabel, gdzie numer_przestrzeni_ ¦tabel to liczba całkowita reprezentująca przestrzeń tabel (tę informację można uzyskać za pomocą polecenia list tablespaces). Oczywiście informacji o kontenerach przestrzeni tabel nie uda się uzyskać w przypadku awarii źródłowej bazy danych. Z tego powodu informacje o przestrzeniach tabel bazy źródłowej należy uzyskać w ramach działań administratora w okresie jej sprawności i zachować na wypadek odtwarzania z przekierowaniem. Te informacje można uzyskać za pomocą polecenia db2look (o czym pisałem w punkcie „Wykorzystanie polecenia db2look”). Następnie należy utworzyć kontenery przestrzeni tabel związane z kopią bazy danych. Na przykład poniższe polecenia utworzą nowe kontenery dla przestrzeni tabel: syscatspace, tempspace1 i userspace1. W tym przypadku wykorzystamy względne ścieżki do katalogów (w stosunku do głównych plików bazy danych): C:\> db2 "set tablespace containers for 0 using (path 'tbsp0cont1')" C:\> db2 "set tablespace containers for 1 using (path 'tbsp1cont1')" C:\> db2 "set tablespace containers for 2 using (path 'tbsp2cont1')"
Etap 3. — kontynuacja odtwarzania bazy z przekierowaniem W etapie 1. odtwarzanie kopii zapasowej zostało zatrzymane dzięki zastosowaniu opcji redirect. Po utworzeniu kontenerów w etapie 2. możemy kontynuować odtwarzanie, wywołując następujące polecenie: C:\> db2 restore db sample continue
Etap 4. — odtworzenie transakcji (rollforward) Podobnie jak w przypadku zwykłego odtwarzania, przy odtwarzaniu z przekierowaniem istnieje możliwość odzyskania danych zapisanych w dzienniku transakcji. W tym celu należy wykonać polecenie rollforward, co zostało opisane w punkcie „Odtwarzanie transakcji”.
Etap 5. — reorganizacja danych i gromadzenie statystyk Ten etap jest szczegółowo omówiony w punkcie „Reorganizacja danych i gromadzenie statystyk” w dalszej części rozdziału.
Odtwarzanie transakcji Jeśli do odtwarzania danych zostało użyte polecenie recover, można pominąć ten punkt, ponieważ to polecenie automatycznie wykonuje odtwarzanie transakcji z dzienników.
Jak już wspomniałem, polecenie restore przywraca dane bazy do stanu z chwili wykonania kopii zapasowej (wykonania polecenia backup). Istnieje bardzo duże prawdopodobieństwo, że od momentu wykonania kopii do wystąpienia awarii w bazie wystąpiły pewne zmiany, 580 |
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
i w przypadku odtworzenia z kopii należy te zmiany uwzględnić. W przypadku gdy została uaktywniona opcja archiwizacji dzienników, po odtworzeniu bazy danych (lub przestrzeni tabel) baza jest ustawiana w trybie oczekiwania na operację rollforward (ang. rollforward pending). Baza danych lub przestrzeń tabel znajdująca się w tym stanie nie może być użyta aż do momentu wykonania na niej polecenia rollforward. Polecenie rollforward w DB2 wykorzystuje dzienniki transakcyjne do odzyskania danych, które zmieniły się w bazie lub przestrzeni tabel od chwili wykonania kopii zapasowej do chwili wystąpienia awarii lub do wskazanego punktu w czasie. Ten punkt w czasie to dowolna chwila od wykonania kopii zapasowej do końca zapisu w dziennikach archiwalnych. Jednakże istnieje wymóg minimalnej wartości punktu w czasie (ang. minimum point in time) dla przestrzeni tabel. To minimum jest określone jako wymóg spójności danych i dziennika transakcyjnego z katalogami systemowymi. Aby zilustrować tę zasadę, załóżmy, że mamy przestrzeń tabel pod nazwą userspace1, której kopia zapasowa została wykonana w czasie T0. W czasie T1 w przestrzeni tabel userspace1 została utworzona nowa tabela. To zdarzenie ustawia minimalną wartość punktu w czasie na T1, ponieważ między T0 a T1 katalogi systemowe nie będą zgodne z operacją rollforward, gdyż nowo utworzona tabela nie była w niej uwzględniona (w punkcie czasu między T0 a T1 nie powinna istnieć). Z tego powodu w celu uniknięcia tego typu niespójności Db2 nie pozwala odtwarzać danych z transakcji w punkcie czasu wcześniejszym od minimalnego. W powyższym przykładzie minimalny punkt w czasie dla operacji rollforward został ustawiony przez utworzenie nowej tabeli. Również inne zdarzenia mogą mieć wpływ na ustawienie tego parametru. Do tej kategorii zalicza się każda operacja typu DDL wykonana na przestrzeni tabel. W związku z tym warto znać minimalną wartość punktu w czasie. Umożliwia to polecenie list tablespaces show detail, na przykład: C:\> db2 connect to sample C:\> db2 create table test like staff in userspace1 C:\> db2 list tablespaces show detail
Informacja na temat przestrzeni tabel userspace1 będzie następująca: Tablespace ID Name Type Contents State Detailed explanation: Normal Total pages Useable pages Used pages Free pages High water mark (pages) Page size (bytes) Extent size (pages) Prefetch size (pages) Number of containers Minimum recovery time
= = = = = = = = = = = = = = =
2 USERSPACE1 System managed space Any data 0x0000 408 408 408 Not applicable Not applicable 4096 32 32 1 2006-03-01-13.23.19.232911
Po wykonaniu operacji rollforward do bazy zostaną odtworzone wszystkie zatwierdzone transakcje zapisane w dzienniku. Niekompletne (a przez to niezatwierdzone) transakcje zostają wycofane (rollback). Na końcu odtwarzania transakcji baza danych znajdzie się w spójnym stanie i będzie gotowa do wykorzystania przez aplikacje.
Odtwarzan e bazy danych
|
581
Jak się można domyślić, do prawidłowego działania operacji rollforward konieczne są dzienniki transakcyjne w nienaruszonym stanie. Dlatego do zapisu tych dzienników warto stosować macierze RAID lub inne urządzenia zapewniające wysoki poziom odporności na uszkodzenia danych. Do wykonania operacji rollforward konieczne są uprawnienia konta sysadm, sysctrl lub sysmaint.
Podobnie jak w przypadku polecenia restore, polecenie rollforward może być wykorzystane na poziomie bazy danych wyłącznie w trybie offline. Polecenie rollforward w trybie online może być wykonane wyłącznie na poziomie przestrzeni tabel. Podobnie jak restore polecenie rollforward w trybie online nie może być wykonane na przestrzeni tabel systemowych (syscatspace). Ta przestrzeń tabel musi być traktowana w sposób szczególny; przede wszystkim w jej przypadku dzienniki transakcyjne muszą być odtwarzane w całości (do końca), nie do wybranego punktu pośredniego. Po zakończeniu odtwarzania transakcji w punkcie czasu DB2 ustawia bazę w trybie oczekiwania na kopię zapasową (ang. backup pending). Aby wykorzystać bazę danych, należy w pierwszej kolejności wykonać jej kopię zapasową.
Poniżej opisuję procedurę odtwarzania transakcji bazy danych lub przestrzeni tabel.
Etap 1. — zgromadzenie dzienników transakcyjnych Aby operacja rollforward zadziałała prawidłowo, należy zgromadzić wszystkie dzienniki transakcyjne. Polecenie rollforward wymaga, aby dzienniki transakcyjne znajdowały się w katalogu dzienników wskazanym w parametrze konfiguracyjnym logpath. Alternatywnie w wywołaniu można wskazać katalog archiwum dzienników (ang. overflow log path), to znaczy katalog, w którym zapisywane są nieaktywne dzienniki transakcyjne (kopiowane w starszych wersjach DB2 przez mechanizm user exit, a od wersji 8.2 — za pomocą parametru logarchmeth1). Jeśli odtwarzanie danych odbywa się w następstwie uszkodzenia dysku, kopie dziennika należy skopiować do katalogu archiwum dzienników, aby operacja rollforward mogła je odczytać.
Etap 2. — określenie minimalnego punktu w czasie Jeśli transakcje mają być odtworzone do wskazanego punktu w czasie, a nie do końca dzienników, należy określić minimalny punkt w czasie. Służy do tego następujące polecenie: C:\> db2 list tablespaces show detail
Etap 3. — wywołanie polecenia rollforward W celu zobrazowania różnych form wywołania polecenia rollforward omówię kilka przykładów. C:\> db2 rollforward db sample user db2admin using password to 2006-03-01-13.23.19.232911 and stop
582
|
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
To polecenie wykonuje operację rollforward dla bazy sample do wskazanego punktu w czasie, z poziomu konta db2admin, z użyciem hasła password. Zastosowany znacznik czasu 2006-0301-13.23.19.232911 określa punkt w czasie określający koniec odtwarzania transakcji. Tę formę odtwarzania stosuje się wówczas, gdy w wyniku błędu do bazy danych zostały wprowadzone niepożądane modyfikacje. Klauzula and stop na końcu polecenia informuje DB2 o tym, że po zakończeniu operacji rollforward operacja zostanie zakończona, zatem może zostać wykonana. Aby odtworzyć transakcje do końca dziennika, należy wywołać następujące polecenie: C:\> db2 rollforward db sample user db2admin using password to end of logs and stop
Jak łatwo zauważyć, nie użyliśmy parametru online. Powodem jest to, że operacji rollforward nie można wykonywać w trybie online na poziomie bazy danych. Można jednak wykonać ją na poziomie przestrzeni tabel, co demonstruje następujący przykład: C:\> db2 rollforward db sample user db2admin using password to end of logs and stop tablespace(userspace1) online
To polecenie wykonuje operację rollforward dla przestrzeni tabel userspace1. Polecenie to jest wywoływane w następstwie polecenia restore dla przestrzeni tabel userspace1. Operacja jest wykonywana z poziomu konta db2admin z użyciem hasła password. W przypadku systemowej przestrzeni tabel (syscatspace) operacja nie może być wykonana w trybie online. Klauzula and stop na końcu polecenia informuje DB2, że po zakończeniu operacji przestrzeń tabel ma być ustawiona w trybie do użytku.
Etap 4. — uwzględnienie ograniczeń (w miarę potrzeby) Szczególną uwagę należy zachować przy wykonywaniu operacji rollforward na przestrzeniach tabel zawierających tabele, w których są zdefiniowane związki z tabelami zapisanymi w innych przestrzeniach tabel. Przy wykonywaniu operacji rollforward na tego typu przestrzeni tabel DB2 ustawia tabelę w stanie oczekiwania na sprawdzenie (ang. check pending). Tabela w takim stanie nie może być użyta aż do momentu wykonania sprawdzenia zależności. Stan tabeli można zmienić ze stanu oczekiwania na sprawdzenie do zwykłego stanu przez wykonanie polecenia set constraints. Przy wywołaniu polecenia set constraints warto wskazać tabelę wyjątków, w której będą zapisywane wiersze niespełniające ograniczeń. Poniższe polecenie zdejmuje stan oczekiwania na sprawdzenie z tabeli test. Jednak zanim tak się stanie, zawartość tej tabeli jest sprawdzana pod kątem określonych dla niej ograniczeń. Wszystkie wiersze niespełniające tych ograniczeń są przenoszone do tabeli badtest. Na końcu operacji tabela jest ustawiana w zwykłym stanie. Dalsze modyfikacje zawartości tabeli będą podlegały tym ograniczeniom. C:\> db2 set constraints for test immediate checked for exception in test use badtest
Etap 5. — wykonanie kopii zapasowej bazy (o ile to konieczne) Jeśli została wykonana operacja rollforward na poziomie przestrzeni tabel (etap 3.), przestrzeń tabel będzie w stanie oczekiwania na wykonanie kopii zapasowej. Aby ustawić przestrzeń w zwykłym trybie pracy, należy wykonać jej kopię zapasową.
Etap 6. — reorganizacja danych i zgromadzenie statystyk Ten etap jest omówiony w następnym punkcie.
Odtwarzan e bazy danych
| 583
Reorganizacja danych i gromadzenie statystyk Po odtworzeniu bazy z kopii zapasowej należy wykonać reorganizację danych. Poniższy przykład wykonuje tę operację w trybie online, co pozwala na dostęp do bazy z poziomu innych aplikacji: C:\> db2 connect to sample C:\> db2 reorgchk update statistics on table all > reorgchk.txt
Polecenie reorgchk wywołuje polecenie runstats, które gromadzi nowy zestaw statystyk bazy danych. Polecenie to zwraca bardzo dużo informacji, dlatego jego wynik warto zapisać w pliku, co może przydać się do dalszych analiz. Ostatnie pole wyniku polecenia reorgchk identyfikuje tabele, które muszą zostać zreorganizowane. Te tabele są oznaczone znakiem gwiazdki w jednej z kolumn. Weźmy poniższy przykład wywołania polecenia reorgchk. Tabela department nie wymaga reorganizacji. Jednak reorganizacja jest wskazana w przypadku tabeli employee. SCHEMA NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG ------------------------------------------------------------------------------Table: ADMINISTRATOR.DEPARTMENT ADMINIST> DEPARTMENT 9 0 1 1 549 0 - 100 --Table: ADMINISTRATOR.EMPLOYEE ADMINIST> EMPLOYEE 32 0 2 2 2784 0 69 100 -*-
Reorganizację tabeli employee można wykonać za pomocą poniższych poleceń (operacja będzie wykonana w trybie online). Należy zwrócić uwagę na to, że polecenie runstats wymaga pełnej definicji tabeli, z uwzględnieniem nazwy schematu. C:\> db2 reorg table employee allow read access C:\> db2 runstats on table administrator.employee allow write access
Mam nadzieję, że ten rozdział o wykonywaniu i odtwarzaniu kopii zapasowych w bazach DB2 okaże się pomocny. Wszyscy zainteresowani tą tematyką powinni zapoznać się z podręcznikami bazy DB2, szczególnie z pozycją Data Recovery and High Availability Guide and Reference. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
584 |
Rozdz ał 18. Wykonywan e odtwarzan e kop zapasowych baz BM DB2
ROZDZIAŁ 19.
Microsoft SQL Server
Microsoft SQL Server to z pewnością najpopularniejsza baza danych dla systemów operacyjnych Windows. Ten produkt powstał w 1989 roku jako wspólny projekt firm: Microsoft, Sybase i Ashton-Tate. W zasadzie była to adaptacja serwera baz danych Sybase z systemów Unix do platformy OS/2. Microsoft SQL Server 4.2, pierwsza wersja dla systemów Windows, został udostępniony w 1992 roku. Ten rozdział powstał przy współpracy ze Scottem Harrisem. Scott to nowo upieczony ojciec, który zastanawia się, ile lat powinien skończyć jego syn, zanim zacznie uczyć się programowania w Perlu.
Współpraca między firmami Sybase i Microsoft zaczęła się załamywać wskutek różnic opinii na temat kodu dla systemu NT. Microsoft, ze zrozumiałych powodów, naciskał, aby kod zoptymalizować pod system NT, natomiast Sybase, z równie zrozumiałych powodów, upierała się przy utrzymaniu kodu w jak najbardziej uniwersalnej postaci. Produkt o nazwie SQL Server jest obecnie rozwijany w całości przez firmę Microsoft i całkowicie różni się od produktu firmy Sybase dla systemów Windows (aby uniknąć problemów z identyfikacją, firma Sybase zmieniła nazwę swojego produktu na Sybase Adaptive Server). Do najważniejszych wydań aplikacji Microsoft SQL Server należą SQL Server 7.0, pierwsza baza danych obsługiwana w całości za pomocą interfejsu GUI, oraz SQL Server 2000, pierwsza baza danych napisana z myślą o architekturze Intel IA64. Kod źródłowy programu Microsoft SQL Server zmienił się znacząco w stosunku do „oryginału” firmy Sybase. Mimo tego od kilkunastu lat w licencji tego programu znajdują się odwołania do własności intelektualnej firmy Sybase. Niektóre koncepcje, jak baza danych master czy polecenie dump database, mogą administratorom baz Sybase wydać się niezwykle znajome. Microsoft SQL Server 2005, najświeższe wydanie tego produktu (w okresie powstawania książki), stanowi kolejny, znaczący krok naprzód w porównaniu z produktami oferującymi jedynie silnik bazy danych. Microsoft SQL Server 2005 oferuje bowiem bogactwo dodatkowych funkcji, jak usługi do analiz, integracji danych, powiadamiania. Jedną z funkcji jest mechanizm brokera usług (ang. service broker). Te wszystkie elementy stanowią w sumie kompletny relacyjny system baz danych, którego można użyć do prostych zadań, jak aplikacje WWW, jak również do bardzo zaawansowanych, jak: data mining, skomplikowane systemy gromadzenia informacji biznesowych, specjalizowane mechanizmy do raportowania i powiadamiania.
585
Odwołując się do określonych wersji, będę po prostu posługiwał się ich numerami, na przykład 2000 odnosi się do produktu Microsoft SQL Server 2000, a 2005 odnosi się do Microsoft SQL Server 2005. Gdy uwaga dotyczy obydwu tych wersji, będę po prostu posługiwał się określeniem SQL Server.
Ogólne informacje o Microsoft SQL Server Jak większość skomplikowanych aplikacji SQL Server jest oferowany w kilku konfiguracjach. W zależności od potrzeb organizacji można dobrać odpowiednią wersję bez zawyżania kosztów i instalowania zbędnych komponentów. Microsoft SQL Server 2005 jest oferowany w czterech podstawowych wersjach i dwóch specjalizowanych, co daje sześć konfiguracji do wyboru. Mamy do dyspozycji edycję dla grup roboczych, standardową, korporacyjną (ang. enterprise), deweloperską, mobilną oraz tzw. express. Więcej informacji na temat poszczególnych wersji można znaleźć w dokumentacji firmy Microsoft.
Połączenie z SQL Serverem oraz administracja Serwerem Microsoft SQL Server 2005 można administrować z poziomu GUI oraz z wiersza poleceń. Wersjami do 2000 administruje się za pomocą aplikacji Enterprise Manager, w wersji 2005 do zarządzania służy SQL Server Management Studio (SSMS). To narzędzie łączy w sobie cechy kilku osobnych programów dostępnych w poprzednich wersjach, jak Query Analyzer czy Analysis Manger. Zwolennicy wiersza poleceń w wersji 2005 znajdą też coś dla siebie: program SQLCMD.EXE. To narzędzie zastępuje OSQL.EXE i ISQL.EXE z poprzednich wersji. Dodatkowo dostępny jest program do masowego importowania i eksportowania danych o nazwie BCP.EXE.
Uwierzytelnianie w SQL Serverze SQL Server integruje się z Active Directory, dzięki czemu istnieje kilka sposobów uwierzytelniania użytkowników bazy danych.
Uwierzytelnianie użytkownika Microsoft SQL Server umożliwia uwierzytelnianie za pośrednictwem Windows Active Directory lub na poziomie kont w ramach samego SQL Servera. W przypadku Active Directory możliwości kontroli dostępu są większe, można tu wykorzystywać uprawnienia poszczególnych kont użytkowników i grup.
Uwierzytelnianie usługi SQL Server udostępnia dwa sposoby uwierzytelniania swojej usługi: Konta domenowe W przypadku wykorzystania większej liczby serwerów lub konieczności dostępu do zasobów sieciowych warto wziąć pod uwagę uwierzytelnianie z użyciem kont domenowych. W przypadku większej liczby serwerów administracja bezpieczeństwem może zostać uproszczona przez zastosowanie polityk domenowych (ang. domain policy), dzięki którym preferencje są propagowane do wskazanego serwera lub do wszystkich. 586 |
Rozdz ał 19. M crosoft SQL Server
Systemowe konto lokalne Lokalne konto systemowe powinno być stosowane wówczas, gdy instalacja nie wymaga dostępu do zasobów sieciowych oraz gdy nie występuje potrzeba uwierzytelniania w domenie. Taka konfiguracja jest przydatna do odizolowania serwera od pozostałej części domeny, co jest stosowane w celu zwiększenia bezpieczeństwa w sieciach, w których występują elementy o niskim poziomie zabezpieczeń.
Perspektywa zaawansowanego użytkownika Zaawansowani użytkownicy z reguły rozumieją elementy architektury SQL Servera wymienione w tym podrozdziale. Użytkownicy ci wykorzystują te pojęcia w rozmowach z administratorami baz danych i systemów.
Egzemplarz Egzemplarz (ang. instance) to kopia SQL Servera działająca w komputerze. W przypadku SQL Servera możemy mieć do czynienia z wieloma egzemplarzami działającymi równolegle. W przypadku wersji 2000 na jednym komputerze mógł działać tylko jeden egzemplarz serwera.
Bazy danych Baza danych w SQL Serverze to kolekcja tabel, indeksów i innych obiektów przechowujących dane w strukturalnym, relacyjnym formacie. Indywidualny egzemplarz SQL Servera może obsługiwać wiele różnych baz danych. Każda baza danych może zawierać dane dostępne z poziomu innych baz, bazy też mogą być zupełnie niezależne. Bazy w SQL Serverze dzieli się na dwie kategorie: bazy systemowe i bazy użytkownika. Systemowe bazy danych zawierają informacje niezbędne do działania aplikacji serwera baz danych oraz poszczególnym bazom. Najważniejszym przykładem bazy systemowej jest baza master. Bazy danych użytkownika zawierają dane aplikacji. Baza danych może, w zależności od sytuacji, znajdować się w różnych stanach: online, offline, w trakcie odtwarzania (ang. restoring), w trakcie odbudowy (ang. recovering), oczekująca na odbudowę (ang. recovery pending), niepewnym (ang. suspect) oraz ratunkowym (ang. emergency). SQL Server 2005 jest bardzo elastycznym serwerem baz danych. Istnieje możliwość wykorzystania do 32 767 baz danych w pojedynczym egzemplarzu, choć nie praktykuje się tego.
Bazy systemowe Bazy systemowe są wykorzystywane przez SQL Server do zarządzania systemem i konfigurowania go . W domyślnej instalacji tworzone są następujące bazy systemowe: master Zawiera konfigurację specyficzną dla serwera oraz konfiguracje wspólne dla wszystkich baz danych.
Perspektywa zaawansowanego użytkown ka
|
587
model Zawiera wzorcową bazę danych, na podstawie której tworzone są nowe bazy danych. tempdb Stanowi obszar tymczasowy do zapisu danych pośrednich zapytań i innych zadań. msdb Wykorzystywana przez narzędzie SQL Server Agent do obsługi ostrzeżeń, powiadomień i zadań planowanych. distribution Wykorzystywana przez Replication Services w przypadku, gdy serwer jest skonfigurowany w trybie publisher lub distributor. Nie należy w bazie master tworzyć własnych obiektów: tabel, procedur składowanych czy wyzwalaczy. Baza master jest wykorzystywana do wewnętrznych celów egzemplarza SQL Serwera.
Bazy użytkownika Bazy użytkownika to bazy przeznaczone do przechowywania danych niezwiązanych z systemem. W nich właśnie zapisywane są dane aplikacji użytkownika.
Analiza informacji o bazach danych Informacje konfiguracyjne o bazie danych można uzyskać, wykorzystując do tego celu systemowe procedury składowane (obszerniej omówię je w dalszej części podrozdziału) w języku Transact-SQL. Na przykład w celu odczytania informacji o określonej bazie danych można wywołać następujące zapytanie Transact-SQL: sp_helpdb nazwa_bazy
To polecenie wypisuje informacje o konfiguracji wskazanej bazy. W przypadku bazy Inventory wynik będzie następujący: name db_size Inventory 3.00 MB
owner Administrator
dbid 7
created status compatibility_level Mar 21 2006 Status=0NLINE 90 Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=FULL, Version=611, Collation=SQL_Latin1_General_CP1_CI_AS, SQLSortOrder=52, IsAutoCreateStatistics, IsAutoUpdateStatistics
name fileid filename Inventory 1 C:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\Inventory.mdf Inventory_log 2 C:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\Inventory_log.ldf filegroup PRIMARY NULL
size 2048 KB 1024 KB
maxsize Unlimited 2147483648 KB
growth 1024 KB 10%
usage data only log only
Te informacje można oczywiście odczytać w programie Management Studio (2005) lub Enterprise Manager (2000).
588 |
Rozdz ał 19. M crosoft SQL Server
Tabele Tabela to obiekt bazy danych, w którym zapisane są dane zorganizowane w strukturze wierszy i kolumn. Serwer 2005 potrafi w każdej tabeli obsłużyć do 1024 kolumn. Każda kolumna jest skonfigurowana do przechowywania danych określonego typu, na przykład tekstowego, liczbowego czy binarnego.
Tabele systemowe Oprócz wspomnianych wyżej tabel użytkownika SQL Server zawiera tabele systemowe, przechowujące dane konfiguracyjne serwera. Te tabele nie mogą być odczytywane lub modyfikowane bezpośrednio, można jednak odczytywać ich zawartość z wykorzystaniem dedykowanego połączenia administracyjnego (dedicated administrator connect, DAC) lub za pomocą perspektyw katalogowych (ang. catalog views). Schemat tych tabel znacząco różni się w kolejnych wersjach serwera, dlatego należy zachować ostrożność w przypadku starszej aplikacji narzędziowej, która ma zarządzać nowszymi wydaniami aplikacji Microsoft SQL Server.
Tabele tymczasowe Tabele tymczasowe mają podobne właściwości do zwykłych tabel użytkownika, z dwoma różnicami: są zapisywane w bazie tempdb i zapisywane w nich dane są z założenia tymczasowe. Mamy do dyspozycji dwa typy tabel tymczasowych, różniące się zakresem dostępności: lokalne i globalne. Lokalne tabele tymczasowe są dostępne jedynie dla użytkownika, który je utworzył, i wyłącznie w ramach tej samej sesji połączenia do egzemplarza SQL Servera. Te tabele są usuwane natychmiast po zakończeniu sesji. Globalne tabele tymczasowe są dostępne dla każdego połączonego użytkownika i każdej sesji. Są usuwane po zakończeniu wszystkich sesji odwołujących się do tabeli.
Indeksy Indeksy są tworzone na tabelach lub perspektywach i służą do przyspieszania operacji wyszukiwania. Indeksy są tworzone na podstawie wartości jednej lub większej liczby kolumn. Dzięki indeksom wyszukiwanie danych z tabeli wymaga odczytu znacznie mniejszej ilości danych, co może mieć znaczący wpływ na wydajność aplikacji.
Tabele spartycjonowane Tabela spartycjonowana to specjalny typ tabeli, w której dane są podzielone na fizyczne części, tzw. filegroups, w ramach bazy danych (więcej informacji na temat tej struktury znajduje się w podrozdziale „Perspektywa administratora”). Taki podział poprawia możliwości zarządzania większymi tabelami, a zapisane w nich dane przeszukuje się szybciej. Dzieje się tak dlatego, że dane w partycjach mogą być przetwarzane w podzbiorach, co oznacza, że w celu wyszukania wyniku serwer baz danych musi przeszukać jedynie podzbiór tabeli.
Indeksy spartycjonowane Indeksy spartycjonowane to indeksy obejmujące więcej niż jedną grupę plikową. Spartycjonowane indeksy, obok spartycjonowanych tabel, zwiększają wygodę administrowania i przyspieszają dostęp do danych.
Perspektywa zaawansowanego użytkown ka
| 589
Procedury składowane Procedury składowane to skompilowane zapytania w języku Transact-SQL, zapisane bezpośrednio w bazie. Procedury składowane to doskonały sposób definiowania kodu w ramach bazy danych, co stanowi alternatywę w stosunku do kodu zaimplementowanego w logice aplikacji. Procedury te dają też spore korzyści z punktu widzenia wydajności wykonania, ponieważ pozwalają zaoszczędzić czas niezbędny do przesłania większych porcji danych do zewnętrznej aplikacji w celu ich dalszego przetworzenia.
Zarządzanie pamięcią W domyślnej konfiguracji silnik baz danych SQL Servera alokuje tak duży obszar pamięci, jak to możliwe, bez powodowania braku pamięci w systemie. Dodatkowa pamięć jest alokowana w przypadku zwiększania się liczby połączeń lub wykonywanych operacji obliczeniowych. To powoduje, że ilość pamięci wykorzystanej przez SQL Server zwiększa się aż do momentu, gdy system operacyjny zasygnalizuje, że nie może już udostępnić dodatkowej pamięci. Pamięć zajmowana przez serwer może być również zwalniana.
Perspektywa administratora W przypadku administratora baz danych niezbędne jest zapoznanie się z następującymi zagadnieniami aplikacji Microsoft SQL Server.
Pliki bazy danych Podobnie jak w przypadku innych serwerów baz danych, SQL Server wykorzystuje pliki danych (ang. datafile) do zapisu danych baz. Z każdą bazą danych związane są co najmniej dwa pliki danych: plik zawierający właściwe dane oraz plik dzienników. Często praktykowaną zasadą jest umieszczanie tych plików na osobnych dyskach twardych w celu zwiększenia wydajności i możliwości przywracania systemu po awariach. Każdy plik danych może być wykorzystywany przez tylko jedną bazę danych. Istnieją trzy typy plików SQL Servera: podstawowe pliki danych (ang. primary datafile), drugorzędne pliki danych (ang. secondary datafile) i pliki dzienników (ang. logfile). Podstawowe pliki danych Każda baza danych wykorzystuje przynajmniej jeden podstawowy plik danych. Ten plik zawiera dane oraz informacje o pozostałych plikach danych. Domyślnym rozszerzeniem podstawowych plików danych jest .mdf. Drugorzędne pliki danych Każdy plik niebędący podstawowym plikiem danych lub plikiem dzienników określa się terminem drugorzędnego pliku danych. W tych plikach są zapisywane dodatkowe informacje. Domyślnym rozszerzeniem plików tego typu jest .ndf. Pliki dzienników Pliki dzienników nie zawierają danych w sposób bezpośredni, zawierają jednak istotne informacje na temat danych w bazie. Każda baza danych musi wykorzystywać co najmniej
590
|
Rozdz ał 19. M crosoft SQL Server
jeden plik danych. Można, a nawet zaleca się tworzyć dodatkowe pliki dzienników i zapisywać je na osobnych dyskach. Domyślnym rozszerzeniem plików tego typu jest .ldf. Nie istnieją kategoryczne wymogi dotyczące fizycznej lokalizacji plików. Można je zapisywać na partycjach FAT lub NTFS. System plików NTFS jest zalecany, ponieważ jest lepiej zintegrowany z zaawansowanymi funkcjami systemu Windows, w tym z mechanizmami bezpieczeństwa. Każdy plik bazy danych może zwiększać swoje rozmiary wraz ze zwiększonym zapotrzebowaniem na rozmiar zasobu danych. Jednostkowy przyrost rozmiaru jest konfigurowany procentowo lub jako wartość bezwzględna. Pliki mogą zwiększać swoje rozmiary aż do osiągnięcia określonego maksymalnego rozmiaru pliku. Jeśli rozmiar ten nie został podany, ograniczeniem jest 16 TB lub całkowity rozmiar partycji. W przypadku wykorzystania większej liczby plików danych rozmiary plików są zwiększane w sposób cykliczny, począwszy od pierwszego pliku w grupie. Istnieje teoretyczne ograniczenie rozmiaru bazy danych (nie pliku): 1 048 516 TB. Podobnie jak bazy danych pliki dzienników mogą znajdować się w różnych stanach: online, offline, odtwarzanie (ang. restoring), oczekiwanie na naprawę (ang. recovery pending), podejrzany (ang. suspect) i uszkodzony (ang. defunct).
Grupy plików Powiązane pliki można zgrupować w postaci grupy plików (ang. filegroup). Grupa plików upraszcza zarządzanie zasobami składowania i administrowanie tymi plikami. Istnieją dwa typy grup plików w SQL Server 2005: podstawowa (ang. primary) i użytkownika (ang. user defined). Podstawowa grupa plików Podstawowa grupa plików (ang. primary filegroup) zawiera podstawowy plik danych oraz inne pliki danych nieprzydzielone do żadnej z pozostałych grup. Podstawowa grupa plików zawiera też wszystkie pliki danych tabel systemowych. Grupy plików użytkownika Grupy plików użytkownika (ang. user filegroups) są tworzone wówczas, gdy w poleceniu create database lub alter database zostanie użyte słowo kluczowe filegroup. Należy pamiętać o następujących regułach dotyczących plików i grup plików: • pliki dziennika nie są umieszczane w grupie, zawsze są zarządzane niezależnie od plików
danych; • pliki nie mogą należeć do kilku grup; • pewne obiekty baz danych (tabele, indeksy, obiekty BLOB) można jawnie przydzielić do
określonych grup;
• zawsze musi być zdefiniowana jakaś grupa domyślna; • przy tworzeniu tabeli lub indeksu, gdy nie jest wskazana określona grupa plików, obiekt
zostanie utworzony w grupie domyślnej;
• w każdym momencie może być zdefiniowana tylko jedna grupa domyślna; • dane zapisane w spartycjonowanym obiekcie mogą być zapisane w różnych grupach plików.
Perspektywa adm n stratora
|
591
Dziennik transakcyjny Dziennik transakcyjny (ang. transaction log) zawiera zapisy wszystkich transakcji (wstawianie, modyfikacja lub usuwanie wiersza, alokacja lub dezalokacja strony danych, instrukcje rozpoczęcia i zakończenia transakcji). W pliku transakcyjnym zapisywana jest informacja o operacji, zanim zmiany są fizycznie wprowadzane w pliku danych. Tego typu dziennik zapisu z wyprzedzeniem (ang. write ahead logging, WAL) gwarantuje, że w pliku danych żadne zmiany danych nie zostaną zapisane, zanim nie zostaną zapisane w dzienniku. To wprowadza nadmiarowość danych, która pozwala w łatwy sposób naprawiać problemy i wycofywać zmiany wprowadzane w ramach transakcji (ang. roll back). SQL Server wykorzystuje dwa typy dziennika transakcyjnego: logiczny i fizyczny. Dziennik fizyczny jest zapisany na dysku. Dziennik logiczny jest reprezentacją dziennika w strukturach danych silnika bazy. Dziennik logiczny można postrzegać jako serię wirtualnych plików dzienników bez określonego rozmiaru. Przestrzeń wykorzystywana przez dziennik logiczny jest wykorzystywana w trybie cyklicznym aż do momentu zapełnienia dziennika. Aby zapobiec nadmiernemu zwiększaniu się rozmiaru dziennika, należy co jakiś czas go przycinać. Jest to operacja z reguły wykonywana automatycznie w ramach wykonywania kopii zapasowej, można to również wykonać ręcznie. Należy pamiętać, że ręczne przycięcie dziennika transakcyjnego przerywa łańcuch logiczny kopii zapasowych.
Plik transakcyjny należy przycinać, aby zapobiec jego zapełnieniu. Jeśli tak się stanie, baza danych przestawi się w tryb tylko do odczytu i nie pozwoli na wprowadzanie dalszych zmian. Przycinanie nie powoduje zmniejszenia rozmiaru fizycznego pliku dziennika, a tylko logicznego. Aby zredukować rozmiar fizycznego pliku transakcyjnego, należy wywołać specjalne polecenia, omówione w dalszej części rozdziału. W przypadku zdefiniowania opcji FILEGROWTH pliki dziennika mogą przyrastać bez ograniczeń. W tym przypadku dziennik transakcyjny po zapełnieniu zostaje zwiększony o określony rozmiar. Oczywiście fizyczny rozmiar pliku dziennika jest ograniczony rozmiarem partycji. Jeśli dziennik transakcyjny zostaje zapełniony, istnieje kilka sposobów jego przycięcia: • wykonanie fizycznej kopii zapasowej dziennika transakcyjnego; • w przypadku gdy jest dostępne miejsce na dysku — zwiększenie rozmiaru pliku dziennika; • jeśli nie ma więcej wolnego miejsca — zwolnienie miejsca na dysku lub przeniesienie dzien-
nika na inny dysk twardy; • dodanie nowego dziennika na innym dysku; • przycięcie w efekcie zastosowania systemowego lub wymuszonego punktu przywracania.
Monitorowanie pliku dziennika za pomocą dbcc Rozmiar plików dziennika można monitorować za pomocą polecenia dbcc sqlperf: dbcc sqlperf (logspace) Database Name Log Size (MB) master 0.4921875 tempdb 0.4921875
592
|
Rozdz ał 19. M crosoft SQL Server
Log Space Used 81.74603 63.39286
(%)
Status 0 0
model msdb ReportServer ReportServerTempDB Inventory
0.4921875 0.4921875 0.7421875 0.7421875 0.9921875
73.01588 86.50793 38.68421 36.77632 45.22638
0 0 0 0 0
Zmniejszenie rozmiaru dziennika fizycznego Czasem może być konieczne zmniejszenie fizycznego rozmiaru dziennika transakcyjnego. Można to zrobić za pomocą polecenia dbcc shrinkfile: dbcc SHRINKFILE (Inventory_Log,l) Dbld Fileld CurrentSize MinimumSize 7 2 128 128
UsedPages 128
EstimatedPages 128
Strony danych Microsoft SQL Server wykorzystuje koncepcję stron danych (ang. page). Dane zapisywane w plikach są podzielone na logiczne fragmenty, zwane stronami, ponumerowane od 0 w górę. Dostęp do dysku odbywa się na poziomie stron, które są traktowane jako najmniejsza jednostka dostępu do dysku (zapis i odczyt odbywa się całymi stronami). W jednym megabajcie mieści się 128 stron danych o rozmiarze 8 kB. Każda strona składa się z nagłówka o rozmiarze 96 bajtów, w których przechowywane są informacje o zawartości strony. Zapisany jest tu między innymi numer strony, identyfikator obiektu — właściciela strony oraz typ i ilość wolnej przestrzeni. Różne typy danych są zapisane w stronach różnych typów: dane, indeksy, tekst lub dane graficzne, globalne i lokalne mapy alokacji, wolna przestrzeń, mapa alokacji indeksów, mapa zmian grupowych (ang. bulk change map) i mapa zmian różnicowych (ang. differential change map). Wiersze danych są zapisywane na stronie sekwencyjnie, natychmiast po nagłówku. Na końcu strony zapisywana jest tabela przesunięć wierszy, zawierająca wpisy dla każdego wiersza na stronie. Każdy wpis zawiera informację o przesunięciu pierwszego bajta wiersza w stosunku do początku strony. Pozycje w tabeli przesunięć są zapisane od końca, w kolejności odwrotnej w stosunku do kolejności wierszy na stronie.
Ekstenty Następnym pojęciem związanym z zapisem danych na dysku jest ekstent. Każdy ekstent składa się z ośmiu fizycznie następujących po sobie stron danych, czyli jeden megabajt składa się z 16 ekstentów. Łączenie stron w ekstenty pozwala na efektywniejsze zarządzanie stronami danych. Wyróżnia się dwa typy ekstentów: jednolite (ang. uniform) i mieszane (ang. mixed). Strony w ekstentach typu jednolitego zawierają dane jednego obiektu. Strony w ekstentach typu mieszanego mogą być zajęte przez maksymalnie osiem obiektów, co oznacza, że każda z ośmiu stron może zawierać dane innego obiektu. Przy tworzeniu nowej tabeli lub indeksu miejsce dla ich danych jest alokowane w stronie z ekstentu typu mieszanego. Gdy tabela rozrasta się do rozmiarów przekraczających osiem stron ekstentu, zapis jej danych zostaje przeniesiony do ekstentów typu jednolitego.
Perspektywa adm n stratora
|
593
Partycje Partycje dzielą dane w sposób umożliwiający bardziej logiczne zarządzanie nimi. Dodatkową zaletą partycjonowania i szczególnym przypadkiem stosowania partycji jest możliwość uzyskania lepszej wydajności dostępu dodanych. W domyślnej konfiguracji tabele są alokowane w pojedynczych partycjach. Tabele lub indeksy zapisane w pojedynczej partycji są takie same jak tabele i indeksy zapisane we wcześniejszych wersjach SQL Servera. W przypadku tabel lub indeksów zapisanych w kilku partycjach dane są rozmieszczone na podstawie wartości kolumny (lub kilku kolumn) będącej kluczem partycji. Partycje mogą wchodzić w skład różnych grup plików tej samej bazy danych. Niezależnie od liczby partycji oraz grup plików, w których zapisana jest tabela, z logicznego punktu widzenia jest traktowana jako jednolita całość. W partycjach w SQL Server 2005 wiersze danych są uporządkowane w jeden z dwóch sposobów: klastrowy (ang. cluster) lub stertowy (ang. heap). Dane klastrowe są uporządkowane na podstawie indeksu. To musi być indeks typu b-tree narzucający fizyczne uporządkowanie wierszy danych. Dane stertowe nie mają narzuconego porządku; w tym przypadku dane są uporządkowane w zupełnie dowolnej kolejności.
Szczegóły techniczne tabel i indeksów Dane w tabelach są zapisane w stronach o stałym rozmiarze 8 kB. Dane są zapisane w wierszach, a każdy wiersz z reguły mieści się na pojedynczej stronie. Wyjątek stanowią tu duże typy danych, jak: (n)text, image, var char (max), xml. Duże typy danych mogą być zapisywane w większej liczbie stron. Tabele mogą być zapisane w większej liczbie partycji, a wiersze danych mogą być w nich uporządkowane w strukturze klastrowej lub stertowej. W zależności od typu danych strony sterty lub indeksu klastrowego są zarządzane w jednej lub większej liczbie jednostek alokacji. Partycje w tego typu strukturze nie stanowią odpowiedników partycji na dyskach, to jedynie środek umożliwiający użytkownikowi zdefiniowanie sposobu uporządkowania danych. Domyślnie tabela lub indeks są związane z tylko jedną partycją. Należy pamiętać o tym, że każda partycja musi być zapisana w tylko jednej grupie plików.
Migawkowe kopie zapasowe (2005) Nowością w SQL Server 2005 jest koncepcja wykonywania i odtwarzania migawkowych kopii zapasowych. Wykorzystanie tej technologii wymaga zastosowania oprogramowania lub sprzętu firm trzecich, zatem w tej książce zalety tej metody omówię jedynie powierzchownie, gdyż zadaniem tej książki jest omówienie niekosztownych metod związanych z kopiami zapasowymi. Wykonywanie migawkowych kopii zapasowych pozwala na bardzo szybkie wykonanie kopii zapasowej bez znaczącego wpływu na wydajność działania serwera. Główna zaleta migawkowych kopii zapasowych polega na tym, że proces odtwarzania kopii zapasowych jest prawie tak samo szybki. Inne zalety tej metody są związane z dodatkowymi możliwościami, jak wykonywanie kopii bazy na potrzeby wykonywania raportów.
594 |
Rozdz ał 19. M crosoft SQL Server
Ten typ kopii zapasowych to odpowiednik zwykłych kopii i można go stosować wymiennie z typowymi kopiami zapasowymi. Kopię migawkową można na przykład wykorzystać w procesie odtworzenia pełnej kopii zapasowej zapisanej na taśmie. Kopie migawkowe są dostępne jedynie w przypadku pełnych, częściowych i plikowych kopii zapasowych, można je też w pewnym ograniczonym zakresie stosować przy kopiach różnicowych.
Kopie zapasowe W SQL Server 2005 większość operacji wykonywania kopii zapasowych można wykonywać bez obaw o obniżenie wydajności operacji użytkowników. W poprzednich wersjach należało poświęcić znacznie więcej uwagi na planowanie architektury bazy danych i wykonywanie kopii zapasowych, aby w trakcie wykonywania kopii zapasowych nie obniżać wydajności pracy użytkowników. Kopie zapasowe mogą być wykonywane w dowolnym czasie, ale w przypadku, gdy serwer próbuje utworzyć lub usunąć plik, wykonywanie kopii zapasowej jest wstrzymywane aż do zakończenia tej operacji. Ponadto w trakcie wykonywania kopii zapasowej nie można tworzyć ani usuwać baz danych. Mimo że tworzenie kopii zapasowych nie powinno mieć negatywnego wpływu na wydajność, nadal zaleca się, aby ich wykonywanie planować na okres najmniejszego obciążenia bazy danych. W przypadku SQL Servera istnieje kilka technik wykonywania i odtwarzania kopii zapasowych, które pozwalają zminimalizować przestoje w przypadku katastrofy. Do tych technik należy wykorzystanie „gorących”, „ciepłych” i „zimnych” serwerów zapasowych. W zależności od budżetu i wykorzystanych technik mirroringu, przenoszenia dzienników i różnych procedur odtwarzania, istnieje możliwość tworzenia różnych scenariuszy odtwarzania danych z zakładanym czasem przestoju od zera (mirroring) do maksymalnie kilku godzin przy zimnym serwerze zapasowym.
Urządzenia do wykonywania kopii zapasowych Urządzeniem do wykonywania kopii zapasowych może być dowolny nośnik danych, np. dysk, taśma, zewnętrzne urządzenie składowania danych lub sieciowe urządzenie składowania (jak SAN lub NAS). W poprzednich wersjach SQL Servera przed wykonaniem kopii zapasowej trzeba było określić urządzenie do wykonywania kopii. W SQL Server 2005 kopie zapasowe mogą być tworzone „w locie”. Jednak nadal za dobrą praktykę uznaje się planowanie procesu wykonywania kopii zapasowych, w tym nośników składowania, co pozwala na zachowanie ciągłości i prostoty administracji. Jeśli nie jest wykorzystywane komercyjne oprogramowanie do wykonywania kopii zapasowych, SQL Server wymaga, aby urządzenie taśmowe było fizycznie przyłączone do serwera baz danych. Nie jest obsługiwane wykonywanie kopii zapasowych na zdalnych urządzeniach taśmowych.
Urządzenia logiczne i fizyczne Urządzenia do wykonywania kopii zapasowych można zidentyfikować na podstawie ich nazw fizycznych lub logicznych. Nazwa fizyczna to nazwa, którą widzi system operacyjny, na przykład d:\backups\backup.bak. Nazwa logiczna to po prostu alias nazwy fizycznej. Mapowanie
Kop e zapasowe
|
595
logicznej nazwy urządzenia na nazwę fizyczną jest zapisane w tabelach systemowych. Nazwa logiczna stanowi po prostu sposób na ułatwienie odwołania do nazwy fizycznej.
Modele odtwarzania Modele odtwarzania (ang. recovery model) pozwala zaplanować, co ma być kopiowane i w jaki sposób wykonywać te kopie. Mamy możliwość zastosowania jednego z trzech podstawowych modeli odtwarzania: prostego (ang. simple), pełnego (ang. full) i typu bulk z dziennikami (ang. bulk-logged). Należy przeanalizować stosowany model wykonywania kopii zapasowych w odniesieniu do potrzeb, ponieważ ten model narzuca typ zastosowanej kopii zapasowej. Model odtwarzania ma wpływ na zakres danych, które mogą być odtworzone. Prosty model odtwarzania Proste odtwarzanie danych, jak sugeruje nazwa, to najbardziej podstawowy typ odtwarzania SQL Servera. W tym typie kopii zapasowych dziennik transakcyjny jest przycinany w sposób automatyczny, a nieaktywne dzienniki są usuwane. Ten sposób powoduje, że istnieje możliwość odtworzenia danych z ostatniej pełnej kopii zapasowej, ponieważ nie są odtwarzane dane z dzienników transakcyjnych. Pełny model odtwarzania Pełne odtwarzanie oferuje możliwość, której nie daje odtwarzanie proste: w tym przypadku dane są odtwarzane również z dzienników transakcyjnych. Dzięki temu dane mogą być odtworzone praktycznie do bieżącego stanu. Model bulk z odtworzeniem dzienników Kopie zapasowe typu bulk mają działanie zbliżone do kopii pełnych: odtwarzane są pliki danych oraz dzienniki transakcyjne. Podstawowa różnica polega na tym, że w tym modelu do dziennika transakcyjnego nie są zapisywane transakcje typu bulk. Dzięki temu dane w bazie można odtworzyć do aktualnego stanu, z wyjątkiem transakcji typu bulk. Model odtwarzania każdej bazy danych można sprawdzić z poziomu interfejsu użytkownika lub za pomocą zapytania w języku Transact-SQL.
SQL Server 2005 Aby sprawdzić model odtwarzania w serwerze SQL Server 2005, należy wykorzystać procedurę składowaną sp_helpdb: sp_helpdb nazwa_bazy
W kolumnie status należy odszukać sekcję RECOVERY=, w której znajduje się nazwa bieżącego modelu odtwarzania. Alternatywnie można wykonać następujące polecenie w języku Transact-SQL: select name, recovery_model from sys.databases;
To polecenie wypisze listę wszystkich baz danych; w kolumnie recovery_model znajdują się liczby: 1, 2 i 3. Oznaczają one kolejno: • pełny model odtwarzania; • model bulk; • prosty model odtwarzania.
596
|
Rozdz ał 19. M crosoft SQL Server
Aby sprawdzić model odtwarzania w aplikacji Management Studio, należy wykonać następujące działania:
1. Uruchomić Management Studio i podłączyć się do odpowiedniego egzemplarza SQL Server Database Engine.
2. Rozwinąć odpowiednią gałąź serwera. 3. Rozwinąć grupę Databases. 4. Wybrać bazę danych (użytkownika lub systemową). 5. Kliknąć prawym przyciskiem myszy na bazę danych i wybrać Properties. 6. Kliknąć Options w oknie Select a page.
SQL Server 2000 Aby sprawdzić model odtwarzania w serwerze SQL Server 2000, należy wykorzystać procedurę składowaną sp_helpdb: sp_helpdb nazwa_bazy
W kolumnie status należy odszukać sekcję REC0VERY=, w której znajduje się nazwa bieżącego modelu odtwarzania. Alternatywnie można wykonać następujące polecenie w języku Transact-SQL: select databasepropertyex('database', 'recovery')
Aby sprawdzić bieżący model odtwarzania w programie Enterprise Manager, należy wykonać następujące działania:
1. Uruchomić program Enterprise Manager i połączyć się z odpowiednim egzemplarzem SQL Server Database Engine.
2. Rozwinąć gałąź serwera. 3. Prawym przyciskiem myszy kliknąć nazwę bazy danych i wybrać Properties. 4. Otworzyć kartę Options. Model odtwarzania jest dostępny w menu rozwijanym Model.
Typy kopii zapasowych Microsoft SQL Server obsługuje kilka typów kopii zapasowych. Każdy z nich ma zalety i wady i zawsze należy dobierać odpowiedni z nich do swojej strategii tworzenia kopii zapasowych.
Pełna Pełna kopia zapasowa bazy danych (ang. full backup) oznacza dokładnie to, co sugeruje jej nazwa. W tej kopii zapisywane są wszystkie obiekty, tabele systemowe, dane i odpowiednie fragmenty dzienników transakcyjnych. Z tego typu kopii zapasowej można odtworzyć bazę danych do stanu odpowiadającego momentowi zakończenia wykonywania kopii zapasowej.
Kop e zapasowe
|
597
Różnicowa Różnicowa kopia zapasowa zawiera wszystkie zmiany od ostatniej pełnej kopii zapasowej. Kopia różnicowa tworzona jest w odniesieniu do pełnej kopii zapasowej i określa się ją często bazą różnicową. Z czasem bazy różnicowe zwiększają swoje rozmiary i w pewnym momencie mogą przekroczyć rozmiar pełnej kopii zapasowej. Dlatego dla zwiększenia efektywności kopii zapasowych należy odpowiednio zaplanować wykonywanie pełnych i różnicowych kopii zapasowych.
Dziennik transakcyjny Ważne jest, aby wykonywać kopie zapasowe dzienników transakcyjnych, ponieważ zapisywane są w nim wszystkie transakcje przed ich zapisaniem w bazie danych. Wykonywanie kopii zapasowych dziennika transakcyjnego pozwala odtworzyć serwer do stanu bieżącego, bezpośrednio poprzedzającego awarię. Istnieją trzy podstawowe typy kopii zapasowych dziennika transakcyjnego: pełna (ang. full, czasem stosuje się też określenie pure, czyli czysta) kopia zapasowa zawiera pełny dziennik transakcyjny za określony okres i nie zawiera zmian typu bulk. Należy pamiętać, że w przypadku tego typu kopii dziennika transakcyjnego nie ma możliwości odtworzenia bazy danych w punkcie czasu (ang. point in time). Kopia zapasowa typu bulk ma podobne cechy, z tą różnicą, że w tym przypadku zapisywane są również zmiany w bazie typu bulk. Kopia zapasowa typu tail log jest stosowana w przypadku, gdy podejrzewa się uszkodzenie fizyczne bazy danych. Tego typu kopia zapisuje rekordy dziennika transakcyjnego, które nie zostały skopiowane za pomocą jednej z pozostałych metod (full lub bulk). Ta kopia może zawierać dane zwykłe oraz typu bulk. Przy odtwarzaniu dzienników transakcyjnych zmiany zawsze są dokonywane w sposób sekwencyjny, począwszy od najstarszej, a skończywszy na najświeższej. Tego typu odtworzenie dziennika transakcyjnego jest z reguły wykonywane po odtworzeniu najnowszej pełnej lub różnicowej kopii zapasowej. Sekwencja dzienników transakcyjnych nazywana jest często łańcuchem dzienników. Łańcuch dzienników musi być w pełni prawidłowy (nieuszkodzony), aby proces odtworzenia transakcji zakończył się powodzeniem. Należy pamiętać, że kopie zapasowe dziennika transakcyjnego są dostępne wyłącznie w pełnym modelu odtwarzania kopii oraz w modelu typu bulk; w modelu prostym nie ma takiej opcji.
Kopia zapasowa typu copy-only Kopie zapasowe typy copy-only to wygodny sposób przeniesienia danych istniejącej bazy danych na nowy serwer. Kopie zapasowe copy-only nie ustawiają znacznika kopii zapasowej, dzięki czemu różnicowe kopie zapasowe nie uwzględniają faktu wykonania takiej kopii (znacznik kopii zapasowej ma znaczenie analogiczne do atrybutu plików Archiwizacja w systemie Windows).
Częściowe kopie zapasowe Częściowe i różnicowe kopie zapasowe są nowością wprowadzoną w SQL Server 2005. Częściowa kopia zapasowa (ang. partial backup) ma właściwości zbliżone do pełnej kopii zapasowej, z tą różnicą, że nie zawiera wszystkich grup plików. Zawiera wszystkie dane w podstawowej grupie plików oraz wszystkie grupy plików dostępne w trybie odczytu i zapisu. Może również zawierać dodatkowe pliki wskazane przez użytkownika. 598 |
Rozdz ał 19. M crosoft SQL Server
Różnicowa częściowa kopia zapasowa (ang. differential partial) ma właściwości zbliżone do kopii częściowej, z tym że zapisuje zmiany dokonane od ostatniej pełnej kopii zapasowej. Podobnie jak w przypadku zwykłych kopii różnicowych za podstawę do odtworzenia tej kopii przyjmuje się ostatnią pełną kopię zapasową.
Pliki i grupy plików Rozwiązaniem alternatywnym do wykonywania kopii zapasowych bazy danych jest zapis kopii indywidualnych plików i grup plików. Ta metoda ma taką zaletę, że zabezpieczone pliki mogą być odtworzone bez dokonywania pełnego odtworzenia bazy danych. Grupa plików stanowi w zasadzie jedynie metodę uproszczenia kwestii uporządkowania plików bazy danych, zatem kopia zapasowa grupy plików stanowi uproszczoną formę skopiowania większej liczby plików.
Wykonywanie i odtwarzanie kopii zapasowych systemowych baz danych Systemowe bazy danych zawierają wszystkie informacje o konfiguracji działającego serwera, jak również wiele innych danych, dotyczących między innymi lokalizacji grup plików, parametrów składowania i konfiguracji na poziomie systemu. Systemowe bazy danych są niezbędne do pełnego odtworzenia bazy danych. Z tego powodu wykonywanie i odtwarzanie kopii zapasowych systemowych baz danych to bardzo istotne zagadnienia. Microsoft SQL Server wykorzystuje sześć omówionych wcześniej systemowych baz danych (master, model, msdb, resource, tempdb i distribution); do uruchomienia egzemplarza bazy jest niezbędna tylko baza master. Jeśli ta baza się uszkodzi, możliwości odtworzenia będą dwie. Pierwsza z nich jest stosowana wówczas, gdy egzemplarz uda się jednak uruchomić. W tym przypadku bazę master można odtworzyć z ostatniej pełnej kopii zapasowej bazy danych. Druga opcja jest stosowana wówczas, gdy uszkodzenie bazy master uniemożliwia uruchomienie egzemplarza. W takim przypadku konieczna jest kompletna odbudowa bazy master. Po skutecznej odbudowie należy odtworzyć bazę master z pełnej kopii zapasowej. Baza danych nie może działać bez bazy master. Z tego powodu kopię tej bazy należy wykonywać zawsze po dokonaniu zmian w konfiguracji i po dodaniu bazy danych. Kopia zapasowa bazy danych master nie zajmuje dużo miejsca, a w przypadku problemów może oszczędzić poważnych kłopotów.
Przeglądanie informacji o kopii zapasowej Administrator ma możliwość przeglądania historii operacji wykonywania kopii zapasowych. Ta informacja jest zapisana w bazie msdb w tabelach: backupfile, backupfilegroup, backupmediafamily, backupmediaset i backupset. Do przeglądania historii kopii zapasowych służą trzy polecenia: restore filelistonly, restore headeronly i restore labelonly. Poniższe przykłady wykorzystują bazę danych Inventory, której kopia zapasowa jest zapisywana w pliku E:\Backups\Inventory.bak. Aby przejrzeć listę plików zapisanych w tej kopii, należy w oknie Transact-SQL (rysunek 19.1) wywołać następujące polecenie (uniwersalne dla wszystkich omawianych wersji SQL Servera): restore filelistonly from disk = 'E:\Backup\Inventory.bak'
Kop e zapasowe
| 599
Rysunek 19.1. Wyświetlanie informacji nagłówkowej kopii
To polecenie powoduje wypisanie nagłówka kopii zapasowej: restore headeronly from disk = 'E:\Backup\Inventory.bak'
Oczywiście ta sama informacja jest dostępna również z poziomu SQL Server Management Studio (2005) oraz Enterprise Manager (2000): • SQL Server 2005 SSMS:
1. Uruchomić aplikację SQL Server Management Studio. 2. Rozwinąć gałąź Management, a następnie Backup Devices. 3. Kliknąć nazwę urządzenia, którego informacje mają być odczytane, po czym kliknąć Properties. • SQL Server 2000 Enterprise Manager:
1. Uruchomić aplikację SQL Server Enterprise Manager. 2. Rozwinąć grupę serwerów oraz gałąź serwera. 3. Rozwinąć gałąź Management i kliknąć pozycję Backup. 4. W panelu Details kliknąć prawym przyciskiem myszy na urządzenie kopii zapasowej i kliknąć Properties.
5. Kliknąć View Contents.
Weryfikacja kopii zapasowych Zawsze po zakończeniu wykonywania kopii zapasowej warto sprawdzić jej poprawność. Jest na to kilka sposobów. Najprostszy z nich polega na zaznaczeniu opcji Verify backup when finished, co przedstawia rysunek 19.2 (2005 Management Studio) oraz rysunek 19.3 (2000 Enterprise Manager). Warto zwrócić uwagę na opcję Perform checksum poniżej opcji Verify backup (2005). Opcja Verify backup powoduje jedynie sprawdzenie możliwości odtworzenia kopii. Opcja Perform checksum powoduje dodatkowo sprawdzenie poprawności danych.
600 |
Rozdz ał 19. M crosoft SQL Server
Rysunek 19.2. Opcja Verify backup when finished w programie SQL Server 2005 Management Studio
Rysunek 19.3. Opcja Verify backup w programie SQL Server 2000 Enterprise Manager
Kop e zapasowe
|
601
Aby zweryfikować kopię z poziomu języka Transact-SQL, należy wywołać następujące polecenie (dla wersji 2000 i 2005): restore verifyonly from disk = 'F:\Backups\Inventory.bak'
Data ważności kopii Ustawienie daty ważności kopii pozwala na nadpisanie nośnika kopii (ang. backup set) bez jawnego wskazywania, że można go nadpisać. Data ważności kopii może być ustawiona w ramach opcji kopii zapasowych wywoływanych z wiersza poleceń, można ją też ustawić w narzędziu graficznym Management Studio (2005) lub Enterprise Manager (2000). Aby ustawić ją w programie Management Studio, należy połączyć się z odpowiednim egzemplarzem silnika bazy danych i wykonać następujące działania:
1. Rozwinąć gałąź Databases i odszukać nazwę odpowiedniej bazy danych. 2. Kliknąć prawym przyciskiem myszy nazwę bazy danych i wywołać funkcję Tasks/Backup. 3. W oknie Back Up Database przejść do karty General i określić datę ważności lub liczbę dni ważności kopii.
W programie Enterprise Manager należy połączyć się z odpowiednim egzemplarzem silnika baz danych i wykonać następujące działania:
1. Rozwinąć gałąź Databases i odszukać nazwę odpowiedniej bazy danych. 2. Kliknąć prawym przyciskiem myszy nazwę bazy danych i wywołać funkcję All Tasks/Backup Database.
3. W karcie Options zaznaczyć opcję Backup set will expire, po czym wpisać datę upłynięcia ważności danej kopii.
Wykonywanie kopii zapasowych Poniżej opisuję najprostszą formę wykonywania pełnej kopii zapasowej, bez uwzględniania strategii wykonywania kopii zapasowych, modeli odtwarzania i innych szczegółów implementacyjnych. Procedura jest w zasadzie taka sama w wersji 2005 i 2000, z jedyną różnicą w postaci różnych etykiet opcji kopii zapasowej.
1. Uruchomić SQL Server Management Studio, połączyć się z odpowiednim egzemplarzem serwera i rozwinąć gałąź Databases.
2. Kliknąć prawym przyciskiem myszy odpowiednią bazę danych i wywołać funkcję Tasks/ Backup.
3. W oknie Back Up Database przejść do karty General (rysunek 19.4). Przy pierwszym uruchomieniu program sugeruje domyślną lokalizację kopii zapasowej, ale warto zmienić ją na inną, położoną na osobnym dysku twardym. Na rysunku 19.4 jest to E:\Backups\Inventory.bak (partycja E: znajduje się na innym dysku fizycznym niż C:, na którym zapisana jest baza danych i pliki dziennika). Mimo że mamy do czynienia z szybką kopią zapasową, za niedbałość należałoby uznać zignorowanie kilku istotnych opcji na karcie Options. Absolutnym minimum jest zaznaczenie opcji weryfikacji poprawności kopii, co zostało zademonstrowane na rysunku 19.3.
602
|
Rozdz ał 19. M crosoft SQL Server
Rysunek 19.4. Okno Back Up Database, strona General
Oczywiście w ten sposób wykonuje się absolutnie podstawową kopię zapasową. Optymalna konfiguracja kopii zapasowych wykorzystuje mechanizmy planowania wykonania kopii. Mamy tu do dyspozycji kopie różnicowe, możliwość określania lokalizacji kopii, ilości zajmowanego miejsca i wielu innych szczegółów.
Wykonywanie kopii zapasowych z poziomu języka Transact-SQL Takie same kopie zapasowe zapisywane na dysku twardym można wykonywać z poziomu języka Transact-SQL za pomocą polecenia backup database (2000 i 2005). Następujące polecenie wykonuje podstawową kopię zapasową bez ustawiania jakichkolwiek dodatkowych opcji: backup database inventory to disk = 'E:\Backups\cmd_Inventory.bak' with name = 'Command Line Inventory Backup' go
Kopie zapasowe dziennika transakcyjnego Ważnym aspektem jest również regularne wykonywanie kopii zapasowych dzienników transakcyjnych. Można to robić jedynie w ramach kopii zapasowych typu full i bulk logged. Aby wykonać tego typu kopię zapasową, należy wykonać następujące działania:
1. Uruchomić Management Studio, podłączyć się do odpowiedniego egzemplarza silnika bazy danych i rozwinąć gałąź Databases.
2. Kliknąć prawym przyciskiem myszy nazwę odpowiedniej bazy danych i wybrać funkcję Tasks/Backup.
Kop e zapasowe
| 603
3. Upewnić się, że opcja Recovery model jest ustawiona na Full lub Bulk Logged. 4. Z listy rozwijanej Backup Type wybrać opcję Transaction log. Opisaną wyżej procedurę przedstawia rysunek 19.5. W przypadku programu Enterprise Manager (2000) procedura jest identyczna, z tą różnicą, że opcje kopii zapasowej są dostępne w postaci przycisków radiowych zamiast listy rozwijanej.
Rysunek 19.5. Wykonywanie kopii zapasowej dziennika transakcyjnego
Oczywiście w praktyce należy odpowiednio dostosować ustawienia pozostałych opcji kopii zapasowej. W ramach minimum należy przejść na stronę Options i wprowadzić odpowiednie ustawienia w sekcji Transaction log, co przedstawia rysunek 19.6. W przypadku zwykłej kopii zapasowej można pozostawić domyślne wartości Truncate the transaction log. Opcję Back up the tail log, and leave the database in restoring state należy ustawiać wyłącznie w przypadku, gdy wykonywana jest kopia zapasowa tail log backup po awarii, na etapie przygotowań do operacji odtwarzania lub na etapie przygotowania konfiguracji drugorzędnej bazy danych typu fail over. Kopię zapasową dzienników transakcyjnych można również wykonać z poziomu języka Transact-SQL. Poniższy przykład wykonuje kopię zapasową bazy danych Inventory do przygotowanego wcześniej urządzenia Inventory_dev. Polecenie działa zarówno w wersji 2005, jak i 2000: backup log Inventory to Inventory_dev
604 |
Rozdz ał 19. M crosoft SQL Server
Rysunek 19.6. Opcje dziennika transakcyjnego
Przycinanie dziennika Dzienniki transakcyjne mogą w teorii przyrastać, aż zapełnią cały dysk twardy. Aby temu zapobiec, należy je systematycznie przycinać. W zależności od modelu odtwarzania dzienniki można przycinać na kilka różnych sposobów. W modelu prostym (simple), w którym nie są wykorzystywane kopie dziennika, przycinanie dzienników odbywa się w sposób automatyczny, najczęściej w ramach operacji checkpoint. W modelach pełnym i bulk-logged dzienniki są przycinane w ramach procedury wykonywania kopii zapasowej.
Kopie zapasowe bazy master Regularne wykonywanie kopii zapasowych bazy master ma bardzo duże znaczenie. W tej bazie zapisane są wszystkie informacje konfiguracyjne działających systemów oraz informacje konfiguracyjne wszystkich baz danych, jak również inne informacje, jak dane kont logowania. Bez tej bazy danych pozostała część systemu jest bezużyteczna! W przypadku bazy master obsługiwane są wyłącznie pełne kopie zapasowe.
Kop e zapasowe
| 605
Planowanie kopii zapasowej Aby zaoszczędzić czas tracony przez ręczne wykonywanie kopii zapasowych, warto skorzystać z opcji wbudowanej w SQL Server, pozwalającej na tworzenie terminarza automatycznych kopii zapasowych. Zadanie automatycznej kopii zapasowej składa się z dwóch elementów: samego zadania oraz terminarza. Aby utworzyć nowe zadanie, należy wykonać następujące działania (2005 Management Studio):
1. Uruchomić Management Studio, podłączyć się do odpowiedniego egzemplarza silnika bazy danych i rozwinąć gałąź Databases.
2. Rozwinąć gałąź SQL Server Agent. 3. Kliknąć prawym przyciskiem myszy pozycję Jobs i wywołać funkcję Create new job. 4. Wprowadzić nazwę zadania i upewnić się, że zaznaczona jest opcja Enabled. To spowoduje utworzenie zadania kopii zapasowej, ale aby je zautomatyzować, należy utworzyć termin. Można to zrobić w oknie tworzenia zadania, wykorzystując kartę Schedules. Po utworzeniu zadania można utworzyć dla niego termin, klikając prawym przyciskiem myszy jego nazwę i wywołując funkcję Properties. Po przejściu do karty Schedules należy kliknąć przycisk New, co spowoduje otwarcie okna nowego terminu (rysunek 19.7). W tym oknie należy wprowadzić nazwę terminu (Name) oraz określić częstotliwość wykonywania kopii zapasowej.
Rysunek 19.7. Planowanie automatycznego wykonania kopii zapasowej
606 |
Rozdz ał 19. M crosoft SQL Server
W programie Enterprise Manager (2000) termin najprościej utworzyć za pomocą kreatora Maintenance Plan:
1. Uruchomić Enterprise Manager, podłączyć się do odpowiedniego egzemplarza silnika bazy danych i rozwinąć gałąź Databases.
2. Kliknąć prawym przyciskiem myszy nazwę bazy danych i wywołać funkcję All Tasks/ Maintenance Plan. Ten kreator poprowadzi użytkownika krok po kroku przez wszystkie etapy niezbędne do zaplanowania automatycznego wykonywania kopii zapasowej.
Kopie na poziomie logicznym (tabel) Alternatywą dla domyślnego mechanizmu kopii zapasowych SQL Servera jest zrzucanie danych do formatu tekstowego, który może posłużyć do załadowania danych do innej bazy, arkusza kalkulacyjnego, a nawet z powrotem do samego SQL Servera. Do tego celu służy narzędzie do kopiowania danych w trybie bulk o nazwie bcp. Podstawowa zaleta tego narzędzia polega na tym, że nie wymaga znajomości języka Transact-SQL, choć jego znajomość przydaje się do poprawiania wyników działania programu. Program bcp jest dostępny dla wszystkich wersji SQL Servera. Następujący przykład wykonuje kopię zapasową tabeli Items z bazy danych Inventory, zapisując jej zawartość w pliku Items.dat: bep inventory..Items out Items.dat -T -c
Analogiczne wywołanie służy do załadowania danych z pliku do tabeli. W tym przykładzie wykonujemy dokładne odwrócenie operacji, ładując dane zapisane w powyższym poleceniu do tabeli, z której pochodzą: bep inventory..Items in Items.dat -T -c
Odtwarzanie i przywracanie W terminologii SQL Servera wyróżnia się wzajemnie niezależne operacje odtwarzania (ang. restore) i przywracania (ang. recovery) bazy danych. Operacja odtwarzania występuje w przypadku kopiowania danych z kopii zapasowej do pierwotnego położenia. W ramach operacji odtwarzania wykonywane są zatwierdzone transakcje zapisane w dzienniku. Transakcje mogą być odtworzone do dowolnego momentu od wykonania pełnej kopii zapasowej do wystąpienia awarii; przy okazji wycofywane są transakcje, które nie zostały znalezione w dzienniku transakcyjnym. Przywracanie jest wykonywane przy uruchomieniu bazy danych. W ramach tej operacji są wycofywane transakcje, które nie zostały sfinalizowane, dzięki czemu baza może znaleźć się w spójnym stanie. Jeśli proces przywracania nie jest w stanie przywrócić bazy do spójnego stanu, może się okazać konieczne wykonanie odtwarzania. Istnieje wiele opcji wykonywania kopii zapasowych, ale nie mniej opcji mamy do dyspozycji w przypadku odtwarzania. Typ odtwarzania jest z reguły uzależniony od typu ostatnio wykonanej kopii zapasowej. Na przykład najlepszym scenariuszem w przypadku pełnej kopii zapasowej jest wykonanie pełnego odtworzenia. Oznacza to po prostu odtworzenie ostatniej pełnej kopii zapasowej bez konieczności odtwarzania kopii różnicowych lub przyrostowych.
Odtwarzan e przywracan e
|
607
Łatwo zauważyć, jak z czasem liczba dostępnych opcji się zwiększa. Można wykonać pełne odtworzenie z przyrostowym, pełne z różnicowym, pełne z dziennikami transakcyjnymi lub pełne z różnicowym i dziennikami transakcyjnymi. Wybór typu odtworzenia wymaga namysłu i uwzględnienia zakresu danych, które mają być odtworzone, oraz typu posiadanych kopii zapasowych.
Elementy odtworzenia Na odtworzenie danych bazy składa się wiele elementów. Zalicza się do nich rollforward set, sekwencje odtwarzania i przywracanie kopii. Rollforward set Rollforward set składa się z wszelkich danych, które mają być odtworzone, niezależnie od tego, czy to dane pełnej, częściowej czy innej kopii zapasowej. Sekwencja odtwarzania Sekwencja odtwarzania (restore sequence) jest definiowana jako grupa kopii zapasowych odtwarzanych w celu uzyskania spójnego stanu bazy. Te kopie są odtwarzane w odpowiedniej sekwencji, stąd nazwa. Przywracanie kopii Proces odtwarzania składa się z trzech faz: kopiowania danych, odtworzenia i wycofania transakcji. Faza kopiowania (data copy) polega na kopiowaniu wszystkich danych, dzienników i stron indeksów z kopii zapasowej do pliku bazy. W fazie odtworzenia transakcji (redo, nazywanej również fazą rollforward), transakcje zapisane w dzienniku transakcyjnym są odtwarzane, co powoduje, że do bazy zapisywane są zmiany, które nastąpiły po wykonaniu kopii zapasowej. Fazę redo można wykonać do określonego punktu w czasie (od ostatniej kopii zapasowej). Po tej fazie baza danych nadal jest w niespójnym stanie, ponieważ należy jeszcze przeprowadzić fazę wycofywania transakcji (undo). W tej fazie (w której odbywa się właściwe przywracanie kopii) wycofywane są wszelkie transakcje niezatwierdzone, co w końcu przywraca spójność danych w bazie. Faza wycofywania nie zawsze jest konieczna, jeśli faza odtwarzania spowoduje, że baza znajdzie się w spójnym stanie. W trakcie tego całego procesu wykonywany jest szereg sprawdzeń, które mają na celu zapobieżenie nadpisaniu istniejących baz danych lub istniejących plików.
Plan odtwarzania Procedura odtwarzania lub przywracania bazy danych bywa skomplikowana i mało zrozumiała. Prawdopodobnie najtrudniej jest jednak zdecydować, od czego właściwie zacząć. W tym punkcie opiszę więc podstawowy plan działań zmierzających do przywrócenia sprawności serwerowi. Proces odtwarzania i przywracania nie przyjmuje założeń, jeśli chodzi o przyczynę problemu z bazą danych. Przed próbą odtworzenia bazy danych z ostatniej kopii zapasowej zawsze warto sprawdzić, czy baza rzeczywiście znajduje się w stanie uniemożliwiającym naprawę. Jest kilka zagadnień, które warto sprawdzić. Gdy wszystkie z nich potwierdzą diagnozę, że baza danych jest uszkodzona, należy przejść do procedury odtwarzania i przywracania.
608 |
Rozdz ał 19. M crosoft SQL Server
Etap 1. — sprawdzenie błędów sprzętu lub serwera To zagadnienie jest zbyt obszerne, aby omówić je szczegółowo; dość wspomnieć, że w pierwszym etapie zawsze należy wyeliminować problemy z winy sprzętu i serwera. Oznacza to, że należy upewnić się, że sprzęt działa prawidłowo lub że wina nie leży po stronie systemu operacyjnego, a także czy są zainstalowane niezbędne poprawki.
Etap 2. — czy można połączyć się z egzemplarzem bazy z poziomu GUI lub za pomocą języka Transact-SQL? Lokalizując przyczynę problemu, w pierwszym kroku warto wykonać kilka podstawowych testów możliwości połączenia z bazą danych. To pozwoli ograniczyć listę potencjalnych problemów, jak również przygotuje do wykonania dodatkowych testów, omówionych w opisach następnych etapów. Jeśli nie uda się połączyć, należy sprawdzić, czy egzemplarz jest uruchomiony, a jeśli nie jest, należy podjąć próbę uruchomienia go. Jeśli nie uda się znaleźć oczywistych przyczyn problemów z uruchomieniem egzemplarza, należy rozpocząć procedurę poszukiwania przyczyn, począwszy od dziennika zdarzeń i plików dzienników. Jeśli uda się podłączyć do egzemplarza, należy przejść do etapu 3.
Etap 3. — czy uda się podłączyć do bazy master? Jeśli egzemplarz działa, następnym etapem jest próba podłączenia bazy master. Należy pamiętać, że bez bazy master nie mogą działać jakiekolwiek inne bazy. Jeśli podłączenie do tej bazy nie powiedzie się, należy podjąć działania opisane w podrozdziale dotyczącym odtwarzania bazy master. Jeśli uda się podłączyć do bazy master, należy przejść do etapu 4.
Etap 4. — czy uda się podłączyć do określonej bazy niesystemowej? Zbliżamy się do sedna problemu. Na tym etapie wiemy już, że sprzęt i system operacyjny są w porządku, że egzemplarz silnika baz danych działa i że baza master jest nienaruszona. Jeśli udałoby się podłączyć do dowolnej niesystemowej bazy danych, problem byłby w zasadzie rozwiązany. Niestety, prawdopodobnie nie będzie jednak aż tak różowo. W pierwszym kroku należy sprawdzić stan bazy danych. Służy do tego następujące polecenie: select databasepropertyex('Inventory', 'Status');
Polecenie to zwraca wartość reprezentującą aktualny stan wskazanej bazy danych. W tym przykładzie możliwymi stanami są: online, offline, restoring, recovering, suspect i emergency. Te wartości pozwalają zorientować się co do stanu sprawności bazy. Od tego wyniku uzależniony jest szacowany czas potrzebny na odtworzenie bazy. Na przykład w przypadku, gdy stan ma wartość offline, prawdopodobnie wystarczy uruchomić bazę. Jeśli jednak stan ma wartość suspect lub emergency, prawdopodobnie określenie przyczyny problemu będzie bardziej pracochłonnym zadaniem. Po określeniu stanu należy kontynuować działania w etapie 5.
Etap 5. — wstępne sprawdzenia Na początku poszukiwań przyczyny problemów należy sprawdzić, czy w dzienniku systemowym nie znajdują się komunikaty o problemach. Należy również sprawdzić dzienniki generowane przez proces agenta; w szczególności cenne informacje można znaleźć w dziennikach błędów i ostrzeżeń.
Odtwarzan e przywracan e
| 609
Inna możliwość polega na uruchomieniu polecenia dbcc z parametrem checkdb (lub innym parametrem sprawdzającym): dbcc checkdb ('Inventory');
Jeśli program dbcc zwróci informację o błędach, należy przyjąć je jako punkt wyjścia w działaniach naprawczych. Istnieje wiele opcji sprawdzania baz danych za pomocą polecenia dbcc. Można sprawdzać całe bazy i pojedyncze tabele (za pomocą parametru checktable). Za pomocą parametrów checkalloc i checkcatalog można sprawdzić spójność alokacji przestrzeni dyskowej oraz katalogu. Wyniki tych poleceń powinny doprowadzić do następnych etapów. Jeśli po zakończeniu działań baza danych nadal jest niesprawna, należy przejść do etapu 6.
Etap 6. — czy pliki danych są kompletne? Na tym etapie wykonamy dość oczywiste sprawdzenie. Na początek należy podjąć próbę uruchomienia bazy danych jednym z dostępnych sposobów. Jeśli pojawia się błąd przedstawiony na rysunku 19.8 (w przypadku uruchamiania z poziomu GUI), przyczyną problemu jest brak pliku.
Rysunek 19.8. Komunikat o brakującym pliku
W przypadku próby uruchomienia bazy danych za pomocą języka Transact-SQL komunikat o błędzie będzie miał następującą postać: alter database Inventory set online; Msg 5120, Level 16, State 101, Line 1 Unable to open the physical file "C:\Program FilesXMicrosoft SQL Server\MSSQL.l\MSSQL\DATA\Inventory.mdf". Operating system error 2: "2(The system cannot find the file specified.)". Msg 945, Level 14, State 2, Line 1 Database 'Inventory' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details. Msg 5069, Level 16, State 1, Line 1 ALTER DATABASE statement failed.
Brakujący plik danych można odtworzyć z pełnej kopii, po czym ponowić próbę uruchomienia bazy. Należy jednak pamiętać, że to nie zagwarantuje odzyskania najbardziej aktualnej zawartości tej bazy. Najczęściej dodatkowo konieczne jest odtworzenie danych z kopii przyrostowej i z dzienników transakcyjnych. Jeśli to nie wystarczy, aby przywrócić bazę do sprawności, należy przejść do etapu 7.
610
|
Rozdz ał 19. M crosoft SQL Server
Etap 7. — czy dziennik transakcyjny jest zapełniony? Jeśli w bazie danych dokonywana jest duża liczba modyfikacji, może to doprowadzić do zapełnienia dziennika transakcyjnego. Przyczyną zapełnienia dziennika może też być zapełnienie dysku, na którym jest zapisany, lub brak opcji automatycznego przyrostu (ang. auto-growth) dziennika. Przed zmianą ustawień dziennika transakcyjnego należy koniecznie wykonać kopię zapasową. Dzięki niej zawsze będzie możliwość powrotu do tego miejsca w przypadku wystąpienia nieoczekiwanych okoliczności. Oczywiście mamy tu do czynienia ze stanem awarii, ale dzięki kopii zapasowej będzie możliwość ponownego rozpoczęcia działań od bieżącego stanu. Jeśli przyczyną problemu jest zapełnienie dysku, na którym jest zapisany dziennik transakcyjny, można tymczasowo poprawić sytuację, przycinając dziennik, wykonując kopię zapasową lub zwalniając miejsce na dysku zajmowane przez zbędne pliki. Rozwiązaniem docelowym będzie przeniesienie dziennika transakcyjnego na nowy dysk o większej pojemności. Jeśli przyczyną nie jest zapełnienie dysku, a samego dziennika transakcyjnego, można uaktywnić opcje automatycznego przyrostu dziennika. Po uaktywnieniu tej opcji może okazać się konieczne wykonanie operacji dodania dodatkowego pliku dziennika. Szczegóły tej operacji są opisane w podrozdziale „Dziennik transakcyjny”. Jeśli miejsce w dzienniku transakcyjnym nie było przyczyną problemów, należy przejść do etapu 8.
Etap 8. — czy uda się naprawić bazę? Jeden ze sposobów rozwiązania problemów z bazą polega na uruchomieniu polecenia dbcc z opcją repair. Jedynie wspominam o tej możliwości, ale nie będę jej omawiał bardziej szczegółowo, ponieważ z reguły wiąże się z utratą danych. Informacje na temat tej metody można znaleźć w podręczniku polecenia dbcc. Tymczasem proponuję przejść do etapu 9.
Etap 9. — przygotowanie do procedury odtwarzania Najważniejszą rzeczą przed rozpoczęciem procedury odtwarzania bazy z kopii zapasowej jest określenie modelu odtwarzania, co ma zasadniczy wpływ na działania w trakcie operacji odtwarzania kopii zapasowej bazy. Więcej informacji na ten temat można znaleźć w podrozdziale „Modele odtwarzania”. Niezależnie od zastosowanego modelu odtwarzania przed jego zastosowaniem zawsze należy wykonać kopię systemu. Dzięki niej, w przypadku problemów z odtworzeniem danych z kopii, będzie możliwość powrotu do bieżącego stanu.
W przypadku modelu odtwarzania typu simple należy przejść do etapu 10. W przypadku modelu odtwarzania typu full lub bulk logged należy przejść do etapu 11.
Etap 10. — odtwarzanie danych w modelu simple Odtwarzanie danych w prostym modelu odtwarzania (simple) to proste zadanie (stąd nazwa). W tym modelu nie są odtwarzane dzienniki transakcyjne, więc procedura jest dość oczywista: odtwarza się ostatnią pełną kopię zapasową, ewentualnie kopie różnicowe lub przyrostowe, i koniec!
Odtwarzan e przywracan e
|
611
Etap 11. — odtwarzanie danych w modelu full lub bulk logged W modelu full lub bulk logged odtwarzanie danych jest nieco bardziej skomplikowaną procedurą w porównaniu z modelem simple, ponieważ w tym przypadku muszą być uwzględnione dzienniki transakcyjne. Należy wykonać następujące działania:
1. Odtworzenie ostatniej pełnej kopii zapasowej. 2. Jeśli istnieją kopie różnicowe, należy je również odtworzyć. 3. Odtworzenie dzienników transakcyjnych. Przed rozpoczęciem odtwarzania należy wykonać kopię aktualnej wersji bazy danych i dzienników transakcyjnych!
Odtwarzanie bazy danych W tym punkcie opiszę działania, które należy wykonać w celu pełnego odtworzenia kopii bazy wykonanej w punkcie „Wykonywanie kopii zapasowych”. Oto procedura dla 2005 Management Studio:
1. Uruchomić SQL Server Management Studio, połączyć się z egzemplarzem, w którym znajduje się baza danych, i rozwinąć gałąź Databases.
2. Wybrać bazę danych do odtworzenia, kliknąć prawym przyciskiem myszy, wybrać funkcję Tasks/Restore/Database.
3. Na stronie General wybrać bazę danych, która ma zostać odtworzona. Jeśli baza danych nie istnieje, należy wprowadzić nazwę dla nowej bazy.
4. Wybrać punkt w czasie. Jeśli nie interesuje nas konkretny moment, wybieramy opcję Most Recent Possible (możliwie aktualna wersja).
5. Określić lokalizację kopii zapasowej do odtworzenia (plik albo urządzenie). 6. Wybrać zbiory kopii (backup set) do odtworzenia i kliknąć OK. 7. Ustawić opcje na stronie Options: a. Ustawić opcję nadpisania istniejącej bazy. b. Ustawić stan bazy po odtworzeniu. Ten stan jest uzależniony od planowanych działań po zakończeniu odtwarzania. Jeśli kopia zapasowa zawiera wszelkie niezbędne informacje do wykonania pełnego odtworzenia, należy zaznaczyć opcję Leave The Database Ready To Use (ustawić w trybie gotowym do użycia). Jeśli jednak po odtworzeniu bazy planujemy wykonać dodatkowe działania przed jej włączeniem w tryb online, mamy do dyspozycji dwie opcje: Leave Database Non-Operational (pozostawić bazę nieaktywną) oraz Leave Database In Read-Only Mode (pozostawić bazę w trybie do odczytu). Pierwsza opcja jest typowa dla ręcznego trybu odtwarzania: baza zostaje odtworzona z kopii (pełnej, różnicowej; dane mogą też zostać uzupełnione z dzienników transakcyjnych), ale po odtworzeniu pozostaje nieaktywna, aby można było wykonać dalsze działania. Do tych działań zalicza się między innymi odtworzenie transakcji z innych kopii. Opcja Leave Database In Read-Only Mode ma podobne działanie, z tą
612
|
Rozdz ał 19. M crosoft SQL Server
różnicą, że po zakończeniu odtwarzania baza danych jest uruchamiana, ale w trybie tylko do odczytu, co pozwala odtworzyć dane z dzienników transakcyjnych. W tym trybie można uruchamiać testy sprawdzające spójność bazy i weryfikujące ich poprawność. Okno Restore Database zostało przedstawione na rysunku 19.9. Procedura jest w zasadzie identyczna dla wersji 2005 i 2000, jedynie kilka opcji ma nieco inne etykiety.
Rysunek 19.9. Okno odtwarzania bazy danych
Opisana wyżej procedura dotyczy najbardziej podstawowej metody odtwarzania. W zależności od planu wykonywania kopii zapasowych może oczywiście być konieczne odtworzenie różnicowych kopii zapasowych i dzienników transakcyjnych.
Odtwarzanie danych za pomocą języka Transact-SQL Podobnie jak w przypadku wykonywania kopii zapasowej, z poziomu języka Transact-SQL można odtworzyć kopię zapasową. Następujące polecenie Transact-SQL odtwarza bazę danych Inventory: restore database Inventory from disk = 'E:\Backups\cmd_Inventory.bak'
Możliwe jest również odtworzenie indywidualnych plików i grup plików zapisanych w kopii. Jeśli obiekt jest zapisany w większej liczbie grup plików, należy odtworzyć wszystkie pliki zawierające jego dane.
Odtwarzan e przywracan e
|
613
Odtwarzanie bazy master Baza master zawiera informacje konfiguracyjne dotyczące wszystkich innych baz danych oraz informacje konfiguracyjne serwera, dlatego bardzo istotne jest wykonywanie kopii zapasowych tej bazy i opanowanie procedury jej odtwarzania. Niestety, nie zawsze jest łatwo stwierdzić, że problem jest rzeczywiście z bazą master. Gdy nie ma możliwości podłączenia się do egzemplarza bazy danych, nie można stwierdzić, czy wina leży po stronie bazy. Gdy jednak uda się stwierdzić, że winę ponosi uszkodzenie bazy master, są dwa sposoby naprawy problemu. Jeśli SQL Server uruchamia się, można połączyć się z nim i odtworzyć bazę master. Ten proces jest dokładnie taki sam jak w przypadku dowolnej innej bazy. Należy jedynie pamiętać, że w przypadku bazy master jedyną formą odtwarzania jest pełne (full). Należy też pamiętać, że ponieważ nie można odtworzyć dzienników transakcyjnych ani kopii różnicowych, po odtworzeniu bazy master z pełnej kopii zapasowej może się ona znajdować w innym stanie niż w chwili uszkodzenia. W takim przypadku jedyne rozwiązanie polega na ponownym, ręcznym wprowadzeniu niezbędnych modyfikacji. Jeśli SQL Server nie uruchamia się, można odbudować bazę master z poziomu programu instalacyjnego SQL Servera. Następnie należy uruchomić SQL Server i odtworzyć tę bazę z kopii zapasowej. Podobnie jak w poprzedniej opcji należy ręcznie wprowadzić niezbędne poprawki. Opcja Rebuild Master programu instalacyjnego odbudowuje również bazy msdb i model. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
614
|
Rozdz ał 19. M crosoft SQL Server
ROZDZIAŁ 20.
Exchange
Exchange Server służy do wysyłania i odbierania wiadomości pocztowych oraz innych treści z wykorzystaniem połączonych sieci komputerowych. Ponadto zawiera kolekcję narzędzi do wspomagania pracy grupowej. Wszystkie te funkcje wykorzystują specjalizowaną bazę danych pozwalającą na wykonywanie zaawansowanych funkcji i zapewniającą dużą konfigurowalność. W tym rozdziale omówię zagadnienia związane z wykonywaniem i odtwarzaniem kopii zapasowych danych oraz odtwarzaniem po katastrofie systemu Exchange Server (który dla ułatwienia będę od tej pory nazywał serwerem Exchange). Przy tworzeniu tego rozdziału uzyskałem znaczną pomoc od Scotta Harrisa. Scott to świeżo upieczony ojciec, którego zmartwieniem jest obecnie to, w jakim wieku jego synek powinien rozpocząć naukę PHP.
Architektura serwera Exchange Aby zrozumieć zagadnienia związane z wykonywaniem i odtwarzaniem kopii zapasowych serwera Exchange, należy zrozumieć jego architekturę. Omówię tu projekt architektury mechanizmu backend serwera Exchange, po czym omówię kilka zagadnień specyficznych dla jego działania.
Struktura bazy danych Serwer Exchange to w zasadzie baza danych przeznaczona specjalnie do przechowywania i przetwarzania wiadomości pocztowych i innych danych o podobnej strukturze. Doskonałe wprowadzenie do omówienia serwera Exchange stanowi wyjaśnienie struktur leżących u podstaw działania jego architektury. Podstawowa technologia baz danych wykorzystywana w serwerze Exchange nosi nazwę Extensible Storage Engine (ESE) i stanowi specjalizowaną wersję technologii Joint Engine Technology (JET) firmy Microsoft. W serwerach Exchange Server 2000 i 2003 wykorzystywana jest wersja ESE98 tej technologii (Active Directory, technologia ściśle związana z serwerem Exchange, wykorzystuje wersję ESENT).
615
Między poszczególnymi wydaniami serwera Exchange istnieją znaczące różnice, jednak większość informacji zawartych w tym rozdziale ma zastosowanie zarówno do wersji 2000 serwera, jak i 2003. Wszystkie zrzuty ekranu zostały wykonane w Exchange Server 2003. Wszelkie znaczące różnice są wyszczególnione w opisie. W okresie tworzenia tej książki firma Microsoft oficjalnie kontynuowała prace nad pełną integracją mechanizmów baz danych wykorzystywanych w Exchange z technologią SQL Server. Czytelnik będzie miał okazję osobiście przekonać się, czy to rzeczywiście nastąpi, a jeśli tak, to kiedy.
Baza danych w architekturze ESE swoje dane zapisuje w plikach. Dwa pliki, jeden z rozszerzeniem .edb, drugi z rozszerzeniem .stm, tworzą zasób składowania (ang. store). Zasoby składowania można grupować, tworząc grupę składowania (ang. storage group). Grupa składowania ma określony wspólny zestaw dzienników transakcyjnych dla wszystkich nośników składowania wchodzących w skład grupy. Ten fragment architektury został przedstawiony na rysunku 20.1.
Rysunek 20.1. Dzienniki transakcyjne wspólne dla wszystkich zasobów w ramach grupy składowania
Gdy już Czytelnik zapoznał się ze sposobem organizacji architektury systemu Exchange Server, mogę obszerniej omówić każdy z jej elementów.
Extensible Storage Engine Serwer Exchange wykorzystuje transakcyjną bazę danych o architekturze przypominającej inne klasyczne, komercyjne bazy danych. ESE obsługuje wszystkie znane funkcje typowego języka Data Manipulation Language, jakie znamy z klasycznych baz danych: operacje wstawiania, aktualizacji, wydobywania i usuwania danych. Te elementy języka DML są wiązane w atomowe całości w ramach transakcji. Transakcje stanowią podstawowy mechanizm zapewnienia spójności bazy danych; pozwalają na wycofywanie zmian (rollback) wprowadzonych przez część transakcji w przypadku wystąpienia problemu na dalszych etapach jej realizacji. Jeśli transakcja wykona się w całości bez problemów, jej zmiany zostaną wprowadzone do bazy (commit). Aby zrozumieć transakcyjną naturę serwera Exchange, warto przeanalizować typową sesję przenoszenia wiadomości z jednego folderu pocztowego do drugiego (nie do pliku typu .pst). Mechanizm ESE działa w trybie izolacji na poziomie migawek (snapshot isolation mode); każda transakcja ma zagwarantowany dostęp do spójnej postaci bazy w czasie wykonania operacji. Na początku transakcji w specjalnej strukturze w pamięci operacyjnej (ang. version store) zapisywane są polecenia usuwające wiadomość z folderu pocztowego. Jeśli ta operacja zakończy się powodzeniem, w version store zapisywane są polecenia zapisujące wiadomość w folderze
616
|
Rozdz ał 20. Exchange
docelowym. Gdy wszystkie te operacje zakończyły się sukcesem, transakcja jest realizowana, to znaczy wszelkie zmiany zachodzące w jej trakcie są fizycznie zapisywane na dysku. Jeśli do tego miejsca operacja jest nadal zakończona sukcesem, transakcja jest finalizowana (ang. commit), w przeciwnym razie transakcja jest wycofywana (ang. rollback) i w bazie nie są zapisane jakiekolwiek zmiany.
Zasoby składowania Czytelnik już wie, w jaki sposób Exchange uzyskuje dostęp do danych, musi jednak wiedzieć, gdzie dane są zapisane. Serwer Exchange zapisuje swoje bazy danych w obiektach określanych jako store (zasoby składowania). Każdy taki zasób składa się z dwóch plików: pliku .edb, zawierającego dane w formacie sformatowanego tekstu (ang. rich text), oraz .stm, zawierającego dane w formacie natywnym (ang. native content database). Pliki .edb są przeznaczone specjalnie do zapisu danych w formacie MAPI (Messaging Application Programming Interface), sum kontrolnych plików .edb i .stm oraz tabel wykorzystywanych przez proces store.exe. Pliki .stm zawierają dane w standardowym formacie wiadomości internetowych, czyli MIME (Multipurpose Internet Mail Extensions). Pliki .edb obsługują większość danych, a główną rolą baz danych .stm jest obsługa klientów niekompatybilnych z formatem MAPI. Rysunek 20.2 przedstawia standardowe lokalizacje plików zasobów składowania w standardowej instalacji serwera Exchange. W przypadku domyślnego zasobu składowania skrzynek pocztowych pliki .edb i .stm są tworzone w katalogu C:\Program Files\Exchsrvr\mdbdata\. Dotyczy to serwera w wersji 2000 i 2003.
Rysunek 20.2. Nazwy plików zasobów składowania
Wszystkie instalacje Exchange mają zasoby składowania poczty oraz folderów publicznych. Zasób składowania poczty zawiera prywatne dane pocztowe użytkowników, a zasób folderów publicznych zawiera informacje publiczne lub współdzielone. Pliki bazy danych w domyślnym
Arch tektura serwera Exchange
|
617
zasobie poczty noszą nazwy privl.edb i privl.stm, pliki zasobów folderów publicznych to publ.edb i publ.stm. W Exchange Server 2003 Standard Edition (przed wersją Service Pack 2) oraz w Exchange 2000 te bazy danych mogły mieć rozmiary do 16 GB. Exchange Server 2003 Standard Edition z SP 2 jest już w stanie obsłużyć te bazy danych o rozmiarach do 75 GB każda. W Exchange Server 2003 i 2000 Enterprise Edition rozmiary tych baz są ograniczone do 16 TB. Rysunek 20.3 przedstawia domyślne grupy i zasoby składowania. W przykładach będę posługiwał się przykładową nazwą serwera EXCH2003.
Rysunek 20.3. Domyślne grupy składowania i zasoby składowania
Grupy składowania Grupy składowania są wykorzystywane do zarządzania jednym lub większą liczbą zasobów składowania. Exchange Server 2000 i 2003 może obsługiwać do czterech grup składowania, a każda z grup może zawierać do pięciu zasobów składowania. Grupy składowania są stosowane w celu zmniejszenia liczby plików dzienników, a przez to również liczby operacji na tych plikach, których byłoby znacznie więcej w przypadku zastosowania osobnych plików dzienników dla każdego zasobu składowania. Dodatkowa zaleta grupowania zasobów polega na tym, że oprócz wspólnych plików dzienników można w ich przypadku stosować ujednolicone mechanizmy zarządzania. Dotyczy to ustawień kopii zapasowych lub terminarza wykonywania tych kopii. Grupy składowania składają się z wielu elementów, w tym z plików dzienników transakcyjnych, plików punktów przywracania, plików dzienników rezerwowych oraz plików tymczasowych.
Pliki dzienników transakcyjnych Plik dziennika transakcyjnego zawiera historię każdej operacji zachodzącej w danej grupie składowania. Transakcje są zapisywane w sposób sekwencyjny w plikach dzienników oraz w pamięci operacyjnej. Z uwagi na prostotę i wydajność transakcje są po prostu dopisywane na końcu pliku transakcyjnego; w przypadku finalizacji transakcji te same operacje są wykonywane we właściwej bazie danych. Ta metoda ma tę zaletę, że operacje odbywają się szybko, a dodatkowo zapewnia doskonałe możliwości odtwarzania zmian w bazie danych w przypadku
618
|
Rozdz ał 20. Exchange
awarii serwera. Jeśli zostanie utracona transakcja zapisana w pamięci, istnieje duża szansa, że zachowała się transakcja zapisana w pliku dziennika transakcyjnego. Pliki dziennika transakcyjnego w serwerze Exchange mają zawsze rozmiar 5 MB. Plik dziennika o stałym rozmiarze ma przewagę nad przyrastającym plikiem, ponieważ nie ma konieczności obsługi mechanizmów zwiększania rozmiaru (ang. grow) oraz przycinania (ang. shrink) pliku dziennika. Przy uruchomieniu serwer Exchange tworzy plik dziennika o rozmiarze 5 MB o nazwie E.log, gdzie to numer kolejny, począwszy od 00, zgodnie z kolejnością tworzenia grup składowania. Na przykład pierwsza domyślna grupa składowania tworzona przy instalacji serwera Exchange, o nazwie First Storage Group (pierwsza grupa składowania), wykorzystuje plik dziennika o nazwie E00.log. Gdyby utworzyć drugą grupę składowania, jej plik dziennika miałby nazwę E01.log i tak dalej. Rysunek 20.4 przedstawia domyślną lokalizację składowania oraz nazwy dzienników transakcyjnych dla Exchange Server 2000 i 2003.
Rysunek 20.4. Domyślna lokalizacja zasobu składowania i dzienników
Ten plik w pewnym momencie zostaje wypełniony, co powoduje, że ESE zmienia jego nazwę na E.log i tworzy nowy plik o tej samej nazwie E.log. Numeracja wypełnionych plików dziennika jest szesnastkowa i rozpoczyna się od 00001, zatem w przypadku pliku dziennika pierwszej grupy składowania będzie to plik o nazwie E0000001.log. Ten proces jest powtarzany za każdym razem, gdy plik dziennika zostaje zapełniony. Przerwanie tego procesu jest możliwe w jednym z dwóch przypadków: gdy liczba utworzonych plików dziennika osiągnie dozwolone maksimum, co spowoduje zapis odpowiedniego komunikatu w dzienniku błędów, po czym zasób składowania zostanie odmontowany w sposób prawidłowy, lub gdy administrator zainicjuje proces wykonania kopii zapasowej w jeden ze sposobów powodujących wyczyszczenie zbędnych plików dziennika.
Grupy składowan a
|
619
Pliki punktów przywracania Pliki punktów przywracania mają duże znaczenie, ponieważ zawierają informacje o tym, jak bardzo zaawansowany jest proces zapisu zawartości plików dzienników transakcyjnych bezpośrednio do bazy. Bez tych informacji nie byłoby możliwości stwierdzenia, od którego miejsca system musi kontynuować odtwarzanie danych z dzienników transakcyjnych w przypadku odtwarzania danych z kopii lub procedury naprawczej. W praktyce oznaczałoby to konieczność odtworzenia każdej transakcji od momentu wykonania ostatniej kopii zapasowej. Pliki punktów przywracania są nazywane zgodnie z zasadą zbliżoną do stosowanej przy plikach dziennika transakcyjnego: E.chk. Plik punktu przywracania dla pierwszej grupy składowania nosi nazwę E00.chk. Dla każdej grupy składowania tworzony jest tylko jeden plik przywracania, a jego rozmiar to zawsze 8 kB. Plik punktu przywracania zawiera wskaźnik na najstarszy plik dziennika w grupie składowania, którego transakcje są już załadowane w bazie danych. Gdy wszystkie transakcje w pliku dziennika są skutecznie zapisane w bazie, punkt przywracania jest przenoszony do następnego pliku w sekwencji, zawierającego kolejne, niezapisane dotychczas dane. W przypadku awarii serwera lub bazy ESE odczytuje zawartość pliku punktu przywracania, skąd uzyskuje informację o nazwie pliku dziennika transakcyjnego zawierającego utracone transakcje. ESE odtwarza te utracone transakcje, zapisując w bazie danych wszystkie transakcje nowsze od ostatniej prawidłowo zapisanej transakcji określonej w pliku punktu przywracania. Wszystkie transakcje niezakończone są pomijane. Jak już wspomniałem, plik E.log nie jest niezbędny do odtworzenia transakcji. ESE może stwierdzić, które transakcje są już zapisane w bazie, przeglądając pliki dziennika transakcyjnego — sekwencyjnie i pojedynczo. Wykorzystanie pliku punktu przywracania pozwala uniknąć konieczności przeglądania wszystkich plików dziennika transakcyjnego od początku, dzięki czemu nie trzeba przeglądać zawartości często setek, a nawet tysięcy plików, aby znaleźć odpowiedni punkt, od którego należy odtworzyć transakcje.
Pliki dzienników rezerwowych Dla każdej grupy składowania ESE rezerwuje dwa pliki o nazwach resl.log i res2.log. Te pliki są wykorzystywane jako zapas na wypadek zapełnienia się miejsca na dysku serwera, gdy nie byłoby możliwości zapisu kolejnego pliku dziennika transakcyjnego. Pliki dzienników rezerwowych mają takie same rozmiary jak zwykłe pliki dziennika; jedyna różnica polega na tym, że w normalnej sytuacji nie są wykorzystywane, a tylko stanowią rezerwę miejsca na dysku. Są wykorzystywane jedynie wówczas, gdy serwer Exchange ma poniżej 5 MB miejsca na dysku, przez co nie może utworzyć nowego pliku dziennika. W takim przypadku ESE wykorzysta jeden z plików rezerwowych. Do takiego pliku są natychmiast przepisywane operacje zapisane w pamięci, po czym bazy danych z grupy składowania są odmontowywane. Oczywiście w takiej sytuacji użytkownicy tracą dostęp do danych, a informacji o problemie należy szukać w dzienniku zdarzeń (Event Log).
620
|
Rozdz ał 20. Exchange
Dodatkowe informacje o dziennikach Pliki dziennika mają te same nazwy w różnych grupach składowania. Aby śledzić przynależność każdego dziennika do grupy składowania, ESE do nazwy pliku dziennika dodaje sygnaturę. Po utworzeniu pierwszego pliku archiwum dziennika E000001.log ta sygnatura jest przypisana na stałe. Rotacja plików dziennika odbywa się według następującej zasady: gdy aktualny dziennik o nazwie E.log osiągnie granicę swojej objętości, tworzony jest plik Etemp.log. Nazwa oryginalnego pliku dziennika jest zmieniana na nazwę archiwalną, z szesnastkowym numerem kolejnym, a nazwa pliku Etemp.log zostaje zmieniona na E.log. Ten proces jest powtarzany za każdym razem, gdy plik dziennika zapełnia się.
Dzienniki pierścieniowe Dzienniki pierścieniowe (ang. circular logs) działają w taki sposób, że transakcje zapisane do bazy danych mogą być na bieżąco nadpisywane przez nowe transakcje. To doskonałe rozwiązanie dla serwerów pośredniczących, jedynie przekazujących pocztę i niemagazynujących jej, ponieważ pozwala na znaczne oszczędności miejsca na dysku, niezbędnego dla dzienników. Podstawowa wada tego rozwiązania polega na tym, że z tego typu dzienników nie można odtworzyć transakcji w przypadku konieczności odtworzenia danych w bazie z kopii zapasowej w punkcie czasu, zatem dane można odtworzyć jedynie w punkcie wykonania ostatniej kopii zapasowej. W przypadku tego typu dzienników istnieje jedynie możliwość wykonywania pełnych kopii zapasowych; kopie przyrostowe i różnicowe nie są obsługiwane. Dzienniki pierścieniowe wykorzystują miejsce zwolnione przez transakcje zapisane w bazie. Zwykłe (niepierścieniowe) dzienniki przyrastają stale aż do momentu zapisu pełnej kopii zapasowej bazy (lub po wyczerpaniu maksymalnej dopuszczalnej liczby plików), choć jednocześnie rzeczywiście wykorzystywanych jest tylko kilka plików, najczęściej cztery. Dzienniki pierścieniowe działają na zasadzie nadpisania najstarszego pliku nowym plikiem dziennika transakcyjnego, chyba że rozmiar transakcji przekracza 5 MB. W takim przypadku tworzony jest nowy plik, aż do przesunięcia punktu przywracania. Po takim przesunięciu nowo utworzone pliki z reguły nie są potrzebne i są usuwane w ramach procedury zapisu kopii zapasowej. Należy wyraźnie zaznaczyć, że taka konfiguracja jest niezalecana w przypadku serwerów Exchange, w których zapisywane są dane użytkowników. Tego typu konfiguracja działa najlepiej w przypadku serwerów przekazujących pocztę, w których nie są skonfigurowane skrzynki użytkowników ani foldery publiczne, lub serwerów NNTP, w których dane nie są przechowywane przez dłuższy czas. Innymi słowy, tego typu konfiguracja jest dopuszczalna tam, gdzie miejsce na dysku jest ważniejsze od możliwości odtworzenia kompletnych danych serwera.
Inne pliki W katalogu danych serwera Exchange można znaleźć również dodatkowe pliki, które nie zawsze występują, ale pojawiają się od czasu do czasu. To są pliki tymczasowe i stanowią efekt normalnego działania serwera Exchange.
Grupy składowan a
|
621
E00tmp.log Ten plik jest tworzony przez ESE na potrzeby tymczasowego zapisu danych na etapie zmiany nazwy dziennika transakcyjnego i tworzenia nowego pliku. tmp.edb Ten plik jest tworzony, gdy Exchange Server potrzebuje tymczasowego zasobu składowania na potrzeby działań administracyjnych, tabel tymczasowych, sortowania i tworzenia indeksów. Pliki stf Te pliki tymczasowe są tworzone przez proces IMAIL w trakcie konwersji formatów wiadomości. Pliki IFS Te pliki tymczasowe są tworzone przez ExIFS i zawierają bufor listy katalogów ExIFS. Rysunek 20.5 przedstawia reprezentację rozmiarów plików w mało obciążonym serwerze Exchange. Mamy tu przykłady praktycznie wszystkich z omówionych typów plików. Warto zauważyć, że pliki dzienników transakcyjnych (E0000335.log i E0000336.log) zwiększyły rozmiary od wykonania ostatniej kopii zapasowej i że rozmiary plików odpowiadają opisanym wyżej zasadom. Plik punktu przywracania ma rozmiar 8 kB, a pliki dzienników transakcyjnych i dzienników rezerwowych mają rozmiary 5 MB.
Rysunek 20.5. Dzienniki transakcyjne w serwerze Exchange
Składowanie pojedynczego egzemplarza Serwer Exchange wykorzystuje doskonałą technikę oszczędzania miejsca na dysku, określaną jako składowanie pojedynczego egzemplarza (single instance storage). Gdy jedna wiadomość jest wysyłana do kilku odbiorców posiadających konta na tym samym serwerze Exchange, wiadomość będzie zapisana tylko raz, a w pozostałych skrzynkach będzie zapisane jedynie odwołanie do danej wiadomości. Ta funkcja działa w zakresie zasobu składowania. Należy pamiętać, że w przypadku, gdy wiadomość jest wysyłana do odbiorców, których dane są zapisane w różnych zasobach składowania, grupach składowania czy serwerach, w każdym z tych zasobów składowania, w każdej grupie składowania czy na każdym z serwerów zostaje zapisany jeden 622
|
Rozdz ał 20. Exchange
egzemplarz wiadomości. Na przykład, jeśli wiadomość jest wysyłana do dwóch adresatów posiadających konta na dwóch serwerach, zostaje zapisana dwa razy. Jeśli jednak wiadomość jest wysyłana do dwóch adresatów, których dane są zapisane w tym samym zasobie składowania, zostaje zapisana tylko raz.
Automatyzacja utrzymania bazy danych Automatyzacja utrzymania bazy danych dotyczy zadań wykonywanych z częstotliwością określoną na karcie Database okna konfiguracyjnego. W ramach tego procesu może być wykonywanych mnóstwo operacji, ale nie będziemy się nimi zajmować szczegółowo; interesuje nas jedynie związek tych operacji z procedurą wykonywania kopii zapasowych. Warto zwrócić uwagę na zagadnienie planowania (ang. scheduling). Zadania wykonywane w ramach automatyzacji mogą intensywnie wykorzystywać procesor, dlatego powinny być planowane do wykonania w okresie, gdy z serwera korzysta najmniejsza liczba użytkowników. Na tym samym serwerze może działać większa liczba grup składowania, dlatego należy tak rozłożyć w czasie zautomatyzowane operacje wykonywane na każdej z nich, aby zminimalizować ryzyko, że będą wykonywane w tym samym czasie, co miałoby niekorzystne skutki dla wydajności.
Ograniczenia zasobów składowania Exchange 2003 Standard Edition może mieć określoną tylko jedną grupę składowania zawierającą skrzynki pocztowe oraz jeden zasób folderów publicznych. Maksymalny rozmiar zasobów do wersji Exchange 2000 i 2003 Service Pack 2 wynosił 16 GB. Od wydania Service Pack 2 ten limit wynosi 75 GB. W Exchange Server 2003 Enterprise Edition można określić do czterech grup składowania, a każda z nich może zawierać do pięciu baz danych, czyli zasobów składowania skrzynek pocztowych lub folderów publicznych. Maksymalny rozmiar każdego zasobu składowania wynosi 16 TB.
Wykonywanie kopii zapasowych Gdy Czytelnik zapoznał się z elementami architektury serwera Exchange, możemy przejść do omawiania zagadnień wykonywania i odtwarzania kopii zapasowych. Zacznijmy od strategii.
Strategia wykonywania kopii zapasowych Strategia wykonywania kopii zapasowych ma zasadniczy wpływ na sukces lub porażkę w sytuacji odtwarzania systemu i jego danych. Dobry administrator systemu Exchange nie powinien myśleć w kategoriach, „czy” jakieś urządzenie lub oprogramowanie zawiedzie, lecz „kiedy” to nastąpi. Stosowanie aktywnej postawy w opracowywaniu strategii wykonywania kopii zapasowych pozwala upewnić się, że kopie są wykonywane w regularnych odstępach czasu i że zawierają użyteczne i niezbędne dane. Dobrze opracowana strategia może spowodować, że odtworzenie danych będzie prostym zadaniem, wykonywanym w bardzo krótkim czasie. Przy opracowywaniu strategii wykonywania kopii zapasowych należy mieć na uwadze kilka czynników. Czy organizacja ma ustalony plan przywracania systemów po katastrofie (ang. disaster recovery plan, DRP), narzucający zasady działania? Jeśli na przykład w działaniach Wykonywan e kop zapasowych
|
623
biznesowych biorą udział jednostki państwowe, organizacja może podlegać ścisłym regułom określającym zakres i częstotliwość wykonywania kopii zapasowych. Czy departament IT ma umowę typu SLA (ang. service-level agreement, umowa określająca poziom usług). Taki dokument może również określać czasy reakcji na awarie skrzynek pocztowych lub zasady, które muszą być przestrzegane przy świadczeniu usług. Rozważając strategię kopii zapasowych, trzeba również uwzględnić techniczną stronę zagadnienia. Ile czasu zajmie proces wykonywania kopii zapasowej? Ile miejsca na dysku potrzebuję do wykonywania różnych typów kopii zapasowych? Czy za każdym razem wykonywać pełne kopie zapasowe, czy wystarczą różnicowe lub przyrostowe?
Typy kopii zapasowych Typ kopii zapasowej określa się za pomocą listy rozwijanej Default Backup Type w karcie Backup Type okna Options programu ntbackup (rysunek 20.6). Każdy typ zostanie omówiony w kolejnych podpunktach. W Exchange 2000 wystarczy uruchomić kreatora kopii zapasowych (kliknąć Start/Uruchom i wywołać polecenie backup) i na stronie Type of Backup określić typ kopii zapasowej. Zrzuty ekranu w dalszej części rozdziału dotyczą systemu Exchange Server 2003. W wersji 2000 są dostępne prawie te same opcje, a jedyna różnica polega na typie interfejsu użytkownika, którym w tym przypadku jest kreator kopii zapasowych.
Rysunek 20.6. Typy kopii zapasowych
Pełna kopia Pełna kopia zapasowa (normal albo full) to w przypadku serwera Exchange najbezpieczniejsza opcja. Ten typ kopii zapasowych zapewnia wykonanie pełnej kopii danych przeznaczonych do archiwizacji. Pełną kopię zapasową należy wykonywać regularnie, ponieważ jednym z działań jest wyczyszczenie plików dzienników transakcyjnych. Jeśli te dzienniki nie są czyszczone, może dojść do przekroczenia ich maksymalnej liczby. Ten limit jest dość wysoki i w przypadku Exchange 2003 wynosi 1 048 540 plików, jednak w przypadku środowiska o dużej liczbie operacji również ten limit jest możliwy do przekroczenia. Należy pamiętać, że choć pełne kopie zapasowe czyszczą stare pliki dzienników transakcyjnych, zdarzają się sytuacje, gdy tak się nie dzieje. Jeśli zostanie odmontowana baza danych w samej grupie składowania, pliki transakcyjne 624 |
Rozdz ał 20. Exchange
tej grupy nie zostaną oczyszczone po wykonaniu kopii zapasowej. Ponadto w przypadku, gdy nie będą zaznaczone do umieszczenia w kopii zapasowej wszystkie bazy danych w ramach danej grupy składowania, wyczyszczone zostaną tylko te dzienniki, które są zaznaczone jako objęte pełną kopią zapasową.
Zwykła kopia Zwykła kopia zapasowa serwera Exchange polega po prostu na skopiowaniu wszystkich plików Exchange Server na nośnik kopii zapasowej. Nie są wówczas czyszczone dzienniki transakcyjne, nie jest też aktualizowana data wykonania ostatniej kopii zapasowej. Podstawowa zaleta tej formy kopii zapasowych polega na tym, że taka kopia może zostać wykonana niezależnie od pozostałych form kopii zapasowych.
Kopia przyrostowa W Exchange Server 2003 przyrostowe (ang. incremental) kopie zapasowe obejmują wyłącznie pliki dziennika zapisane po wykonaniu ostatniej pełnej lub przyrostowej kopii zapasowej. Zaleta w tym przypadku polega na tym, że przyrostowe kopie zapasowe wykonują się znacznie szybciej od pełnych kopii. Jednak w przypadku odtwarzania systemu lub danych z takich kopii należy odtworzyć pełną kopię zapasową i wszystkie kopie przyrostowe.
Kopia różnicowa Różnicowe kopie zapasowe mają podobne cechy, co kopie przyrostowe, ponieważ uwzględniają wyłącznie pliki dziennika. Jednakże w przeciwieństwie do kopii przyrostowych dzienniki transakcyjne nie są oczyszczane. Dzięki temu odtwarzanie bazy z kopii przyrostowej jest prostsze, ponieważ do działania niezbędna jest tylko ostania pełna kopia zapasowa i ostatnia kopia różnicowa. Wada tej metody polega na tym, że z faktu, iż dzienniki transakcyjne nie są oczyszczane wynika, iż liczba plików dziennika przyrasta z czasem i należy uważniej opracowywać strategię wykonywania kopii zapasowych, aby upewnić się, że od czasu do czasu dzienniki są czyszczone. W mniejszych organizacjach może okazać się, że to nie jest poważny problem, ale może nim być w przypadku serwerów Exchange obsługujących duże ilości danych.
Dzienna kopia Nie należy mylić pojęcia dziennej kopii zapasowej z potocznym pojęciem kopii zapasowych wykonywanych codziennie. W tym przypadku mamy bowiem do czynienia z kopią zapasową danych zmodyfikowanych w danym dniu. W przypadku dziennej kopii zapasowej dzienniki transakcyjne nie są czyszczone, podobnie jak w przypadku zwykłej kopii.
Określanie zawartości kopii Skuteczna kopia zapasowa serwera Exchange 2003 powinna zawierać nie tylko bazy danych i dzienniki transakcyjne. Do odtworzenia kopii może być bowiem niezbędna spora ilość informacji.
Wykonywan e kop zapasowych
|
625
Typowe dla Exchange Nie trzeba podkreślać, że w celu odtworzenia serwera Exchange należy odtworzyć wszystkie elementy tego systemu. Mam tu na myśli bazy, zasoby, grupy zasobów, dzienniki transakcyjne i pliki punktów przywracania. Inne ważne elementy serwera Exchange obejmują informacje o konektorach, indeks wyszukiwania pełnotekstowego (ang. full-text index), dzienniki śledzenia wiadomości (ang. message tracking logs), usługę replikacji (ang. site replication service), dane klastra Exchange, bazę danych SRS, samo oprogramowanie aplikacji, oprogramowanie firm trzecich, jak narzędzia antywirusowe przeznaczone dla serwera Exchange, oraz skrypty stworzone na potrzeby upraszczania pracy administratora.
Typowe dla Windows Kopia zapasowa serwera Exchange to kluczowy element strategii, ale nie mniej istotne jest sporządzenie kopii zapasowej systemu operacyjnego, w którym zainstalowany jest Exchange. W zależności od konfiguracji w tym systemie mogą znajdować się dane innych aplikacji, nie tylko serwera Exchange. Exchange na tym samym serwerze często towarzyszy Active Directory, a w przypadku Small Business Server ten sam serwer obsługuje wszystkie istotne usługi sieciowe. W rozdziale 11. znajduje się opis odzyskiwania uszkodzonego systemu Windows z kopii zapasowej, ale warto również w tym miejscu wspomnieć, że szczególnie przydatne jest wykonywanie kopii zapasowych następujących podsystemów systemu Windows (oprócz serwera Exchange): • rejestru, • metabazy IIS, • Active Directory, • plików systemu operacyjnego, • stanu systemu, • plików rozruchowych, • partycji rozruchowej, • informacji o partycjach, • bazy danych rejestracji komponentów COM+, • katalogu SYSVOL, • informacji DNS, • usługi klastra, • bazy usługi certyfikatów.
Czego nie kopiować wraz z systemem Windows W przypadku serwera Exchange należy zaopatrzyć się w odpowiednie oprogramowanie do wykonywania kopii zapasowych. Jeśli oprogramowanie tego typu nie ma funkcji integrujących z serwerem Exchange, służących do koordynacji procesu wykonywania kopii, istnieje ryzyko uszkodzenia bazy danych, a wykonana w ten sposób kopia nie nada się do odtworzenia stanu
626
|
Rozdz ał 20. Exchange
serwera Exchange. Aby tego uniknąć, przy wykonywaniu kopii zapasowych z użyciem niezintegrowanych narzędzi należy pominąć następujące elementy systemu: • pliki bazy danych i dzienników (zawartość folderu MDBDATA); • instalowane napędy systemów plików (installable filesystem drives, IFS).
Metody wykonywania kopii Dawno minęły już czasy, gdy administrator mógł pozwolić sobie na całkowite zatrzymanie bazy danych w celu wykonania kopii zapasowej. W Exchange Server 2003 kopie zapasowe online nie są zatem czymś nowym, ale zostały znacząco udoskonalone i są bezpieczniejsze niż we wcześniejszych wersjach. Od wersji 2000 nie ma powodu, aby zatrzymywać serwer Exchange lub odmontowywać zasoby na potrzeby wykonania prawidłowej i kompletnej kopii zapasowej. W rzeczywistości w Exchange 2003 można wyrządzić serwerowi sporo szkód, jeśli nie wykonuje się regularnych kopii zapasowych online. Powodem jest to, że dzienniki transakcyjne systematycznie „puchną”, a ich zawartość jest czyszczona dopiero w przypadku prawidłowego wykonania kopii zapasowej online. Ponadto w trakcie wykonania kopii zapasowej w Exchange 2000 i 2003 wykonywane są testy spójności. Jeśli takie testy zakończą się błędem, kopia zapasowa nie zostanie wykonana.
Kopie online Kopie zapasowe online (określane jako hot, czyli „na gorąco”) to obecnie standardowy typ kopii zapasowych serwera Exchange. Dodatkowo w ramach kopii online wykonywane są sumy kontrolne CRC (ang. cyclical redundancy check), co stanowi dodatkową weryfikację danych. W trybie offline tego typu kontrola nie jest przeprowadzana. Dodatkowo, jak już wspominałem, kopie online czyszczą przyrastające pliki dzienników transakcyjnych.
Kopie offline Kopie online to preferowany sposób wykonywania kopii serwera Exchange, ale zastosowanie znajdują również kopie offline. Podstawowa wada kopii zapasowych offline polega na tym, że kopiowana grupa składowania musi zostać odmontowana, co oznacza, że w czasie wykonywania kopii baza danych jest zupełnie niedostępna. Ta forma wykonywania kopii nie powoduje wyczyszczenia dzienników transakcyjnych i nie jest ustawiany znacznik wykonania pełnej kopii zapasowej. Rozwiązanie polega na wykonaniu kopii zapasowej czyszczącej dzienniki transakcyjne. Jedna z poważniejszych zalet kopii zapasowej offline polega na tym, że w ramach tej kopii można zapisać również dane konfiguracyjne serwera Exchange, takie jak informacja o połączeniach. Do zalet należą również łatwość i szybkość wykonywania kopii. Taką kopię można wykonać z użyciem programu ntbackup, można również po prostu skopiować pliki .edb i .stm, choćby za pomocą polecenia copy lub xcopy.
Kopie strumieniowe Microsoft Exchange Server 2003 obsługuje API, za pomocą którego można wykonywać kopie strumieniowe. Ta metoda pozwala na wykonywanie kopii zapasowych w formie strumienia danych na nośniku kopii zapasowej. Ta metoda zapewnia, że dane zapisane w kopii są zawsze aktualne.
Wykonywan e kop zapasowych
|
627
Kopie cienia Microsoft Exchange 2003 Service Pack 1 obsługuje dodatkową funkcję o nazwie Volume Shadow Copy Service (musi być uruchomiony w systemie Windows Server 2003). Ta technologia pozwala na wykonywanie migawek baz serwera Exchange. Te migawki mogą być w jednym z dwóch typów: clone lub copy-on-write (kopia przy zapisie). Jak sugeruje nazwa, migawka typu clone stanowi pełną kopię oryginalnych danych. Metoda copy-on-write zapisuje jedynie zmiany dokonane w oryginalnym woluminie od wykonania ostatniej migawki. Obie metody mogą być zaimplementowane programowo lub sprzętowo. Jednak tylko kopie wykonane sprzętowo można przenieść na inny serwer. Aby wykorzystać Volume Shadow Copy Service, mechanizm ten musi być zaimplementowany zarówno w aplikacji (w tym przypadku jest to serwer Exchange), jak i w urządzeniu do wykonywania kopii. Wyróżnia się trzy poziomy obsługi Volume Shadow Copy Service: Requestor Oprogramowanie, na przykład aplikacja do wykonywania kopii zapasowych, wykorzystujące funkcję shadow copy. Writer Element pozwalający na wykonywanie migawek, z reguły przeznaczony dla konkretnej aplikacji, na przykład Exchange czy SQL Server. Provider Oprogramowanie lub sprzęt zapisujące na nośniku. Program ntbackup wykorzystuje się w trybie Volume Shadow Copy Service requestor. Jednak należy pamiętać, że ntbackup requestor wykorzystuje wyłącznie metodę copy-on-write. Aby wykonać kopię zapasową z wykorzystaniem drugiej z tych metod, trzeba zastosować aplikację implementującą odpowiednie API obsługi Volume Shadow Copy Service. Ze względu na naturę tych migawek i to, że dane są w nich zapisywane ciągłym strumieniem, konieczne jest zastosowanie nośników o dużych pojemnościach. Z tego powodu do zapisu kopii typu shadow najlepiej nadają się nośniki danych typu NAS lub SAN. Niektórzy producenci urządzeń NAS zaimplementowali odpowiednie mechanizmy bezpośrednio w sprzęcie, dzięki czemu wykonywanie i odtwarzanie kopii stało się niezwykle prostym zadaniem.
Weryfikacja kopii Wykonywanie kopii jest istotne, ale nie mniej istotne jest weryfikowanie ich poprawności. Cała ciężka praca nad opracowaniem terminarza kopii i jego implementacją może pójść na marne, jeśli nie zweryfikuje się tego, czy wykonana kopia zapasowa da się odtworzyć. W pierwszym etapie weryfikacji kopii zapasowej należy po zakończeniu jej wykonywania przejrzeć raport z wykonania kopii. To pozwoli zapoznać się ze stanem operacji, choć te informacje mogą w niektórych przypadkach okazać się za mało szczegółowe. Więcej szczegółów można znaleźć w systemowym dzienniku zdarzeń. Tu często można znaleźć znacznie więcej informacji niż w raporcie. Program ntbackup ma również opcję weryfikacji pozwalającą sprawdzić poprawność wykonania kopii. To jest dobra opcja uzupełniająca pozostałe techniki weryfikacji, ale nie warto traktować jej jako ostatecznej.
628 |
Rozdz ał 20. Exchange
Najlepszą formą weryfikacji kopii jest wykonanie odtworzenia. Odtworzenie danych z kopii na serwer testowy daje więcej korzyści niż jedynie sprawdzenie poprawności kopii; pozwala również w praktyce przetestować procedurę odtwarzania danych, która będzie stosowana w przypadku awarii. Dodatkowo wszelkie elementy procedury odtwarzania danych można przetestować w bezstresowej sytuacji, dzięki czemu administrator może spokojnie robić notatki oraz dokładnie i bez pośpiechu ćwiczyć każdy etap procedury. Dzięki temu w razie potrzeby taki administrator będzie gotowy i będzie mógł działać precyzyjnie i efektywnie.
Wykorzystanie programu ntbackup Program ntbackup może być użyty do wykonywania kopii online serwera Exchange dzięki temu, że firma Microsoft wyposażyła to narzędzie w obsługę Exchange API. To jedyna opcja wykonywania zautomatyzowanych kopii zapasowych serwera Exchange bez konieczności zakupu narzędzi firm trzecich.
Wykonywanie podstawowej kopii Aby uruchomić oprogramowanie do wykonywania kopii zapasowej, należy wywołać z menu funkcję Start/Uruchom i wpisać polecenie ntbackup. Program ntbackup domyślnie uruchamia się w trybie kreatora (rysunek 20.7). Zarówno w przypadku Exchange 2000, jak i 2003 procedura wykonywania kopii jest taka sama. W systemie Windows Server w wersji wcześniejszej od 2003 program do wykonywania kopii zapasowych nazywa się backup i uruchamia się go przez wywołanie polecenia backup po kliknięciu Start/Uruchom.
Rysunek 20.7. Program ntbackup — tryb kreatora
Bardziej zaawansowani użytkownicy mogą zrezygnować z trybu kreatora i przejść do trybu zaawansowanego. W takim przypadku warto zaznaczyć opcję Uruchamiaj w trybie kreatora, po czym kliknąć przycisk Tryb zaawansowany. Aby przełączyć program w tryb zaawansowany, należy zastosować funkcję Narzędzia/Włącz tryb kreatora.
Wykorzystan e programu ntbackup
|
629
Po włączeniu trybu zaawansowanego ekran programu ntbackup ma postać przedstawioną na rysunku 20.8. Z tego okna można z łatwością uruchomić tryb kreatora; można też skonfigurować kopię zapasową w karcie Kopia zapasowa. W tym przykładzie wykorzystamy tryb zaawansowany.
Rysunek 20.8. Główne okno kreatora kopii zapasowych
Wybór elementów do kopii zależy od zainstalowanych elementów serwera Exchange. Aby wykonać kopię zapasową wszystkich grup składowania należy zaznaczyć opcję Microsoft Information Store. Aby wykonać kopię zapasową określonej grupy składowania, należy rozwinąć gałąź Microsoft Information Store i zaznaczyć opcje odpowiednich grup składowania. Na rysunku 20.9 zaznaczyliśmy opcję Information Store for the Exchange Server, a lokalizację kopii zapasowej określiliśmy jako E:\Exchange\Backup.bkf. Nośnikiem jest w tym przypadku zewnętrzne urządzenie składowania, jak NAS lub SAN. Wśród możliwości jest również zapis bezpośrednio na taśmie. W prawym panelu określiliśmy, że zostanie wykonana kopia zarówno skrzynek pocztowych, jak i folderów publicznych. Po zaznaczeniu elementów do skopiowania należy kliknąć przycisk Wykonaj kopię, co spowoduje wyświetlenie okna przedstawionego na rysunku 20.10. W tym oknie można (a raczej należy) wprowadzić szczegółowy opis wykonywanej kopii oraz określić opcje, można też zaplanować czas wykonania kopii, zamiast uruchamiać jej wykonywanie od razu. Po kliknięciu przycisku Funkcje zaawansowane pojawi się okno przedstawione na rysunku 20.11, w którym można zmodyfikować część opcji lub typ kopii zapasowej. Warto za każdym razem weryfikować poprawność wykonania kopii zapasowej, zatem ta opcja jest domyślnie zaznaczona. W przypadku zmiany typu kopii zapasowej należy pamiętać o tym, aby wybrać taką formę kopii zapasowej, która czyści pliki transakcyjne i ustawia znacznik backup.
630
|
Rozdz ał 20. Exchange
Rysunek 20.9. Wybór grupy składowania do wykonania kopii
Rysunek 20.10. Informacja o zadaniu wykonania kopii zapasowej
Rysunek 20.11. Zaawansowane opcje kopii zapasowej Wykorzystan e programu ntbackup
|
631
Po zaznaczeniu odpowiednich opcji należy kliknąć przycisk OK, co spowoduje powrót do głównego okna, w którym znajduje się przycisk Wykonaj kopię. Pojawi się okno stanu wykonania kopii przedstawione na rysunku 20.12.
Rysunek 20.12. Okno postępu wykonania kopii zapasowej
Po wykonaniu kopii należy zweryfikować jej poprawność, co omawia następny punkt.
Weryfikacja kopii Po wykonaniu kopii należy sprawdzić, czy operacja zakończyła się powodzeniem. W tym celu należy zapoznać się z komunikatem wyświetlanym w oknie postępu (rysunek 20.12). Po kliknięciu przycisku Raport… wyświetli się raport z wykonania kopii zapasowej, w którym należy sprawdzić, czy nie wystąpiły błędy. Rysunek 20.13 przedstawia przykład takiego raportu. Domyślny raport to jedynie podsumowanie. Jeśli wystąpiły błędy i potrzeba bardziej szczegółowych informacji, można ponownie uruchomić proces wykonywania kopii zapasowej z zaznaczoną opcją szczegółowego raportu. Wszystkie kopie zapasowe na tym serwerze zapisują swoje komunikaty w jednym pliku; znalezienie błędu może wymagać przejrzenia dużej liczby komunikatów. Jeśli kopia zapasowa została wykonana z opcją Weryfikuj dane, należy sprawdzić raport, aby upewnić się, że kopia wykonała się prawidłowo. W tym celu należy szukać wierszy z informacją o liczbie różnic. Jeśli ta liczba jest różna od zera, może to oznaczać problemy, ale różnica między zawartością plików nie zawsze musi być symptomem problemu, dlatego należy podjąć dalsze kroki sprawdzające. Opisane tu metody pozwalają wykryć większość problemów, ale kluczowym źródłem informacji jest dziennik systemowy (rysunek 20.14). Ważne jest, aby systematycznie sprawdzać dziennik systemowy w poszukiwaniu informacji o błędach, bo nie wszystkie problemy są sygnalizowane w dzienniku programu ntbackup. Należy zwrócić szczególną uwagę na pozycje dotyczące programu ntbackup lub ESE.
632
|
Rozdz ał 20. Exchange
Rysunek 20.13. Weryfikacja wykonania kopii zapasowej przez analizę raportu
Rysunek 20.14. Status kopii zapasowej w oknie zdarzeń systemowych
Jeśli kopia wykonała się bez ewidentnych błędów, istnieje szansa, że wykonała się prawidłowo. Aby jednak mieć całkowitą pewność, należy wykonać odtworzenie systemu, co jest omówione w następnym podrozdziale.
Wykorzystan e programu ntbackup
|
633
Odtwarzanie Kopia zapasowa będzie całkowicie bezużyteczna, jeśli nie uda się za jej pomocą odtworzyć systemu po katastrofie. Ten podrozdział zawiera wskazówki, jak przeprowadzić procedurę odtwarzania serwera Exchange z kopii zapasowej.
Naprawiać czy odtwarzać? Jedno z pierwszych pytań, na które należy odpowiedzieć, brzmi: czy po katastrofie należy podjąć próbę naprawienia istniejącej instalacji serwera Exchange czy po prostu odtworzyć go z kopii zapasowej? W nowszych wydaniach serwera są dostępne narzędzia, które znacznie upraszczają zadania naprawcze, utrudnione w poprzednich wydaniach serwera. Szczególnie duże możliwości istnieją w przypadku naprawy poszczególnych skrzynek.
Typowe zadania podczas naprawy i odtwarzania Naprawianie i odtwarzanie mają kilka cech wspólnych. Na przykład, zanim zacznie się odtwarzać lub naprawiać serwer Exchange, warto sprawdzić fundamenty, na których stoi. W tym przypadku chodzi o system operacyjny Windows Server. Kilka prostych testów może oszczędzić wielu godzin pracy. Wiele razy miałem okazję widzieć administratorów usiłujących naprawić serwer Exchange; w końcu udawało się i taki dzielny administrator otrzymywał gratulacje i podziękowania od kolegów i współpracowników. Niestety, po niedługim czasie taki serwer ponownie psuł się tylko dlatego, że jego fundament, czyli system operacyjny, był niestabilny. W pierwszej kolejności przed rozpoczęciem naprawy lub odtwarzania należy upewnić się, że system Windows Server działa prawidłowo. Do tego służą następujące działania: Sprawdzenie dysków twardych Należy sprawdzić spójność nośnika danych za pomocą programu chkdsk lub innego przeznaczonego do tego narzędzia. Weryfikacja plików systemu Windows Server Należy zweryfikować spójność systemu plików za pomocą programu chkdsk. Ostatnia znana dobra konfiguracja Przy uruchamianiu systemu Windows należy wybrać opcję Ostatnia znana dobra konfiguracja. Konsola odtwarzania systemu Windows Ta opcja, dostępna w systemie Windows 2000 i nowszych, jest dostępna w przypadku uruchomienia systemu z instalacyjnego dysku CD. Odtwarzanie z zestawów kopii zapasowych Odtwarzanie całego systemu z zestawu kopii zapasowych jest oczywiście jedną z dostępnych opcji, ale jest zadaniem pracochłonnym i zajmuje dużo czasu. Ta metoda wiąże się ze zbudowaniem podstawowej konfiguracji serwera, na której zostanie odtworzony zestaw kopii zapasowych, co da działający serwer. Automated System Recovery (ASR) Funkcja ASR to wygodny sposób na automatyczne odtworzenie serwera Windows 2003. W przypadku tej funkcji wykorzystuje się dyskietkę ASR w połączeniu z uruchomieniem systemu z instalacyjnego dysku CD, co pozwala przywrócić serwer do ostatniego stanu zapisanego w tym trybie. 634 |
Rozdz ał 20. Exchange
Oczywiste problemy Ta porada może okazać się oczywista, ale zbyt często okazuje się, że problem błędnie działającego serwera Exchange jest spowodowany za małą ilością wolnego miejsca na dysku twardym
Naprawa serwera Exchange Po upewnieniu się, że problemem nie jest serwer Windows, lub gdy zostały usunięte przyczyny problemów systemu operacyjnego, a Exchange nadal nie działa prawidłowo, należy bliżej przyjrzeć się właśnie temu ostatniemu. Jak Czytelnik pamięta, mamy do wyboru naprawę serwera lub odtworzenie go z kopii zapasowej. Niezależnie od tego, która z opcji zostanie wybrana, zawsze należy wykonać dodatkową kopię zapasową aktualnego stanu serwera. Dzięki temu w przypadku niepowodzenia działań naprawczych lub odtworzenia serwera będziemy mieli dostęp do ostatniej kopii zapasowej w punkcie czasu, która może być przydatna również w stanie uszkodzonym. Jeśli próby naprawy lub odtworzenia poprzedniego stanu serwera spowodują pogorszenie problemu, będziemy mieli do czego wrócić.
Naprawa baz danych Exchange Wraz z serwerem Exchange instalowanych jest kilka narzędzi uruchamianych z wiersza poleceń, które są pomocne w naprawianiu uszkodzonych plików bazy danych i zasobów składowania wiadomości. W standardowej instalacji Exchange 2003 te narzędzia znajdują się w folderze C:\Program Files\Exchsrvr\bin (nazwę dysku i ścieżkę należy dostosować do posiadanej instalacji). Program ESEUtil służy do sprawdzania integralności bazy danych i naprawy uszkodzeń. Program ISINTEG testuje odłączony (w trybie offline) zasób składowania w poszukiwaniu błędów spójności, potrafi również naprawiać te błędy. W Exchange 2000 program ISINTEG znajduje się w katalogu C:\Program Files\Exchsrvr\bin, a ESEUtil można znaleźć na dysku CD w katalogu D:\Support\Utils (D: to litera napędu CD) i przed użyciem należy go zainstalować. Te dwa narzędzia mają bardzo duże możliwości naprawy uszkodzeń serwera Exchange; opcji pomocnych w jego naprawie i odtwarzaniu jego danych jest bardzo dużo. W rzeczywistości w niektórych instalacjach te dwa programy są jedynymi dostępnymi opcjami odtwarzania i naprawy serwera Exchange. Więcej informacji na ich temat można znaleźć na stronie http://support.microsoft.com; w wyszukiwarce należy wpisać słowo kluczowe eseutil lub isinteg.
Naprawa przez ponowną instalację Jednym ze sposobów przywrócenia sprawności serwera Exchange jest ponowna instalacja aplikacji na jej już istniejącej instalacji. Ten sposób jest skuteczny w przypadku, gdy pliki DLL niezbędne do działania serwera Exchange zostały uszkodzone lub omyłkowo usunięte, lub w przypadku uszkodzenia wpisów rejestru dotyczących serwera Exchange. Oczywiście w przypadku wykorzystania tego sposobu procesy serwera Exchange muszą zostać zatrzymane na czas instalacji, przez co będą niedostępne dla użytkowników. Należy również pamiętać o tym, że po ponownej instalacji każdego oprogramowania należy przywrócić dokładnie tę samą wersję, włącznie z zainstalowanymi poprawkami. Podczas takiej instalacji naprawczej należy zastosować parametr /DisasterRecovery, który spowoduje, że instalator nie doda do Active Directory kolejnego egzemplarza serwera Exchange. Należy jednak pamiętać o tym, że konfiguracja serwera Exchange musi znaleźć się w Active Odtwarzan e
|
635
Directory. Jeśli dane dotyczące serwera Exchange zostały usunięte również z Active Directory (albo serwer był wyłączony tak długo, że te informacje zostały usunięte automatycznie), należy podjąć dodatkowe działania uzupełniające te dane.
Odtwarzanie serwera Exchange Jeśli działania naprawcze zakończą się niepowodzeniem, pozostaje jedynie ostateczność: odtworzenie serwera Exchange.
Informacje wstępne Proces odtwarzania można streścić następująco: • odmontowanie zasobów składowania; • skopiowanie plików baz danych z nośnika kopii zapasowej w ich oryginalne miejsce na
serwerze Exchange, z nadpisaniem oryginalnych plików .edb i .stm (o ile istnieją); • skopiowanie plików dzienników transakcyjnych do wskazanego miejsca tymczasowego; • odtworzenie transakcji; • skopiowanie w oryginalne miejsce pliku restore.env, zawierającego informacje na temat
plików dziennika (grupy składowania, do których należą, ścieżki do bazy danych, zakresy dziennika itp.).
Odtwarzanie skrzynek pocztowych Exchange oraz zasobów folderów publicznych Przy odtwarzaniu zasobów składowania serwera Exchange mamy do wyboru kilka opcji. Podstawowa procedura jest jednak zbliżona dla każdej z tych metod i to ją opisuję poniżej.
Odtwarzanie kopii online Odtworzenie kopii online to najprostszy sposób odtworzenia bazy Exchange, ponieważ większość aplikacji wykonujących i odtwarzających kopie zapasowe jest zoptymalizowana właśnie pod kątem tej metody. W programie ntbackup łatwo jest domontować odtwarzany zasób składowania: wystarczy zaznaczyć odpowiednią kopię do odtworzenia, a program automatycznie wykona wszystkie niezbędne działania. Szczegółowa procedura działania w takim przypadku jest omówiona w dalszej części rozdziału.
Kopie przyrostowe i różnicowe Z podrozdziału omawiającego wykonywanie kopii zapasowych Czytelnik dowiedział się, że kopie różnicowe i przyrostowe pozwalają zaoszczędzić dużo miejsca na nośnikach kopii zapasowej i dużo czasu. Jednak przy odtwarzaniu danych z takich kopii wszelkie oszczędności mszczą się na administratorze, ponieważ z reguły odtwarzanie zajmuje znacznie więcej czasu i wymaga większego nakładu pracy, a w sytuacjach odtwarzania tego czasu zwykle nie ma za wiele. Chodzi o to, że w przypadku kopii przyrostowych i różnicowych w pierwszej kolejności należy odtworzyć kopię pełną, a następnie kolejno wszystkie kopie przyrostowe do tej samej 636
|
Rozdz ał 20. Exchange
lokalizacji tymczasowej. Przy odtwarzaniu ostatniej kopii przyrostowej należy zaznaczyć opcję informującą o tym, co spowoduje automatyczne odtworzenie transakcji z dzienników. W tego typu konfiguracji najbardziej widać konsekwencje wykorzystania do zapisu kopii konkretnego nośnika: w przypadku zapisu kopii na taśmie można spodziewać się dużo liczniejszych problemów niż w przypadku zapisu kopii na nośniku SAN lub NAS. Jeśli przy odtwarzaniu ostatniej kopii przyrostowej w oknie Restore Database Store nie została zaznaczona opcja Last Restore Set lub gdy dane są odtwarzane z różnych lokalizacji, administrator musi samodzielnie wykonać operacje twardego odtwarzania transakcji z dzienników.
Odtwarzanie twarde i miękkie Odtwarzanie twarde polega na odtworzeniu transakcji z dzienników transakcyjnych po odtworzeniu plików bazy danych z kopii online. Po pomyślnym zakończeniu twardego odtwarzania baza danych znajduje się w tak zwanym stanie niespójnym, lub niezsynchronizowanym. Podstawowa różnica między twardym a miękkim odtwarzaniem polega na tym, że w twardym wykorzystywany jest nie plik punktu odtwarzania, a plik restore.env. Ten plik określa zakres dzienników transakcyjnych, które muszą być dostępne we wskazanym folderze tymczasowym. Odtwarzanie miękkie polega na odtworzeniu transakcji z dziennika do kopii bazy offline. Ten proces wymaga, aby wszystkie niezbędne pliki były dostępne i nieuszkodzone. W tym przypadku wykorzystywany jest plik punktu przywracania. Jeśli nie istnieje punkt przywracania, przywracanie rozpoczyna się od najstarszego pliku dziennika transakcyjnego.
Odtwarzanie offline Odtwarzanie offline polega na skopiowaniu plików z kopii do właściwej lokalizacji serwera Exchange. Przed rozpoczęciem odtwarzania offline należy zdecydować się na jedną z dwóch opcji: Odtwarzanie w punkcie czasu Ten typ odtwarzania (ang. point-in-time restore) nie wykorzystuje plików dziennika, przez co dane zapisane w bazie już po wykonaniu kopii są tracone. Odtwarzanie rollforward Dostępne pliki dziennika są odtwarzane. Jeśli dostępne są wszystkie pliki dziennika, istnieje możliwość odtworzenia wszystkich danych. Jeśli stosowane są dzienniki pierścieniowe, istnieje tylko możliwość odtworzenia w punkcie czasu.
Recovery Storage Group Recovery Storage Groups (RSG) to doskonała funkcja dostępna od wydania Exchange Server 2003. Pozwala administratorowi serwera Exchange zaoszczędzić sporo czasu. W poprzednich wersjach Exchange do zamontowania odtwarzanych baz danych konieczne było skonfigurowanie kompletnej instalacji serwera Exchange. W przypadku RSG można odtworzyć kopię zapasową do tej bazy danych bez skutków ubocznych dla działania systemu i pracy jego użytkowników. Po odtworzeniu kopii można zastosować kreator Mailbox Merge (ExMerge) lub Recover Mailbox Data w celu połączenia informacji z kopii zapasowej z główną grupą składowania.
Odtwarzan e serwera Exchange
|
637
Funkcji Recovery Storage Groups nie należy postrzegać jako podstawowego mechanizmu naprawczego systemu Exchange po awarii. To pomocniczy mechanizm, przydatny w odtwarzaniu danych serwera, uzupełniający istniejące metody. Należy pamiętać, że RSG służy przede wszystkim do odtwarzania danych z pojedynczych skrzynek i że nie działa z folderami publicznymi.
Przykład RSG Uruchamiamy Exchange System Manager: Start/Wszystkie programy/Microsoft Exchange/System Manager. Prawym przyciskiem myszy klikamy nazwę serwera, w którym ma zostać utworzona RSG, i z menu kontekstowego wybieramy New/Recovery Storage Group, co przedstawia rysunek 20.15.
Rysunek 20.15. Tworzenie grupy składowania Recovery Storage Group w programie System Manager
Domyślna lokalizacja plików dziennika i ścieżka systemowa zostały przedstawione na rysunku 20.16. Należy je dostosować do własnych potrzeb. Gdy te wartości zostaną poprawione i zweryfikowane, należy kliknąć OK, co spowoduje utworzenie grupy RSG. W tym momencie w standardowej instalacji Exchange grupy składowania powinny mieć postać jak na rysunku 20.17. Mamy tu dwie grupy składowania: First Storage Group i Recovery Storage Group. Warto zwrócić uwagę, że do Recovery Storage Group nie mogą być dostarczone jakiekolwiek wiadomości. W celu odtworzenia bazy danych należy kliknąć prawym przyciskiem myszy na Recovery Storage Group i wybrać funkcję Add Database to Recover (rysunek 20.18). Zostanie wyświetlone okno dialogowe przedstawione na rysunku 20.19. Należy kliknąć kopię zapasową, która ma być odtworzona do RSG, i kliknąć OK. W oknie Mailbox Store Properties (rysunek 20.20) należy otworzyć kartę Database i wybrać lokalizację odtworzonych z kopii zapasowej plików .edb i .stm. Po dostosowaniu lokalizacji można kliknąć przycisk OK.
638 |
Rozdz ał 20. Exchange
Rysunek 20.16. Okno właściwości grupy składowania Recovery Storage Groups
Rysunek 20.17. Utworzona grupa składowania Recovery Storage Group w programie System Manager
Rysunek 20.18. Opcja Add Database to Recover dla Recovery Storage Groups
Odtwarzan e serwera Exchange
| 639
Rysunek 20.19. Wybór bazy do odtworzenia
Rysunek 20.20. Okno właściwości zasobu składowania poczty
Po zakończeniu operacji w RSG znajdzie się odtworzony zasób zawierający skrzynki pocztowe. Po odtworzeniu zasób zawsze znajduje się w stanie niezamontowanym, zatem należy zamontować go ręcznie. W tym momencie można w standardowy sposób kontynuować procedurę odtwarzania danych z kopii. Jeśli proces odtwarzania danych serwera Exchange napotka RSG, użyje jej w sposób automatyczny.
Przykład zastosowania RSG — odzyskanie sygnału Doskonałym przykładem wykorzystania RSG jest metoda określana jako odtworzenie sygnału (ang. dial-tone database restore). Zadaniem tej metody jest jak najszybsze odtworzenie skrzynek pocztowych, nawet bez zawartości (czyli, w nomenklaturze telekomunikacyjnej, odzyskanie 640 |
Rozdz ał 20. Exchange
sygnału nadawania). Dzięki temu użytkownicy uzyskają natychmiastową możliwość wysyłania i odbierania wiadomości. Taki stan serwera jest często dopuszczalnym przejściowym kompromisem, pozwalającym administratorowi spokojnie pracować nad odtworzeniem starych wiadomości. Użytkownicy nie mają, co prawda, natychmiastowego dostępu do historycznych wiadomości, mają jednak możliwość w miarę normalnej pracy. Ta metoda jest szczególnie przydatna w firmach wykorzystujących pocztę elektroniczną jako główne medium komunikacyjne. Jeśli serwer Exchange miał awarię sprzętową i musi być odtworzony od zera, a dane serwera mają pokaźne rozmiary, taki proces może zająć długie godziny. W przypadku odtworzenia sygnału użytkownicy natychmiast mają możliwość wysyłania i odbierania poczty, a w międzyczasie administrator pracuje nad odtworzeniem ich starej poczty z kopii zapasowych.
Często pomijane (a użyteczne) metody odtwarzania Z reguły w pierwszej chwili po poważnej awarii administrator wpada w stan mniejszej lub większej paniki i od razu chciałby wykonywać pełne odtworzenie systemu o 4 nad ranem. To dość poważne zadanie. Jednak często doskonale sprawdzają się metody odtwarzania pojedynczych skrzynek pocztowych, a nawet pojedynczych wiadomości.
Odtwarzanie usuniętych skrzynek pocztowych Serwer Exchange ma funkcję, która pozwala na to, aby usunięte konto użytkownika i skrzynka pocztowa pozostały na serwerze przez ustaloną liczbę dni, niedostępne dla konta użytkownika. To oznacza sytuację przejściową między usunięciem konta na serwerze a fizycznym usunięciem wiadomości z tego konta. Rysunek 20.21 jest tego przykładem: zostaje usunięte konto użytkownika Temp User. Skrzynka pocztowa nadal istnieje i jest widoczna w programie Exchange System Manager, ale jej ikona zawiera kropkę ze znakiem X, która informuje o tym, że ta skrzynka nie ma dołączonego konta użytkownika.
Rysunek 20.21. Przykład usunięcia użytkownika
Istnieją dwa sposoby przyłączenia tej skrzynki do konta użytkownika. W każdym z tych przypadków należy utworzyć konto użytkownika bez skrzynki pocztowej. Po kliknięciu prawym przyciskiem myszy na skrzynkę pocztową użytkownika Temp User z menu kontekstowego można wybrać funkcję Reconnect. To spowoduje wyświetlenie okna wyszukiwania obiektu, pozwalającego wybrać konto użytkownika, z którym ma zostać połączona ta skrzynka. Po wyszukaniu konta pozbawionego skrzynki pocztowej należy je zaznaczyć i kliknąć OK. Od tego momentu wybrane konto użytkownika jest połączone ze skrzynką. Odtwarzan e serwera Exchange
|
641
Druga możliwość polega na wykorzystaniu programu Mailbox Recovery Center. Podstawowe zasady działania w tym przypadku są takie same, ale tym razem należy zamontować zasób składowania zawierający konta użytkowników niezwiązane ze skrzynkami pocztowymi. Od tego momentu podłączenie skrzynki do konta odbywa się w taki sam sposób jak w poprzedniej metodzie. Możliwość montowania różnych zasobów składowania pozwala w programie Mailbox Recovery Center na łatwe importowanie skrzynek pocztowych. Należy pamiętać, że w tym przypadku zastosowanie mają również uprawnienia Active Directory, zatem w przypadku problemów z uprawnieniami cała procedura może nie być tak prosta, jak sugeruje ten opis.
Odtwarzanie usuniętych elementów Możliwość odtwarzania usuniętych elementów to jedna z najciekawszych funkcji serwera Exchange, ponieważ zdejmuje z administratora ciężar procesu odtwarzania danych, umożliwiając rozwiązywanie tego typu problemów użytkownikowi. Użytkownicy programu Outlook, którzy muszą odzyskać trwale usunięte wiadomości (nieprzeniesione do kosza), mogą to zrobić, wykorzystując funkcję Recover Deleted Items tego programu. Wystarczy kliknąć folder Deleted Items i wybrać z menu Narzędzia funkcję Recover Deleted Items. Pojawi się okno przedstawione na rysunku 20.22, w którym można wybrać wiadomości do przywrócenia.
Rysunek 20.22. Przywracanie usuniętych elementów w programie Outlook
Aby ta opcja działała, należy uaktywnić opcję Keep Deleted Items w konfiguracji zasobu składowania. Do tego celu służy karta Limits funkcji Property programu Exchange Server Manager (rysunek 20.23). Ta metoda działa również w przypadku folderów publicznych.
Wykorzystanie programu ntbackup do odtwarzania Program ntbackup jest bardzo użyteczny również w przypadku odtwarzania danych z kopii.
Podstawowe odtworzenie Na początek odtwarzane zasoby składowania muszą zostać ustawione w trybie offline z możliwością nadpisania przez ich kopie zapasowe. W tym celu należy uruchomić program Exchange System Manager, wybierając Start/Wszystkie programy/Microsoft Exchange/System Manager. Należy rozwinąć gałąź Servers, następnie gałąź serwera, którego dane będą odtwarzane, a na koniec grupę składowania, w której znajduje się odtwarzany zasób. Aby domontować zasób, należy kliknąć jego nazwę prawym przyciskiem myszy i z menu kontekstowego wybrać opcję
642 |
Rozdz ał 20. Exchange
Rysunek 20.23. Ograniczenia miejsca składowania dla usuniętych elementów
Dismount Store (rysunek 20.24). Należy pamiętać, że dane odmontowanego zasobu nie są dostępne dla użytkowników. Jak już wspomniałem, ta procedura w przypadku serwera 2000 jest zbliżona; tym razem wykorzystywany jest kreator kopii zapasowej (należy kliknąć Start/Uruchom i wywołać polecenie backup).
Rysunek 20.24. Odmontowanie zasobu Odtwarzan e serwera Exchange
| 643
Należy ponownie kliknąć nazwę zasobu i wybrać funkcję Properties, co spowoduje wyświetlenie okna przedstawionego na rysunku 20.25. Następnie należy przejść do karty Database i upewnić się, że opcja This database can be overwritten by a restore jest zaznaczona.
Rysunek 20.25. Należy upewnić się, że baza danych może być nadpisana
Następnie należy uruchomić program ntbackup, co zostało opisane w punkcie „Wykonywanie podstawowej kopii”. Należy przejść do karty Restore and Manage Media. Ekran przedstawia listę kopii zapasowych do wyboru (rysunek 20.26). Należy odszukać odpowiednią kopię, rozwinąć jej szczegóły i wybrać elementy, które mają zostać odtworzone.
Rysunek 20.26. Wybór kopii do odtworzenia
Po wybraniu kopii do odtworzenia należy kliknąć przycisk Start Restore, co spowoduje wyświetlenie okna przedstawionego na rysunku 20.27.
644 |
Rozdz ał 20. Exchange
Rysunek 20.27. Opcje odtwarzania w oknie Restoring Database Store
Należy upewnić się, że w polu Restore To jest wprowadzona nazwa właściwego serwera Exchange. W przypadku podstawowego odtworzenia danych z pełnej kopii mamy do czynienia z tylko jednym zbiorem kopii zapasowych, należy zatem zaznaczyć opcję Last Restore Set. W przypadku odtwarzania większej liczby kopii przyrostowych lub różnicowych opcję tę należy zaznaczyć przy odtwarzaniu ostatniego elementu kopii. Po zakończeniu procedury odtwarzania należy ponownie zamontować zasób. Można też zaznaczyć opcję Mount Databases After Restore (rysunek 20.27), dzięki czemu ta operacja wykona się automatycznie. Po zaznaczeniu opcji odtwarzania należy kliknąć przycisk OK, co spowoduje rozpoczęcie odtwarzania danych z kopii. Po jego zakończeniu pojawi się okno z informacją o stanie procesu. Jeśli przy ostatnim elemencie procedury odtwarzania nie zostanie zaznaczona opcja Last Restore Set, baza danych będzie znajdowała się w niespójnym stanie. Można ręcznie uruchomić procedurę odtwarzania transakcji z dzienników przez wywołanie polecenia eseutil /cc. Należy upewnić się, czy odtworzenie danych zakończyło się powodzeniem, sprawdzając pole Status tego okna — musi się tu znaleźć komunikat Completed (rysunek 20.28). Dodatkowe informacje można znaleźć w raporcie (przycisk Report…) oraz w dzienniku systemowym.
Rysunek 20.28. Okno stanu procedury odtwarzania
Odtwarzan e serwera Exchange
| 645
Należy sprawdzić, czy zasoby składowania zostały prawidłowo zamontowane. Na koniec należy połączyć się z serwerem Exchange za pomocą programu Outlook lub Outlook Web Access (OWA), aby sprawdzić, czy odtworzone dane są dostępne. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
646 |
Rozdz ał 20. Exchange
ROZDZIAŁ 21.
PostgreSQL
Jak wspomniałem w rozdziale 15., poważne dane można powierzyć jedynie tym relacyjnym bazom danych, które są w pełni zgodne z zasadami ACID. Właśnie takim serwerem baz danych jest PostgreSQL. W serwerze baz danych MySQL również można uzyskać zgodność z ACID, pod warunkiem że zastosuje się silnik składowania danych (ang. storage engine) InnoDB lub NDB. Natomiast serwer PostgreSQL jest bezwarunkowo zgodny z zasadami ACID. Oprócz tej niewątpliwej zalety PostgreSQL ma wiele innych ciekawych cech, jak: odtwarzanie danych w punkcie czasu (ang. point in time recovery), przestrzenie tabel (ang. tablespace), punkty przywracania (ang. checkpoint), możliwość wykonywania kopii zapasowych w locie (ang. hot backup), księgowanie z wyprzedzeniem zapisu (ang. write ahead logging) oraz odporność na błędy (ang. fault tolerance). Te wszystkie cechy bardzo sprzyjają bezpieczeństwu z punktu widzenia integralności danych.
Architektura serwera PostgreSQL PostgreSQL z punktu widzenia zaawansowanego użytkownika to baza danych bardzo podobna do innych. Poniższe terminy oznaczają w przypadku serwera PostgreSQL dokładnie to samo co w przypadku innych rozwiązań tego typu: • baza danych, • tabela, • indeks, • wiersz, • atrybut, • sektor, • partycja, • transakcja, • klaster.
Klaster w PostgreSQL-u ma analogiczne znaczenie do pojęcia egzemplarza (ang. instance) w innych relacyjnych bazach danych. Każdy klaster może być wykorzystywany z jedną lub większą liczbą baz danych. Nieczęsto zdarza się jednak wykorzystywać większą liczbę klastrów w pojedynczym serwerze bazy danych, ale to jest możliwe i stosowane w szczególnych przypadkach. Na przykład można wyobrazić sobie współdzielone środowisko u dostawcy usług 647
internetowych, w którym poszczególni klienci nie powinni widzieć wzajemnie swoich danych. Uprawnienia użytkownika są zdefiniowane na poziomie klastra, zatem w celu utworzenia rozłącznych grup danych i uprawnień do nich wystarczy utworzyć większą liczbę klastrów (egzemplarzy). Do zarządzania klastrami wykorzystuje się polecenie pg_ctl.
Przestrzeń tabel Pojęcie przestrzeni tabel (ang. tablespace) w PostgreSQL-u ma dokładnie takie samo znaczenie jak w innych relacyjnych serwerach baz danych, co zostało opisane w rozdziale 15. W skrócie jest to „przestrzeń”, w której zapisywane są tabele i inne obiekty. Podobnie jak w przypadku innych serwerów baz danych, w PostgreSQL-u przestrzeń tabel składa się z większej liczby plików stron danych (ang. datafile lub pagefile). Różnica w przypadku PostgreSQL-a polega jednak na sposobie tworzenia tych plików stron. Przy tworzeniu przestrzeni tabel w PostgreSQL-u nie określa się listy nazw plików danych, a jedynie nazwę katalogu, w którym będzie zapisana przestrzeń tabel. Na przykład domyślna przestrzeń tabel jest tworzona w tym samym katalogu, w którym zapisany jest główny klaster serwera PostgreSQL. Dodatkowe przestrzenie tabel mogą być zapisane na woluminie LVM lub na zewnętrznym woluminie RAID, co może być podyktowane na przykład względami wydajności. Przy tworzeniu przestrzeni tabel PostgreSQL tworzy pierwszy plik stron danych. Gdy w przestrzeni tabel zapisywane są dane, plik stron danych zwiększa swój rozmiar. Gdy plik stron danych osiąga rozmiar 1 GB, PostgreSQL zakłada dodatkowy plik stron. Ta procedura jest kontynuowana aż do momentu, gdy zapełni się nośnik, na którym zapisana jest przestrzeń tabel. W dowolnym momencie można utworzyć dodatkowe przestrzenie tabel, a same tabele przenosi się między przestrzeniami poleceniem ALTER TABLE. Wyczerpanie miejsca w przestrzeni tabel to bardzo niepożądana sytuacja: backend serwera PostgreSQL kończy swoje działanie z błędem, a wszelkie trwające transakcje są porzucane.
Plik stron danych Jak wspomniałem w punkcie poświęconym przestrzeni tabel, pliki stron danych w PostgreSQL-u mają podobne znaczenie co pliki danych w innych bazach danych, z jednym wyjątkiem. Nie są bowiem tworzone wprost przez administratora baz danych i przydzielane do przestrzeni tabel. Są tworzone automatycznie przez backend PostgreSQL-a, w miarę jak przestrzeń tabel potrzebuje większej ilości miejsca na dane.
Skrypty startowe Serwer PostgreSQL jest z reguły uruchamiany przez skrypty dostosowane do wymagań środowiska. PostgreSQL nie wykorzystuje globalnych plików konfiguracyjnych, na przykład oratab w przypadku baz Oracle, w których zapisywane są informacje o wszystkich egzemplarzach serwera w ramach danej maszyny. W przypadku PostgreSQL-a informację o egzemplarzach serwera można odczytać z listy procesów. Na przykład w systemach Unix i Linux listę serwerów można odczytać za pomocą polecenia ps -ef, co daje wynik tego typu:
648 |
Rozdz ał 21. PostgreSQL
# ps -ef | grep postgres postgres 7897 1 0 18:37 ? 00:00:00 /usr/lib/postgresql/8.2/bin/postgres D /var/lib/postgresql/8.2/main -c config_file=/etc/postgresql/8.2/main/postgresql.conf postgres 8124 7897 0 18:37 ? 00:00:00 postgres: writer process postgres 8125 7897 0 18:37 ? 00:00:00 postgres: stats collector process
Tabele systemowe Tabele systemowe są zapisane w domyślnej przestrzeni nazw i mogą służyć do zapoznania się z listą baz w klastrze, listą przestrzeni tabel w bazie itd. Te informacje są również doskonałym źródłem danych na potrzeby wykonywania kopii zapasowych. Oto przykład generujący listę baz danych w klastrze: postgres=# select datname from pg_database order by datname; datname -----------------calendar postgres systemvdm2 template0 template1 (5 rows)
Listę przestrzeni tabel można uzyskać następującym poleceniem: postgres=# select spcname from pg_tablespace order by spcname; spcname -----------pg_default pg_global (2 rows)
Obiekty binarne PostgreSQL obsługuje specjalne typy danych do przechowywania obiektów binarnych, jak pliki graficzne czy duże dane tekstowe. Takimi typami danych są: ByteA, BLOB i Text. W zależności od konfiguracji dane obiektów tego typu są zapisywane w osobnych plikach na dysku. Od wersji 8.1 serwera PostgreSQL dane tych typów są zrzucane do kopii zapasowych za pomocą poleceń pg_dump oraz pg_dumpall. W poprzednich wersjach, aby wymusić takie działanie, należy posłużyć się opcją -b polecenia pg_dump.
Proces wycofania zmian PostgreSQL proces wycofywania zmian niesfinalizowanej transakcji (rollback) obsługuje w nieco inny sposób, niż to się odbywa w innych relacyjnych bazach danych. Weźmy na przykład skomplikowaną transakcję składającą się z instrukcji BEGIN TRANSACTION, po której następują setki operacji modyfikujących, a na końcu znajduje się instrukcja COMMIT. Wiele serwerów baz danych zapisuje zmiany na dysku na bieżąco, nawet w przypadku, gdy transakcja nie jest jeszcze zakończona. Założenie jest bowiem takie, że 99,9% transakcji odbywa się właśnie w ten sposób, zatem i tak, prędzej lub później, zmiany powinny zostać zapisane. Problem zaczyna się jednak w przypadku, gdy nagle zabraknie prądu przed finalizacją transakcji: na dysku znajdą się częściowo zmodyfikowane dane transakcji, pozostawiając bazę w niespójnym stanie.
Arch tektura serwera PostgreSQL
| 649
Uniknąć sytuacji tego typu pozwala dziennik wycofywania transakcji (ang. rollback log). Przed dokonaniem zmiany w samej bazie danych jej obraz jest zapisywany właśnie w dzienniku wycofywania transakcji. Jeśli transakcja jest sfinalizowana (np. instrukcją COMMIT), obrazy zmodyfikowanych w niej danych są przepisywane do plików danych. W przypadku awarii serwera baz danych wprowadzone zmiany są odtwarzane z dziennika transakcji, co pozwala przywrócić bazę do spójnego stanu. PostgreSQL działa inaczej. Na dysku zapisywane są wyłącznie sfinalizowane transakcje, niesfinalizowane są zapisywane jedynie w pamięci operacyjnej. Druga ważna różnica polega na tym, że w PostgreSQL-u zmiany w krotkach nie nadpisują ich poprzednich wersji. PostgreSQL zapisuje nową wersję krotki, a poprzednią oznacza jako nieaktywną. Jeśli transakcja zostaje sfinalizowana, jej zmiany zapisywane są na dysku twardym, a nieaktywna krotka jest oznaczana do usunięcia w najbliższej operacji oczyszczania (ang. vacuum). Jeśli transakcja zostaje wycofana, poprzednia wersja krotki jest ponownie oznaczana jako aktywna, a nowa — jako nieaktywna. W ten sposób PostgreSQL nie wymaga zastosowania osobnego dziennika wycofywania transakcji. Proces oczyszczania bazy danych jest wykonywany w sposób systematyczny i polega na fizycznym usuwaniu z tabeli krotek oznaczonych do usunięcia. Ten proces jest bardzo ważny, a jego wykonywanie jest koniecznością. Dlatego jeśli komuś uda się wykonać ponad cztery miliardy transakcji bez wywołania procedury oczyszczania, baza danych odmówi zapisu kolejnych transakcji aż do momentu wykonania operacji VACUUM. Jeśli proces oczyszczający nie jest uruchamiany, przynajmniej okazyjnie, baza danych może odmówić współpracy i rozpoczęte transakcje nie będą finalizowane. Warto o tym pamiętać. Dobra wiadomość jest taka, że od wersji 8.1 PostgreSQL oferuje mechanizm automatycznego oczyszczania. Jednak domyślnie jest on nieaktywny.
Dziennik zapisu z wyprzedzeniem Dziennik zapisu z wyprzedzeniem (ang. write ahead log, w skrócie WAL) ma podobne zastosowanie co dzienniki wycofywania transakcji w innych serwerach baz danych. Wszystkie dane modyfikowane w wyniku transakcji są zapisywane w dzienniku, zanim zostaną zapisane w pliku danych, dzięki czemu w przypadku awarii baza danych może odtworzyć te zapisy. Dziennik zapisu z wyprzedzeniem jest również użyteczny w przypadku odtwarzania danych w punkcie czasu (ang. point in time recovery). Taka operacja polega na ponownym wykonaniu transakcji sfinalizowanych od momentu wykonania ostatniej kopii zapasowej. Działający serwer PostgreSQL tworzy serię rekordów WAL w postaci plików segmentów WAL, z reguły o rozmiarze 16 MB, choć na etapie kompilacji PostgreSQL-a można określić rozmiar segmentów. Pliki segmentów mają nazwy liczbowe określające pozycję w sekwencji rekordów WAL. Jeśli w konfiguracji nie została ustawiona opcja archiwizacji dziennika zapisu z wyprzedzeniem, PostgreSQL tworzy określoną, stałą liczbę plików segmentów i wykorzystuje je sekwencyjnie, zmieniając nazwę najstarszego tak, aby odpowiadała numerowi rekordu WAL. Tego typu metoda pozwala na wykonywanie kopii w locie (ang. hot backup) i automatyczne odtworzenie transakcji w przypadku awarii, ale nie może służyć do odtwarzania zawartości bazy danych w punkcie czasu.
650
|
Rozdz ał 21. PostgreSQL
Archiwizacja dziennika WAL polega na kopiowaniu plików segmentów do innej lokalizacji przed zmianą nazwy. Aby wykorzystać te pliki do odtwarzania bazy danych w punkcie czasu, serwer PostgreSQL (postmaster) musi być uruchomiony z opcją archive_command. Ta opcja może również zostać określona w pliku postgresql.conf. W tym drugim przypadku, w celu wprowadzenia w życie zmiany w konfiguracji, należy wymusić ponowne wczytanie pliku konfiguracyjnego serwera przez wykonanie polecenia pg_ctl reload. Jeśli to nie pomoże, konieczne może okazać się ponowne uruchomienie bazy danych. Wartość opcji archive_command to ciąg znaków określający polecenia kopiujące plik do określonej lokalizacji. W danym ciągu znaków każde wystąpienie podciągu %p jest zastępowane pełną ścieżką do archiwizowanego pliku, a %f reprezentuje nazwę pliku bez ścieżki (znak procenta definiuje się za pomocą sekwencji %%). Oto kilka przykładowych wartości tej zmiennej, prosto z podręcznika serwera PostgreSQL: archive_command = 'cp -i %p /mnt/server/archivedir/%f'
Taka definicja spowoduje skopiowanie każdego segmentu WAL do katalogu /mnt/server/archivedir. Aby uniknąć nadpisania istniejących plików, można posłużyć się następującym poleceniem: archive_command = 'test ! -f .../%f && cp %p .../%f'
Polecenie to przed skopiowaniem sprawdza, czy plik o podanej nazwie występuje w katalogu docelowym. Oczywiście każdy z tych przykładów należy dostosować do wykorzystywanej konfiguracji. Alternatywnie można wykorzystać własny skrypt kopiujący i wykonujący inne zadania pomocnicze. Poniższy przykład demonstruje użycie takiego samodzielnie przygotowanego skryptu: archive_command = 'mycp.sh %p /mnt/server/archivedir/%f'
Oprócz skopiowania plików do odpowiedniej lokalizacji skrypt mycp.sh może dodatkowo sprawdzić warunki wykonania tej operacji oraz wykonywać dodatkowe operacje, na przykład: • kompresować plik segmentu WAL; • zabezpieczać przed niepożądanym nadpisaniem istniejącego już pliku segmentu WAL.
Kopie zapasowe i ich odtwarzanie PostgreSQL oferuje trzy metody wykonywania kopii zapasowych i ich odtwarzania. Służą do tego polecenia pg_dump i pg_dumpall, a do wykonywania i odtwarzania kopii w punkcie czasu — para poleceń select pg_start_backup i select pg_stop_backup. Każde z tych narzędzi ma inne przeznaczenie, co omawia poniższa tabela. Binarny format kopii zapasowej uzyskanej poleceniem pg_dump może być dostosowywany do potrzeb i można go upodobnić do formatu kopii zapasowych baz Sybase i SQL Server. Format tekstowy kopii uzyskanych za pomocą poleceń pg_dump i pg_dumpall jest zbliżony do wyniku działania polecenia mysqldump bazy MySQL. Polecenie pg_dump może służyć do wykonywania kopii pojedynczej bazy, natomiast pg_dumpall wykonuje kopię wszystkich baz, włącznie z tabelami systemowymi. Mechanizm tworzenia kopii zapasowej na potrzeby odtwarzania w punkcie czasu ma działanie zbliżone do analogicznego mechanizmu baz Oracle i poleceń begin backup i end backup. Polecenia te służą do przygotowania bazy danych do wykonania kopii, nie wykonują jej jednak.
Kop e zapasowe ch odtwarzan e
|
651
pg_dump
pg_dumpall
pg_start_backup, pg_stop_backup
Obsługuje kopie zapasowe w locie
Obsługuje kopie zapasowe w locie
Obsługuje kopie zapasowe w locie
Kopiuje pojedynczą bazę danych tabelę lub schemat
Kopiuje wszystkie bazy danych w klast ze
pg_start_backup p zygotowuje klaste do wykonania kopii Zawa tość kopii jest uzależniona od zastosowanego sk yptu kopiującego
Kopie odtwa zane p zez pg_restore
Kopie nieodtwa zane p zez
Kopie nieodtwa zane p zez pg_restore Są wyko zystywane w amach p ocedu y odtwa zania danych w punkcie czasu
pg_restore
Kopie mogą być w fo macie tekstowym tar lub własnym fo macie bina nym
Kopie są w fo macie tekstowym
Kopie są dokładnymi kopiami plików danych i mogą być zapisane w dowolnym fo macie
Kopie tekstowe są użyteczne dla polecenia psql
Kopie są użyteczne dla polecenia psql
Kopie nie mogą być użyte p zez polecenie psql
Nie można kopiować globalnych tabel systemowych w tym tabel użytkowników i g up
Globalne tabele systemowe są zapisywane w każdej kopii Można wykonać kopię wyłącznie globalnych tabel systemowych z zastosowaniem opcji -g
Kopiuje całą zawa tość klast a
Można odtwo zyć zawa tość bazy danych odpowiadającą momentowi wykonania kopii poleceniem pg_dump
Można odtwo zyć zawa tość bazy danych odpowiadającą momentowi wykonania kopii poleceniem pg_dumpall
Można odtwo zyć bazę danych aż do punktu awa ii o ile są dostępne wszystkie dzienniki zapisu z wyp zedzeniem
Nie ma konieczności a chiwizacji WAL
A chiwizacja WAL musi być uaktywniona
Nie ma konieczności a chiwizacji WAL
Za pomocą kombinacji poleceń pg_dump i psql nie można wykonać odtworzenia danych w punkcie czasu. Jednym z powodów jest to, że tworzą one nowy dziennik zapisu z wyprzedzeniem. Dlatego nie ma możliwości odczytu dziennika zapisu z wyprzedzeniem pochodzącego z poprzednich sesji.
Wszystkie dostępne metody wykonywania kopii zapasowych mogą być użyte na aktywnej bazie danych PostgreSQL. Dodawanie lub usuwanie rekordów podczas trwania procedury wykonywania kopii zapasowej nie uszkadzają tej kopii. Zmiany w fizycznej strukturze bazy danych (jak: dodawanie kolumn, dodawanie lub usuwanie tabel itp.) w czasie wykonywania kopii zapasowej mogą jednak powodować problemy przy odtwarzaniu tej kopii, zatem tego typu operacje są blokowane na czas wykonywania kopii zapasowej.
Wykorzystanie pary poleceń pg_dump i pg_restore Kopie zapasowe wykonane z użyciem polecenia pg_dump mogą być wykorzystywane z poleceniami pg_restore i psql. W tym punkcie omówię wykonywanie kopii zapasowych na potrzeby ich odtwarzania z użyciem pg_restore.
Wykonywanie kopii poleceniem pg_dump Polecenie pg_dump obsługuje dwa formaty binarne kompatybilne z poleceniem pg_restore: tar i custom. Format tar nie pozwala modyfikować kolejności ani pomijać elementów kopii zapasowej podczas odtwarzania danych. Format kopii zapasowych typu custom pozwala na zmianę kolejności i pomijanie elementów schematu bazy danych podczas odtwarzania; format custom można dodatkowo poddawać kompresji. Domyślnym formatem polecenia pg_dump jest format 652
|
Rozdz ał 21. PostgreSQL
tekstowy, który jednak nie jest kompatybilny z poleceniem pg_restore. Dlatego w celu użycia programu pg_restore podczas wykonywania kopii zapasowej poleceniem pg_dump należy użyć opcji -Ft, wymuszającej format tar, lub opcji -Fc, tworzącej kopię w formacie custom. Tworząc kopie zapasowe za pomocą programu pg_dump w formacie tekstowym w wersjach wcześniejszych niż 8.1, w celu uwzględnienia specjalnych typów binarnych należy użyć opcji -b. Od wersji 8.1 wzwyż obiekty tego typu są uwzględniane w kopii zapasowej w sposób automatyczny. W ostatnim argumencie polecenia pg_dump należy wskazać nazwę kopiowanej bazy danych. Tylko polecenie pg_dumpall automatycznie wykonuje kopię zapasową wszystkich baz danych w klastrze. Poniższe polecenie wykonuje kopię zapasową bazy danych, wykorzystując format custom (-Fc), uwzględniając dane typu BLOB (-b) i kompresując kopię z najwyższym dostępnym współczynnikiem upakowania (-Z9): $ pg_dump -Fc -Z9 -b test > db.dmp
Odtwarzanie kopii poleceniem pg_restore Program pg_restore jest wykorzystywany do odtwarzania całej bazy danych PostgreSQL w przypadku awarii, ale istnieje możliwość odtworzenia jedynie wybranych elementów bazy. Na początek omówię podstawowe funkcje odtwarzania. Poniższe polecenie odtwarza kopię zapasową wykonaną w taki sposób jak w powyższym przykładzie, czyli zapisaną poleceniem pg_dump w pliku db.dmp. Kompresja i format kopii są wykrywane automatycznie, z kopii odtwarzane są automatycznie również dane typu BLOB (o ile istnieją). Polecenie to do działania wymaga, aby istniała baza danych o nazwie test: $ pg_restore –d test db.dmp
Jeśli odtwarzana baza danych nie istnieje, można zastosować opcję -C, która spowoduje utworzenie bazy o podanej nazwie: $ pg_restore –C –d test db.dmp
Można również zażądać odtworzenia pojedynczej tabeli lub wyzwalacza (ang. trigger). W tym przypadku również należy posłużyć się odpowiednią opcją wiersza poleceń. Poniższy przykład spowoduje odtworzenie tabeli o nazwie special: $ pg_restore test –t special db.dmp
Następujące polecenie odtworzy wyzwalacz o nazwie specialtrigger i zapisze go w bazie danych test: $ pg_restore test –T specialtrigger db.dmp
Jeśli trzeba odtworzyć wybrane obiekty bazy danych, należy utworzyć listę nazw obiektów zapisanych w bazie, zmodyfikować jej zawartość tak, aby pozostawić jedynie wybrane obiekty, po czym wskazać tę listę programowi pg_restore. W pierwszej kolejności tworzymy pełną listę zawartości kopii bazy: $ pg_restore -l db.dmp > dump.list
To polecenie utworzy plik dump.list o następującej postaci: ; ; Archive created at Sun Jul 02 22:28:36 2006 ; dbname: test ; TOC Entries: 50
Kop e zapasowe ch odtwarzan e
|
653
; Compression: 9 ; Dump Version: 1.4-0 ; Format: CUSTOM ; ; ; Selected TOC Entries: ; 2; 145344 TABLE species postgres 3; 145344 ACL species 4; 145359 TABLE nt_header postgres 5; 145359 ACL nt_header 6; 145402 TABLE species_records postgres 7; 145402 ACL species_records 8; 145416 TABLE ss_old postgres 9; 145416 ACL ss_old 10; 145433 TABLE map_resolutions postgres 11; 145433 ACL map_resolutions 12; 145443 TABLE hs_old postgres 13; 145443 ACL hs_old
Wiersze można blokować, poprzedzając ich zawartość znakiem średnika. Program pg_ restore odtworzy jedynie te obiekty, których definicja nie jest zablokowana w tym listingu. W ten sposób można również zmodyfikować kolejność obiektów odtwarzanych przez program. $ pg_restore -L dump.list db.dump
Wykorzystanie pary poleceń pg_dump i psql Domyślnym formatem kopii zapasowej wykonywanej za pomocą programu pg_dump jest format tekstowy. Dlatego w przypadku, gdy przy wywołaniu programu nie zostanie wskazany format kopii, program utworzy plik tekstowy zawierający zrzut danych w bazie. Można również jawnie wskazać, aby została wykonana kopia w formacie tekstowym. $ pg_dump -Fp -b test > db.sql
To polecenie tworzy plik tekstowy zawierający polecenia (w języku SQL) niezbędne do odtworzenia zawartości bazy danych. W związku z zastosowaniem opcji -b w kopii zostaną zapisane również obiekty typu BLOB, przekonwertowane na format tekstowy (od wersji 8.1 opcja -b nie jest potrzebna). Format tekstowy nie obsługuje kompresji, zatem plik wynikowy warto skompresować, wykorzystując polecenie gzip lub podobne: $ pg_dump -Fp -b test | gzip –c > db.sql.gz
Bazę z kopii odtwarza się następującym poleceniem: $ psql -d test -f db.sql
W przypadku zastosowania kompresji należy posłużyć się potokiem poleceń: $ gzip –dc db.sql.gz | psql -d test
Oczywiście plik zawierający polecenia SQL możemy edytować, usuwając definicje tabel i innych obiektów, które chcemy pominąć przy odtwarzaniu.
Wykorzystanie pary poleceń pg_dumpall i psql Polecenie pg_dumpall wykonuje kopię wszystkich baz w ramach klastra, a jedynym formatem obsługiwanym przez to polecenie jest format tekstowy. Najczęstszym zastosowaniem polecenia pg_dumpall jest wykonanie pojedynczego pliku kopii wszystkich baz w klastrze, a najprostsza forma użycia tego polecenia jest następująca: $ pg_dumpall > all-databases.sql
654 |
Rozdz ał 21. PostgreSQL
Polecenie to tworzy plik tekstowy zawierający polecenia SQL niezbędne do odtworzenia wszystkich baz w ramach klastra, włączając w to dane typów binarnych (BLOB). Format tekstowy nie obsługuje kompresji, zatem plik wynikowy warto skompresować, wykorzystując polecenie gzip lub podobne: $ pg_dumpall | gzip –c > all-databases.sql.gz
Jeśli do wykonywania kopii zapasowej wykorzystuje się polecenie pg_dump lub technikę kopii zapasowych na potrzeby odtwarzania danych w punkcie czasu, polecenie pg_dumpall może być użyte do wykonania dodatkowej kopii globalnych danych systemowych, takich jak dane użytkowników i grup. Do tego celu służy opcja -g polecenia: $ pg_dumpall –g > global-objects.sql
Tę kopię oczywiście również można poddać kompresji: $ pg_dumpall –g | gzip –c > global-objects.sql.gz
Polecenie to tworzy plik tekstowy zawierający polecenia SQL niezbędne do odtworzenia tabel systemowych klastra. Aby odtworzyć dane z tych kopii, należy przekazać kopie do polecenia psql: $ psql -f all-databases.sql
lub: $ psql -f global-objects.sql
Jeśli wykorzystuje się kopie skompresowane, przed przekazaniem zrzutu bazy do polecenia psql należy wywołać polecenie rozpakowujące: $ gzip –dc all-databases.sql.gz | psql $ gzip –dc global-objects.sql.gz | psql
Oczywiście plik zawierający polecenia SQL możemy edytować, usuwając definicje tabel i innych obiektów, które chcemy pominąć przy odtwarzaniu.
Odtwarzanie danych w punkcie czasu Proces odtwarzania danych w punkcie czasu w przypadku serwera PostgreSQL znacząco różni się od standardowego procesu odtwarzania kopii wykonanych za pomocą narzędzi pg_dump i pg_dumpall. Jednak użytkownicy zaznajomieni z wykonywaniem gorących kopii zapasowych w bazach danych Oracle (bez wykorzystania polecenia rman) z pewnością z łatwością odkryją analogie. W przypadku PostgreSQL-a proces ten jest również nieco prostszy.
Wykonywanie kopii zapasowych z myślą o odtwarzaniu danych w punkcie czasu Aby umożliwić odtwarzanie danych w punkcie czasu (ang. point in time recovery), należy uaktywnić mechanizm archiwizacji dziennika zapisu z wyprzedzeniem (ang. write-ahead log, w skrócie WAL). Informacje na temat sposobu uaktywnienia tej funkcji można znaleźć w podrozdziale poświęconym mechanizmowi WAL.
Odtwarzan e danych w punkc e czasu
|
655
Po uaktywnieniu archiwizacji dziennika WAL procedura wykonywania kopii jest prosta. W tym celu należy:
1. Zainicjować wykonanie kopii dziennika WAL, wykonując odpowiednie polecenie przygotowujące serwer PostgreSQL do tej czynności (select pg_start_backup).
2. Wykonać kopię dziennika. 3. Poinformować bazę danych PostgreSQL o tym, że procedura kopii została zakończona (select pg_stop_backup).
Przeanalizujmy ten proces nieco bardziej szczegółowo. W pierwszej kolejności należy poinformować bazę PostgreSQL, że będzie wykonywana kopia dziennika WAL. Kopia będzie wykonywana w locie (ang. hot backup), dzięki czemu nie ma potrzeby zatrzymywania normalnych działań bazy; należy jedynie zainicjować specjalny tryb jej działania na potrzeby kopii. W tym celu należy uruchomić konsolę psql i połączyć się z dowolną bazą w kopiowanym klastrze, po czym wykonać następujące polecenie SQL: > select pg_start_backup('etykieta');
Ciąg znaków etykieta to dowolna nazwa identyfikująca kopię zapasową. W efekcie tego polecenia PostgreSQL utworzy plik o nazwie backup_label w katalogu zawierającym klaster. Ten plik zawiera informacje o kopii, takie jak czas rozpoczęcia i zakończenia jej wykonywania, oraz informacje zapisane w trakcie w segmentach dziennika WAL. W wyniku wywołania powyższego polecenia serwer PostgreSQL otrzymał informację o tym, że będzie wykonywana kopia zapasowa w sposób niezależny od samego serwera. W tym momencie można wykonać kopię plików danych klastra, w zupełnie dowolny sposób; warto jedynie pominąć podkatalog pg_xlog, aby oszczędzić nieco miejsca. Metody wykonania samej kopii są przeróżne: od utworzenia archiwum tar na dysku po zastosowanie komercyjnego oprogramowania do wykonywania kopii zapasowych na taśmie itp. Po wykonaniu kopii należy poinformować o tym bazę PostgreSQL. W tym celu z konsoli psql należy wykonać polecenie > select pg_stop_backup();
W trakcie odtwarzania danych z kopii tego typu wykorzystywany jest dziennik WAL. Dzięki temu uzupełniane są niespójności w danych wynikłe w efekcie zmian w trakcie wykonywania kopii zapasowej. Z tego powodu do odtwarzania danych w punkcie czasu niezbędne jest, aby mieć wszystkie segmenty dziennika WAL z okresu między wywołaniem polecenia selected pg_start_backup a wywołaniem polecenia pg_stop_backup. Jeśli zabraknie choćby jednego segmentu dziennika WAL z tego okresu, wykonana kopia zapasowa będzie bezużyteczna. Segment WAL jest archiwizowany w momencie, gdy zostanie w nim zapisana odpowiednia liczba zmian. To może być kilka godzin, ale też wiele dni, w zależności od intensywności wprowadzania zmian w bazie. Jeśli zostanie utracony cały katalog danych bazy (włącznie z podkatalogiem pg_xlog), utworzona przed chwilą kopia zapasowa nie będzie użyteczna, ponieważ utracone zostaną niezbędne do jej odtworzenia segmenty WAL. Dlatego przydatna byłaby funkcja przełączania segmentów WAL w momencie wykonywania kopii zapasowej, niestety, w czasie pisania tej książki tego typu operacja nie była obsługiwana. Gdyby jednak istniała, można by wymusić natychmiastową archiwizację bieżącego segmentu WAL, co spowodowałoby, że kopia plików stron danych byłaby wystarczająca do odtworzenia kopii zapasowej w punkcie czasu.
656
|
Rozdz ał 21. PostgreSQL
Załóżmy, że znaleźliśmy się w sytuacji zmuszającej do odtworzenia danych wykonanej przed chwilą kopii, ponieważ został uszkodzony dziennik WAL (zapisany w podkatalogu pg_xlog na uszkodzonym dysku twardym). Co można zrobić w takiej sytuacji? Dostępna jest opcja odtworzenia danych z jak najmniejszym zakresem braków, to znaczy odtworzenie danych od ostatniej użytecznej kopii zapasowej wraz ze zarchiwizowanymi dziennikami zapisu z wyprzedzeniem pozwalającymi na odtworzenie zmian, które zostały od tamtej pory wprowadzone w bazie (ang. roll forward). Aby sprawdzić, które segmenty WAL są niezbędne do odtworzenia posiadanej kopii stron danych, należy sprawdzić zawartość pliku .backup utworzonego w katalogu archiwum WAL. Plik ten będzie zawierał następującą informację: 000000010000001A00000012.00535CD8.backup
W tym przykładzie aktualnym dziennikiem WAL w momencie zainicjowania kopii zapasowej (pg_start_backup) był 000000010000001A00000012, w punkcie 00535CD8. W tym pliku znajdziemy następujące informacje: START WAL LOCATION: 1A/12535CD8 (file 000000010000001A00000012) STOP WAL LOCATION: 1A/131C407C (file 000000010000001A00000013) CHECKPOINT LOCATION: 1A/12535CD8 START TIME: 2006-07-11 11:59:02 BST LABEL: DBBACK-FILE-20060614-132.tar.gz STOP TIME: 2006-07-11 12:04:21 BST
Z tych danych wynika, że do odtworzenia tej kopii zapasowej absolutnie niezbędny jest plik określony w START WAL LOCATION (w tym przypadku 000000010000001A00000012), plik określony w STOP WAL LOCATION (w tym przypadku 000000010000001A00000013) oraz wszystkie pliki pomiędzy nimi (w tym przykładzie mamy jedynie dwa pliki).
Gdy uda się zapewnić dostępność tych plików, kopię zapasową można będzie uznać za gotową.
Odtwarzanie danych w punkcie czasu Procedura odtwarzania danych w punkcie czasu jest stosunkowo prosta. Oczywiście jest bardziej skomplikowana od odtwarzania kopii za pomocą poleceń pg_restore czy psql, ale odtwarzanie danych tą metodą ma dwie duże zalety. Po pierwsze, dane można odtwarzać w trybie wielowątkowym, co może znacząco przyspieszyć proces odtwarzania danych o dużych rozmiarach. Po drugie, dane można odtworzyć aż do momentu wystąpienia problemu. Oczywiście nie we wszystkich zastosowaniach te zalety mają znaczenie; wówczas można z powodzeniem wykorzystać pozostałe metody wykonywania i odtwarzania kopii. Procedura odtwarzania w punkcie czasu jest następująca:
1. Zatrzymanie procesu postmaster. 2. Jeśli mamy dostęp do odpowiedniej ilości miejsca na dyskach, warto wykonać kopię za-
pasową całego klastra bazy danych. W najgorszym razie należy przynajmniej wykonać kopię zapasową podkatalogu pg_xlog, ponieważ może zawierać niezarchiwizowane pliki dziennika WAL.
3. Usunięcie wszelkich plików z katalogu plików danych klastra oraz z podkatalogu pg_xlog. 4. Odtworzenie plików bazy danych z wykonanej wcześniej kopii zapasowej, przy zachowaniu
odpowiednich uprawnień. Należy upewnić się, że w tym procesie nie zostaną nadpisane utworzone wcześniej dowiązania symboliczne. Odtwarzan e danych w punkc e czasu
|
657
5. Jeśli w procedurze odtworzenia plików danych zostały odtworzone jakiekolwiek pliki w podkatalogu pg_xlog, należy je usunąć, ponieważ na tym etapie zawierają przestarzałe dane. Należy jednak zachować sam katalog pg_xlog oraz jego podkatalog pg_xlog/archive_ ¦status.
6. Skopiowanie (nie przeniesienie) do podkatalogu pg_xlog wszelkich niezarchiwizowanych plików WAL zachowanych w punkcie 2. lub zachowanych natychmiast po wykonaniu odtwarzanej właśnie kopii danych.
7. Utworzenie w katalogu klastra pliku recovery.conf. Ten plik powinien zawierać definicję
zmiennej restore_command, która stanowi dopełnienie zmiennej archive_command wykorzystanej do archiwizacji plików segmentów WAL. Załóżmy, że mamy następującą definicję zmiennej archive_command: archive_command = 'cp -i %p /mnt/server/archivedir/%f'
Dopełnieniem tej definicji będzie: restore_command = 'cp /mnt/server/archivedir/%f %p'
Tę definicję należy umieścić w pliku recovery.conf.
8. Dobrym pomysłem jest również wprowadzenie odpowiednich zmian w pliku pg_hba.conf, aby na czas odtwarzania danych uniemożliwić dostęp do bazy zwykłym użytkownikom. Gdy już wiadomo, że odtworzenie danych odbyło się prawidłowo, można przywrócić oryginalną zawartość tego pliku, co przywróci normalne działanie bazy danych.
9. Uruchomienie procesu postmaster. Serwer automatycznie uruchomi się w trybie przywracania (recovery), przetwarzając odpowiednie pliki WAL. Po zakończeniu tego etapu proces postmaster zmienia nazwę pliku recovery.conf na recovery.done i uruchamia bazę w standardowym trybie działania.
10. Sprawdzenie bazy danych pod kątem kompletności i prawidłowości działania. Jeśli wy-
stępują problemy, procedurę należy wykonać od początku. Jeśli wszystko działa prawidłowo, należy przywrócić standardową konfigurację środowiska. Jeśli w punkcie 8. został zablokowany dostęp użytkowników, należy przywrócić standardową zawartość pliku pg_hba.conf i wykonać polecenie pg_ctl reload.
Należy mieć na uwadze, że opisana tu metoda działa na zasadzie „wszystko albo nic”. Metody odtwarzania w punkcie czasu nie można użyć do odtworzenia pojedynczej tabeli, przestrzeni tabel lub bazy danych. Nie można również przywrócić bazy do punktu wcześniejszego od momentu wykonania kopii zapasowej. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
658 |
Rozdz ał 21. PostgreSQL
ROZDZIAŁ 22.
MySQL
MySQL to popularna baza danych na licencji open source z bardzo dużą społecznością użytkowników. Z perspektywy użytkownika MySQL jest bazą danych bardzo podobną do innych rozwiązań tego typu. Jednak z perspektywy administratora baz danych MySQL to zupełnie inny zwierz. Wielka różnica między bazą MySQL a innymi polega na koncepcji silników składowania (ang. storage engine). Taki silnik zajmuje się zapisywaniem danych na dysku. MySQL jest zbudowana w architekturze wymiennych wtyczek silników składowania. Oznacza to, że może współpracować z dowolnym mechanizmem składowania zgodnym z API zdefiniowanym przez twórców MySQL-a. W czasie pisania tej książki istniało kilkanaście silników składowania danych bazy MySQL. Do najpopularniejszych należą: MyISAM, InnoDB, BDB, Memory, Merge, Archive, Federated, NDB, CSV, BlackHole i Example. Ponadto kilka innych silników było na etapie tworzenia: PBXT, SolidDB oraz silnik o nazwie kodowej Falcon. Wtyczkowa architektura silników składowania zastosowana w MySQL-u znacząco komplikuje zadanie pisania skryptów wykonujących kopie zapasowe. Każdy silnik składowania może mieć własne metody wykonywania i odtwarzania kopii zapasowych, co zmusza do zastosowania instrukcji warunkowych i analizy sytuacji. Polecam lekturę dokumentacji wykorzystywanych silników składowania, aby zapoznać się ze specyfiką zadań wykonywania i odtwarzania kopii zapasowych. Osoby stawiające pierwsze kroki w administracji baz MySQL powinny tez zapisać się na listę dyskusyjną i poczytać o najczęściej popełnianych błędach, których świadomość pozwala łatwo ich uniknąć.
Instrukcje opisane w tym rozdziale zostały przetestowane z bazami MySQL w wersji 5.0 i 5.1. Nie ma pewności, czy będą działać ze starszymi lub nowszymi wersjami bazy. Zdecydowałem się również omówić jedynie silniki składowania: MyISAM, InnoDB i NDB. Domyślnym silnikiem składowania jest MyISAM, InnoDB jest uważany za najbardziej zgodny z wymogami ACID, a NDB (również zgodny z ACID) jest silnikiem składowania w pamięci operacyjnej wykorzystywanym w klastrze bazy MySQL. Zgodność ze standardem ACID została szczegółowo omówiona w rozdziale 15.
659
Architektura bazy danych MySQL Architektura bazy danych MySQL, w szczególności jej część związana ze składowaniem i wykonywaniem kopii zapasowych, jest zależna od wykorzystywanego silnika składowania, ale większość silników składowania ma pewne cechy wspólne.
Wspólne cechy architektury W poniższych podpunktach omawiam elementy architektury składowania bazy MySQL niezależne od zastosowanego silnika składowania.
Perspektywa użytkownika Z perspektywy użytkownika MySQL jest bazą jak każda inna. Poniższe terminy oznaczają w przypadku baz MySQL dokładnie to samo co w innych bazach relacyjnych: • baza danych, • tabela, • indeks, • wiersz, • atrybut, • partycja, • egzemplarz.
Egzemplarze Egzemplarz silnika bazy danych MySQL jest tym samym co w przypadku innych relacyjnych baz danych. Obsługuje on dostęp do jednej lub większej liczby baz danych MySQL. Egzemplarz bazy MySQL jest dostępny po uruchomieniu procesu mysqld. Istnieje możliwość uruchomienia kilku egzemplarzy serwera, pod warunkiem że każdy z nich będzie obsługiwał osobne katalogi danych i nasłuchiwał na innym porcie i gnieździe TCP. Do monitoringu tych egzemplarzy i zarządzania nimi można wykorzystać menedżer egzemplarzy (Instance Manager) bazy MySQL.
Skrypty uruchomieniowe Baza MySQL może być uruchomiona za pomocą dowolnego skryptu, ale z dystrybucją bazy MySQL otrzymujemy kilka gotowych do użycia skryptów startowych. Na przykład standardowy skrypt mysqld_safe jest zalecanym sposobem uruchamiania serwera mysqld. Jak sugeruje nazwa skryptu, wykorzystuje on pewne funkcje bezpieczeństwa, jak ponowne uruchamianie serwera w przypadku wystąpienia błędu i zapisywanie informacji diagnostycznych w pliku dziennika. W standardowej instalacji serwera MySQL znajdziemy również skrypt mysql.server oraz Instance Manager, wykorzystywany do zarządzania egzemplarzami serwera (Instance Manager ma w przyszłości w pełni zastąpić skrypt mysqld_safe). Ważnym plikiem jest również my.cnf, zapisany z reguły w katalogu /etc/ (w systemach Unix i Linux). Ten plik jest opcjonalny, ale często wykorzystywany i pozwala na zdefiniowanie opcji startowych bazy danych MySQL.
660 |
Rozdz ał 22. MySQL
Bazy danych i przestrzenie tabel Do uzyskania listy baz danych w egzemplarzu służy polecenie show databases. Te informacje mogą być użyte na potrzeby wykonywania kopii zapasowych. To polecenie swoje informacje uzyskuje nie z tabel systemowych w bazie MySQL, lecz z zawartości katalogu w systemie plików.
W przypadku wykorzystania silnika składowania InnoDB listę przestrzeni tabel można uzyskać za pomocą następującego polecenia: > show variables like 'innodb_data_file_path%' +-----------------------+------------------------+ | Variable_name | Value | +-----------------------+------------------------+ | innodb_data_file_path | ibdata1:10M:autoextend | +-----------------------+------------------------+
Obiekty binarne MySQL obsługuje specjalne typy danych do przechowywania obiektów, takich jak pliki obrazów i obszerne dane tekstowe. Istnieją cztery typy obiektów binarnych: tinyblob, blob, mediumblob i longblob, które różnią się jedynie maksymalnym rozmiarem obiektów. Do zapisu dużych porcji tekstu służą cztery typy danych: tinytext, text, mediumtext i longtext. Wszystkie obiekty binarne i tekstowe są zapisywane bezpośrednio w bazie, zatem są uwzględniane w kopiach zapasowych bazy.
Dziennik binarny Dziennik binarny zawiera historię poleceń SQL powodujących zmiany w danych, a jego głównym zadaniem jest odtwarzanie danych w punkcie czasu oraz w celach replikacji. Dziennik binarny w połączeniu ze spójną kopią zapasową bazy MySQL może posłużyć do pełnego odtworzenia bazy danych w punkcie czasu i jest wykorzystywany do przesyłania informacji o zmianach z serwera nadrzędnego do serwerów podrzędnych w ramach procedury replikacji. Dziennik binarny zawiera wyłącznie instrukcje SQL, a te instrukcje można wykonać wyłącznie na spójnej bazie danych. Z tego powodu nie można go użyć do przywrócenia bazy danych do spójnego stanu na przykład po awarii. Nie można go również użyć do zbudowania spójnej kopii zapasowej na podstawie niespójnej kopii zapasowej działającej bazy danych, analogicznie do dzienników typu redo baz danych Oracle, wykonywanych za pomocą poleceń begin backup i end backup. Z tego powodu administratorzy baz MySQL nie nazywają dziennika binarnego dziennikiem transakcyjnym. Odtwarzanie stanu bazy po awarii to bowiem główne zadanie właśnie dziennika transakcyjnego. Dziennik binarny w niektórych systemach jest aktywny w domyślnej konfiguracji, w innych należy go uaktywnić za pomocą odpowiedniej opcji. W tym celu należy podać odpowiednią wartość parametru log-bin=base_name w pliku my.cnf: [mysqld] log-bin[=base_name]
Arch tektura bazy danych MySQL
|
661
W miejsce słowa kluczowego base_name najlepiej jest wprowadzić bezwzględną ścieżkę do pliku (na przykład /backups/binarylog); dziennik musi być zapisywany w katalogu o odpowiednich uprawnieniach dla właściciela procesu mysqld. W tym przykładzie właściciel procesu mysqld musi mieć prawa zapisu do katalogu /backups.
MySQL do nazwy określonej w parametrze dopisuje przyrostek liczbowy (na przykład .001); w ten sposób powstaje sekwencja dzienników o kolejnych numerach. Na przykład w przypadku, gdy wartość base_name zostanie ustawiona na /backups/binarylog, baza utworzy plik o nazwie /backups/binarylog.001, następnie o nazwie /backups/binarylog.002 itd. Te pliki należy zachować w celu wykonania odtworzenia danych w punkcie czasu. Należy je stosować w połączeniu z pozostałymi kopiami zapasowymi bazy danych wykonanymi w tym samym czasie. Chwilę uwagi należy poświęcić zmiennej max_binlog_cache_size (rozmiar bufora dziennika binarnego), która jest domyślnie ustawiona na wartość 4 GB. Jeśli rozmiar tego bufora będzie za mały, aby zmieścić informacje o transakcji, zakończy się ona niepowodzeniem i zostanie wycofana.
Silnik składowania MyISAM Silnik składowania MyISAM jest domyślnym silnikiem składowania w bazie MySQL, a w przypadku tabel systemowych to jedyny silnik, który może być stosowany. Silnik MyISAM jest bardzo szybki; niestety, nie jest zgodny z ACID (atomicity, consistency, independence, durability, czyli „atomowość, spójność, niezależność i trwałość”). Silnik ten nie obsługuje transakcji, przez co atomowe są wyłącznie operacje pojedynczych instrukcji SQL. Nie obsługuje kluczy obcych i innych cech SQL-a niezbędnych do zapewnienia spójności odwołań, przez co nie przechodzi testów spójności. Obsługuje mechanizm blokowania jedynie na poziomie tabel, przez co trudna do uzyskania jest cecha niezależności. Jeśli nastąpiłaby awaria serwera w trakcie serii zmian, istnieje duże prawdopodobieństwo, że baza danych znalazłaby się w niespójnym stanie, co z kolei zmusza do wykonania pełnego odtworzenia bazy, a zatem baza nie spełnia warunku trwałości. Dobre kopie zapasowe i dziennik binarny pozwalają na odtworzenie bazy do spójnego stanu, ale ten proces z reguły trwa o wiele dłużej niż przywrócenie do spójnego stanu bazy zgodnej z regułą ACID. Każda tabela MyISAM jest zapisana w trzech plikach. Plik z rozszerzeniem .FRM zawiera definicję formatu tabeli. Same dane są zapisane w plikach z rozszerzeniem .MYD (MYData), a indeksy w pliku o rozszerzeniu .MYI (MYIndex). Rozszerzenia te mogą być pisane małymi lub dużymi literami. Tabele nie mogą być zapisywane w większej liczbie plików .MYD, zatem rozmiar tabeli jest ograniczony rozmiarami pliku w systemie plików. Kiedyś ograniczenie to wynosiło 2 GB, ale w większości nowszych systemów plików ograniczenie to zostało usunięte. Pliki MyISAM są zapisane w tzw. katalogu danych (ang. datadir). Każda baza danych tworzy podkatalog w katalogu datadir i w nim zapisuje swoje pliki. Ścieżkę do datadir można odczytać za pomocą następującej instrukcji w konsoli mysql: > show variables like 'datadir'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | datadir | /var/lib/mysql/ | +---------------+-----------------+
662
|
Rozdz ał 22. MySQL
Aby wykonać kopię zapasową tabeli MyISAM, należy uzyskać blokadę zapisu do tej tabeli. Taka blokada zapobiega modyfikacjom w trakcie wykonywania kopii zapasowej, takim jak zmiany, wstawianie i usuwanie wierszy z tabeli.
Silnik składowania InnoDB Jeśli aplikacja wymaga zgodności z regułami ACID, stanowczo należy rozważyć zastosowanie silnika InnoDB. Ten mechanizm jest w pełni zgodny z ACID i obsługuje transakcje, przestrzenie tabel, wycofywanie zmian transakcji, klucze obce i wykonywanie kopii zapasowych w locie. Silnik ten nie jest tak szybki jak silnik MyISAM, ale istnieje poważne uzasadnienie takiego stanu rzeczy: po prostu zadania związane z zapewnieniem spójności transakcyjnej tabel wymagają dodatkowego czasu. Jeśli ktoś wykorzystuje już tabele MyISAM i zdecyduje się przejść na InnoDB ze względu na obsługę integralności, może to zrobić w dość prosty sposób. Służy do tego instrukcja alter table ... engine=innodb; można też utworzyć pustą tabelę InnoDB o identycznej definicji i skopiować do niej wszystkie wiersze za pomocą instrukcji insert into ... select * from.... W dokumentacji bazy MySQL można znaleźć porady dotyczące przyspieszenia procesu importowania dużych tabel. Z uwagi na kwestie integralności danych w systemach Linux należy wyłączyć systemowe buforowanie zapisu. W tym celu należy wykonać polecenie hdparm -W0 /dev/hda (dla dysków ATAPI).
Aby silnik InnoDB był wykorzystywany w przypadku wszystkich tabel niesystemowych, należy w pliku konfiguracyjnym serwera, w sekcji [mysqld], wpisać opcję default-storageengine=innodb. Nie należy konwertować tabel systemowych na format InnoDB. Tabele systemowe muszą być zapisane w formacie MyISAM.
Podobnie jak pliki MyISAM pliki InnoDB są z reguły zapisywane w domyślnym katalogu danych (ang. datadir). Każda baza danych tworzy w tym katalogu podkatalog, w którym zapisywane są jej pliki danych. Bezpośrednio w katalogu danych zapisana jest domyślna przestrzeń tabel o nazwie ibdata1. W przypadku wykonywania kopii zapasowych na poziomie plików, należy skopiować również ten plik. Ścieżkę do domyślnego katalogu danych można odczytać za pomocą następującej instrukcji wywołanej z konsoli mysql: > show variables like 'datadir'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | datadir | /var/lib/mysql/ | +---------------+-----------------+
Nie należy zapominać o wykonywaniu kopii zapasowej pliku domyślnej przestrzeni tabel, czyli /ibdata1. Bardzo często zdarza się, że administratorzy wykonują jedynie kopie zapasowe plików w katalogach baz danych (/), a zapominają o tym pliku domyślnej przestrzeni tabel w . Należy również pamiętać, że nie jest konieczne, aby wszystkie pliki danych były zapisane w .
Arch tektura bazy danych MySQL
| 663
Obawy związane z InnoDB Silnik składowania InnoDB jest produktem komercyjnym licencjonowanym przez fińską firmę Innobase. W 2005 roku firma Innobase została kupiona przez Oracle, co wzbudziło obawy, że firma Oracle zdecyduje się przerwać rozwój silnika InnoDB. Jak do tej pory obawy te nie sprawdziły się, o czym można przekonać się w oficjalnym oświadczeniu firmy Oracle (http://www.oracle. ¦com/innodb/index.html): „Firma Oracle od lat wspiera oprogramowanie open source, jak Linux i Apache”, stwierdził Charles Rozwat, wiceprezes firmy Oracle do spraw technologii baz danych i warstw pośrednich. „Innobase to innowacyjna firma rozwijająca technologie open source. Oracle planuje kontynuować rozwój technologii InnoDB również w zakresie oprogramowania open source. Nasza firma opracowała i udostępniła między innymi klastrowy system plików dla Linuksa. Spodziewamy się w przyszłości zwiększyć zakres naszego wkładu w tej dziedzinie”.
Transakcje Transakcja w bazie MySQL wykorzystującej silnik InnoDB ma zbliżone właściwości do transakcji w innych bazach danych, z tą różnicą, że InnoDB nie obsługuje takich samych poziomów izolacji co większość pozostałych. Można tworzyć proste lub skomplikowane transakcje, a wszystkie modyfikacje będą zapisywane w dzienniku transakcyjnym InnoDB oraz segmentach wycofywania transakcji (ang. rollback segments). Instrukcje SQL są również zapisywane w binarnych dziennikach bazy MySQL. Dziennik transakcyjny i segmenty wycofywania są wykorzystywane przez proces odtwarzania bazy danych w przypadku awarii, a dzienniki binarne mogą być wykorzystane do powtórzenia instrukcji SQL na spójnej kopii bazy danych w celu odtworzenia stanu bazy.
Przestrzeń tabel Przestrzenie tabel (ang. tablespace) w przypadku silnika InnoDB i NDB mają podobną konstrukcję co w przypadku baz Oracle, to znaczy składają się z kilku plików. Przestrzeń tabel NDB może być utworzona za pomocą instrukcji create tablespace lub alter tablespace (dostępnych od wersji 5.1 bazy MySQL). Obecnie przestrzenie tabel InnoDB można tworzyć jedynie przez edycję pliku konfiguracyjnego my.cnf.
Plik danych Plik danych (ang. datafile) jest częścią przestrzeni danych InnoDB. Jest dodawany do przestrzeni danych przez wywołanie polecenia create tablespace lub alter tablespace.
Segment wycofywania lub grupa dzienników Segment wycofywania (ang. rollback segment) silnika składowania InnoDB ma podobne zastosowanie co segment wycofywania w bazach Oracle. Baza wykorzystuje informacje zapisane w tym segmencie do wycofywania transakcji. Segment ten jest również wykorzystywany do odczytu poprzedniej wartości wiersza. Informacje w segmencie wycofywania są przechowywane dopóty, dopóki są niezbędne do wycofania transakcji. W przypadku silnika NDB tę samą funkcję pełni grupa dzienników (ang. log group).
664 |
Rozdz ał 22. MySQL
Dziennik transakcyjny InnoDB ma własny dziennik transakcyjny, w którym są zapisywane transakcje wykonywane na tabelach InnoDB. Dziennik ten jest wykorzystywany wraz z segmentem wycofywania w celu przywrócenia bazy do spójnego stanu. Nie jest jednak wykorzystywany do powtórzenia transakcji na podstawie spójnej kopii bazy danych (ang. roll forward), zatem dzienników tych nie ma sensu archiwizować. Z tego powodu parametr innodb_log_archive ma wartość 0, co oznacza brak archiwizacji dziennika transakcji dla silnika InnoDB.
Inne silniki składowania Oprócz opisanych wyżej istnieją inne silniki składowania dostępne dla bazy MySQL. Niektóre były dostępne już w czasie pisania tej książki, inne były dopiero na etapie tworzenia. Omówmy je pokrótce. NDB NDB to silnik składowania wykorzystujący pamięć RAM w charakterze nośnika danych. Ten silnik jest wykorzystywany przez klaster bazy MySQL. W wersji 5.1 bazy MySQL pojawiła się możliwość zapisywania nieindeksowanych tabel z wykorzystaniem przestrzeni tabel w charakterze miejsca składowania i grupy dzienników na potrzeby wycofywania. Pozostałe obiekty istnieją wyłącznie w pamięci RAM i są zapisywane na dysku twardym w punkcie kontrolnym (ang. checkpoint) oraz w ramach procedury zamykania serwera. Silnik składowania NDB obsługuje mechanizm kopii zapasowych w locie, co zostanie omówione w podrozdziale „Wykonywanie i przywracanie kopii zapasowych w locie”. Klaster NDB obsługuje izolację transakcji na poziomie read commited. PBXT PBXT jest silnikiem składowania rozwijanym niezależnie od projektu MySQL. Po ukończeniu silnik ten będzie udostępniany jako wtyczka do bazy MySQL. Szczegóły na temat projektu można znaleźć pod adresem http://forge.mysql.com/projects/view.php?id=43. SolidDB SolidDB jest kolejnym wtyczkowym silnikiem składowania. Projekt jest rozwijany przez Solid Information Technology. Szczegóły na temat projektu można znaleźć pod adresem http://forge.mysql.com/projects/view.php?id=139. Falcon Falcon to nazwa kodowa nowego silnika składowania dla bazy MySQL. Silnik ten jest tworzony przez Jima Starkeya. Szczegóły na temat projektu można znaleźć pod adresem http://forge.mysql.com/wiki/Falcon.
Metodologie wykonywania i odtwarzania kopii zapasowych baz MySQL Istnieją dwa sposoby wykonywania kopii zapasowych baz MySQL bez ponoszenia dodatkowych kosztów finansowych. Pierwszy z nich polega na utworzeniu serii instrukcji języka SQL odtwarzających zawartość bazy danych. Do tego celu służy polecenie mysqldump. Drugi sposób polega na skopiowaniu samych plików bazy danych, pod warunkiem że zapewni
Metodolog e wykonywan a odtwarzan a kop zapasowych baz MySQL
| 665
się niezmienność tych plików podczas całej procedury wykonywania kopii. Ten warunek jest obecnie do spełnienia wyłącznie w przypadku tabel archiwalnych MyISAM z zastosowaniem skryptu mysqlhotcopy. Niezależnie od wyboru metody wykonania kopii zapasowej należy upewnić się, że przed rozpoczęciem wykonywania kopii został uaktywniony dziennik binarny. Dzięki temu możliwe będzie wykonanie odtworzenia bazy w punkcie czasu.
Użytkownicy tabel InnoDB mogą również skorzystać z komercyjnego rozwiązania do wykonywania kopii zapasowych w locie autorstwa Oracle. Tego narzędzia nie opisuję w tej książce, ale mogę stwierdzić, że jego możliwości uzasadniają koszt zakupu.
Tworzenie i odtwarzanie kopii na poziomie SQL-a Program mysqldump został zaprojektowany w celu automatyzacji tworzenia kopii zapasowych na poziomie SQL-a jednej lub większej liczby baz danych MySQL. Program ten tworzy plik tekstowy w formacie czytelnym dla człowieka zawierający polecenia SQL niezbędne do odtworzenia baz MySQL i ich zawartości. Aby wykonać zrzut bazy w formacie SQL, należy zablokować wszystkie tabele przed zapisem i odblokować je po zakończeniu wykonywania kopii. Do tego celu służą polecenia dialektu SQL obsługiwanego przez bazę MySQL. Jeśli kopiowane są tabele MyISAM, można posłużyć się opcją --lock-tables lub --lock-alltables programu mysqldump. Opcja --lock-tables blokuje tabele pojedynczo, co może spowodować problem z integralnością bazy, gdy zmiany zostaną wprowadzone tylko w wybranych tabelach. Opcja --lock-all-tables pozwala zapobiec takiej sytuacji, dając gwarancję zachowania spójności bazy, ale baza danych będzie niedostępna przez cały czas wykonywania kopii. Zatem mimo tego, że baza danych pozostaje aktywna przez okres wykonywania kopii „w locie”, blokady na tabelach znacząco obniżają jej użyteczność w tym czasie. Operacje: INSERT, UPDATE i DELETE nie są wykonywane, to znaczy są wstrzymywane przez okres blokady i wznawiane po zdjęciu jej z tabel (zakończeniu wykonywania kopii). W przypadku wykonywania kopii tabel InnoDB należy zastosować opcję --single-transaction. Tworzy ona blokadę na krótki czas na początku procesu wykonywania kopii i pozwala zachować spójność bazy danych bez stałego blokowania tabel przez cały okres wykonywania kopii. Opcje: --lock-tables, --lock-all-tables oraz --single-transaction wzajemnie się wykluczają. Gdy w wywołaniu wystąpią dwie z nich, kopia zapasowa nie zostanie wykonana, a program zakończy działanie komunikatem o błędzie. W niektórych przypadkach nadmiarowe opcje mogą również zostać zignorowane.
Jeśli do odtwarzania bazy danych w punkcie czasu planujemy wykorzystać dziennik binarny, przy wykonywaniu kopii należy zastosować opcje --flush-logs i --master-data=2. Pierwsza z nich powoduje zapis w bazie danych informacji zapisanych w dzienniku binarnym, dzięki czemu w dzienniku zostaną zapisane jedynie te zmiany, które zostały wprowadzone po rozpoczęciu wykonywania kopii zapasowej. Opcja --master-data=2 powoduje, że plik zrzutu będzie zawierał instrukcję zmiany nazwy i pozycji dziennika binarnego (CHANGE MASTER TO).
666
|
Rozdz ał 22. MySQL
Wykonywanie kopii tabel MyISAM Poniższe polecenia wykonują zrzut w formacie SQL wszystkich baz danych dla danego egzemplarza bazy MySQL, z zastosowaniem blokad na tabelach, zrzucaniem dzienników binarnych i zapisem instrukcji zmiany nazwy i pozycji dziennika binarnego. Drugie polecenie spowoduje kolejną zmianę dziennika binarnego, aby zapisać kopię zmian, które nastąpiły w trakcie wykonywania poprzedniej kopii. $ mysqldump --all-databases --lock-all-tables --flush-logs --master-data=2 > all_databases.sql $ mysqladmin --flush-logs
Wykonywanie kopii tabel InnoDB W przypadku kopiowania tabel InnoDB opcję --lock-all-tables należy zastąpić opcją --single-transaction. Dzięki temu cały proces mysqldump będzie traktowany jak pojedyncza transakcja. Pierwsze z przykładowych poleceń wykonuje kopię wszystkich baz danych, zrzuca dane z dzienników i zapisuje w kopii informację o nowej nazwie dziennika. Drugie polecenie wykonuje kopię jedynie bazy danych o nazwie mysql, wykorzystując opcję --lock-all-tables, co jest jak najbardziej prawidłowe, ponieważ baza mysql (baza tabel systemowych) wykorzystuje silnik składowania MyISAM. Trzecie polecenie powoduje zapisanie zawartości dziennika binarnego, dzięki czemu zostaje wykonana kopia danych zmodyfikowanych w bazie w czasie tworzenia kopii zapasowych. $ mysqldump --all-databases --single-transaction --flush-logs --master-data=2 > all_databases.sql $ mysqldump --database=mysql --lock-all-tables --flush-logs --master-data=2 > system.sql $ mysqladmin --flush-logs
Naprawa uszkodzonych tabel MyISAM Istnieją dwa powody odtwarzania baz danych. Pierwszym z nich jest fizyczne uszkodzenie, na przykład usunięcie plików bazy danych lub awaria nośnika, na którym baza była zapisana. Drugi powód to uszkodzenie „logiczne”, polegające na wprowadzeniu błędnych danych do jednej lub większej liczby tabel bazy. Jeśli uszkodziły się tabele MyISAM, warto w pierwszym kroku podjąć próbę ich naprawienia. Ten sposób może okazać się szybszy. Większość problemów można naprawić poleceniem myisamchk. Aby wykorzystać tę możliwość, należy przejść do katalogu zawierającego dane MyISAM i wywołać następujące polecenie: $ myisamchk -r -q nazwa_tabeli
Jeśli to nie wystarczy, może okazać się konieczne zastosowanie bardziej radykalnej metody naprawczej: $ myisamchk --safe-recover nazwa_tabeli
Odtwarzanie baz MySQL z użyciem plików z kodem SQL Odtwarzanie baz MySQL z kopii wykonanych poleceniem mysqldump to proste zadanie. Wystarczy wywołać polecenie mysql, podając mu na wejściu odpowiedni plik kopii: $ mysql –u username –p < all_databases.sql
Oczywiście wynik programu mysqldump możemy wyedytować, usuwając bazy i tabele, których nie planujemy odtwarzać.
Metodolog e wykonywan a odtwarzan a kop zapasowych baz MySQL
|
667
Aby odtworzyć zmiany, które zaszły w tabeli od czasu wykonania ostatniej kopii zapasowej, należy zastosować się do instrukcji z punktu „Odtwarzanie danych w punkcie czasu” w dalszej części rozdziału.
Wykonywanie i odtwarzanie kopii zapasowych na poziomie plików Tabele MyISAM są zapisane jako pliki w systemie, można je więc skopiować, wykorzystując do tego dowolny program do wykonywania kopii zapasowych, pod warunkiem że zadba się o to, aby nie zostały zmodyfikowane w trakcie tego procesu.
Samodzielne przygotowanie narzędzia do kopii zapasowych na poziomie plików Istnieje sporo sposobów wykonywania kopii zapasowej bazy MySQL na poziomie plików, ale wszystkie sprowadzają się do zatrzymania bazy MySQL i skopiowania plików jej danych. Można to zrobić na trzy sposoby: • Zrzucenie do plików danych wszelkich oczekujących zapisów, uzyskanie blokady na tabe-
lach, skopiowanie plików danych i zwolnienie blokady. • Zrzucenie do plików danych wszelkich oczekujących zapisów, uzyskanie blokady na tabe-
lach, wykonanie migawki systemu plików (ang. filesystem snapshot) i zwolnienie blokady. • Zatrzymanie bazy danych, skopiowanie plików (lub wykonanie migawki) i uruchomienie
bazy. Jeśli pliki MyISAM mają być zrzucane „na gorąco” (w trakcie działania bazy), należy upewnić się, że MySQL ich nie zmodyfikuje. W tym celu należy zadbać o to, aby baza danych zapisała na dysku dane przechowywane w buforach, oraz uzyskać blokadę na odpowiednich tabelach. W tym momencie można wykonać kopię plików danych. Aby uzyskać blokadę tabel i zrzucić na dysk oczekujące zmiany, należy wykonać następujące polecenia (z konsoli mysql): mysql> flush tables with read lock; mysql> flush logs;
Od tego momentu operacje wstawiania, modyfikowania i usuwania wierszy będą wstrzymane, dzięki czemu można będzie skopiować pliki bez obawy, że uzyska się niespójną kopię. Oczywiście, aby zminimalizować przestoje w działaniu bazy, warto zadbać o to, aby kopia wykonała się tak szybko, jak to tylko możliwe. Mamy do dyspozycji wykonanie typowej kopii plików danych lub wykonanie tak zwanej migawki. Jeśli zdecydujemy się na wykonanie kopii plików, możemy to zrobić w dowolny sposób. Możemy na przykład wykonać archiwum tar albo obraz cpio na dysku lub taśmie. Można również wykorzystać dowolny program do wykonywania kopii zapasowych — komercyjny lub dostępny na licencji open source. Po wykonaniu kopii należy zwolnić blokadę: mysql> unlock tables;
Inny ciekawy sposób polega na użyciu mechanizmu Linuksa o nazwie Logical Volume Manger (LVM) i wykonaniu za jego pomocą tzw. migawki systemu plików. Polega to w przybliżeniu na zamrożeniu wirtualnego obrazu zawartości dysku twardego, co pozwala na wykonanie kopii zapasowej bazy bez konieczności przetrzymywania blokady przez cały okres wykonywania 668 |
Rozdz ał 22. MySQL
kopii. Niemniej jednak nadal istnieje konieczność zrzucenia buforów i blokowania tabel, lecz tym razem jedynie na czas wykonania migawki systemu LVM. mysql> flush tables with read lock; mysql> flush logs;
Po wykonaniu tych poleceń należy wykonać migawkę LVM. W miejsce ciągu znaków rozmiar należy w poniższym poleceniu podać rozmiar migawki i w miejsce ciągu znaków nazwa wstawić jej nazwę. Ciągi znaków volgroup i lvol określają odpowiednio nazwę grupy woluminów oraz wolumin logiczny, na przykład vg01/lvol1: # lvcreate --snapshot --size=rozmiar --name=nazwa /dev/volgroup/lvol
W tym momencie można odblokować tabele: mysql> unlock tables;
Po wykonaniu migawki należy ją zamontować: # mkdir -p /mnt/nazwa # mount -o -ro /dev/volgroup/nazwa /mnt/nazwa
Po wykonaniu tych poleceń w katalogu /mnt/nazwa znajdziemy zawartość migawki, którą możemy skopiować bez nadmiernego pośpiechu, a następnie odmontować. Gdy już migawka nie jest potrzebna, należy ją usunąć za pomocą następującego polecenia: # lvremove -f /dev/volgroup/lvol
Można oczywiście również wykonać zimną kopię, to znaczy kopię plików danych po zatrzymaniu serwera. Jedyny element przygotowań do zimnej kopii zapasowej polega na zatrzymaniu serwera mysqld. Po wykonaniu kopii plików lub migawki można ponownie uruchomić serwer bazy danych.
Kopie na poziomie systemu plików z użyciem programu mysqlhotcopy W przypadku wykorzystania tabel MyISAM lub Archive warto zastosować polecenie mysqlhotcopy, które automatyzuje proces tworzenia kopii na poziomie systemu plików. Wywołanie programu jest proste: podaje się dwa parametry: nazwa_bazy oraz katalog (w tym katalogu zostaną zapisane kopie plików): $ mysqlhotcopy nazwa_bazy /katalog
Problem związany z tą metodą wiąże się z koniecznością przekazania na wejściu polecenia nazwy użytkownika i hasła, co jest niezalecaną praktyką z uwagi na obniżenie bezpieczeństwa. Rozwiązanie tego problemu polega na edycji pliku my.cnf, w sekcji [klient]: [client] username=root password=haslo
Odtwarzanie bazy z kopii zapasowych na poziomie systemu plików Odtwarzanie kopii zapasowych na poziomie systemu plików to proste zadanie. Wystarczy zatrzymać proces bazy danych i po prostu przywrócić skopiowane pliki na ich pierwotne miejsce. Jedną z wad tego podejścia jest to, że nie ma prostego sposobu na połączenie danych zapisanych w tego typu kopiach z istniejącymi tabelami. Można je jednak odtworzyć w innym katalogu, a następnie wykonać polecenie sqldump, aby zrzucić ich zawartość do pliku tekstowego, po czym połączyć je z istniejącymi danymi, odtwarzając je w odpowiednich tabelach.
Metodolog e wykonywan a odtwarzan a kop zapasowych baz MySQL
| 669
Do odtworzenia zmian dokonanych w bazie danych od momentu wykonania ostatniej kopii zapasowej służy technika odtwarzania danych w punkcie czasu. To zagadnienie jest omówione w następnym podrozdziale.
Projekty związane z bazą MySQL Społeczność MySQL-a pracuje nad nowymi funkcjami dla tej bazy danych. Jedną z nich ma być mechanizm kopii zapasowych online, zaprojektowany w celu pełnego zastąpienia narzędzi mysqldump i mysqlrestore. W czasie pisania tej książki pozostawało jeszcze dużo pracy; szczegóły na temat postępu prac można znaleźć na stronie projektu: http://forge.mysql.com/wiki/OnlineBackup. Innym ciekawym projektem jest silnik składowania zgodny z ACID o nazwie kodowej Falcon.
Wykorzystanie mechanizmów odtwarzania danych w punkcie czasu Jeśli w systemie aktywna jest opcja wykorzystania dziennika binarnego, istnieje możliwość odtwarzania danych w punkcie czasu, niezależnie od zastosowanej formy wykonywania i odtwarzania kopii zapasowych bazy. Jeśli tworzy się dziennik binarny, ścieżka i nazwy plików dziennika są określone opcją wywołania procesu mysqld z opcją --log-bin=sciezka. Na przykład w przypadku zastosowania wartości /backups/binarylog w katalogu /backups będą tworzyć się kolejno pliki: binarylog.001, binarylog.002 i tak dalej. W przypadku dziennika binarnego typowo stosuje się tę samą ścieżkę, w której są zapisane również dane bazy. Ja jednak preferuję zapisywanie tych ważnych plików w innych lokalizacjach, najlepiej w osobnym systemie plików, wraz z wynikami działania polecenia mysqldump lub innych narzędzi do wykonywania kopii zapasowych bazy.
Istnieją dwa sposoby odtwarzania danych z dziennika binarnego. Pierwszy z nich polega na bezpośrednim wykorzystaniu dziennika, bez pośredniego przekształcania go na format tekstowy. Druga opcja polega na przekształceniu go na tekst, na przykład przez zapisanie w pliku jego tekstowej reprezentacji, a następnie wykorzystaniu tego pliku do wygenerowania poleceń SQL. W pierwszej kolejności należy oczywiście odtworzyć z kopii bazę danych, wykorzystując jedną z opisanych wyżej metod, na przykład za pomocą poleceń mysqldump lub mysqlcopy, czy własnej metody wykonywania i odtwarzania kopii bazy danych. Po wykonaniu tego zadania baza danych jest odtworzona z zawartością z momentu utworzenia kopii bazy. Z taką bazą można wykorzystać dziennik binarny, odtwarzając zmiany, które zaszły w bazie od momentu wykonania jej kopii.
Bezpośrednie wykorzystanie dzienników binarnych Najprostszą metodą wykorzystania dzienników binarnych jest przekazanie ich zawartości na wejście polecenia mysql. Załóżmy, że mamy dwa dzienniki binarne zawierające zmiany od momentu wykonania kopii zapasowej bazy: /backups/binarylog.093 i /backups/binarylog.094.
670
|
Rozdz ał 22. MySQL
Wystarczy przetworzyć ich zawartość za pomocą programu mysqlbinlog, a wynik przekazać programowi mysql: $ mysqlbinlog --database=database /backups/binarylog.093 /backups/binarylog.094|mysql
To polecenie przekazuje na wejście programu mysql serię poleceń SQL odzwierciedlających zmiany w bazie zapisane w dzienniku binarnym.
Wykorzystanie dzienników binarnych z użyciem przejściowych plików tekstowych Program mysqlbinlog przetwarza dzienniki binarne i wysyła je na standardowe wyjście polecenia SQL odpowiadające zapisanym w nich operacjom. Wystarczy zatem zapisać to wyjście do pliku: $ mysqlbinlog --database=database /backups/binarylog.093 \ /backups/binarylog.094 >/backups/myredo.sql
Ten plik tymczasowy zawiera polecenia SQL, które można przekazać do wykonania programowi mysql: $ mysql < /backups/myredo.sql
Obie te metody w zasadzie wykonują dokładnie tę samą operację, ale w przypadku drugiej z nich dane zapisane w dzienniku binarnym można oczywiście poddać edycji przed załadowaniem do bazy danych.
Ładowanie danych z dzienników binarnych z zastosowaniem zakresów dat Czasem zdarza się tak, że nie chcemy ładować bazy aż do momentu wystąpienia awarii, szczególnie w przypadku, gdy „awaria” jest efektem błędu użytkownika. Załóżmy, że administrator bazy danych przez nieuwagę usunął ważną tabelę i nie ma możliwości wycofania tej transakcji (co jest możliwe szczególnie w przypadku tabel MyISAM, które nie obsługują mechanizmu wycofywania transakcji). W takiej sytuacji można przywrócić bazę do momentu wykonania ostatniej pełnej kopii bazy i uzupełnić dane z dziennika binarnego aż do momentu poprzedzającego usunięcie tabeli. Można to zrobić na dwa sposoby. Jeśli dokładnie wiadomo, kiedy nastąpiło pechowe zdarzenie, można programowi mysqllog podać zakres dat, z którego mają być odtworzone zmiany w bazie: $ mysqlbinlog --start-date="2006-07-09 15:00:00" --stop-date="2006-07-10 15:00:00" \ /backups/binarylog.093 /backups/binarylog.094 |mysql
Inny sposób polega na zapisaniu w pliku odczytanych z dziennika binarnego poleceń SQL modyfikujących bazę: $ mysqlbinlog /backups/binarylog.093 /backups/binarylog.094 >/backups/myredo.sql
Następnie należy poddać edycji plik /backups/myredo.sql i odszukać miejsce, w którym usuwana jest dana tabela (polecenie DROP TABLE). Każda instrukcja w dzienniku jest numerowana za pomocą ciągu znaków log_pos). Następnie wskazujemy programowi mysqlbinlog pozycję, w której powinien zatrzymać odtwarzanie bazy: $ mysqlbinlog --start-position="337280" --stop-position="337302" \ /backups/binarylog.093 /backups/binarylog.094 |mysql
Można również zapisać polecenia SQL w pliku i po prostu usunąć zbędne operacje. Tak zmodyfikowany plik można następnie wykorzystać z programem mysql. W pierwszej kolejności należy utworzyć plik: $ mysqlbinlog /backups/binarylog.093 /backups/binarylog.094 >/backups/myredo.sql
Metodolog e wykonywan a odtwarzan a kop zapasowych baz MySQL
|
671
Następnie należy zmodyfikować jego zawartość, po czym przekazać ją do programu mysql: $ cat /backups/myredo.sql|mysql
Wykonywanie i przywracanie kopii zapasowych w locie Bazy klastra MySQL są zapisywane w wielu węzłach. Wykonywanie kopii zapasowych działa nieco inaczej niż w przypadku innych baz danych. Pojedyncze polecenie powoduje zapis we wskazanym katalogu trzech plików dla każdego węzła. Po uzyskaniu informacji o zakończeniu tworzenia kopii zapasowej można dowolną metodą zarchiwizować utworzone pliki. Jak wspomniałem, kopia każdego węzła składa się z trzech plików zawierających różne dane. Nazwy tych plików rozpoczynają się ciągiem znaków BACKUP i zawierają identyfikatory i . Identyfikator jest unikalny dla każdej wykonanej kopii zapasowej i jest generowany na początku procesu wykonywania kopii, to unikalny identyfikator każdego węzła, dla którego tworzony jest plik kopii. W pliku BACKUP-..ctl zapisywane są metadane. Ten plik zawiera nazwy i definicje wszystkich tabel bazy danych. Dla każdego węzła w jego pliku metadanych zapisywane są definicje wszystkich tabel w odpowiednim klastrze. Dane tabel zapisywane są w pliku BACKUP--0..datafile. Każdy węzeł zawiera fragment całej bazy danych; na początku pliku datafile znajduje się nagłówek określający tabele, których rekordy są zapisane w tym pliku. Dziennik transakcyjny jest zapisywany w pliku BACKUP-..logfile. Ten plik zawiera rekord transakcyjny określający sposób zapisu danych w bazie. Dla każdego węzła zapisywany jest wyłącznie dziennik transakcyjny tabel zapisanych w tym węźle.
Konfiguracja wstępna Aby wykonać kopię zapasową klastra bazy MySQL, należy określić wartości czterech parametrów konfiguracyjnych bazy. Domyślne wartości tych parametrów mogą jednak być wykorzystane w większości środowisk. BackupDataBufferSize
Rozmiar pamięci bufora przy zapisie na dysk.
BackupLogBufferSize
Rozmiar pamięci, która zostanie wykorzystana na potrzeby rekordów dziennika, zanim zostaną zrzucone na dysk.
BackupMemory
Całkowita ilość pamięci przydzielonej na potrzeby kopii zapasowej. Ten rozmiar powinien być co najmniej równy wartościom BackupDataBufferSize i BackupLogBufferSize.
BackupWriteSize
Rozmiar bloku przy zapisie na dysk; dotyczy wszystkich operacji wykonywanych w ramach kopii zapasowej.
Opcjonalnie można określić wartość BackupDataDir, określającą katalog, w którym zostaną zapisane kopie danych klastra. Jeden z popularnych sposobów wykorzystuje sieciowy katalog NFS, w którym są zapisywane kopie zapasowe. Jeśli wartość parametru BackupDataDir nie zostanie określona, kopie zapasowe będą zapisywane w podkatalogu BACKUP katalogu wskazanego parametrem FileSystemPath. 672
|
Rozdz ał 22. MySQL
Wykonywanie kopii klastra bazy MySQL Procedura wykonywania kopii jest stosunkowo prosta: należy wywołać jedno polecenie i zweryfikować wypisywane przez nie informacje:
1. Uruchomienie procedury kopii zapasowej (z wiersza poleceń): $ ndb_mgm –e "start backup"
2. Polecenie to wysyła do klastra bazy danych polecenie rozpoczynające tworzenie kopii
zapasowej, po czym odpowiada komunikatem Start of backup ordered. Dopiero tym momencie zostało złożone zlecenie wykonania kopii; nie ma nawet pewności, że klaster zaakceptował polecenie.
3. Po uruchomieniu kopii program wypisuje komunikat Backup backup_id started, gdzie backup_id jest unikalnym identyfikatorem przydzielonym kopii. W tym momencie mamy
informację, że procedura wykonania kopii zapasowej została rozpoczęta.
Procedura może zająć dłuższą chwilę. Aby przerwać jej wykonanie, należy z wiersza poleceń wykonać następujące polecenie: $ ndb_mgm –e "abort backup backup_id"
gdzie backup_id jest identyfikatorem zgłoszonym przez polecenie wykonania kopii.
4. Po wykonaniu kopii klient zarządzający wypisuje komunikat Backup backup_id completed. 5. W tym momencie w katalogu wskazanym w konfiguracji znajdziemy utworzone kopie plików danych klastra MySQL.
Odtwarzanie danych klastra MySQL Kopie zapasowe klastra MySQL wykonane opisaną wyżej metodą odtwarza się za pomocą polecenia ndb_restore. To polecenie należy wykonać osobno dla każdego zestawu (trójki) plików każdego węzła klastra. Innymi słowy, należy je wywołać tyle razy, ile węzłów ma klaster. Aby można było odtworzyć klaster bazy MySQL, musi on być działający i musi istnieć pusta baza danych, do której klaster będzie odtwarzany. Musi również być dostępne połączenie z klastrem, które zostanie wykorzystane do odtworzenia. Aby sprawdzić, czy tego typu połączenie jest dostępne, należy wywołać polecenie ndb_mgm –e show. Odtworzenie klastra bazy MySQL wykonuje się zgodnie z poniższą procedurą:
1. Na każdym węźle klastra wywołać polecenie ndbd --initial. 2. Ustawić klaster w trybie pojedynczego użytkownika. 3. Po utworzeniu pustej bazy danych oraz sprawdzeniu dostępności połączenia do bazy można przystąpić do odtwarzania.
4. Wywołać polecenie ndb_restore, wskazując mu pierwszy klaster. W tym celu należy określić host i port serwera MySQL Cluster Management Server, podając opcję –c mgm_host:port oraz numer węzła w klastrze za pomocą opcji -n (na przykład -n 1). Węzły można odtwarzać w dowolnej kolejności, oczywiście dla zachowania porządku warto rozpocząć od pierwszego. Przy odtwarzaniu pierwszego węzła należy dodatkowo zastosować opcję -m.
Metodolog e wykonywan a odtwarzan a kop zapasowych baz MySQL
|
673
W poleceniu należy również wskazać backup_id za pomocą opcji -b (na przykład -b 7) oraz nazwę katalogu zawierającego pliki kopii (na przykład /backups/mysqlcluster). Przy odtwarzaniu pierwszego klastra należy zastosować opcję -m, która powoduje odtworzenie tabel. Oto przykładowe wywołanie odtwarzające pierwszy węzeł z kopii zapasowej o backup_id równym 7. Kopie zapasowe są zapisane w katalogu /backups/mysqlcluster: $ ndb_restore -c mgm_host:port -n 1 -m –b 7 -r /backups/mysqlcluster
5. Po zakończeniu działania polecenia należy wywołać je dla następnych klastrów. Poniżej
przedstawiam polecenia odtwarzające kolejne trzy węzły klastra. Powyżej odtworzyliśmy już pierwszy węzeł, następny odtwarzany węzeł ma zatem numer 2: $ ndb_restore -c mgm_host:port -n 2 -b 7 -r /backups/mysqlcluster $ ndb_restore -c mgm_host:port -n 3 -b 7 -r /backups/mysqlcluster $ ndb_restore -c mgm_host:port -n 4 -b 7 -r /backups/mysqlcluster
Po uruchomieniu pierwszego polecenia ndb_restore (z opcją -m) następne można wywoływać w sposób równoległy. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
674
|
Rozdz ał 22. MySQL
CZĘŚĆ VI
Różności
Część VI składa się z dwóch rozdziałów: Rozdział 23. „VMWare i inne” W tym rozdziale omówiona jest problematyka wykonywania kopii zapasowych serwerów VMWare oraz systemów plików dynamicznie modyfikowanych. Dla inspiracji na końcu rozdziału umieściłem nieco poezji związanej z kopiami zapasowymi. Rozdział 24. „Ochrona danych” Wyjaśnia, że wykonywanie i odtwarzanie kopii zapasowych to jedynie jeden z elementów rozległej tematyki ochrony danych. Rozdział ten omawia zagadnienia, które należy brać pod uwagę, w tym strategię odtwarzania systemów po katastrofach oraz to, w jaki sposób oszacować potrzeby, jeśli chodzi o ochronę danych.
ROZDZIAŁ 23.
VMware i inne
Niezależnie od tego, jak uda się zorganizować książkę, zawsze trafią się zagadnienia niepasujące do reszty. Ten rozdział zbiera te zagadnienia. Czytelnik znajdzie tu ważne informacje dotyczące wykonywania kopii ulotnych systemów plików oraz zagadnień typowych dla sieci Ethernet.
Wykonywanie kopii zapasowych serwerów VMware Popularność wirtualnych serwerów VMware znacznie się zwiększyła w ciągu ostatnich kilku lat, co z kolei sprowokowało pytania o najefektywniejszą metodę wykonywania ich kopii zapasowych. W tym rozdziale opiszę architekturę VMware, po czym omówię metody jej archiwizacji.
Architektura VMware Serwerowe oprogramowanie VMware jest obecnie dostępne w dwóch wersjach: VMware Server i VMware ESX Server. VMware Server jest darmową wersją VMware oferującą podstawowe możliwości wirtualizacyjne, dostępne na platformach Linux i Windows. Każda maszyna wirtualna jest reprezentowana przez zbiór plików w podkatalogu standardowego systemu plików. Katalog ten ma tę samą nazwę co maszyna wirtualna. Jeśli na przykład zdecydujemy, że na maszyny wirtualne chcemy przeznaczyć katalog /vmachines, a host wirtualny zostanie nazwany Windows 2000, jego pliki znajdą się w katalogu /vmachines/Windows 2000. VMware Server działa w ramach standardowego systemu Linux lub Windows, natomiast VMware ESX Server wykorzystuje specjalne jądro Linuksa oraz specjalny system plików, VMFS, w którym zapisane są pliki maszyn wirtualnych. Pliki maszyn wirtualnych można również zapisać na surowych partycjach dysków. Surowe partycje dyskowe oraz partycje VMFS nie są dostępne dla typowych programów wykorzystywanych do wykonywania kopii zapasowych, zatem do ich archiwizacji konieczne są specjalne techniki.
Kopie zapasowe systemów VMware W celu wykonania kopii zapasowych maszyny VMware należy wykonać kopię zapasową systemu operacyjnego, w którym działa serwer VMware (w przypadku systemów ESX serwer ten nazywa się service console) oraz sama aplikacja VMware. Należy również wykonać kopię
677
zapasową plików każdej maszyny wirtualnej. Plików maszyny wirtualnej nie da się jednak skopiować za pomocą klasycznego oprogramowania do wykonywania kopii zapasowych. W trakcie działania maszyny wirtualnej jej dyski wirtualne są ciągle otwarte i stale dokonują się w nich zmiany, przez co, w przypadku ich zwykłego skopiowania, istnieje wysokie prawdopodobieństwo, że kopia będzie niespójna. Nawet programy do śledzenia otwartych plików mogą działać w sposób mało wiarygodny w przypadku maszyn wirtualnych o gigabajtowych rozmiarach. Z tego powodu mamy trzy opcje wykonywania kopii zapasowych maszyn wirtualnych działających pod VMware: • kopiowanie maszyn wirtualnych jako maszyn fizycznych; • kopiowanie wstrzymanych maszyn wirtualnych; • wykorzystanie narzędzi VMware do wykonywania kopii zapasowych działających maszyn
wirtualnych.
Kopiowanie maszyn wirtualnych jako maszyn fizycznych Ta metoda jest najprostsza ze wszystkich. Należy po prostu uznać, że każda maszyna wirtualna jest maszyną fizyczną; wówczas stosuje się standardowe metody wykonywania kopii. Ta metoda ma oczywiście swoje wady i zalety. Wykorzystując tę metodę, nie należy zapominać o tym, aby podczas wykonywania kopii zapasowej systemów VMware Server lub ESX service console pominąć pliki maszyn wirtualnych.
Pierwsza zaleta tej metody polega na tym, że można użyć tego samego oprogramowania co w przypadku pozostałych serwerów (również fizycznych). Z tego, że maszyny są wirtualne, nie wynika jednak, że należy zawsze je tak traktować. Dzięki temu system wykonywania kopii zapasowych może być znacząco uproszczony. To podejście pozwala dodatkowo na wykorzystanie pełnych możliwości kopii przyrostowych. Pozostałe metody nie pozwalają na pełne wykorzystanie tych możliwości, chyba że wykorzystywany system kopii zapasowych obsługuje kopie przyrostowe na poziomie części plików, gdyż maszyna wirtualna jest zbudowana z plików o dużych rozmiarach, które jako całość zmieniają się praktycznie na bieżąco. Pierwsza metoda pozwala wreszcie wykonywać kopie zapasowe na gorąco. Wada tej metody polega na tym, że istnieje konieczność indywidualnego skonfigurowania kopii zapasowych każdej maszyny wirtualnej. Niektóre osoby mogą preferować konfigurację jednego mechanizmu kopii zapasowych dla całego serwera VMware, niezależnie od liczby maszyn wirtualnych. W przypadku zastosowania komercyjnego oprogramowania zastosowanie tej techniki zwiększa koszty, ponieważ należy zapłacić osobno za licencję dla każdej maszyny wirtualnej. Wadą jest również to, że konieczne jest zastosowanie procedury niskopoziomowego odtwarzania kopii zapasowej systemu operacyjnego (ang. bare metal recovery) każdej z maszyn wirtualnych. Pozostałe dwie metody nie wymagają tego, ponieważ odtworzenie plików maszyny wirtualnej powoduje odtworzenie jej systemu operacyjnego.
Kopiowanie wstrzymanych maszyn wirtualnych Jeśli można sobie pozwolić na okres niedostępności maszyn wirtualnych, przed wykonaniem kopii zapasowej można przenieść je w stan wstrzymania. Wówczas można wykonać kopię zapasową pików maszyny wirtualnej, stosując do tego celu dowolne oprogramowanie, ponieważ 678
|
Rozdz ał 23. VMware nne
pliki te nie będą otwarte ani modyfikowane w okresie wstrzymania maszyn wirtualnych. Funkcja wstrzymania systemu (ang. suspend) działa w VMware analogicznie do odpowiedniej funkcji laptopów (jak i niektórych serwerów fizycznych). Aktualny obraz pamięci oraz działających procesów jest zapisywany w pliku wykorzystywanym przy wznowieniu działania maszyny (ang. resume), co pozwala na przywrócenie dokładnie takiego samego środowiska co przed wstrzymaniem. Zalety tej metody polegają na tym, że nie ma konieczności konfigurowania kopii zapasowych dla każdej maszyny wirtualnej z osobna i niskopoziomowego odtwarzania kopii zapasowej systemu. Do wad tego rozwiązania należy zaliczyć konieczność wykonywania pełnych kopii zapasowych każdej nocy, chyba że istnieje możliwość wykonywania przyrostowych kopii zapasowych na poziomie części plików (ang. subfile incremental backup). Jedynym produktem na licencji open source przystosowanym do wykonywania kopii zapasowych tego typu jest rdiff-backup, opisany w rozdziale 7. Druga wada polega na tym, że ta metoda wymaga wstrzymania maszyn wirtualnych, co powoduje, że w czasie wykonywania kopii stają się bezużyteczne. W wielu środowiskach takie wyłączenie serwera z użytku może być niedopuszczalne. Jednym ze sposobów uniknięcia tego problemu jest umieszczenie plików maszyny wirtualnej na woluminie LVM obsługującym mechanizm migawek. W takim wypadku również jest konieczne wstrzymanie maszyny wirtualnej, ale wyłącznie na czas wykonania migawki, po czym można maszynę wznowić i odpowiednio wykonać kopię zapasową. Dzięki zastosowaniu tej metody czas niedostępności serwera jest maksymalnie skrócony, a procedura wykonywania kopii zapasowej z migawki LVM może być dowolnie długa.
Aby wstrzymać maszynę wirtualną, z wiersza poleceń należy wykonać następujące polecenie (plik config.vmx to plik konfiguracyjny zapisany w podkatalogu każdej maszyny wirtualnej): C:\> vmware-cmd ścieżka_maszyny_wirtualnej/config.vmx suspend
W tym momencie należy wykonać kopię zapasową plików maszyny wirtualnej (za pomocą dowolnego oprogramowania). Po zakończeniu wykonywania kopii zapasowej (lub migawki LVM) należy wznowić działanie maszyny wirtualnej, wykonując następujące polecenie: C:\> vmware-cmd ścieżka_maszyny_wirtualnej/config.vmx start
W przypadku wykorzystania oprogramowania VMware ESX Server narzędzia wykonywania kopii zapasowych mogą mieć problem z uzyskaniem dostępu do plików na partycji VMFS. Warto sprawdzić różne narzędzia do wykonywania kopii zapasowych.
Wykorzystanie dedykowanych narzędzi VMware (tylko ESX) W przypadku użycia systemu VMware ESX Server można wykorzystać API języka Perl do wykonania kopii zapasowych w czasie działania maszyn wirtualnych. W tym przypadku również wykorzystywany jest mechanizm migawek (ang. snapshot); zmiany w plikach maszyn wirtualnych są wykonywane w plikach dziennika wznawiania (ang. redo log), co pozwala na skopiowanie plików maszyn wirtualnych. Ta metoda ma te same zalety co omówiona powyżej, z tą różnicą, że pozwala wykonać kopię systemów wirtualnych w czasie, gdy działają.
Wykonywan e kop zapasowych serwerów VMware
|
679
Wykorzystywane są tu skomplikowane skrypty w Perlu; nie będę ich omawiał w tym miejscu. Przykłady odpowiednich skryptów można znaleźć na stronie firmy VMware (http://www. ¦vmware.com). Istnieje też narzędzie vmbk na licencji open source, autorstwa Massimiliana Daneriego, które pozwala zautomatyzować większą część tego procesu. Szczegóły można znaleźć na stronie http://www.vmts.net/vmbk.htm.
Wykorzystanie procedur niskopoziomowego odtwarzania systemów w celu migracji do VMware Jedną z zalet VMware (i innych rozwiązań wirtualizacyjnych) jest to, że w przypadku awarii nie ma konieczności niskopoziomowego odtwarzania systemów operacyjnych serwerów wirtualnych. Jeśli uda się sporządzić kopię zapasową plików serwera wirtualnego (zapewniając ich spójność w czasie tego procesu), w procesie odtwarzania wystarczy przywrócić te pliki. Jednak procedura niskopoziomowego odtwarzania systemów operacyjnych opisana w rozdziale 11. jest doskonałym sposobem przenoszenia maszyn fizycznych na maszyny wirtualne. W jednej z instalacji udało nam się przenieść 25 starych serwerów fizycznych na jeden dobrze wyposażony serwer VMware. Poniżej opiszę bardzo pouczającą, moim zdaniem, historię tej migracji. Często zdarza mi się odpowiadać na pytania dotyczące produktów do wykonywania kopii zapasowych oraz sprawdzać ich zachowanie w różnych systemach operacyjnych i aplikacjach. Oprócz standardowego sprzętu wykorzystywanego do wykonywania kopii zapasowych (SAN, biblioteki taśmowe, VTL) moje laboratorium składa się ze sprzętu firm: Sun, IBM i HP z systemami: Solaris, AIX i HP-UX. Aż do niedawna mieliśmy również 25 maszyn serwerowych klasy PC z zainstalowanymi różnymi wersjami systemów Linux i Windows oraz różnymi aplikacjami (Exchange, SQL Server, Oracle itd.). Nigdy nie mogłem z przekonaniem stwierdzić, że posiadam wystarczającą liczbę maszyn, i nigdy nie zdarzyło mi się, aby komputery były przyłączone do odpowiedniego sprzętu. Wiecznie wymienialiśmy karty SCSI i Fibre Channel, oprócz tego instalowaliśmy i usuwaliśmy oprogramowanie. Równie dobrze mógłbym zażyczyć sobie stu komputerów, ale taka decyzja byłaby nie do przyjęcia z wielu względów (samo chłodzenie stałoby się problemem trudnym do opanowania). Niedawno zdecydowaliśmy się podjąć próbę opanowania sytuacji za pomocą VMware. Zakupiliśmy solidny sprzęt wyposażony w dwurdzeniowy procesor AMD 3,5 GHz, 4 GB RAM DDR2 i wewnętrzne dyski twarde SATA o łącznej pojemności 1,75 TB. W tym serwerze zainstalowałem dwie karty Fibre Channel oraz dwie karty SCSI. Następnie zastosowałem metodę alt-boot recovery do odtworzenia tych fizycznych serwerów w maszynach wirtualnych, co stanowiło wirtualne uaktualnienie procesorów, systemu składowania i pamięci. Oto etapy mojej pracy, praktycznie identyczne dla każdego z serwerów:
1. Wykorzystałem metodę alt-boot z kompletnym obrazem dysku twardego /dev/hda, który zapisałem w zasobie NFS nowego serwera VMware. Obrazy miały z reguły rozmiary od 4 do 10 GB (to były naprawdę stare maszyny!).
2. Wykorzystałem VMware do utworzenia maszyny wirtualnej, określając jej wirtualny dysk twardy IDE o rozmiarze większym od oryginalnego; z reguły było to od 20 do 40 GB.
3. Wykorzystałem VMware do utworzenia wirtualnego napędu CD wykorzystującego dowiązanie symboliczne do zapisanego na dysku obrazu ISO dysku CD z dystrybucją Knoppix.
680 |
Rozdz ał 23. VMware nne
4. Uruchomiłem maszynę wirtualną za pomocą wirtualnego dysku Knoppix CD. 5. Za pomocą dd skopiowałem obraz rzeczywistego dysku twardego na wirtualny dysk twardy maszyny wirtualnej uruchomionej z wirtualnego dysku CD (w tym celu zamontowałem zasób NFS, w którym został zapisany obraz dysku).
6. „Usunąłem” dysk CD Knoppiksa, zmieniając dowiązanie symboliczne wirtualnego dysku CD na wskazujące na nierozruchowy dysk CD, i ponownie uruchomiłem serwer wirtualny.
7. Prawie w każdym przypadku wirtualny serwer uruchamiał się bez problemów. W ten spo-
sób udało mi się przenieść serwer fizyczny na serwer wirtualny. Jeden z serwerów Windows miał problemy: zawieszał się, wyświetlając niebieski ekran błędu. W tym przypadku wystarczyło zastosować opcję Ostatnia dobra konfiguracja z menu rozruchowego Windows (dostępnego po naciśnięciu klawisza F8) i wszystko wróciło do normy.
8. W każdej z maszyn wirtualnych zainstalowałem pakiet VMware tools, dzięki któremu poprawiła się efektywność działania wirtualnej karty graficznej i innych urządzeń.
9. Po zweryfikowaniu poprawności działania każdej z maszyn zmieniłem dowiązanie symboliczne wirtualnego dysku CD ponownie na Knoppiksa i ponownie uruchomiłem system. W Knoppiksie za pomocą programów qtparted (dla systemów Linux), fdisk i ntfsresize (dla systemów Windows) zmieniłem oryginalny rozmiar systemu plików na nowy, co zostało omówione w ramce „Odtwarzanie na większe dyski twarde” w rozdziale 11.
Z 4 GB pamięci RAM i dwurdzeniowym procesorem 3,5 GHz mogę jednocześnie uruchomić osiem serwerów wirtualnych bez objawów braku pamięci, takich jak nadmierne wykorzystanie przestrzeni wymiany. Z reguły potrzebuję najwyżej dwóch jednocześnie, a co nie mniej ważne, jeśli dla swoich potrzeb uruchamiam Exchange 2000, SQL Server X czy XYZ x.x, nie muszą one działać aż tak szybko (właśnie dlatego zupełnie wystarczały tamte stare maszyny). Każda z maszyn wirtualnych ma dostęp do dowolnej z kart Fibre Channel lub SCSI, dzięki czemu mają także dostęp do fizycznych i wirtualnych napędów taśm. Również jeśli chodzi o moc procesora czy ilość pamięci, systemy te mają o wiele więcej zasobów niż w swojej starej, sprzętowej konfiguracji. W razie potrzeby każdej z tych maszyn wirtualnych mogę tymczasowo przydzielić nawet całą dostępną pamięć RAM i całą moc 3,5-gigahercowego procesora i nie muszę w tym celu otwierać obudowy i przekładać pamięci RAM ani innych podzespołów. Dzięki tej konfiguracji nareszcie mam możliwość testowania setek wirtualnych serwerów bez jakichkolwiek problemów z chłodzeniem, ponieważ każdy z nich to zaledwie kilkadziesiąt gigabajtów przestrzeni na dysku. Mogę uruchamiać kilka serwerów Windows 2000: jeden bez aplikacji, jeden z Exchange 5, jeden z SQL Server 7; mogę uruchamiać serwery z Windows 2003: jeden bez aplikacji, jeden z Exchange 2000; mogę mieć komputer z systemem Windows Vista. A wszystkie na tej samej maszynie. Mogę mieć serwery z wszelkimi dostępnymi dystrybucjami Linuksa, FreeBSD czy Solaris x86 i wszelkimi aplikacjami dostępnymi dla tych systemów. Mam nadzieję, że już stało się oczywiste, skąd bierze się mój entuzjazm dla wirtualizacji. Na dyskach twardych umieszczonych w tym jednym serwerze mam dość miejsca na 300 kombinacji serwerów wirtualnych. Takie możliwości są trudne do ogarnięcia umysłem.
Ulotne systemy plików Ulotne systemy plików (ang. volatile filesystems) to takie, których zawartość jest stale modyfikowana w czasie wykonywania kopii zapasowej. Wykonywanie kopii zapasowych ulotnego systemu plików jest narażone na szereg niekorzystnych efektów ubocznych. Zakres negatywnego Ulotne systemy pl ków
|
681
wpływu na spójność kopii jest wprost proporcjonalny do poziomu ulotności systemu plików i zależny od narzędzia użytego do wykonania kopii zapasowej. Do efektów niepożądanych należą brakujące lub uszkodzone pliki w kopii lub zapisane nieprawidłowe wersje plików. Najgorszym z możliwych problemów jest oczywiście uszkodzenie samej kopii, choć taka sytuacja powinna raczej należeć do rzadkości. Szczegóły dotyczące możliwych uszkodzeń kopii zapasowej typu dump ulotnego systemu plików można znaleźć w punkcie „Mechanizm dump”.
Brakujące lub uszkodzone pliki Pliki, których zawartość zmienia się w trakcie wykonywania kopii, mogą znaleźć się w tej kopii uszkodzone. Jest to szczególnie prawdopodobne wówczas, gdy w trakcie wykonywania kopii zmieni się nazwa pliku lub jego lokalizacja w ramach i-węzłów. Zakres uszkodzeń w kopii zapasowej jest szczególnie zależny od typu zastosowanego narzędzia oraz od stopnia ulotności systemu plików. Załóżmy, że narzędzie wykonujące kopię przed rozpoczęciem kopiowania wykorzystuje mechanizm zbliżony w działaniu do narzędzia find, za pomocą którego tworzy listę plików do skopiowania. Kopia jest sporządzana na podstawie tej listy. Jeśli zatem nazwa pliku zmieni się w trakcie wykonywania kopii, program wygeneruje błąd przy próbie wykonania kopii pliku ze starą nazwą. Właściwy plik (pod nową nazwą) zostanie pominięty. Inny scenariusz dotyczy sytuacji, gdy nazwa pliku nie zmienia się, lecz modyfikowana jest jego zawartość. Dokładniej: program zaczyna kopiować plik, a inny program w trakcie tego procesu zmienia zawartość pliku. Tego typu problem najczęściej dotyczy plików baz danych o dużych rozmiarach. Taka kopia jest w zasadzie bezużyteczna, ponieważ różne fragmenty pliku odpowiadają zupełnie różnym jego wersjom. Dokładnie taka sytuacja zachodzi w przypadku bazy danych Oracle kopiowanej w trybie hot-backup. Gdyby baza Oracle nie miała wbudowanych mechanizmów odbudowywania tych plików, takie kopie byłyby bezużyteczne.
Problemy więzów integralności Tego typu problemy są zbliżone do problemów uszkodzonych plików, ale występują na poziomie systemu plików. Wykonanie kopii systemu plików może zająć kilka godzin. Oznacza to, że różne pliki w kopii zapasowej pochodzą z różnych momentów działania systemu. W przypadku gdy te pliki nie mają wzajemnych powiązań, problem jest stosunkowo niewielki. Załóżmy jednak, że dwa pliki mają związek, to znaczy w przypadku modyfikacji jednego pliku zmodyfikowany musi zostać też drugi. Oznacza to, że w przypadku odtworzenia jednego pliku należy koniecznie odtworzyć plik z nim związany. Oznacza to również, że jeśli zostanie odtworzona kopia pliku odpowiadająca jego zawartości z godziny 23:00 dzień wcześniej, drugi z odtworzonych plików musi mieć zawartość z godziny 23:00 tego samego dnia. Tego typu sytuacja jest powszechna w bazach danych, ale można ją również spotkać w innych systemach wykorzystujących zbiory wzajemnie powiązanych plików. Załóżmy, że proces wykonywania kopii zapasowej rozpoczął się o godzinie 22:00. Proces wykonywania kopii zapasowej z reguły wykorzystuje pewne predefiniowane zasady ustalania kolejności kopiowania plików, jak numer i-węzła czy kolejność alfabetyczna plików w katalogu. Załóżmy, że z tego typu względów jeden z plików został skopiowany o godzinie 22:15, a drugi o 23:05. O godzinie 23:00 obydwa pliki zmieniły się w korelacji ze sobą. W tym przypadku w kopii zapasowej jeden z plików znajdzie się w wersji przed zmianą, a drugi — po. 682 |
Rozdz ał 23. VMware nne
Nie ma zatem możliwości odtworzenia tych plików w taki sposób, aby zachowane były więzy integralności. Można odtworzyć te pliki jedynie w dwóch niezgodnych wersjach: jeden z godziny 22:15, drugi z godziny 23:05. Jednak zawartość obu musi być w pełni skorelowana. Jeśli pliki w systemie plików postrzegać jako rekordy w bazie danych, mamy do czynienia z problemem integralności.
Uszkodzona lub nieczytelna kopia zapasowa Jeśli system plików często się zmienia w trakcie wykonywania kopii, niektóre narzędzia mogą tworzyć kopie zapasowe, których wręcz nie da się odczytać. Tego typu sytuacja jest oczywiście jedną z najgorszych, ale na szczęście występuje jedynie w najbardziej niekorzystnych warunkach.
Programy do ekstremalnego testowania kopii zapasowych W 1991 roku Elizabeth Zwicky stworzyła na potrzeby konferencji LISA1 opracowanie pod tytułem „Torture-testing Backup and Archive Programs: Things You Ought to Know But Probably Would Rather Not” („Programy do ekstremalnego testowania kopii zapasowych — rzeczy, które powinniście wiedzieć, choć wolelibyście o nich nie myśleć”). Ten materiał jest oczywiście już mocno nieaktualny, ale często można napotkać odwołania do niego w kontekście kopii zapasowych. Elizabeth pozwoliła mi zacytować w tej książce wybrane fragmenty tego opracowania. Wiele osób do wykonywania kopii zapasowych stosuje programy tar, cpio lub jakieś ich odmiany. W ich dokumentacji można znaleźć wzmianki na temat ich słabych punktów; inne wady tych programów można poznać z relacji innych użytkowników albo na własnej skórze. Krążą sprzeczne plotki na temat działających i niedziałających funkcji oraz tego, które z rozwiązań są najlepsze. Zmęczyło mnie to i zdecydowałam się odszukać Prawdę, uzbrojoną wyłącznie w Perl (oraz gromadkę pomocników posiadających różne maszyny). Jak można się było spodziewać, istnieje o wiele więcej problemów, niż można znaleźć w podręcznikach systemowych. Ale naprawdę przerażające są inne moje odkrycia. Na przykład w podręcznikach systemowych poleceń tar i cpio w systemie SunOS 4.1 można znaleźć informację o błędach, których próżno szukać w samych programach. Inne „powszechnie znane” błędy w tych programach również znikły w niewyjaśnionych okolicznościach. Z drugiej strony łatwo w nich zidentyfikować zupełnie inne, nie mniej fascynujące błędy, prowadzące do ciekawych problemów, takich jak rozbieżności między nazwami plików a ich zawartością. Elizabeth przeprowadziła testy w dwóch kategoriach. Do pierwszej z nich należały testy statyczne polegające na wykonywaniu kopii zapasowych plików o niestandardowych nazwach, nienormalnie długich nazwach, kopie nazwanych potoków itp. W tym podrozdziale interesują nas jednak ulotne systemy plików, nie będę więc obszerniej omawiać wyników tych statycznych testów. Do dynamicznych testów należały następujące operacje w trakcie wykonywania kopii zapasowej:
1
Large Installation System Administration Conference, sponsorowana przez Usenix i Sage (http://www.usenix.org).
Ulotne systemy pl ków
| 683
• zmiana pliku na katalog o tej samej nazwie, • zmiana katalogu na plik o tej samej nazwie, • usunięcie pliku, • utworzenie pliku, • zmniejszenie rozmiaru pliku, • zwiększenie w różnym stopniu rozmiarów dwóch plików.
W ten sposób Elizabeth wyjaśnia reakcję narzędzi na tego typu sytuacje, co ma związek ze sposobem ich działania: Programy, które nie przeglądają katalogów w systemie plików, jak dump, osobno zapisują strukturę systemu plików i zawartość plików. Plik zmieniający się w katalog i katalog zmieniający się w plik może przez to spowodować poważne problemy, ponieważ zawartość i-węzła nie jest tym, czego program się spodziewał. Odtworzenie takiej kopii spowoduje utworzenie pliku lub katalogu zgodnie z oryginalnym typem obiektu, ale z nową zawartością. Jeśli informacja o katalogach jest zapisywana przed zawartością plików, plik usunięty podczas zapisu kopii pojawi się w kopii z nieokreśloną zawartością, w zależności od tego, czy bloki na dysku zostały ponownie użyte przez inne pliki. Opisane wyżej problemy są specyficzne dla programu dump i pokrewnych; programy przeglądające system plików są na nie mniej podatne. Z drugiej strony pliki zmniejszające lub zwiększające swój rozmiar w trakcie wykonywania kopii mogą sprawić poważne problemy programowi tar. Program dump zapisuje bloki pliku niezależnie od tego, co dzieje się z plikiem. Jeśli rozmiar pliku zmniejszy się o blok lub większą liczbę bloków, tar zapisze jego kopię, dopisując „śmieci” na końcu do pierwotnego rozmiaru. Jeśli rozmiar pliku zwiększył się, jego kopia zostanie przycięta do pierwotnego rozmiaru. Tego typu przypadki są problematyczne, ale raczej nie powodują zniszczenia całej kopii. Programy przeglądające system plików zapisują nagłówek pliku, który zawiera jego rozmiar, a dopiero następnie zapisują dane. Poważne problemy mogą wystąpić jedynie wówczas, gdy programista nie uwzględnił przypadku rozbieżności między rozmiarem pliku w metadanych a ilością zapisanych danych. Jeśli rozmiar pliku w nagłówku nie zgadza się, odtworzenie tego pliku może zakończyć się nieprzyjemnymi niespodziankami. W teorii programy w opisywanej sytuacji przytną plik lub wypełnią przypadkowymi danymi do pierwotnego rozmiaru. Wiele z programów wypisze stosowny komunikat o tym, że rozmiar pliku zmienił się. Niestety, wiele programów nie wykonuje tego typu działań naprawczych, choć niektóre potrafią wypisać komunikat (do głowy przychodzi znany komunikat „cpio out of phase: get help!”2). W wielu przypadkach problemy z takimi kopiami są w jakiś sposób niwelowane przez program odczytujący dane z kopii, co jeszcze bardziej utrudnia identyfikację. Przykładem może być program tar w SunOS 4.1, który wypisze komunikat o błędnym rozmiarze pliku w archiwum, po czym bez dalszych problemów odtworzy plik z odpowiednio zmodyfikowanym rozmiarem. Mój skrypt testujący był napisany w taki sposób, że działał, dopóki działał program archiwizujący. Skrypt stopniowo zwiększał rozmiar pliku w pętli w czasie, gdy program tar go archiwizował. Dopiero zapełnienie się systemu plików przerwało tę sytuację zakleszczenia.
2
W wolnym tłumaczeniu: „Błąd synchronizacji programu cpio, wezwij pomoc!” — przyp. tłum.
684 |
Rozdz ał 23. VMware nne
Inne ostrzeżenia Większość ostrzeżeń, które uzyskałam od innych użytkowników, okazała się fałszywymi alarmami, z drugiej jednak strony wiele osób (w tym ja) spodziewało się prawidłowego zachowania programów, podczas gdy popełniały one błędy. Często winne tej rozbieżności jest założenie, że wszystkie wersje programu są identyczne, a w rzeczywistości nazwa programu nie determinuje jego zachowania. Stwierdzenia, że tar zachowuje się w taki, a nie inny sposób, nie są wiele warte, ponieważ z reguły stanowią stwierdzenie stanu idealnego lub tego, w jaki sposób ten program działał w określonej wersji w przeszłości. Nie należy też ufać w to, że program przyzna się do błędu. Z reguły moje prowokacje w postaci kurczących się lub puchnących plików, plików zmieniających nazwy bądź zmieniających postać, często przechodziły bez żadnego komunikatu o błędzie.
Wnioski Wyniki tych testów są w większości przypadków dość mało optymistyczne. Nie dziwi to, że dump radzi sobie stosunkowo najlepiej, lecz to, że nie przeszedł testu zmiany długości nazwy, to dość nieprzyjemna niespodzianka, ponieważ przynajmniej w teorii nie powinno mieć znaczenia, jaka jest nazwa kopiowanego pliku. Z drugiej strony z tego, iż ten błąd ujawnia się dość późno, można wywnioskować, że problem nie występuje bezpośrednio w efekcie tej zmiany. Pozostałe programy ujawniają błędy w o wiele poważniejszych momentach. Na potrzeby kopiowania fragmentów systemu plików program afio okazuje się dobrym wyborem, szczególnie w przypadku długich nazw plików. Jeśli jednak mamy pewność, że wszystkie nazwy plików będą spełniały określone wymagania co do długości, prawdopodobnie GNU tar okaże się lepszy, gdyż lepiej radzi sobie z dużą liczbą dowiązań oraz problemami uprawnień do plików. W opracowaniu Elizabeth pocieszające jest jedno stwierdzenie: „Warto nadmienić, że większość użytkowników nie napotyka opisanych problemów”. Można odetchnąć z ulgą.
Wykorzystanie migawek do wykonywania kopii zapasowych ulotnych systemów plików Czy istnieje sposób wykonania kopii zapasowej systemu plików, aby nie miał znaczenia poziom jego ulotności? Odtworzenie takiej kopii zapasowej powinno przywrócić system plików do stanu zgodnego z momentem rozpoczęcia wykonywania kopii. Dokładnie do tego celu służy technologia znana jako migawka systemu plików (ang. filesystem snapshot). Migawka służy do uzyskania niezmiennej (statycznej) postaci systemu plików. Jeśli program do wykonywania kopii zapasowych postrzega system plików z punktu widzenia jego migawki, proces wykonywania kopii zapasowej może trwać cały dzień, a mimo to po odtworzeniu systemu plików uzyskamy jego spójną postać z momentu, gdy została wykonana migawka.
Mechanizm działania migawek W momencie utworzenia migawki mechanizm ten zachowuje informację, kiedy to nastąpiło. Migawka otrzymuje nową nazwę, pod którą jest widoczna dla programu wykonującego kopię zapasową. Na przykład w przypadku wykonania migawki katalogu /home w sieciowym urządzeniu składowania zawartość migawki może być dostępna w katalogu /home/.snapshot. Warto zwrócić uwagę, że utworzenie migawki nie oznacza utworzenia kopii katalogu /home Ulotne systemy pl ków
| 685
w katalogu /home/.snapshot, ale użytkownik ma wrażenie, jakby tego typu operacja została rzeczywiście wykonana. Jeśli zajrzymy do katalogu /home/.snapshot, znajdziemy w nim zawartość całego systemu plików dokładnie w takiej postaci, w jakiej znajdował się w momencie wykonania migawki. Wykonanie migawki zajmuje zaledwie kilka sekund. Niektórzy użytkownicy nie są w stanie zrozumieć, w jaki sposób oprogramowanie było w stanie wykonać dokładny obraz systemu plików bez kopiowania jego zawartości. Podpowiedzią może być nazwa techniki: migawka nie kopiuje (klonuje) obiektu, ale wykonuje jego wierną „fotografię”. Po wykonaniu migawki mechanizm monitoruje system plików pod kątem modyfikacji. Gdy zmienia się blok danych, mechanizm migawki zapisuje jego poprzednią zawartość z momentu wykonania migawki. Techniczne szczegóły funkcjonowania migawek są zależne od specyficznej implementacji tej techniki. Gdy zajrzymy do katalogu migawki, zobaczymy, że sterownik tego mechanizmu analizuje dokładnie, co w danej chwili jest odczytywane. Jeśli odczytywany jest blok danych, który nie zmienił się od momentu wykonania migawki, dane zostaną odczytane z oryginalnego systemu plików. Jeśli jednak odczytywany będzie blok, którego zawartość zmieniła się, odczytywana będzie jego poprzednia zawartość, zachowana na potrzeby migawki. Oczywiście cały ten mechanizm działa w sposób niewidoczny dla użytkownika czy aplikacji odczytującej dane. Użytkownik ma wrażenie, że widzi kopię systemu plików z momentu wykonania migawki.
Dostępne oprogramowanie do wykonywania migawek Większość urządzeń NAS ma wbudowane mechanizmy NAS. Również wiele systemów plików oferuje takie możliwości.
Zasada działania programu dump Podrozdział napisany przez Davida Younga.
Programy: cpio, ntbackup i tar działają na poziomie systemu plików, co oznacza, że dostęp do plików uzyskują za pośrednictwem systemu plików. Jeśli kopiowany plik zmienia się, zostaje usunięty lub dodany w trakcie wykonywania kopii zapasowej, w najgorszym razie w kopii znajdą się „śmieci” zamiast rzeczywistych danych. Niestety, narzędzia działające na poziomie systemu plików mają jedną poważną wadę: wykonanie kopii powoduje modyfikację parametrów czasu i-węzła (atime lub ctime). Program dump nie czyta plików na poziomie systemu plików Uniksa, zatem nie ma tej wady. Program ten odczytuje dane za pośrednictwem sterownika „surowych” urządzeń. Dokładna zasada działania programu dump jest jednak słabo znana administratorom systemów. Niewielką pomoc stanowi tu podręcznik programu dump, ponieważ sieje FUD (fear, uncertainty, and doubt, czyli strach, niepewność i zwątpienie). Oto przykład z podręcznika systemowego programu ufsdump autorstwa firmy Sun:
686 |
Rozdz ał 23. VMware nne
W czasie działania programu ufsdump system plików musi być nieaktywny, w przeciwnym razie wyniki działania programu mogą być niespójne, a prawidłowe odtworzenie danych może okazać się niemożliwe. System plików jest nieaktywny, gdy jest odmontowany lub gdy system jest uruchomiony w trybie pojedynczego użytkownika. Z tego ostrzeżenia trudno wywnioskować skalę problemu. Czy uszkodzone mogą być pojedyncze pliki w archiwum? Czy całe katalogi? Czy też wszelkie dane od miejsca w zrzucie, w którym wystąpiło uszkodzenie? A może cała kopia? Czy rzeczywiście nie ma innej możliwości uzyskania prawidłowej kopii, jak odmontowanie systemu plików przed wykonaniem zrzutu? Takie pytania sprawiają poważne problemy użytkownikom zainteresowanym wykonywaniem kopii zapasowych za pomocą programu dump. Czy w kluczowej chwili dowiemy się, że wykonana kopia zapasowa jest bezużyteczna, bo została wykonana na zamontowanym systemie plików, mimo tego, że większość czasu był nieaktywny (rzeczywiście, nie według definicji firmy Sun)? W tym podrozdziale odpowiem na tego typu pytania, ale najpierw należy zapoznać się z zasadą działania programu dump.
Praca z programem dump Program dump jest mocno zależny od systemu plików, zatem dla różnych systemów plików i platform Uniksa będą istniały różne odmiany programu dump. Jednak istnieje ogólna zasada działania programu na poziomie niezależnym od systemu plików, ponieważ większość implementacji jest tworzona na podstawie tej samej bazy kodu. Na początek przyjrzyjmy się wynikowi wywołania programu dump. Zajmiemy się kopią przyrostową, ponieważ wypisywane przez nią komunikaty są znacznie bardziej interesujące od kopii typu level-0: # /usr/sbin/ufsdump 9bdsfnu 64 80000 150000 /dev/null / DUMP: Writing 32 Kilobyte records DUMP: Date of this level 9 dump: Mon Feb 15 22:41:57 2006 DUMP: Date of last level 0 dump: Sat Aug 15 23:18:45 2005 DUMP: Dumping /dev/rdsk/c0t3d0s0 (sun:/) to /dev/null. DUMP: Mapping (Pass I) [regular files] DUMP: Mapping (Pass II) [directories] DUMP: Mapping (Pass II) [directories] DUMP: Mapping (Pass II) [directories] DUMP: Estimated 56728 blocks (27.70MB) on 0.00 tapes. DUMP: Dumping (Pass III) [directories] DUMP: Dumping (Pass IV) [regular files] DUMP: 56638 blocks (27.66MB) on 1 volume at 719 KB/sec DUMP: DUMP IS DONE DUMP: Level 9 dump on Mon Feb 15 22:41:57 2006
W tym przykładzie program ufsdump wykonuje kopię zapasową systemu plików w pięciu etapach. Widzimy również, że etap II został wykonany trzy razy. Jakie działania wykonuje program dump na każdym z tych etapów?
Etap I Na podstawie zawartości pliku dumpsdates (najczęściej /etc/dumpdates) oraz wartości poziomu wykonania kopii określonego w wierszu poleceń obliczana jest wartość zmiennej DUMP_SINCE. Każdy plik zmodyfikowany po dacie DUMP_SINCE staje się kandydatem do zrzutu. Program dump przeszukuje dysk twardy w poszukiwaniu odpowiednich i-węzłów. Należy pamiętać, że dump „rozumie” strukturę systemu plików, ale nie korzysta z jego sterowników, wykorzystując surowe urządzenie dyskowe. Zasada dz ałan a programu dump
|
687
Pomijane są niezaalokowane i-węzły. Czasy modyfikacji zaalokowanych i-węzłów są porównywane z wartością DUMP_SINCE. Kandydatami do wykonania kopii są i-węzły o datach modyfikacji większych lub równych dacie DUMP_SINCE, pozostałe są pomijane. Na tym etapie dump tworzy następujące struktury pomocnicze: • listę i-węzłów do zrzucenia, • listę sprawdzonych i-węzłów katalogów, • listę użytych (zaalokowanych ) i-węzłów.
Etap IIa Program dump ponownie skanuje i-węzły, korzystając z listy i-węzłów katalogów wygenerowanej na etapie I i sprawdzając, czy zawierają pliki przeznaczone do wykonania kopii. Jeśli nie, i-węzeł katalogu jest wyrzucany z listy kandydatów do zrzutu.
Etap IIb Po usunięciu katalogów, które nie muszą być zrzucone, to samo może dotyczyć katalogu nadrzędnego, co jest sprawdzane na tym podetapie. Program ponownie sprawdza katalogi, aby upewnić się, czy nie kwalifikują się do pominięcia.
Etap IIc W podetapie IIb z listy katalogów do zrzutu zostały usunięte pewne katalogi. Należy sprawdzić, czy to nie powoduje, że ich katalogi nadrzędne kwalifikują się do pominięcia. W tym momencie etap II kończy się, bo takie katalogi nie zostały zidentyfikowane, jeśli jednak tak by się stało, program musiałby wykonać kolejną iterację etapu II.
Etap poprzedzający etap III Na tym etapie program dump zaczyna zapisywać dane w kopii. Przed rozpoczęciem etapu III dump zapisuje informację o kopii. Dane są przez dump zapisywane w bardzo ustrukturalizowanej postaci. Program najczęściej zapisuje nagłówek opisujący dane, a natychmiast po nim same dane. Potem zapisywany jest następny nagłówek i następne dane. W fazie poprzedzającej etap III dump zapisuje nagłówek i dwie mapy i-węzłów. Dane te zapisuje się w sposób sekwencyjny, na przykład: nagłówek Nagłówek zrzutu TS_TAPE. nagłówek TS_CLRI. usedinomap Mapa i-węzłów usuniętych od ostatniego zrzutu. nagłówek TS_BITS. dumpinomap Mapa i-węzłów w bieżącym zrzucie.
688 |
Rozdz ał 23. VMware nne
Mapa usedinomap to lista i-węzłów usuniętych od ostatniego wykonania zrzutu. Mapa ta jest wykorzystywana przez program restore przed samym odtworzeniem plików z archiwum. Mapa dumpinomap jest listą wszystkich i-węzłów zapisywanych przez ten zrzut. W nagłówku można znaleźć sporą ilość informacji: • typ rekordu, • datę zrzutu, • numer woluminu, • logiczny blok rekordu, • numer i-węzła, • liczbę magiczną, • sumę kontrolną rekordu, • i-węzeł, • liczbę rekordów kontynuacji, • etykietę zrzutu, • poziom zrzutu, • nazwę zrzucanego systemu plików, • nazwę zrzucanego urządzenia, • nazwę zrzucanego hosta, • pierwszy rekord w woluminie.
Pole typu rekordu opisuje typ informacji zapisywanej po nagłówku. Do dyspozycji jest sześć typów rekordów: TS_TAPE
Nagłówek zrzutu. TS_CLRI
Mapa i-węzłów usuniętych od ostatniego zrzutu. TS_BITS
Mapa i-węzłów w bieżącym zrzucie. TS_INODE
Początek rekordu pliku. TS_ADDR
Kontynuacja rekordu pliku.
TS_END
Znacznik końca woluminu. Należy zwrócić uwagę na to, że przy zapisie nagłówka zapisywana jest kopia struktury i-węzła dla kopiowanego pliku lub katalogu. Struktura i-węzłów różni się jednak w różnych systemach plików, zmiany następowały również między różnymi podwersjami implementacji, zatem to mogłoby powodować problemy z kompatybilnością archiwów. Z tego powodu dump „normalizuje” swoje dane, konwertując struktury i-węzłów na klasyczny format BSD. Właśnie struktura i-węzłów w formacie BSD jest zapisywana w nagłówku kopii zapasowej.
Zasada dz ałan a programu dump
| 689
Dzięki temu nie powinno być problemu z odtworzeniem danych w dowolnym systemie Unix, którego program restore oczekuje struktur i-węzłów w formacie BSD. Można bez przeszkód odtwarzać w systemie Solaris kopie wykonane programem dump w systemie HP-UX lub AIX i na odwrót.
Etap III Na tym etapie w archiwum zapisywane są katalogi. Program dump zapisuje tylko katalogi zawierające dane oznaczone do umieszczenia w kopii. Podobnie jak w fazie poprzedzającej etap III dump zapisuje dane zgodnie z następującą zasadą: Nagłówek (TS_INODE) Bloki dysku (bloki katalogu) Nagłówek (TS_ADDR) Bloki dysku (dalsze bloki katalogu) . . . Nagłówek (TS_ADDR) Bloki dysku (dalsze bloki katalogu) Pierwsze cztery elementy są powtarzane dla każdego katalogu z listy katalogów uwzględnionych w kopii.
Etap IV Na tym etapie zapisywane są pliki. Na etapie IV dump zapisuje pliki oznaczone do umieszczenia w kopii. Oto schemat zapisu danych plików, zbliżony do stosowanej na etapie III zasady zapisu danych katalogów: Nagłówek (TS_INODE) Bloki dysku (bloki pliku) Nagłówek (TS_ADDR) Bloki dysku (dalsze bloki pliku) . . . Nagłówek (TS_ADDR) Bloki dysku (dalsze bloki pliku) Pierwsze cztery elementy są powtarzane dla każdego pliku z listy i-węzłów uwzględnionych w kopii.
Operacje po fazie IV Aby zaznaczyć zakończenie kopii zapasowej, dump zapisuje rekord typu TS_END. Ten rekord oficjalnie sygnalizuje koniec zrzutu.
Podsumowanie etapów zrzutu Podsumujmy pokrótce poszczególne etapy działania programu dump:
690 |
Rozdz ał 23. VMware nne
Etap I Budowanie listy plików, które mają być uwzględnione w zrzucie.
Etap II Wielokrotne skanowanie dysku w celu określenia listy katalogów, które mają być uwzględnione w zrzucie. Etap wstępny etapu III Zapis nagłówka i dwóch map i-węzłów. Etap III Zapis nagłówka (zawierającego i-węzeł katalogu) oraz bloków danych każdego katalogu z listy. Etap IV Zapis nagłówka (zawierającego i-węzeł pliku) oraz bloków danych każdego pliku z listy. Etap finalizujący Zapis rekordu końcowego, sygnalizującego koniec zrzutu.
Odpowiedzi na pytania Oto krótka seria pytań i odpowiedzi związanych z zagadnieniami poruszonymi w tym podrozdziale
Pytanie 1 Pytanie: Czy przy wykonaniu zrzutu aktywnego systemu plików uszkodzenia będą dotyczyły pojedynczych plików lub katalogów? Odpowiedź: To zależy. Poniżej przedstawiam listę scenariuszy, które mogą wystąpić w przypadku modyfikacji systemu plików w trakcie wykonywania zrzutu: Plik zostaje usunięty przed etapem I. Plik nie jest uwzględniony w kopii, ponieważ nie istnieje w momencie wykonania etapu I. Plik zostaje usunięty po etapie I, ale przed etapem IV. Plik może być uwzględniony na liście plików do zrzutu, ale w trakcie etapu IV dump sprawdza, czy obiekt istnieje i czy jest plikiem. Jeśli przynajmniej jeden z tych warunków nie jest spełniony, plik zostanie pominięty. Jednak w takim przypadku mapa i-węzłów zapisana w fazie poprzedzającej etap III będzie błędna. Ta niespójność nie ma wpływu na proces wykonywania kopii, ale program restore nie będzie w stanie odtworzyć pliku mimo tego, że znajduje się na liście plików zawartych w kopii. Zawartość pliku zakwalifikowanego do umieszczenia kopii zmienia się (numer i-węzła pozostaje bez zmian). W tym przypadku możliwe są dwa scenariusze. Modyfikacja pliku w czasie, gdy dump nie zapisuje jego zawartości, nie będzie miała żadnego wpływu na spójność pliku w kopii. Program dump zapisuje, co prawda, listę numerów i-węzłów, ale zmiana zawartości pliku modyfikuje zawartość i-węzła, ale nie modyfikuje jego numeru.
Zasada dz ałan a programu dump
|
691
Modyfikacja pliku w trakcie zapisu jego zawartości w kopii prawdopodobnie uszkodzi dane zapisane w kopii. Program dump odczytuje i-węzeł, po czym odczytuje dane z następnych węzłów i zapisuje ich kopię. Jeśli zmieni się adres albo zawartość przynajmniej jednego z węzłów, dane w kopii będą uszkodzone. Zmienia się numer i-węzła pliku. Jeśli zmieni się numer i-węzła kopiowanego pliku po zapisaniu go na liście i-węzłów do skopiowania (czyli numer i-węzła zmieni się po etapie I, a przed etapem IV), w momencie wykonania kopii pliku może wystąpić jeden z następujących scenariuszy: • i-węzeł nie jest już wykorzystywany przez system plików i dump pominie wykonanie
jego kopii. Mapa i-węzłów zapisana w fazie poprzedzającej etap III będzie nieprawidłowa. Taka niespójność nie ma żadnego wpływu na wykonanie kopii, ale może zaburzyć procedurę odtwarzania: plik pojawia się na liście, ale nie można go odtworzyć. • i-węzeł został ponownie użyty przez system plików, ale obecnie jest katalogiem, poto-
kiem lub gniazdem. Program dump zauważy, że plik nie jest już zwykłym plikiem, więc pominie go w procesie kopiowania. W tym przypadku ponownie mapa i-węzłów wykonana w fazie poprzedzającej etap III będzie niespójna.
• i-węzeł został ponownie użyty przez system plików i jest wykorzystywany przez inny
plik. Program dump zapisze ten plik. Co gorsza, nazwa pliku zapisana w etapie III dla danego numeru i-węzła będzie dotyczyła poprzedniej zawartości i-węzła, więc będzie zupełnie nieprawidłowa. Zapisany plik może dotyczyć zupełnie innych danych systemu plików. Mamy tu taką sytuację, jak byśmy wykonywali kopię zapasową /etc/hosts, a w pliku znalazłaby się zawartość pliku /bin/ls. Zawartość pliku w zasadzie nie jest uszkodzona, ale w przypadku odtworzenia pliku uzyskamy zupełnie bezwartościowy plik. Plik zmienia lokalizację w systemie plików. I w tym przypadku istnieje kilka możliwych scenariuszy: • Nazwa pliku zmienia się przed zrzuceniem zawartości katalogu na etapie III. Zostanie
zapisana nowa nazwa pliku. Dalsze etapy kopii zapasowej zostaną wykonane prawidłowo, tak jakby nazwa pliku nie została zmieniona. • Nazwa pliku zostaje zmieniona po zapisaniu katalogu na etapie III. Numer i-węzła nie
zmienia się, zatem dump zapisze kopię pliku. Jednak nazwa pliku zapisana na etapie III nie będzie zgodna z obecną nazwą pliku. W zależności od sposobu wykorzystania kopii zapasowej ten scenariusz może być dość mało szkodliwy. • Plik został przeniesiony do innego katalogu w ramach tego samego systemu plików,
zanim został zapisany katalog plików na etapie III. Jeśli numer i-węzła nie zmienił się, konsekwencje będą takie same jak w pierwszym scenariuszu. • Plik został przeniesiony do innego katalogu w ramach tego samego systemu plików po
zapisaniu katalogu plików na etapie III. Jeśli numer i-węzła nie zmienił się, kopia pliku zostanie wykonana, ale w archiwum plik znajdzie się w starym katalogu pod starą nazwą.
• Numer i-węzła zmienił się. Kopia pliku nie zostanie wykonana albo w jego miejsce zo-
stanie wykonana kopia innego pliku (jeśli inny plik został zapisany w i-węźle o tym samym numerze).
692
|
Rozdz ał 23. VMware nne
Pytanie 2 Pytanie: Jeśli zostanie wykonany zrzut aktywnego systemu plików, czy uszkodzenia mogą dotyczyć katalogów? Odpowiedź: To możliwe. Większość uwag dotyczących plików dotyczy również katalogów. Najważniejsza różnica polega na tym, że zawartość katalogów jest zrzucana na etapie III, a dane plików na etapie IV, zatem potencjalny czas między rozpoczęciem zrzutu a modyfikacją może być mniejszy. Z tego można wywnioskować, że dump jest mniej podatny na uszkodzenia katalogów, ponieważ czas między sporządzeniem listy i-węzłów katalogów a zrzuceniem zawartości katalogów jest krótszy. Jednak zmiany w plikach, które powinny zostać uwzględnione w katalogach, również powodują zapis archiwum w niespójnym stanie.
Pytanie 3 Pytanie: Jeśli wykonamy zrzut aktywnego systemu plików, czy uszkodzenia będą dotyczyły całego zrzutu czy tylko jego fragmentu od miejsca wystąpienia błędu do jego końca? Odpowiedź: Żadne z powyższych. Mimo tego, że dump zrzuca pliki na poziomie surowego urządzenia, w praktyce kopiowanie odbywa się na poziomie pojedynczych i-węzłów. Zatem mimo innego poziomu abstrakcji w praktyce kopia wykonywana jest na poziomie plików. Uszkodzenie jednego pliku nie uszkodzi pozostałych plików w archiwum.
Pytanie 4 Pytanie: Czy rzeczywiście jedyny pewny sposób uzyskania spójnego zrzutu wymaga odmontowania systemu plików? Odpowiedź: Nie. Istnieje duże prawdopodobieństwo, że zrzut zamontowanego systemu plików, w którym nie są dokonywane modyfikacje, będzie w pełni prawidłowy. Im system plików jest aktywniejszy, tym wyższe jest prawdopodobieństwo uszkodzenia plików w zrzucie. Jednak ryzyko uszkodzenia plików w archiwum jest zbliżone do analogicznego ryzyka przy zastosowaniu narzędzia działającego na poziomie systemu plików.
Pytanie 5 Pytanie: Czy może się okazać, że zrzut aktywnego systemu plików jest zupełnie bezużyteczny? Odpowiedź: Nie. Istnieje prawdopodobieństwo, że poszczególne pliki w archiwum będą uszkodzone, ale szanse, że cały zrzut jest uszkodzony, są bardzo niewielkie. Program dump zrzuca dane na poziomie i-węzłów, jego działanie jest bardzo zbliżone do programów działających na poziomie systemu plików.
Zasada dz ałan a programu dump
| 693
Podsumowanie uwag o działaniu programu dump Jak pisałem, wykorzystanie programu dump do wykonania kopii zapasowej zamontowanego systemu plików może spowodować uszkodzenie poszczególnych plików w kopii lub niemożność odtworzenia plików, pozornie dostępnych w zrzucie. Prawdopodobieństwo wystąpienia tego typu sytuacji jest wprost proporcjonalne do liczby i częstotliwości zmian zachodzących w systemie plików w trakcie wykonywania zrzutu. Istnieją również sytuacje, w których kopia została wykonana prawidłowo, ale informacje zapisane w zrzucie są niespójne. Może również zdarzyć się, że zapisane zostaną niewłaściwe pliki, które po odtworzeniu będą zawierały całkowicie nieprawidłowe dane, co może wprawić w zdumienie niejednego administratora. Warto również zajrzeć do ramki „Narzędzie dump w systemach Mac OS i Linux” w rozdziale 3.
Możliwość wystąpienia uszkodzenia archiwum jest dość niewielka, ale nadal istnieje. W większości przypadków wykonanie zrzutu aktywnego systemu plików o dość małej dynamice zmian da prawidłową kopię zapasową. Można uznać, że prawdopodobieństwo uzyskania prawidłowej kopii zapasowej za pomocą programu dump jest zbliżone do zastosowania programów tar i cpio.
Jak odczytać ten wolumin? Doświadczony administrator systemu z pewnością prędzej czy później spotka się z sytuacją, gdy użytkownik przyniesie mu tajemniczy nośnik danych i poprosi: „Czy mógłbyś mi to odczytać”? Nie wie, jaki jest format nośnika ani skąd pochodzi, ale chce poznać jego zawartość. Albo na dnie szuflady znajdzie bardzo starą kopię zapasową, która może zawierać interesujące dane, ale trudno je odtworzyć. Jak radzić sobie w takich sytuacjach? W jaki sposób sprawdzić format woluminu? W jaki sposób odczytać wolumin zapisany w innym komputerze? Na wszystkie te pytania postaram się odpowiedzieć w tym podrozdziale. W takich przypadkach należy ustalić około dziesięciu faktów związanych z nośnikiem, z których połowa dotyczy samej kompatybilności sprzętu. Zatem połowa problemów dotyczy formatu danych. Jeśli ktoś natrafi na problem z odczytaniem danych z nośnika, istnieje duże prawdopodobieństwo, że przyczyną jest jeden z opisanych niżej problemów.
Przygotowanie Jeśli właśnie dostałeś do ręki nośnik i musisz go odczytać natychmiast, przejdź do następnego punktu. Jeśli jednak pracujesz w środowisku heterogenicznym i spodziewasz się, że możesz natrafić na problematyczny nośnik, przeczytaj uważnie ten punkt. Odczytywanie danych na platformach innych niż ta, na której zostały zapisane, jest zawsze doskonałym kandydatem na przyczynę problemów. Z wyjątkiem przypadków, gdy mamy do czynienia z awarią nośnika albo uszkodzeniem danych, w rzeczywistości jedyny pewny sposób na odczytanie danych polega na wykorzystaniu tego samego sprzętu, na którym zostały zapisane. Nie wolno zakładać, że uda się odczytać wolumin w innym systemie tylko dlatego, że ma tę samą wielkość lub jest obsługiwany przez 694 |
Rozdz ał 23. VMware nne
ten sam system operacyjny, a nawet identyczną wersję programu do archiwizacji danych. Tak naprawdę nie należy przyjmować jakichkolwiek optymistycznych założeń. Należy zatem przyjąć, że będzie się zmuszonym do odczytu woluminu na innym systemie lub na innym typie urządzenia. W takim wypadku warto wcześniej sprawdzić, czy w ogóle istnieje taka możliwość. Warto również zachować jedno lub dwa stare urządzenia, które mogą się przydać w przypadku, gdy nowe urządzenia sobie nie poradzą (znam firmy, w których przechowuje się stare, 10-, a nawet 15-letnie komputery wyłącznie do tego celu). Jeśli przeprowadzi się testy z góry, może okazać się na przykład, że w celu przygotowania archiwum do odtworzenia na innym urządzeniu należy zastosować specjalną opcję przy wykonywaniu kopii. Oczywiście lepiej to sprawdzić z góry, niż dowiedzieć się po dwóch latach, że „gdyby kopia tych niezwykle ważnych danych została zapisana w nieco inny sposób, dałoby się ją odtworzyć”…
Niewłaściwy typ nośnika Wiele typów nośników wygląda podobnie, ale często posiadają zasadnicze różnice. Napędy typu DLT, LTO, AIT itp. to zupełnie różne generacje i ich nośniki bardzo różnią się wzajemnie. Jeśli problematyczny nośnik jest taśmą a napęd wyposażony jest w system rozpoznawania nośnika (media recognition system, MRS), urządzenie może zgłosić nieprawidłowy typ nośnika. Czasem mechanizm MRS nie jest uaktywniony, lub w ogóle nie występuje, przez co użytkownik zakłada, że wszystko powinno działać, skoro kaseta pasuje do napędu. Niektóre typy nośników współpracują tylko z wybranymi napędami i w przypadku zastosowania nieodpowiedniego nośnika z określonym napędem, może wystąpić problem z odczytaniem archiwum. Czasem taka sytuacja nie jest oczywista, ponieważ napęd nie zgłasza błędów zapisu. Problem niekompatybilności nośników można naprawić przez zastosowanie najnowszego posiadanego napędu dla danego typu nośnika. Sekret w tym, że nowsze napędy często potrafią obsłużyć starsze typy nośników. Jednak nie jest to złota reguła i również może stać się przyczyną problemów.
Uszkodzona lub zabrudzona taśma lub napęd Jeśli typ nośnika jest zgodny z napędem, a występują problemy z odczytem danych na taśmie, może to oznaczać, że napęd jest uszkodzony lub zabrudzony. Warto zastosować taśmę czyszczącą, o ile jest dostępna dla danego napędu. Jeśli to nie pomoże, może to oznaczać, że napęd jest uszkodzony. Możliwe jest również, że uszkodzony był napęd, na którym taśma została zapisana. Na przykład tego typu problemy może przysparzać napęd o błędnie ustawionych głowicach: tak nagranej taśmy nie odczyta sprawny napęd. Z tego powodu po utworzeniu kopii zapasowej danych, które muszą być odtwarzalne po dłuższym czasie przechowywania, należy sprawdzić, czy taśma daje się odczytać w innym napędzie. Istnieją również urządzenia oczyszczające taśmy, choć są rzadziej stosowane. Tego typu urządzenie wygląda jak napęd taśmowy. Do takiej maszyny ładuje się taśmę, po czym jest ona poddawana procesowi oczyszczania i odkurzania. Czasem w przypadku, gdy taśma jest nieczytelna, jej oczyszczenie może przywrócić ją do pełnej użyteczności. W dużych centrach danych tego typu narzędzie może okazać się wręcz bezcenne.
Jak odczytać ten wolum n?
| 695
Spróbuj ponownie Podczas odtwarzania danych natrafiłem na taśmę, która była rozpoznawana jako pusta. Oczywiście odtworzenie taśmy było istotne, ponieważ ktoś przypadkowo usunął ważny plik. Po kilku próbach we wszystkich czterech napędach, które mieliśmy, udało się rozpoznać taśmę i odczytać jej zawartość. Odtworzenie danych nie przysporzyło żadnych dodatkowych problemów. Po dłuższej chwili wstrzymywania powietrza, modlitw i przekleństw zrozumiałem, że morał z tej historii brzmi: jeśli nie uda ci się za pierwszym razem, spróbuj ponownie, a potem jeszcze raz i jeszcze, aż do skutku! — Ed Lam
Różne typy napędów Ten punkt również dotyczy problemu kompatybilności napędów i taśm. Nie wszystkie napędy, które wyglądają podobnie, mają podobne właściwości. Nie wszystkie taśmy zawierają etykietę informującą o typie napędu, z którym są zgodne. Nie wszystkie napędy stosujące kompresję sprzętową mają stosowne opisy na obudowie. Jedyny sposób weryfikacji zgodności dwóch urządzeń polega na sprawdzeniu symbolu modelu. Jeśli urządzenia pochodzą od różnych producentów, należy udać się na ich strony WWW, a być może uda się znaleźć informację o kompatybilności.
Błędne ustawienia poziomu i typu kompresji Najczęściej napędy tego samego typu stosują ten sam typ kompresji. Jednakże wielu dostawców typu VAR (value-added reseller) oferuje urządzenia o rozszerzonych możliwościach, na przykład zapewniające niestandardowe algorytmy kompresji. Dzięki tym rozszerzeniom napęd może lepiej skompresować dane, dzięki czemu na tym samym nośniku zmieści się więcej informacji, a proces zapisu kopii będzie trwał krócej. Jeśli wszystkie urządzenia do kompresji są tego samego typu, stosowanie tych rozszerzeń nie stanowi problemu, pod warunkiem że dostawca istnieje na rynku. Jeśli jednak pozostałe napędy nie obsługują niestandardowego poziomu kompresji, należy zdecydować się na zastosowanie bardziej standardowego poziomu, jak IDRC czy DCLZ. I w tym przypadku należy odpowiednio zaplanować strategię wykorzystania kopii zapasowych.
Niekompatybilność architektury maszyny Istnieją różnice między maszynami zbudowanymi w różnych architekturach, które mogą wręcz uniemożliwiać wzajemne przenoszenie danych. Te różnice dotyczą uporządkowania bajtów w słowie (big-endian, little-endian) oraz bitowej reprezentacji liczb ujemnych: w formie uzupełnienia do jedności (ones complement) i uzupełnienia do dwóch (twos complement). Na przykład maszyny z procesorami Intela (i kompatybilne) mają architekturę typu little-endian, a procesory RISC są typu big-endian. Przenoszenie danych między tymi architekturami może być niemożliwe. Większość wielkich maszyn uniksowych ma architekturę big-endian, ale popularna rodzina procesorów Intel x86 oraz starsze maszyny Digital mają architekturę little-endian (zobacz tabela 23.1). Oznacza to, że w przypadku próby odczytania na maszynie NCR Intel SVr4 (littleendian) kopii zapasowej zapisanej na NCR 3b2 (big-endian) należy spodziewać się problemów. 696
|
Rozdz ał 23. VMware nne
Tabela 23.1. Platformy big-endian i little-endian Maszyny typu b g-end an
Maszyny typu l ttle-end an
SG /M PS BM/RS6000 P/PA R SC Spa c/R SC Powe PC DG Aviion P/Apollo (400 DN3xxx DN4xxx) NCR 3B2 T 1500 Macintosh na Powe PC Alpha3
DECStation4 VAX ntel x86
Istnieje drugie pojęcie związane z architekturą procesorów, które może przysporzyć problemów z odtwarzaniem kopii zapasowych. Chodzi tu o formy reprezentacji liczb ujemnych, a co za tym idzie, całej związanej z tym arytmetyki dwójkowej, czyli o arytmetykę uzupełnienia do jedności (ones compliment arithmetics) oraz uzupełnienia do dwóch (twos compliment). Analiza różnic między architekturami little-endian i big-endian oraz arytmetyką uzupełnienia do jedności czy uzupełnienia do dwóch wybiega znacznie poza tematykę tej książki; chodzi mi przede wszystkim o to, aby zaznaczyć, że tego typu różnice istnieją i że można napotkać poważne problemy z odczytem danych w systemie jednej z tych architektur zapisanych w systemie z drugiej. Z reguły jedynym sposobem odzyskania tego typu danych jest odczytanie ich na oryginalnej architekturze. Większość formatów kopii zapasowych wykorzystuje format „niezależny od architektury” (endian-independent), co oznacza, że ich nagłówek i dane mogą być odczytane na dowolnej architekturze obsługującej dany format archiwum. W ten sposób działają programy tar i cpio, szczególnie jeśli chodzi o wersje GNU tych narzędzi. Zdarzało mi się odtwarzać w Uniksie lub Linuksie na maszynie typu Intel (little-endian) archiwa tar zapisane na maszynach HP/PA-RISC lub Sun Sparc (big-endian). Na przykład dość powszechną praktyką jest pobieranie archiwów tar z serwerów Unix na maszyny z systemem Windows, na których można z nich korzystać za pomocą programu WinZip. Jednak skuteczność tego typu operacji może bardzo zależeć od szczegółów. Niektórzy użytkownicy informują o zastosowaniu następującej techniki: dane odczytuje się za pomocą polecenia dd i przestawia kolejność bajtów, wykorzystując opcję conv=swab. Sądzę jednak, że choć ta technika może spowodować, że nagłówek archiwum będzie czytelny, jednak dane będą raczej bezużyteczne. Powodem może być różnica rozmiaru bajta (8 lub 16 bitów) oraz wiele innych czynników, na których omawianie nie ma tutaj miejsca. W każdym razie warto uznać, że najskuteczniejsza strategia odczytu danych polega na odczytywaniu ich na tej samej architekturze, na której zostały zapisane.
Rozmiar bloku (taśmy) Dane są zapisywane na woluminach z zastosowaniem różnych rozmiarów bloków i aby odczytać taki wolumin, należy znać rozmiar bloku zastosowany przy zapisie. W tym punkcie opiszę zasadę działania bloków danych oraz pokażę, w jaki sposób określić ich rozmiar. Gdy program czyta lub zapisuje dane na urządzeniu lub w pamięci, wykonuje operację wejściawyjścia. Dane są zapisywane lub odczytywane w stałych porcjach, zwanych blokami wejściawyjścia. Utworzenie każdego bloku wymaga zasobów, choć większe rozmiary bloków oznaczają szybsze operacje wejścia-wyjścia (w naszym przypadku — szybsze wykonywanie kopii 3
Słyszałem, że procesory Alpha mogą być ustawiane w tryb little-endian i big-endian, jednak nie udało mi się znaleźć na to dowodów. Ważne jest jednak to, że Digital Unix jest napisany w architekturze big-endian, dlatego umieściłem go w tej kolumnie.
4
Chodzi o starsze maszyny DEC 3x00 i 5x00 z systemem operacyjnym Ultrix.
Jak odczytać ten wolum n?
|
697
zapasowych). Gdy operacja wejścia-wyjścia zapisuje dane na dysku, rozmiar bloku wykorzystywanego do tej operacji nie ma wpływu na organizację danych na nośniku, ale ma wpływ na wydajność tej operacji. Jednak w przypadku, gdy operacja wejścia-wyjścia zapisuje dane na dysku, każdy blok danych staje się blokiem na taśmie, a poszczególne bloki są oddzielane odstępami międzyblokowymi. Tę zasadę ilustruje rysunek 23.1.
Rysunek 23.1. Bloki na taśmie i odstępy międzyblokowe
Wszystkie operacje wejścia-wyjścia na takiej taśmie muszą znać rozmiar bloku, w przeciwnym razie zakończą się błędem. W przypadku zastosowania niewłaściwego rozmiaru bloku może wystąpić jedna z poniższych sytuacji: Rozmiar bloku operacji stanowi wielokrotność oryginalnego. Na przykład dane zostały zapisane w blokach o rozmiarze 1024 bajtów, a są odczytywane w blokach o rozmiarze 2048 bajtów. Tego typu scenariusz jest dość powszechny — wszystko działa prawidłowo. W zależności od wielu czynników wynikowa prędkość odczytu może być większa lub mniejsza w porównaniu z zastosowaniem tej samej wielkości bloku co przy zapisie (zastosowanie za dużej wielkości bloku powoduje obniżenie wydajności operacji wejścia-wyjścia). Rozmiar bloku przy odczycie jest większy od zastosowanego przy zapisie, ale nie stanowi jego wielokrotności. Na przykład taśma została zapisana z zastosowaniem bloków o rozmiarze 1024 bajtów, a do odczytu wykorzystane są bloki o rozmiarze 1050 bajtów. Dokładny efekt jest zależny od aplikacji, ale większość aplikacji zwróci błąd wejścia-wyjścia. Operacja odczytu próbuje zapełnić danymi cały blok, a gdy osiąga koniec bloku odczytu, nie znajduje przerwy międzyblokowej, co kończy się błędem. Większość aplikacji wyświetli komunikat o błędzie i zakończy działanie. Rozmiar bloku przy odczycie jest mniejszy od zastosowanego przy zapisie. Na przykład taśma została zapisana z zastosowaniem bloków o rozmiarze 1024 bajtów, ale próbujemy ją odczytać z zastosowaniem bloków o rozmiarze 512 bajtów. Taka sytuacja prawie zawsze zakończy się błędem wejścia-wyjścia. Operacja odczytu zapełnia danymi cały 512-bajtowy blok, a gdy osiąga koniec bloku odczytu, nie znajduje przerwy międzyblokowej, co kończy się błędem. Większość aplikacji wyświetli komunikat o błędzie i zakończy działanie. Przerwy międzyblokowe zajmują miejsce na taśmie. W przypadku zastosowania zbyt małych rozmiarów bloków duża część nośnika zostanie zmarnowana na przerwy międzyblokowe niezawierające danych, co obniży pojemność taśmy.
698 |
Rozdz ał 23. VMware nne
Każdy napęd taśmowy charakteryzuje się pewnym optymalnym rozmiarem bloku, pozwalającym na uzyskanie najlepszych rezultatów. Zadaniem administratora jest znalezienie tego optymalnego ustawienia. Zbyt mały rozmiar bloku spowoduje obniżenie wydajności, za duży również może ją obniżyć, przede wszystkim z powodu większej zajętości pamięci operacyjnej, co może skończyć się nadmiernym wykorzystaniem przestrzeni wymiany. Niektóre systemy operacyjne i aplikacje do archiwizacji również mają własne ograniczenia co do rozmiaru bloku operacji wejścia-wyjścia.
Określenie współczynnika wielkości bloku Do tego celu warto zastosować sposób opisany w rozdziale 3., w punkcie „Zastosowanie programu dd do określenia rozmiaru bloku na taśmie”. Dotyczy to kopii zapasowych w formacie tar lub dump. Program tar stosuje bloki o rozmiarze 512 bajtów, a dump — 1024. Informacje na ten temat można znaleźć w podręczniku systemowym oprogramowania. Rozmiar bloku operacji wejścia-wyjścia należy podzielić przez rozmiar bloku stosowanego przez program archiwizujący. W ten sposób oblicza się współczynnik wielkości bloku. Załóżmy, że archiwum na taśmie zostało zapisane za pomocą programu dd z zastosowaniem bloków o rozmiarze 32 768 bajtów. Podręcznik systemowy programu dump informuje, że program ten wykorzystuje bloki o rozmiarze 1024 bajtów. Gdy podzielimy 32 768 przez 1024, otrzymamy 32. Tę liczbę należy zastosować przy odtwarzaniu danych z tej taśmy.
AIX i jego 512-bajtowy rozmiar bloku Niektóre systemy operacyjne, jak AIX, pozwalają zapisać na stałe rozmiar bloku w urządzeniu taśmowym. Oznacza to, że nie ma znaczenia, jaki rozmiar bloku będzie stosowany w oprogramowaniu; urządzenie zawsze będzie stosowało z góry określony rozmiar bloku. Większość użytkowników stosuje tu rozmiar bloku równy zeru, co powoduje, że określenie tego rozmiaru jest pozostawione oprogramowaniu do wykonywania kopii (technikę tę nazywa się zmiennym rozmiarem bloku). Jednak w trakcie pewnych operacji AIX automatycznie ustawia wielkość bloku na 512 bajtów. Dotyczy to wykonywania kopii zapasowych mksysb lub sysback, a powodem jest to, że rozmiar bloku równy 512 bajtów sprawia, że napęd taśmowy może być widziany przez system jak dysk twardy. Dzięki temu system może uruchomić się z taśmy. Większość skryptów mksysb i sysback po zakończeniu działania ustawia rozmiar bloku na domyślny. Należy sprawdzić, czy stosowane skrypty zachowują się odpowiednio, aby nie zapisać innych kopii zapasowych z użyciem wielkości bloku równej 512 bajtów. Dlaczego w innych systemach nie można odtworzyć taśm zapisanych w systemie AIX z użyciem bloku o rozmiarze 512 bajtów? Ponieważ AIX nie wykorzystuje bloków o rozmiarze 512 bajtów. Tak naprawdę dane są zapisywane w blokach 512-bajtowych, po których następuje 512 bajtów zerowych wypełnienia. Czyli efektywnie wykorzystywane są bloki o rozmiarze 1024 bajtów, z których połowa jest pusta! Tylko napędy taśmowe dla systemów AIX rozumieją ten format, co oznacza, że taśmy zapisane w systemie AIX w trybie bloków 512-bajtowych nie mogą być odczytane w innych systemach. Jeśli jednak zostanie ustawiony rozmiar bloku urządzenia na wartość 0, nie powinno być problemów z odczytaniem danych w innych systemach, pod warunkiem że format kopii jest kompatybilny. Wartość 0 powoduje, że napęd działa tak samo jak w innych systemach, zastosowanie będzie miał bowiem rozmiar bloku określony w programie wykonującym kopię zapasową. Jak odczytać ten wolum n?
| 699
Aby to zrobić w systemie AIX, należy uruchomić program smit i wybrać opcję Devices/Tape Drives/Change Characteristics, po czym ustawić rozmiar bloku na 0 dla wszystkich urządzeń taśmowych. Rozmiar bloku urządzenia można ustawić na wartość 1024 bez obawy o kompatybilność. W ten sposób urządzenie będzie zawsze zapisywało kopie archiwów z zastosowaniem bloków o rozmiarze 1024 bajtów, niezależnie od ustawień oprogramowania do wykonywania kopii zapasowych. Jednak w tym przypadku będą to „normalne” bloki, w przeciwieństwie do bloków o specjalnej strukturze tworzonych w efekcie ustawienia bloków o rozmiarze 1024 bajtów. Zakładając, że format wykonywania kopii zapasowych jest kompatybilny, takie archiwum powinno bez przeszkód dać się odtworzyć na innej platformie. Jednak nie znam żadnego uzasadnienia, aby rozmiar bloku ustawiać na wartość 1024 bajtów. Aby przywrócić wartość 0 rozmiaru bloku urządzenia, należy wywołać następujące polecenie: # chdev -l nazwa_urządzenia -a block_size=0
Nieznany format kopii Gdy w ręce trafia nam wolumin danych zapisany przez kogoś innego, istnieją niewielkie szanse, że uda się odgadnąć, jakie narzędzie posłużyło do jego utworzenia. W takim przypadku warto na początek zidentyfikować rozmiar bloku użyty do zapisu, co stanowi pierwszy, istotny krok w procesie odczytu danych zapisanych w nieznanym formacie. Następnie należy użyć tego rozmiaru bloku i spróbować odczytać wolumin za pomocą różnych narzędzi do odtwarzania kopii zapasowych, jak: tar, cpio, dump, pax. Podana przeze mnie kolejność nie jest przypadkowa: najczęściej można spotkać format tar, ponieważ jest najbardziej przenośny. Jeden ze sposobów identyfikacji formatu kopii zapasowej polega na odczytaniu pierwszego bloku takiej kopii i wykorzystaniu programu file. Można dzięki temu stwierdzić, czy dane zostały zapisane przez program cpio lub tar. Jeśli tak się właśnie okaże, to doskonała wiadomość. Jeśli zatem zastosowaliśmy metodę identyfikacji rozmiaru sektora opisaną wyżej, w pliku /tmp/sizefile znajdzie się pierwszy fragment archiwum, wykorzystywany do rozpoznania rozmiaru sektora. Jeśli jednak nie mamy tego pliku, należy go utworzyć (instrukcje powyżej), po czym wywołać następujące polecenie: # file /tmp/sizefile
Jeśli program file poinformuje, że to dane typu „data”, będzie to oznaczać, że nie mamy szczęścia. W internecie można znaleźć plik definiujący różne egzotyczne formaty plików, o nazwie robust.magic, który możemy wykorzystać do zwiększenia szans identyfikacji: # file -f /etc/robust.magic /tmp/sizefile
Ten plik jest szczególnie przydatny do rozpoznawania formatów plików tworzonych przez programy i narzędzia niedostępne na danej platformie systemowej.
Inny format kopii Czasem dwa polecenia mają podobne nazwy, ale odmienne działanie. Dotyczy to zarówno takich prostych do rozwiązania sytuacji, jak niekompatybilne wersje polecenia cpio, jak i bardziej skomplikowanych, jak niekompatybilne wersje programu dump. Niespójności formatów między różnymi wersjami programów tar i cpio można często obejść, stosując wersje GNU tych narzędzi,
700
|
Rozdz ał 23. VMware nne
ponieważ te wersje potrafią w sposób automatyczny rozpoznać podformat odczytywanego archiwum. Jeśli jednak mamy do czynienia z archiwum utworzonym przez niekompatybilną wersję programu dump (jak xfsdump systemu IRIX), mamy większy problem. Do odczytania takiego archiwum niezbędny będzie dokładnie taki sam system. Oczywiście skuteczność operacji będzie znacząco zróżnicowana w zależności od stopnia heterogeniczności środowiska. Zawsze należy przetestować kompatybilność archiwów z innymi posiadanymi systemami, które mogą kiedyś posłużyć do ich odtworzenia.
Format kompresji Zdarzyło się kiedyś, że musieliśmy odtworzyć dane ze starej taśmy i mieliśmy z tym problemy. Napędy wypisywały komunikaty o błędach wejścia-wyjścia za każdym razem, gdy usiłowaliśmy odczytać zawartość taśm. Po chwili poszukiwań okazało się, że taśmy powstały z myślą o określonej marce napędów wykorzystujących niestandardowy algorytm kompresji. Niestety, firma nie produkowała już tego typu urządzeń. Na szczęście udało nam się zdobyć kilka urządzeń z drugiej ręki, które bez problemu przeczytały taśmy. Pierwsze, co zrobiliśmy, to skopiowaliśmy dane z tych taśm na napęd wykorzystujący standardowe algorytmy kompresji. — Mike Geringer
Uszkodzone archiwum Jednym z pytań, które najczęściej zdarza mi się spotkać w listach dyskusyjnych, jest: „Omyłkowo wywołałem polecenie tar cvf, zamiast tar xvf. Czy istnieje jakiś sposób, aby odczytać nienadpisany fragment tego archiwum?”. Odpowiedź brzmi „nie”. Dlaczego tak jest? Za każdym razem, gdy kopia zapasowa jest zapisywana na taśmie, na końcu kopii zapasowej zapisywany jest znacznik końca nośnika (end-of-media, EOM). Ten znacznik informuje oprogramowanie sterujące napędem, że „po tym znaczniku nie są zapisane żadne dane”. Nieważne, jaki program zostanie użyty — zawsze zakończy odczyt na znaczniku EOM, ponieważ będzie uważać, że to ostatnia kopia zapasowa na danej taśmie. Oczywiście, taśma mogła być uszkodzona lub zawierać błędy. Jedną ze sztuczek stosowanych w takim przypadku jest wykorzystanie polecenia cat do odczytu uszkodzonej taśmy: # cat device/tmp/somefile
To polecenie odczytuje dane z taśmy do pliku /tmp/somefile, skąd można próbować je odzyskać za pomocą poleceń: tar, cpio lub dump.
Odczyt „opornej” taśmy Jedną z atrakcji dostępnych specjaliście od kopii zapasowych są historie opowiadane przez użytkowników. Mój przyjaciel Jim Donellan opowiedział mi o problemach z dość specyficznie zachowującą się taśmą. System odczytywał dane z tej taśmy bez problemów, po czym następował błąd wejścia-wyjścia i odtwarzanie kończyło się błędem. Jeśli jednak próba odczytu była ponawiana od miejsca, w którym poprzednio wystąpił błąd, odtwarzanie odbywało się prawidłowo przez jakiś czas, po czym sytuacja się powtarzała. Jim napisał specjalny skrypt odczytujący taśmę w szczególny sposób: po napotkaniu błędu odczytu skrypt przewijał taśmę do początku, następnie znów przewijał ją do miejsca błędu (fast-forward, instrukcja fsr programu
Jak odczytać ten wolum n?
|
701
mt), po czym kontynuował odczyt. Ten skrypt działał dwa i pół dnia, zanim udało mu się odczytać całą zawartość taśmy. Nigdy nie słyszałem o takim samozaparciu. Stwierdziłem, że po prostu muszę napisać o tym w tej książce, i poprosiłem Jima Donnellana o zgodę na zacytowanie jego skryptu. Kod skryptu o nazwie read-tape.sh przedstawia listing 23.1. Być może przyda się komuś w podobnej sytuacji. Listing 23.1. Skrypt read-tape.sh # !/bin/sh DEVICE=/dev/rmt/0cbn # Urządzenie nieprzewijające taśmy. touch rawfile # Plik rawfile powinien już się tam znajdować, tworzymy go na wszelki wypadek. while true ; do size=`ls -l rawfile | awk '{print $5}'` # Sprawdzenie rozmiaru rawfilef. blocks=`expr "$size" / 512` full=`df -k . | grep | awk '{print $6}'` # Niestety, to jest sprawdzane co jakiś czas, być może lepiej zrobić fork? echo $size # Dla informacji. echo $blocks echo $full if [ $full -gt 90 ] ; then echo "system plików się przepełnia " exit 1 fi mt -f $DEVICE rewind # Aby nie kusić losu. Zaczynamy od początku. sleep 60 # Zaczekamy chwilę. mt -f $DEVICE fsr $blocks # Pomijamy fragment taśmy odpowiadający rozmiarowi pliku rawfile dd if=$DEVICE bs=512 >> rawfile # Zapisujemy tak dużo, ile się uda. if [ $? -eq 0 ] ; then # Jeśli polecenie dd zostało przerwane przez błąd napędu, oznacza to, że skrypt musi wykonać dalszą pracę. echo "dd zakończyło się prawidłowo" # Oznacza to, że bez problemu przetworzyło cały plik. # Koniec pracy. exit 0 fi done
Bardzo chętnie zapoznam się z podobnymi wskazówkami dotyczącymi odczytywania uszkodzonych woluminów danych. Jeśli wykorzystam je w przyszłych wydaniach tej książki, z pewnością poinformuję o ich autorach! Dodatkowo wszystkie sugestie umieszczam na swojej stronie WWW.
702
|
Rozdz ał 23. VMware nne
Wiele partycji na taśmie Ta wskazówka stanowi jedynie efekt pewnego spostrzeżenia. Zawsze przy zapisie danych na taśmie należy pamiętać o tym, że na nośniku może wystąpić większa liczba partycji. Przy próbie odczytu nieznanej taśmy warto wywołać następujące polecenia: # mt -t urządzenie rewind # mt -t urządzenie fsf 1
Następnie można ponownie spróbować odtworzyć tę kopię. Jeśli próba zakończy się błędem wejścia-wyjścia, będzie to oznaczać, że na taśmie nie znajdują się dodatkowe kopie (innymi słowy, został osiągnięty znacznik EOM). Jeśli operacja nie zakończy się błędem, należy zastosować te same polecenia co na początku taśmy, aby odczytać zawartość nośnika. Nie należy jednak zakładać, że następna partycja ma ten sam format co poprzednia. Należy też pamiętać, że za każdą próbą odczytu zawartości taśmy należy ją przewinąć do początku, a następnie przewinąć do następnej partycji, wykorzystując powyższe dwa polecenia.
Jeśli nie uda się za pierwszym razem… Nie należy się poddawać. Zawsze gdy natrafisz na taśmę, której nie udaje się odtworzyć, przypomnij sobie historię mojego przyjaciela Jima i jego opornej taśmy.
Gigabit Ethernet Ilość danych, którą jesteśmy zmuszeni kopiować, rośnie wykładniczo, podobnie jak wydajność oprogramowania do wykonywania kopii zapasowych. Wykonywanie kopii tak ogromnych ilości danych jest możliwe dzięki stosowaniu zaawansowanych technik, takich jak dynamiczne zrównoleglenie operacji i programowa kompresja danych. Jednak ilość danych zapisanych na serwerach jest tak duża, że niemożliwe stało się wykonywanie kopii zapasowej z zastosowaniem zwykłej sieci LAN. Nawet gdyby sieci LAN były bardzo szybkie, ich wydajność nadal byłaby ograniczona. Standard Gigabit Ethernet miał uratować technologie kopii zapasowych w sieci. Dziesięć razy szybszy od poprzednika (Fast Ethernet), z pewnością rozwiązałby problem wydajności. Wielu administratorów (również i ja) projektowało swoje systemy kopii zapasowych z myślą o zastosowaniu sieci Gigabit Ethernet. Niestety, w większości przypadków te próby kończyły się rozczarowaniem. Choć wydajność na poziomie 1000 Mb/s była osiągalna między przełącznikami, to uzyskanie jej między klientem a serwerem kopii zapasowych było po prostu niemożliwe. Liczba przerwań, które musi obsłużyć system operacyjny, jest tak duża, że sama transmisja danych w sieci zużywa większość zasobów serwera. Nawet gdyby na transmisję poświęcić całą pamięć RAM i moc procesora, można by liczyć jedynie na wydajność rzędu 500 Mb/s. Jednak należy pamiętać, że przy tej prędkości przesyłania danych systemy nie mogłyby wykonać żadnych innych operacji. Oznacza to zatem, że w codziennych warunkach działania sieci LAN wydajność transmisji gigabitowych wynosi średnio od 200 do 400 Mb/s. W czasie pisania tej książki w sprzedaży pojawiły się karty sieciowe o przepustowości 10 Gb/s. Także one mają ocalić, po raz kolejny, technologię wykonywania kopii zapasowych w sieci. Pod warunkiem że użytkownik jest skłonny wydać kilkaset dolarów na kartę sieciową. Można w to wierzyć lub nie, ale rozmawiałem z administratorami, którym udało się osiągnąć prędkość
G gab t Ethernet
|
703
transmisji na poziomie 4000 – 5000 Mb/s w systemie Solaris 10. Jeśli te wyniki są osiągalne również w innych konfiguracjach, z pewnością istnieje nadzieja. Sądzę jednak, że to przegrana bitwa.
Odzyskiwanie zawartości uszkodzonych dysków Wydaje się, że w książce poświęconej kopiom zapasowym i bezpieczeństwu danych właściwa jest choćby wzmianka na temat firm odzyskujących dane. Gdy zawiodą wszystkie inne możliwości, istnieje szansa, że ci ludzie będą w stanie pomóc. Od czasu do czasu zdarza się bowiem, że psuje się dysk twardy, którego kopia zapasowa nie wykonała się prawidłowo (lub w ogóle). Aby odczytać zawartość uszkodzonego dysku, firma odzyskująca dane po prostu rozbiera go na części. Taka usługa może kosztować kilka tysięcy dolarów i płaci się niezależnie od powodzenia operacji. Takie usługi są kosztowne, ale często zdarza się, że udaje się odzyskać dane, a czasem to faktycznie jedyny sposób, aby je uratować. Firmy tego typu można znaleźć praktycznie w każdym kraju; wystarczy w wyszukiwarce wpisać hasło „disk recovery”. Należy jednak mieć nadzieję, że nigdy ich usługi nie będą niezbędne…
Wczoraj Gdy ta parodia piosenki Paula McCartneya pojawiła się w sieci, otrzymałem ją e-mailem niezależnie od ponad stu osób! Autor tekstu jest nieznany. Trudno wyobrazić sobie lepsze miejsce niż taki rozdział o wszystkim i o niczym.
704
Yesterday,
Wczoraj
All those backups seemed a waste of pay.
Kopie zapasowe wydawały się marnowaniem pieniędzy.
Now my database has gone away.
Teraz moja baza zniknęła
Oh I believe in yesterday.
Och, już wierzę w siłę wczoraj.
Suddenly,
Nagle
There’s not half the files there used to be,
Nie ma plików, które kiedyś tu były,
And there’s a milestone hanging over me
A terminy zbliżają się nieubłaganie.
The system crashed so suddenly.
System załamał się tak niespodziewanie.
I pushed something wrong
Kliknąłem niewłaściwy przycisk,
What it was I could not say.
Co to było, nie wiem sam.
Now all my data’s gone
Teraz dane zniknęły,
and I long for yesterday-ay-ay-ay.
A ja tęsknię za tym, co było wczoraj.
Yesterday,
Wczoraj
The need for backups seemed so far away.
Potrzeba wykonywania kopii była tak odległa.
I knew my data was all here to stay,
Wierzyłem, że moje dane są wieczne,
Now I believe in yesterday.
Teraz wierzę w siłę wczoraj.
|
Rozdz ał 23. VMware nne
Zaufaj mi, jeśli chodzi o kopie zapasowe Oto jeszcze jedna porcja humoru dotyczącego kopii zapasowych, systematycznie obiegającego internet. To jest kolejna parodia, której autorstwo przypisuje się Charlesowi Meighowi, oparta na piosence „Use Sunscreen” Mary Schmich, która z kolei była adaptacją odczytu Kurta Vonneguta (który sam nigdy nie napisał ani nie wygłosił odczytu). W każdym razie nieważne. Po prostu przeczytaj to! Wykonaj kopię zapasową dysku twardego. Gdybym mógł dać ci tylko jedną radę, to byłoby właśnie to: rób kopie zapasowe. Konieczność wykonywania regularnych kopii zapasowych jest wyraźnie sygnalizowana tym, że podaje się współczynnik MTBF na obudowach dysków twardych, ale uzasadnienia mojej rady należy szukać przede wszystkim w moim niezbyt szczęśliwym doświadczeniu życiowym. Teraz pogłębię nieco tę radę. Napawaj się wolnością i niewinnością swojego niedoświadczenia. Nie próbuj tego zrozumieć. Nie zrozumiesz uroku wolności i niewinności, dopóki nie zostaną wyparte przez gorzki cynizm. Ale zaufaj mi, za trzy miesiące spojrzysz wstecz na swoje posty na grupie groups.google.com i przypomnisz sobie, że nie zdawałeś sobie sprawy z tego, jakie miałeś możliwości i jaki potrafiłeś być dowcipny. Nie jesteś tak zgorzkniały, za jakiego się miałeś. Codziennie pisz jeden post całkowicie na temat. Dyskutuj. Nie trolluj na obcych grupach dyskusyjnych. Nie toleruj trolli na swoich grupach dyskusyjnych. Aktualizuj oprogramowanie antywirusowe. Czasem uda ci się wysforować przed innych, czasem pozostaniesz w tyle. Wyścig jest długi, a na końcu okazuje się, że walczyłeś z samym sobą. Pamiętaj otrzymane pochwały. Zapomnij niesłuszne obelgi. Jeśli ci się to uda, powiedz mi, jak to zrobiłeś. Zdobądź dobry monitor. Szanuj wzrok. Docenisz go, gdy ci go zabraknie. Być może coś zaobserwujesz, być może nie. Być może spotkasz kogoś twarzą w twarz, być może nie. Niezależnie od tego, co zrobisz, nie gratuluj sobie nadmiernie, nie bądź jednak dla siebie zbyt surowy. Twoje wybory to w połowie ślepy traf. Zaufaj m , jeśl chodz o kop e zapasowe
|
705
Tak samo jak wszystkich innych. Ciesz się ze swojego dostępu do internetu. Używaj go na wszystkie możliwe sposoby. Nie bój się go ani tego, co inni sądzą na jego temat. To przywilej, nie coś, co się należy. Czytaj readme.txt, nawet jeśli tego nie zrozumiesz. Nie czytaj podręczników systemowych Uniksa. Przez nie tylko poczujesz się głupszy. Poznaj swoich kolegów z grup dyskusyjnych. Nigdy się nie spostrzeżesz, gdy odejdą na dobre. Zrozum, że przyjaciele przychodzą i odchodzą, ale tylko naprawdę niewielu jest takich, z którymi warto trzymać. Umieszczaj posty na r.a.sf.w.r-j, ale przestań, zanim staniesz się za twardy. Umieszczaj posty na a.f.e, ale przestań, zanim staniesz się za miękki. Przeglądaj. Zaakceptuj pewne niepodważalne fakty: spam będzie się zwiększał, grupy dyskusyjne będą miejscem jałowych potyczek słownych, ty też kiedyś staniesz się starym wyjadaczem. A kiedy tak się stanie, będziesz marzyć o czasach, gdy znów jesteś żółtodziobem, spam jest rzadkością, listy dyskusyjne to miejsca wyrafinowanych dyskusji, a ludzie czytają dokumentację. Czytaj dokumentację. Uważaj, czyich rad słuchasz, ale bądź cierpliwy wobec tych, którzy ich udzielają. Porada jest formą nostalgii. Udzielanie porad przypomina łowienie wiedzy w dziennikach systemowych, ponowne jej formatowanie i wtórne wykorzystanie na większą skalę, niż rzeczywiście zasługuje. Mimo to zaufaj mi, że należy robić kopie zapasowe. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
706
|
Rozdz ał 23. VMware nne
ROZDZIAŁ 24.
Ochrona danych
Poprzednie rozdziały omawiały jedynie zagadnienia wykonywania i odtwarzania kopii zapasowych, ale uważam, że przed zakończeniem tej książki muszę przekazać kilka dodatkowych, istotnych informacji. Wykonywanie i odtwarzanie kopii zapasowych to niezwykle istotne zagadnienia, jednak stanowią jedynie wybrane elementy problematyki ochrony danych. Ochrona danych jest definiowana jako „działania związane z zabezpieczaniem danych przed skutkami sytuacji niepożądanych”. Do tych działań zalicza się wykonywanie i odtwarzanie kopii zapasowych, archiwizację, zapewnienie bezpieczeństwa i odtwarzanie systemu po katastrofie. Każda organizacja, niezależnie od jej rozmiaru, powinna być świadoma wagi tych zagadnień. Niektóre aspekty ochrony danych, jak długoterminowa archiwizacja i problemy kompatybilności, mogą mieć mniejsze znaczenie w niewielkich firmach. Jednak należy regularnie analizować każdy aspekt ochrony danych z punktu widzenia zakresu przetwarzanych danych w świetle zmian zachodzących w firmie. Właśnie dlatego zdecydowałem, żeby książkę poświęconą w znakomitej większości tematyce wykonywania i odtwarzania kopii zapasowych zakończyć rozdziałem o ochronie danych. Chcę upewnić się, że Czytelnik jest świadomy, jakie to ważne, a przede wszystkim, że zdaje sobie sprawę, iż wykonywanie i odtwarzanie kopii zapasowych to dopiero początek drogi. Może zdarzyć się, że korporacyjne wymagania dotyczące archiwizacji danych są łatwe do spełnienia i można zastosować rozwiązania open source i prosty schemat rotacji nośników poza miejscem podstawowego składowania danych. Bywa jednak tak, że wymagania dotyczące archiwizacji lub bezpieczeństwa składowania archiwów są skomplikowane i zastosowanie rozwiązań open source w niektórych obszarach wiąże się przede wszystkim z koniecznością zaoszczędzenia pieniędzy na kosztowne rozwiązania sprzętowe lub programowe, spełniające te ostre wymagania. Może się też okazać, że Czytelnik, zanim zajrzał do tego rozdziału, nie brał pod uwagę zagadnień bezpieczeństwa danych. W takim wypadku mam nadzieję, że przedstawiony tu przegląd zagadnień ochrony danych będzie dobrą podstawą do dalszych przemyśleń. Żyjemy w epoce informacji. Nawet najmniejsze firmy rodzinne opierają dziś swoją działalność na jakiejś formie systemu komputerowego, w którym przechowują ważne dla siebie dane. Może to być lista danych kontaktowych klientów, dziennik transakcji, a nawet specyfikacja techniczna nowego produktu. Niezależnie od merytorycznej zawartości tych informacji biznes dozna znaczącego uszczerbku w przypadku braku dostępu do tych danych: zagubienia, usunięcia, zniszczenia lub kradzieży. Kompletny system ochrony danych chroni właśnie przed zagrożeniami tego typu.
707
System ochrony danych nie tylko służy do odzyskiwania utraconych danych. Pozwala również odzyskać dane przeniesione na inne nośniki lub zapisane w inny sposób niż ten, w jaki trzeba je odczytać. Zapobiega przed wpadnięciem danych w niepowołane ręce i zapewnia firmie zgodność z regulacjami prawnymi. Oczywiście pełny system ochrony danych zapewnia, że dane mogą zostać odzyskane w przypadku katastrofy. Istnieją biznesowe i techniczne powody stosowania ochrony danych. Dwa następne podrozdziały omawiają poszczególne zagadnienia związane z tymi kryteriami.
Biznesowe powody ochrony danych Podobnie jak w przypadku większości funkcji informatyki, celem każdej strategii ochrony danych jest zmniejszenie ryzyka, redukcja kosztów i udoskonalenie poziomu usług.
Zmniejszenie ryzyka Podstawowym celem systemu ochrony danych jest zmniejszenie ryzyka. W informatyce zmniejszenie ryzyka jest z reguły równoznaczne z dostępnością danych, bezpieczeństwem wewnętrznym i zewnętrznym i zgodnością z prawem.
Dostępność danych Wiele współczesnych biznesów wymaga, aby użytkownicy i aplikacje biznesowe mieli dostęp do krytycznych informacji 24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku (24*7*365). Biznesy, które nie są w stanie uzyskać dostępu do krytycznych informacji, mogą mieć problem z realizacją kluczowych funkcji, jak przyjmowanie zamówień czy ich przetwarzanie. Również partnerzy takich firm mogą mieć problemy z przyjmowaniem i przetwarzaniem zamówień w przypadku braku dostępu do tych informacji. Planowane i nieplanowane przestoje, choćby pojedynczego podsystemu, mogą mieć poważne konsekwencje z punktu widzenia zarówno firmy, jak i jej partnerów i klientów. Konsekwencje braku dostępu do danych mogą być poważne i obejmować utratę dochodów (zobacz podrozdział „Redukcja kosztów” w dalszej części rozdziału). Co gorsza, publiczne informacje na temat takich zdarzeń mogą mieć długofalowe konsekwencje dla firmy i jej partnerów, wliczając w to obniżenie wartości marki i utratę reputacji.
Bezpieczeństwo wewnętrzne i zewnętrzne Istnieje prawdopodobieństwo, że informacje kluczowe dla organizacji są obiektem pożądania jej konkurentów. W rzeczywistości, co może być zaskakujące, wiele dużych i małych firm podejmuje dość radykalne kroki, takie jak szpiegostwo przemysłowe, proste złośliwości i terroryzm elektroniczny, aby uzyskać dostęp do listy kluczowych klientów, planów produkcyjnych czy własności intelektualnej. Kradzież tożsamości (znana również jako fałszowanie tożsamości) to kolejny powód do zmartwień dla departamentów IT. Również ten problem musi znaleźć swoje odzwierciedlenie w strategiach zabezpieczeń. Nazwisko i informacje identyfikacyjne klienta (jak: adres, data urodzenia, numery ubezpieczeniowe stosowane w USA) to często wystarczające dane, aby opróżnić komuś konto bankowe czy uzyskać dostęp w jego imieniu do innych usług. 708
|
Rozdz ał 24. Ochrona danych
Kradzież strategicznych informacji biznesowych lub uzyskanie do nich dostępu mogą również nieść szereg konsekwencji biznesowych, włączając w to utratę przewagi konkurencyjnej, utratę wizerunku korporacji, kary nakładane przez instytucje państwowe, a nawet likwidację firmy. Oto lista prawdziwych przypadków tego typu sytuacji w ostatnich latach: • Wiele firm przestało istnieć 11 września 2001 roku, gdy okazało się, że ich główne serwery
były zainstalowane w jednej z wież Word Trade Center. 1
• W kilku sprawach sąd podjął orzeczenie o „obciążającym braku dowodów ” i zarządził ka-
ry sięgające milionów dolarów.
• Reputacja wielu firm została zniszczona, gdy okazało się, że dane ich klientów nie były
odpowiednio chronione.
Zgodność z przepisami Regulacje prawne to dodatkowe zadania dla departamentu IT. Współczesny biznes musi radzić sobie z coraz większą liczbą przepisów. Na przykład organizacje przechowujące informacje medyczne w USA podlegają przepisowi Health Insurance Portability and Accountability Act (HIPAA). Organizacje finansowe prowadzące interesy w USA muszą stosować się do zaleceń Securities and Exchange Commission (SEC) 17a-4, a firmy przemysłowe wszystkich typów podlegają regułom określonym w przepisie Sarbanes-Oxley Act (SOX). Każda firma prowadząca interesy w Unii Europejskiej powinna doskonale znać przepisy dyrektywy o ochronie danych z roku 1998, które określają zakres kontroli i dostępu do danych osobowych, jak „numer identyfikacyjny lub (…) jedna lub większa liczba cech szczególnych, służących do określenia fizycznej, fizjologicznej, umysłowej, ekonomicznej, kulturowej lub społecznej tożsamości”. Każdy duży kraj na świecie ma taką regulację lub jest w trakcie jej opracowywania. Niezastosowanie się do tego typu wymogów ma z reguły surowe konsekwencje, na przykład wysokie kary finansowe, sięgające w USA setek milionów dolarów, osobista odpowiedzialność sądowa członków zarządu firmy lub zakaz prowadzenia działalności przez firmę.
Redukcja kosztów Gdy dane nie są odpowiednio chronione, organizacja jest zmuszona do ponoszenia długiej listy dodatkowych kosztów policzalnych (jak kary nakładane w efekcie procesów sądowych) i niepoliczalnych (jak utrata szansy rynkowej czy reputacji). Efektywna strategia ochrony danych jest w stanie zminimalizować te koszty, zapewniając dostępność danych dla autoryzowanych użytkowników wtedy, gdy jej potrzebują, i zgodnie z wymogami biznesowymi firmy.
Koszty przestojów Jeśli informacje, które z powodu awarii są niedostępne, są wykorzystywane do generowania dochodu, dochód zostanie utracony. Jednak dokładne obliczenia strat ponoszonych przez organizację w wyniku przestoju są uzależnione od wielu czynników, takich jak typ biznesu, typ danych, do których utracono dostęp, oraz czas, przez który dane nie były dostępne. Koszt może wynieść od setek do milionów dolarów na godzinę przestoju. 1
Decyzja o obciążającym braku dowodów dotyczy sytuacji, gdy sędzia instruuje ławę przysięgłych, aby brak określonego dowodu traktowała jako element potwierdzający oskarżenie. Tego typu środki podejmuje się w przypadku, gdy sędzia ma podejrzenie, że dowody zostały celowo zniszczone lub ukryte.
B znesowe powody ochrony danych
|
709
Jednak przestój może również wiązać się z utratą okazji do dochodu, co może mieć równie niekorzystne, choć trudniejsze do oszacowania skutki finansowe. Na przykład klienci, którzy nie mogą zrealizować swoich potrzeb związanych z firmą (na przykład nie są dostępne dane umożliwiające przetwarzanie zamówień), mogą nawiązać kontakt z konkurencją — tymczasowo lub na stałe. Oczywiście, klienci mający z firmą kontakty od wielu lat będą bardziej tolerancyjni od nowych klientów. Przestoje mają również wpływ na wiele innych kosztów, w tym płacowych (czyli firma jest zmuszona wypłacać pracownikom pensje za pracę, której nie mogą wykonać z powodu braku dostępu do danych), a czasem również związanych z koniecznością utworzenia dodatkowych nośników kopii zapasowej. Pracownicy obawiający się o skuteczność centralnych systemów kopii zapasowych mogą samodzielnie tworzyć kopie zapasowe na dysku twardym, taśmach czy innych nośnikach. Przy dużej liczbie tych dodatkowych kopii i drogich nośnikach dodatkowe koszty mogą być znaczące.
Elektroniczny materiał dowodowy Dowody elektroniczne to informacje zapisane elektronicznie wykorzystywane w sprawach sądowych. Na przykład firma może być zmuszona do udostępnienia w procesie sądowym wszystkich e-maili wysłanych przez wskazanego użytkownika lub zawierających określone słowa kluczowe. Na przykład od firmy brokerskiej sąd może zażądać przedstawienia e-maili zawierających słowa kluczowe „obiecuję” lub „gwarantuję”. W Unii Europejskiej mogą pojawić się żądania przedstawienia zgodności z dyrektywą o ochronie danych. Jeśli firma nie jest w stanie uzyskać tych informacji (to znaczy jeśli te informacje nie są dostępne od ręki), koszty ich uzyskania mogą być bardzo duże. Oczywiście forma może przedstawić w sądzie oszacowanie kosztów, sugerując, że są za wysokie, lecz sędzia nie musi przychylić się do wniosku o zwolnienie z obowiązku przedstawienia tych dowodów. Istnieje wiele precedensów w prawodawstwie amerykańskim, gdy tego typu wnioski były odrzucane.
Naruszenia zabezpieczeń Naruszenia zabezpieczeń to rezultat nieautoryzowanego dostępu do informacji organizacji. Podobnie jak w przypadku przestojów koszty naruszenia zabezpieczeń trudno oszacować i są one zależne od rodzaju prowadzonej działalności. Również przepisy określające zakres naruszenia zabezpieczeń są różne w zależności od kraju. W niektórych stanach USA istnieje prawo zmuszające firmy do publicznego ujawniania przypadków naruszenia zabezpieczeń. Dodatkowo, w zależności od typu działalności, firma może podlegać karom za umożliwienie takiego naruszenia. Zakres konsekwencji, które firma może ponosić wskutek umożliwienia naruszenia zabezpieczeń, jest określony w rozdziale „Judicial Remedies, Liability, and Sanctions” („prawne zabezpieczenia, odpowiedzialność i sankcje”) dyrektywy o ochronie danych.
Klasyfikacja danych Nie wszystkie informacje w organizacji mają takie samo znaczenie i nie wolno traktować wszystkich danych tak, jakby były równe. W przeciwnym razie koszty ochrony danych będą bardzo wysokie. Na przykład zależnie od rodzaju działalności kopia archiwalna zamówienia sprzed trzech lat może mieć mniejsze znaczenie niż dane zamówienia sprzed godziny. Wiele firm w sposób nieprzemyślany nowe dane traktuje z punktu widzenia bezpieczeństwa tak samo jak stare, ponosząc te same koszty ich archiwizacji.
710
|
Rozdz ał 24. Ochrona danych
Kluczowym zagadnieniem jest tu odpowiednia klasyfikacja danych na podstawie wieku, statusu prawnego oraz poziomu ochrony. Firmy, które przestrzegają tej zasady, mogą znacząco zredukować koszty utrzymania (TCO) swoich zasobów składowania.
Udoskonalanie poziomu usług Co ochrona danych ma wspólnego z poziomem usług biznesowych? A dokładniej: w jaki sposób lepsza ochrona danych pozwoli organizacji udoskonalić ten poziom? Ten problem sprowadza się do odwiecznego dylematu: dostępność a poziom bezpieczeństwa. Im bardziej dostępna jest informacja, tym większa jest potencjalna korzyść biznesowa. Jednakże im więcej użytkowników ma dostęp do informacji, tym większe zagrożenie, że jakaś osoba zechce uzyskać informacje, do których nie powinna mieć dostępu. Firmy, które w sposób szczególny blokują dostęp do informacji o znaczeniu krytycznym dla firmy, ryzykują utratę produktywności. Główne wyzwanie polega tu na tym, aby ustalić zadowalający kompromis między dostępnością a bezpieczeństwem danych.
Techniczne uzasadnienie ochrony danych Jak wspomniałem, ochrona danych dotyczy ich bezpieczeństwa (ochrony przed przypadkowym lub celowym usunięciem, uszkodzeniem lub błędną obsługą), dostępności (dla autoryzowanych użytkowników, działów i partnerów zewnętrznych) i zgodności (z wewnętrznymi zaleceniami organizacji, jak również prawem). Wspomniałem tez, że zapewnienie tych poziomów ochrony to często dość skomplikowane wyzwanie. Z technicznego punktu widzenia problem jest nie mniej skomplikowany. Od awarii dysku twardego poprzez utracone lub skradzione nośniki po zagrożenia związane z sieciami komputerowymi.
Problemy sprzętowe Wiele technologicznych przyczyn stosowania ochrony danych wynika z różnic między urządzeniami używanymi do przechowywania danych. Każde nowe urządzenie zwiększa ryzyko ataku.
Awarie dysków Dyski fizyczne (lub woluminy dyskowe) mogą się psuć z wielu powodów. Średni czas między awariami określany przez producentów sprzętu jest dość wysoki, szczególnie jeśli chodzi o bardziej kosztowne dyski twarde, ale na trwałość tych urządzeń wpływ mają też inne czynniki, jak sposób użytkowania i warunki środowiska. Awarie dysków mogą również wynikać z czynników zewnętrznych, takich jak pożary i inne klęski żywiołowe, akty terroryzmu czy wandalizmu.
Nośniki taśmowe — zużycie, kradzież, zagubienie Dane na taśmie są zapisywane w sposób sekwencyjny, nie dowolny, jak to ma miejsce w przypadku dysków twardych. Z tego powodu zarówno napęd, jak i sama taśma mogą dość intensywnie się zużywać z powodu częstych operacji zapisu i odczytu. Nośniki taśmowe są podatne na czynniki środowiska, jak wilgotność i temperatura. Techn czne uzasadn en e ochrony danych
|
711
Dane są najczęściej zapisywane na taśmach w nieszyfrowanym formacie (np. tar), przez co jest możliwe, że w przypadku przejęcia nośnika przez nieautoryzowanych użytkowników dane te mogą być odczytane bez przeszkód, co może skutkować ujawnieniem własności intelektualnej i informacji osobistych klientów firmy. Z tego powodu duże znaczenie ma solidne fizyczne zabezpieczenie tych nośników kopii zapasowych.
Zagrożenia nośników sieciowych Sieciowe systemy składowania są dostępne w dwóch podstawowych typach: storage area network (SAN) oraz network-attached storage (NAS). Te popularne rozwiązania mają oczywiście zalety, ale również istotne wady. Z jednej strony sieciowe systemy składowania zwiększają dostępność danych i usprawniają zarządzanie nimi, z drugiej mogą powodować dodatkowe zagrożenia ze strony sieci. Przed pojawieniem się koncepcji sieciowych systemów składowania dyski twarde (najczęściej ATA lub SCSI) były przyłączane bezpośrednio do serwerów, które z kolei były przyłączone do środowiska sieci lokalnej LAN. Obecnie tę formę zasobów składowania określa się mianem direct-attached storage, w skrócie DAS. W przypadku rozwiązań DAS jedyny sposób uzyskania dostępu do danych polegał na włamaniu się do serwera, w którym zainstalowany był dysk twardy. Dopóki serwery były odizolowane od potencjalnego włamywacza, organizacje mogły podejmować próby określania poziomów zabezpieczeń w sieci LAN w zależności od wymagań. W środowisku sieciowych systemów składowania sytuacja jest już inna. Możliwe jest, w zależności od konfiguracji i poziomu bezpieczeństwa w sieci składowania, aby kilka hostów miało dostęp do zasobu, co może umożliwić włamanie do wszystkich zasobów składowania dzięki włamaniu do jednego serwera. Innymi słowy, nie trzeba włamywać się do wszystkich serwerów, aby przejąć wszystkie dane. Dostęp do zasobów jest przyznawany z zastosowaniem różnych protokołów sieciowych, takich jak uniksowy NFS, windowsowy Common Internet File System (CIFS), Fibre Channel i sieciowy (oparty na protokole TCP/IP) protokół iSCSI. Włamywacz, w zależności od strategii, może atakować serwery, może też atakować bezpośrednio same urządzenia składowania sieciowego. W przypadku uzyskania dostępu włamywacz może wprowadzić zmiany w zasobach, aby wywołać zamieszanie w organizacji, na przykład zablokować dostęp do usług zapewniających dane. W pewnym momencie nie ma dostępu do danych i nikt nie ma pojęcia, co się stało.
Poczta też bywa krytycznie ważna Byłem administratorem serwerów poczty elektronicznej firmy medycznej i ostrzegłem administratorów systemu, że konieczne jest wykonywanie kopii zapasowych niektórych zasobów pocztowych z większą częstotliwością niż dotychczas lub umieszczenie tych zasobów na macierzy RAID dla zwiększenia bezpieczeństwa danych. Zostałem odesłany z kwitkiem. Około miesiąca później zasoby pocztowe prezesa, szefa IT, szefa finansów i właściciela firmy zostały nieodwracalnie uszkodzone z powodu awarii dysku twardego. Mnóstwo pracy ze strony wszystkich zainteresowanych zajęło odtworzenie danych na tyle, aby firma nie straciła transakcji wartej kilka milionów dolarów (dla 50-osobowej firmy to była duża transakcja). Po tym zdarzeniu samodzielnie skonfigurowałem napęd RAID i umieściłem na nim zasoby pocztowe prezesa i właściciela firmy. Administrator kopii zapasowych zaczął czytać dzienne raporty z systemów kopii zapasowych informujące o tym, co zostało wykonane prawidłowo, a co nie. Wcześniej oczywiście również dostawał te raporty, ale automatycznie wyrzucał je do kosza. — Scott Boss
712
|
Rozdz ał 24. Ochrona danych
Zagrożenia zewnętrzne Oprócz zagrożeń związanych ze specyfiką zastosowanych urządzeń istnieją zagrożenia powodowane przez ludzi, którzy używają tych urządzeń lub mają do nich dostęp. Dotyczy to również wirusów, robaków, koni trojańskich oraz oczywiście celowego lub przypadkowego usunięcia plików.
Wirusy Dobrym punktem wyjścia jest definicja wirusa zaproponowana przez firmę Microsoft. Brzmi ona: „[wirus to] fragment kodu przyłączający się do programu lub pliku w celu rozprzestrzeniania się między komputerami, zarażając [oprogramowanie, sprzęt i pliki] w ramach tego rozprzestrzeniania”.
Robaki Robak, podobnie jak wirus, jest zaprojektowany w taki sposób, że kopiuje swój kod z jednego komputera na drugi, ale w przeciwieństwie do wirusa robi to w sposób automatyczny, przejmując kontrolę nad komputerem w celu transmisji plików i informacji. Gdy w systemie znajdzie się robak, może się rozprzestrzeniać samoistnie. Nie musi przyczepiać się do plików lub programów. Robaki mogą być niebezpieczne, ponieważ często potrafią rozprzestrzeniać się, wykorzystując pocztowe książki adresowe. Wynik takiego działania może być niszczący choćby ze względu na utrudnienia w korzystaniu z sieci przeciążonej w efekcie dodatkowego ruchu sieciowego.
Konie trojańskie Konie trojańskie, podobnie jak mitologiczny koń podstępem wprowadzony za mury Troi, działają na zasadzie socjotechniki. Użytkownika wprowadza się w błąd, że otrzymuje atrakcyjny podarunek, najczęściej w postaci załącznika w poczcie elektronicznej. Może to być fałszywa aktualizacja bezpieczeństwa lub inne ważne (lub interesujące) informacje. W rzeczywistości użytkownik, usiłując uruchomić taki plik, instaluje w swoim systemie wirusy, których zadaniem jest unieszkodliwienie oprogramowania antywirusowego i zapory sieciowej. Niezależnie od tego, czy zagrożeniem jest wirus, robak czy koń trojański, bardzo ważne jest, aby organizacje zabezpieczały się przed atakami tego typu. Gdy już tego typu szkodniki dostaną się do sieci, bardzo trudno jest je zlikwidować i przywrócić system do idealnego stanu.
Przypadkowe usunięcie Nie wszystkie firmy to przyznają, ale przypadki omyłkowego usunięcia ważnych danych są dość częstą przyczyną problemów. Tego typu sytuacje dotyczą przypadkowego usunięcia pojedynczych plików, całych systemów lub użytkowników z konfiguracji sieciowej. Jedyne rozwiązane w takich sytuacjach polega na odzyskaniu kopii takich danych z archiwum lub wykonanej wcześniej migawki.
Techn czne uzasadn en e ochrony danych
|
713
Celowe usunięcie Niektóre dane zostają usunięte w efekcie działania osób o złych intencjach. Kilka lat temu doszło do dość poważnego incydentu, gdy jeden z pracowników firmy usunął wszystkie pliki ze wszystkich serwerów i stacji roboczych w dużej instytucji finansowej, a wszystko to dlatego, że nie otrzymał podwyżki. Dobry system ochrony danych mógł wykryć taką próbę i zabezpieczyć się przed tym. W najgorszym razie dobry system ochrony danych byłby w stanie odtworzyć dane utracone w taki sposób.
Kopie zapasowe a archiwa danych Dwa najważniejsze elementy ochrony danych to wykonywanie kopii zapasowych i archiwizacja. Te pojęcia są powiązane, ale jednak znacząco się różnią. Kopia zapasowa to kopia danych z jednego miejsca umieszczona w innym na wypadek uszkodzenia lub utraty oryginału. Archiwizacja polega na skopiowaniu lub przeniesieniu danych na nośnik o przedłużonym okresie przechowywania w celu szybkiego odzyskania danych dla specyficznych potrzeb biznesowych. Poniższe porównanie kopii zapasowych i archiwizacji pozwoli lepiej zrozumieć różnice między nimi: Kopia zapasowa tworzy drugorzędną kopię pierwszorzędnych danych. Zadaniem kopii zapasowej jest umożliwienie odzyskania oryginalnych danych w przypadku uszkodzenia, usunięcia lub zniszczenia. Archiwum jest pierwszorzędną kopią drugorzędnych danych. To kopia ważnych danych, ale nie na tyle istotnych, aby były zapisane na głównym nośniku składowania. Dotyczy to starych danych przeniesionych do drugorzędnego zasobu w celu oszczędzenia miejsca, jak również drugorzędnych kopii pierwszorzędnych danych, tworzonych na drugoplanowe potrzeby, na przykład na potrzeby wyszukiwania zawartości. Kopie zapasowe pozwalają odzyskać dane zniszczone, usunięte lub uszkodzone. To jest jedyny cel wykonywania kopii zapasowych. Jeśli plik został usunięty lub jest uszkodzony, można go odzyskać z kopii zapasowej. Warto zauważyć, że aby móc odtworzyć dane, należy znać lokalizację kopii pliku i mieć dostęp do aplikacji, która posłużyła do wykonania kopii. Archiwa odczytują kopie danych z drugorzędnych zasobów składowania. Określenia: „odtwarzać” (restore), „przywracać” (recover) i „odczytywać” (retrieve) z reguły mogą być używane zamiennie, lecz w przypadku kopii zapasowych i archiwów mają własne, niezależne znaczenia. Odtwarzanie i przywracanie odnoszą się do odzyskiwania danych z kopii i zapisywania ich w oryginalnej lokalizacji, a odczytywanie danych z archiwów odbywa się bezpośrednio z alternatywnego zasobu. Z tego powodu z kopii zapasowych przywraca się lub odtwarza, a z archiwów odczytuje. Z archiwów dane odczytuje się w sposób odmienny od sposobu ich zapisu. Wiele aplikacji tworzy wiele niepowiązanych wzajemnie informacji zapisywanych w plikach, e-mailach i bazach danych. Niewiele aplikacji potrafi przeszukiwać informacje zapisane w wielu różnych aplikacjach, typach plików i różnych punktach czasu, ale nowoczesne aplikacje archiwizujące służą właśnie do takich celów. Dynamiczny system archiwizujący, na przykład system poczty elektronicznej, potrafi monitorować i archiwizować wszystkie przychodzące i wychodzące e-maile, pozwalając użytkownikowi wyszukiwać treści 714
|
Rozdz ał 24. Ochrona danych
w wielu e-mailach, na wielu serwerach i w różnych punktach czasu. Niektóre systemy plików potrafią realizować analogiczne funkcje w stosunku do plików. Innymi słowy, z archiwów dane odczytuje się w inny sposób, niż zostały zapisane. Kopie zapasowe są przechowywane przez okres dostosowany do cyklu życia zapisanych w nich danych. Kopie zapasowe muszą być zapisane tylko tak długo, jak długo są potrzebne zapisane w nich dane. Ten okres jest uzależniony od wzorca wykorzystania danych. Niektóre dane są potrzebne tylko raz na kwartał, ich kopie należy zatem przechowywać przez okres dłuższy niż kwartalny. Jeśli plik jest odczytywany raz na kwartał, a jego kopia jest przechowywana tylko miesiąc, nie ma możliwości odzyskania pliku usuniętego trzy miesiące temu. Archiwa są przechowywane przez całe lata, a nawet dekady. Czasem archiwa zawierają informacje, które zostały usunięte z głównego zasobu i zarchiwizowane, na wypadek gdyby były jeszcze potrzebne. Na przykład mogą to być plany projektowe produktu, który już nie jest wytwarzany. W zależności od polityki utrzymania danych może być wymagana decyzja o usunięciu tego typu danych z archiwum. Czasem archiwa zawierają dane, których minimalny okres przechowywania określa prawo. W efekcie dane mogą być przechowywane w archiwach przez okres wielu lat, a nawet dekad.
Dokumentacja zmian W dużej firmie naftowej, przed wakacjami, operator kopii zapasowych zdecydował się zmienić typ kopii zapasowej z pełnej na przyrostową, ponieważ założył, że przez okres wakacji dane nie będą się znacząco zmieniały. Administrator szybko zapomniał o wprowadzonej zmianie. Trzy miesiące później, gdy trzeba było odzyskać dane z kopii, okazało się, że dane trzeba odtwarzać z całych ostatnich trzech miesięcy, a do tego ze wszystkich kopii przyrostowych. — David Bregman
Co należy kopiować? W środowisku korporacyjnym należy kopiować praktycznie wszystko. Ważniejszym pytaniem jest: co może być odtwarzane i jak szybko należy to odtwarzać? Jak wspomniałem w poprzednim podrozdziale, należy określić wymagania, jeśli chodzi o odtwarzanie każdego typu danych w firmie. Podstawowym celem wykonywania kopii zapasowych jest umożliwienie dostępu do danych w przypadku usunięcia lub uszkodzenia danych podstawowych. W firmach dane objęte wykonywaniem kopii zapasowych dzieli się na trzy rodzaje: Własność intelektualna Tego typu informacje zawierają wszelkie osiągnięcia firmy. W przypadku firmy biochemicznej mogą to być dane z procesu badań, dla firmy badającej rynki będą to bazy danych statystyk rynkowych. Dane klientów Przykłady danych tego typu to elektroniczne kopie zdjęć rentgenowskich pacjenta, informacje uzyskane w wyniku badań rynkowych i zapisy z analiz tendencji zakupowych w poszczególnych segmentach rynku. Dane te mogą być również wykorzystywane do kradzieży tożsamości, to znaczy takich danych, jak adres klienta, jego data urodzenia i numer identyfikacyjny. Co należy kop ować?
|
715
Dane operacyjne Ta ostatnia kategoria zawiera wszelkie typy danych dostępnych w organizacji. Może obejmować dane o źródłach materiałów niezbędnych do wytwarzania produktów, jak również dane firm dostarczających produkty do klientów. Do tej kategorii należą informacje płacowe i księgowe, wszelkie typy informacji na temat własności intelektualnej oraz informacje osobowe klientów.
Co należy archiwizować? Oprócz wykonywania kopii zapasowych danych organizacje muszą wypracować strategię archiwizacji danych. Oba te zagadnienia stanowią integralne elementy efektywnej strategii i wymagają zrozumienia biznesowej wartości danych (archiwizacja danych może pod tym względem mieć większe znaczenie od kopii zapasowych). Archiwizacja wykonywana prawidłowo może skutkować oszczędnościami, może też stanowić zabezpieczenie, szczególnie w przypadku, gdy ze względów prawnych lub na potrzeby audytów niezbędny jest dostęp do informacji historycznych. Jeśli jednak archiwizacja jest wykonywana w sposób nieprawidłowy, może to narazić firmę na znaczne straty związane z obniżeniem dochodów, karami i dodatkowymi wydatkami. Problem polega na tym, że wiele organizacji niewłaściwie traktuje archiwizację i kopie zapasowe jako tę samą kategorię problemów. Niezrozumienie zagadnień archiwizacji często jest winą dostawców rozwiązań do wykonywania kopii zapasowych, którzy twierdzą, że ich produkty mają możliwości archiwizacyjne. Często bywa tak, że te możliwości polegają po prostu na wykonywaniu kopii zapasowych i usuwaniu danych z ich pierwotnego położenia. To nie jest archiwizacja. Produkty do obsługi kopii zapasowych oferują różne poziomy możliwości „archiwizacyjnych”. Niektórzy dostawcy traktują archiwizację po prostu jako kopię zapasową, po której wykonaniu dane usuwa się z pierwotnego nośnika. Ten typ archiwizacji służy przede wszystkim do usuwania starych danych zaśmiecających serwery. Taki problem najlepiej jest rozwiązać przez zastosowanie technik zarządzania zasobami składowania (storage resource management, SRM) lub hierarchicznego zarządzania zasobami składowania (hierarchical storage management, HSM). Czym zatem jest archiwizacja i w jaki sposób wpasować ją w politykę ochrony danych? Archiwizacja jest długoterminowym składowaniem informacji na potrzeby odczytywania logicznych elementów dla specyficznych celów biznesowych. Kopie zapasowe natomiast służą do zabezpieczania danych przed utratą w krótszym okresie, na przykład w wyniku ich usunięcia, uszkodzenia lub awarii urządzenia. Kandydatami do archiwizacji danych są m.in. okresowe informacje finansowe tworzone na potrzeby audytów, informacje medyczne dotyczące pacjentów gromadzone przez ustalony okres ze względów prawnych i dane badań klinicznych nowych leków gromadzone na potrzeby certyfikacji. Dalsze przykłady to poczta elektroniczna i zapis innych rodzajów komunikacji elektronicznej, które także mogą być wymagane w czasie audytu. Długoterminowa natura archiwizacji danych jest przyczyną dodatkowych komplikacji.
716
|
Rozdz ał 24. Ochrona danych
Zgodność wstecz Taśmy i napędy optyczne z reguły nie potrafią czytać nośników starszych niż dwie generacje wstecz, dlatego organizacje muszą zastosować określoną strategię długoterminowego dostępu do danych archiwalnych w przypadku danych zapisanych na taśmach. Dane mogą być przenoszone na nowe nośniki w przypadku zmiany sprzętu, ale niekiedy zmiana nośnika może wiązać się z koniecznością ponownej rejestracji archiwum, na przykład gdy zakres archiwalnych danych jest objęty ścisłą kontrolą. Żywotność nośników Jeśli dane muszą być dostępne przez dłuższy czas na taśmie lub nośniku optycznym, należy zapewnić odpowiednią żywotność nośników. Należy tu uwzględnić również kontrolę środowiska przechowywania oraz ewentualne odświeżanie nośników. Czytelność i użyteczność danych po odtworzeniu Dane archiwalne muszą być „przenośne”. Nie mogą być uzależnione od przestarzałej wersji oprogramowania lub platformy systemowej. Dla celów archiwizacji i wykonywania kopii zapasowych krytycznym czynnikiem jest odpowiednie zrozumienie korporacyjnej wartości zabezpieczanych danych. Decyzja, jakie dane muszą być archiwizowane, jest kluczowa dla procesu zarządzania zasobem. Tego typu system klasyfikacji danych może rozwinąć się do inteligentnego zarządzania zarówno zasobami pierwszorzędnymi (na dysku twardym), jak i drugorzędnymi (kopie zapasowe i archiwa).
Przykłady kopii zapasowych i archiwów Następujące dwa przykłady ilustrują różnice między zarchiwizowaną informacją a informacją zapisaną w kopii zapasowej. Przechowywanie kopii zapasowych przez wiele lat nie powoduje, że stają się archiwami. Są po prostu kopiami zapasowymi przechowywanymi przez dłuższy okres. Weźmy za przykład fikcyjną firmę WingsRUs, producenta samolotów. Firma ta ma szczegółowe dane na temat nowego modelu samolotu, WingsRUs 563. Dane te zawierają krytyczne informacje marketingowe, szczegółowe specyfikacje techniczne, faktury za materiały, plany i wyniki testów, informacje dotyczące państwowych inspekcji technicznych oraz informacje o klientach. Dane są zapisane w różnych bazach danych na różnych serwerach i w różnych lokalizacjach. Kopie zapasowe w firmie WingsRUs są wykonywane regularnie z wykorzystaniem tradycyjnych aplikacji. Gdy firma zaczyna produkcję kolejnego modelu, WingsRUs 565, zostaje podjęta decyzja, że dane zapasowe dotyczące modelu 563 nie muszą już być przechowywane. W to miejsce będą zapisywane kopie zapasowe danych dotyczących modelu 565, który w tym momencie stanowi najważniejszy projekt dla firmy. Firma zdecydowała się zachować większość danych modelu 563 na wypadek problemów z nim. Instytucje państwowe mogą w przyszłości zażądać szczegółowych specyfikacji, wyników testów czy innych kluczowych danych. WingsRUs przenosi kopie zapasowe danych modelu 563 na system archiwizujący, dzięki czemu możliwy jest dostęp do tych informacji w sposób efektywny kosztowo. Jeśli dane zostaną zarchiwizowane w sposób prawidłowy, firma powinna mieć możliwość odczytania starych planów nawet bez świadomości, na którym serwerze, na jakim systemie plików i w jakim systemie operacyjnym są zapisane. Przykłady kop zapasowych arch wów
|
717
Amerykańska firma finansowa komunikuje się z klientami głównie za pośrednictwem poczty elektronicznej. Po uzyskaniu informacji o tym, że ta firma „obiecuje” określone zwroty z inwestycji, komisja Securities and Exchange Commission podjęła stosowne śledztwo. Na początku zażądano wszystkich wiadomości e-mail wysłanych w okresie ostatnich dwóch lat zawierających słowa kluczowe „promise” i „guarantee”. Bez systemu archiwizacji poczty elektronicznej tego typu żądanie byłoby trudne do spełnienia. Gdyby firma wykonywała dzienne kopie zapasowe swojego systemu poczty elektronicznej w okresie ostatnich dwóch lat, konieczne byłoby odzyskanie 730 (365 dni w roku przez 2 lata) wersji bazy danych serwera poczty Exchange Server i przeszukanie wszystkich pod kątem występowania w nich danych słów kluczowych. Jeśli jednak poczta była na bieżąco zapisywana w archiwum, wystarczyło po prostu przeszukać wszystkie wiadomości wysłane w ciągu ostatnich dwóch lat, co pozwoliłoby uzyskać wynik praktycznie natychmiast.
Czy oprogramowanie open source nadaje się do poważnych zadań? Informacje elektroniczne są zapisywane na wiele różnych sposobów; niektóre z nich wymagają szczególnego traktowania w czasie procesu wykonywania kopii zapasowych. Zlekceważenie tych szczególnych wymagań może doprowadzić do następujących konsekwencji: • znaczącego obniżenia wydajności wykonywania kopii zapasowych, • jeszcze większego obniżenia wydajności procesu odtwarzania tych kopii, • niemożliwości pełnego odtworzenia systemu.
Sposób traktowania informacji jest uzależniony od sposobu ich składowania. Standardowy i najbardziej powszechny sposób polega na zapisaniu informacji w pliku w systemie plików. Najbardziej typowym systemem plików jest C:\ w systemach Windows i / w Uniksach. Większość produktów do wykonywania kopii zapasowych bez problemów radzi sobie z klasycznymi plikami, ale niektóre systemy plików i typy danych mogą przysparzać im problemów i muszą być traktowane w szczególny sposób. Na przykład: • bardzo aktywne systemy plików, • systemy plików zawierające duże ilości danych (powyżej 1 TB), • systemy plików zawierające miliony pików, • informacje zapisane w bazach danych, • metadane niezapisane w systemie plików lub bazie danych, • struktury dowiązań i pliki urządzeń, • informacje zapisane w systemach plików urządzeń NAS, • informacje zapisane w systemach plików urządzeń SAN.
Większość komercyjnych produktów do wykonywania kopii zapasowych ma dodatkowe funkcje uwzględniające te przypadki szczególne, często za dodatkową opłatą. W tym podrozdziale przeanalizuję, na ile produkty open source radzą sobie z wyzwaniami tego typu.
718
|
Rozdz ał 24. Ochrona danych
Bardzo aktywne systemy plików Podstawowym założeniem tradycyjnego systemu do wykonywania kopii zapasowych jest to, że plik nie zmienia się w czasie wykonywania kopii. W przeszłości na czas wykonywania kopii zapasowej administratorzy przełączali serwery w tryb jednego użytkownika, co gwarantowało, że pliki nie będą się zmieniać w trakcie wykonywania kopii. Obecnie administratorzy rzadko mają taki komfort, aby zatrzymać działanie serwerów, zatem twórcy oprogramowania opracowali techniki pozwalające wykonywać kopie zapasowe plików tych typów. Stale zmieniające się pliki stanowią dodatkowe wyzwanie dla aplikacji wykonujących i odtwarzających kopie zapasowe; nawet komercyjne produkty nie zawsze radzą sobie zadowalająco z tego typu problemami. Dodatkowo w niektórych systemach plików aplikacje mają możliwość zablokowania plików do wyłącznego użytku, co uniemożliwia wykonanie kopii zapasowej nawet specjalizowanym programom. Jeśli plik zmienia się bardzo dynamicznie lub w okresie wykonywania kopii zapasowej jest zablokowany, komercyjne systemy wykorzystują techniki wykonywania migawek, których zadaniem jest zapewnienie spójności wykonanej kopii. Technologia migawek pozwala wykorzystać statyczny obraz systemu plików na potrzeby wykonania kopii. Jeśli taki problem wystąpi w środowisku Windows, należy zweryfikować, jak stosowane rozwiązanie open source integruje się z tym systemem operacyjnym. Jeśli ten problem wystąpi w systemie Unix lub Macintosh, problem może być niemożliwy do rozwiązania bez zastosowania produktu komercyjnego.
Duże ilości danych Systemy plików zawierających dane o dużym rozmiarze to kolejne wyzwanie dla oprogramowania wykonującego kopie zapasowe. Tradycyjne programy wykonujące kopie zapasowe są oparte na technikach wykorzystujących system plików, przez co każdy system plików czy napęd jest kopiowany w osobnej procedurze. Ta metoda działa zadowalająco w przypadku systemów plików o niewielkim rozmiarze, lecz w przypadku systemów plików zawierających powyżej 1 TB danych mogą pojawić się problemy. Problem polega na tym, że prędkość zapisu najszybszego napędu taśmowego wynosi około 200 MB/s (przy zapisie). Jeśli strumień danych udałoby się dostarczać z tą prędkością, system plików zawierający 1 TB danych zapisywałby się około dwóch godzin. Problem polega na tym, że z reguły nie ma możliwości uzyskania tak dużej prędkości przesyłania danych, przez co kopia zapasowa zapisuje się o wiele wolniej. W przypadku wystąpienia problemu tego typu warto wziąć pod uwagę prawie ciągłą ochronę danych (ang. near-continuous data protection). Tego typu ochrona danych wykorzystuje techniki replikacji w celu utrzymania kopii zapasowej. Modyfikacje danych rzadko odbywają się w sposób masowy, zatem do wykonania kopii zapasowej wykorzystywane są znacznie mniejsze zasoby systemu. Tego typu techniki działają na poziomie dysku, zatem odtworzenie takiej kopii zapasowej odbywa się zawsze tak szybko, jak szybko działa sprzęt. Więcej informacji na temat rozwiązań prawie ciągłej ochrony danych na licencji open source można znaleźć w rozdziale 7.
Czy oprogramowan e open source nadaje s ę do poważnych zadań?
|
719
Duża liczba plików Systemy plików zawierające dużą liczbę plików to również dość poważne wyzwanie dla oprogramowania wykonującego kopie zapasowe. W rzeczywistości system plików o pojemności 1 GB zawierający pięć milionów plików będzie tak samo problematyczny jak system plików o pojemności 1 GB zawierający kilka tysięcy plików. Dlaczego tak się dzieje? Z powodu dużej liczby operacji wykonywanych podczas wykonywania i odtwarzania kopii zapasowych. Przy odtwarzaniu danych z kopii problem jeszcze się pogarsza, ponieważ to zadanie wymaga wykonania większej liczby czynności. Aplikacja odtwarzająca kopię zapasową musi w pierwszej kolejności poinformować system operacyjny, że musi utworzyć plik, następnie musi otworzyć ten plik do zapisu, po czym zapisać w nim jego zawartość. Po odtworzeniu zawartości weryfikowana jest poprawność zapisanego pliku i jego zgodność z kopią zapasową. Każda z tych operacji zajmuje sporo czasu, a ponieważ są wykonywane sekwencyjnie, mogą znacząco spowolnić procedurę odtwarzania kopii zapasowej. Niewielkie znaczenie ma tu prędkość odczytu urządzenia zawierającego kopię. Najszybszy dysk twardy czy napęd taśmowy nie wykorzysta swojej teoretycznej prędkości przy tak dużej liczbie operacji systemowych związanych z odtwarzaniem ogromnej liczby niewielkich plików. Alternatywny sposób wykonywania i odtwarzania kopii zapasowych wykorzystuje technikę obrazów (ang. image), która pomija mechanizmy systemu plików i wykonuje kopię dysku na poziomie bloków fizycznych. Niestety, wszystkie znane mi narzędzia open source tego typu wymagają domontowania systemu plików. Jeśli to ograniczenie jest nie do przyjęcia, należy rozważyć zastosowanie produktu komercyjnego.
Informacje zapisane w bazach danych Informacje z baz danych mogą być trudne do kopiowania z powodu sposobu ich zapisu, zmiennej natury baz danych oraz wymogów związanych z odtwarzaniem danych. Bazy danych z reguły zapisują dane w plikach, ale niektóre bazy potrafią zapisywać dane w postaci „surowej” bezpośrednio na dysku. Zapisywanie danych w postaci surowej często pozwala osiągnąć optymalną wydajność, ale z reguły znacznie komplikuje proces wykonywania kopii zapasowych. Pliki danych ciągle są modyfikowane, dlatego główne wyzwanie polega na tym, aby stworzyć spójną kopię zapasową całego obrazu danych w bazie. Zastosowanie tu ma szereg technik, w tym zimne kopie zapasowe, kopie gorące oparte na skryptach i techniki wykorzystujące wbudowane funkcje baz danych. Zimna kopia bazy danych jest wykonywana na wyłączonej bazie. Kopie gorące oparte na skryptach ustawiają silnik bazy danych w specjalnym trybie kopii zapasowej, pozwalając na skopiowanie plików danych za pomocą klasycznego programu do wykonywania kopii. Każda z tych metod działa zadowalająco z zastosowaniem narzędzi opisanych w tej książce. W czasie pisania tej książki żadne ze znanych mi narzędzi do wykonywania kopii nie wykorzystywało wbudowanych mechanizmów baz danych. Jednak wiele baz danych ma mechanizmy wykonujące kopie zapasowe na dysku bez udziału zewnętrznych narzędzi. Przykładem może tu być polecenie rman bazy Oracle, dump database znane z baz Oracle i Microsoft SQL Server czy wtyczka ntbackup do serwera Exchange. Wszystkie te narzędzia pozwalają na wykonywanie kopii
720
|
Rozdz ał 24. Ochrona danych
zapasowej bazy danych bez konieczności przerywania jej działania. Plik zapisany za pomocą tych narzędzi może być zapisany na nośniku kopii zapasowej z zastosowaniem tradycyjnych narzędzi. W przypadku baz danych wymagania dotyczące odtwarzania danych z kopii są z reguły bardziej restrykcyjne niż w przypadku innych typów informacji. W przypadku pliku procesora tekstów dopuszczalne może być, że kopia zostanie odtworzona w wersji z poprzedniej nocy, lecz w przypadku baz danych niedopuszczalne jest odtworzenie danych sprzed kilku godzin. Bazy danych wykorzystują dzienniki transakcyjne zapisujące zmiany wprowadzane w bazie pomiędzy cyklami wykonywania kopii zapasowych. Prawidłowa kopia zapasowa produkcyjnej bazy danych musi zatem zawierać kopię danych oraz kopię dziennika transakcyjnego.
Informacje zapisane w zasobach współdzielonych Informacje zapisane w zasobach współdzielonych również dodają wymagania stawiane narzędziom do wykonywania i odtwarzania kopii. Istnieją dwa główne typy takich urządzeń: SAN i NAS. Urządzenia SAN są oparte na magistrali SCSI i umożliwiają kilku systemom dostęp blokowy do współdzielonych urządzeń dyskowych lub taśmowych. Urządzenia SAN wykorzystują magistralę SCSI over Fibre Channel lub IP (iSCSI). Urządzenia NAS wykorzystują protokoły NFS lub CIFS, które pozwalają współużytkować pliki w sieciach IP.
Systemy plików urządzeń SAN Niskobudżetowe programy do wykonywania kopi zapasowych opisane w tej książce nie będą traktowały urządzeń SAN inaczej niż jakiekolwiek lokalne systemy plików. Dostępne są produkty komercyjne zoptymalizowane pod kątem kopii zapasowych w urządzeniach SAN.
Systemy plików urządzeń NAS Mimo że oprogramowanie do wykonywania migawek oraz replikacji offsite oferowane przez niektórych dostawców rozwiązań klasy NAS cechuje się doskonałymi możliwościami odtwarzania danych, to nie zwalnia z obowiązku wykonywania kopii zapasowych danych zapisanych na systemach NAS. Wszystkie produkty open source opisane w tej książce poradzą sobie z wykonywaniem kopii zapasowej systemu plików (za pośrednictwem protokołu NFS lub CIFS).
Odtwarzanie danych po katastrofie Opracowanie dobrego planu odtwarzania po katastrofie (disaster recovery, DR) trochę przypomina malowanie mostów w niektórych miastach. Malarze zaczynają pracę po jednej stronie mostu na jednym brzegu i malują, aż skończą na drugim. Następnie zaczynają malować drugą stronę mostu, aż zakończą na pierwszym brzegu. Prawie natychmiast zaczynają malować pierwszą stronę mostu i tak dalej, praktycznie bez końca. Właśnie w taki sposób powinno się budować plan DR. Należy zacząć od zera i dopracowanie go do perfekcji może zająć całe miesiące. W tym momencie należy zacząć od nowa. Środowiska komputerowe nieustannie się zmieniają, zatem należy ciągle analizować i modyfikować plany, aby działały jak należy.
Odtwarzan e danych po katastrof e
|
721
Ten podrozdział nie ma być wyczerpującym podręcznikiem planowania procedury odtwarzania systemu po katastrofie. Istnieją całe książki poświęcone tylko tej tematyce i zanim Czytelnik podejmie się opracowania pierwszego w swoim życiu planu odtwarzania po katastrofie, zalecam głębsze przestudiowanie tej tematyki. Ta część rozdziału przedstawia jedynie przegląd zagadnień niezbędnych do realizacji tego typu planu oraz kilka szczegółów, które trudno znaleźć w innych książkach.
Wszystko zaczyna się od biznesu Projekt systemu odtwarzania po katastrofie powinien być skoncentrowany na przywróceniu funkcjom biznesowym dostępu do informacji niezbędnych do prowadzenia typowej działalności, bez udostępniania tych informacji nieuprawnionym odbiorcom. Dane nie są chronione, jeśli jest to szkolny projekt albo interesujące hobby. Chronimy dane, ponieważ w przypadku ich utraty prowadzenie działań biznesowych może być zagrożone. Z tego powodu jako punkt wyjścia planu należy przyjąć biznes.
Definicja podstawowej funkcji organizacji Przy analizie ochrony danych należy zadać sobie następujące pytanie: „Jakie są najważniejsze produkty i usługi oferowanie przez tę organizację?”. Następnym ważnym pytaniem jest: „Jaka informacja jest niezbędna, aby móc oferować ten kluczowy produkt lub usługę, i jakie aplikacje są konieczne do efektywnego wykorzystania tych informacji?”. Odpowiedź na drugie z tych pytań określa zakres własności intelektualnej (intellectual property, IP) organizacji. Pozbawiona tych systemów informacyjnych organizacja nie może funkcjonować. Wiele typów informacji można zakwalifikować jako IP. Może to być „sekretny przepis”, który stanowi klucz do unikalności produktu lub usługi firmy. Oczywiście bez klientów ten przepis jest niewiele wart. Z tego powodu dane kontaktowe klientów również stanowią element IP. Dotyczy to również danych potencjalnych klientów. Jeśli jakieś informacje nie powinny trafić w ręce konkurencji, one również stanowią element IP. Taka szeroka definicja obejmuje informacje wielu typów. Własność intelektualna to kluczowy element systemu informacyjnego, ale nie są to jedyne dane w firmie. Wokół procesu tworzenia i dostarczania produktów i usług istnieje mnóstwo innych, takich jak system zamówień, płacowy, ewidencji środków trwałych, sprzedażowy i wsparcia klientów. Każdy z tych systemów jest ważny dla działania biznesu i każdy do działania wymaga określonych informacji.
Ustalenie priorytetów funkcji biznesowych niezbędnych do realizacji podstawowej funkcji Po zidentyfikowaniu wszelkich własności intelektualnych oraz aplikacji i systemów biznesowych należy ustalić ich priorytety z punktu widzenia realizacji podstawowej funkcji firmy, czyli dostarczania najważniejszych produktów lub usług. Nie chodzi tu tylko o kompetencje, należy również uwzględnić kwestie pilności i krytyczności każdego z tych elementów.
722
|
Rozdz ał 24. Ochrona danych
Aby określić najważniejsze własności intelektualne, należy zrozumieć podstawowe funkcje organizacji. Następnie należy ustalić priorytety ochrony danych oraz plany ich odtwarzania w przypadku utraty dostępu. Jeśli podstawowa funkcja polega na wytwarzaniu produktu, to aby można było kontynuować działalność biznesową, kluczowe są systemy zarządzania produkcją. Inne systemy, jak poczta elektroniczna, mogą być mniej krytyczne dla podstawowej funkcji i nie wymagają ochrony na tym samym, wysokim poziomie. Jednak systemy do komunikacji z klientami mogą być krytyczne i dlatego może okazać się, że jednak poczta elektroniczna powinna być zaliczona do kluczowych systemów. Ważne jest, aby zrozumieć kluczowe elementy systemu informatycznego z punktu widzenia wsparcia podstawowych funkcji biznesowych; nie należy upraszczać sprawy i chronić na tym samym poziomie całej zawartości serwerów.
Powiązanie każdego systemu z funkcją biznesową i priorytetyzacja Jako przykład weźmy dostawcę energii elektrycznej. Jeśli nie dostarczy klientom rozliczenia opłat za energię elektryczną przez kilka tygodni, wielu klientów z pewnością nawet tego nie zauważy, a nawet jeśli, nie przejmie się tym. Wierzyciele firmy z pewnością jednak zauważą brak rozliczeń i z pewnością będą się tym martwić. Nawet wówczas firma może załagodzić sytuację, tłumacząc się przejściowymi problemami. Co się jednak stanie, jeśli firma przez kilka minut przestanie dostarczać energię elektryczną? Informacja na ten temat z pewnością pojawi się w wieczornych wiadomościach, wszyscy biznesowi klienci będą mieli pretensje za straty, które ta przerwa im wyrządziła, klienci indywidualni będą się złościć, że muszą od nowa programować radiobudziki i kuchenki mikrofalowe. Taka sytuacja może również spowodować falę zaniku zasilania na rozległym obszarze, jaka przytrafiła się na początku 21. wieku w USA (tego typu sytuacje dość regularnie przytrafiają się w różnych częściach świata). Z tych rozważań łatwo wywnioskować, że najważniejszą funkcją tej firmy jest dostarczanie energii elektrycznej. Po ustaleniu podstawowych własności intelektualnych i systemów wspierających i wyznaczeniu tych najbardziej krytycznych należy ustalić lokalizację zasobów niezbędnych do ich działania. Czy te informacje są zapisane w bazie danych? Czy są zapisane gdzieś w plikach systemu plików? W większości przypadków dane te będą zapisane w jednym z systemów informatycznych. Każdy komputer i system składowania danych musi zostać przydzielony do funkcji biznesowej na podstawie poziomu krytyczności danej funkcji. W ten sposób systemy uzyskają ten sam priorytet odtwarzania co funkcje biznesowe, do których są przydzielone. Doskonały przykład tego typu priorytetyzacji można znaleźć w publikacjach amerykańskiej Federal Communications Commission (FCC). Publikacja ta (http://www.fcc.gov/webinventory/) definiuje różne typy danych i poziom ich krytyczności. Co interesujące, do najbardziej krytycznych systemów zalicza się tu te, których dane są wymagane przez prawo. Na drugim poziomie krytyczności znajdują się systemy niezbędne do realizacji kluczowych funkcji biznesowych, następnie najczęściej odczytywane dane, a na końcu pozostałe. Większość firm w stosunku do kluczowych funkcji biznesowych stosuje określenie mission critical. W tym przypadku FCC stwierdziła, że bez danych wymaganych przepisami organizacja ta nie będzie mogła realizować swojej misji. Z tego przykładu wynika bardzo istotne spostrzeżenie: każda firma jest inna i nie można skorzystać z gotowych wzorców; priorytety dla każdej organizacji należy określić całkowicie indywidualnie. Wszystko zaczyna s ę od b znesu
|
723
Określenie RPO i RTO dla każdego systemu krytycznego Wymóg czasu odtwarzania (recovery time objective, RTO) określa czas, w którym system powinien zostać odtworzony. Wartość RTO może wynosić od zera do kilku dni, a nawet tygodni. Każda aplikacja obsługuje jakąś funkcję biznesową, należy zatem określić, jak długo firma może radzić sobie bez tej funkcji. Jeśli odpowiedź brzmi: firma nie może funkcjonować bez danej funkcji nawet sekundy, RTO wyniesie zero sekund. Jeśli odpowiedź brzmi: może działać dwa tygodnie, RTO wyniesie dwa tygodnie. Wymóg punktu w czasie (recovery point objective, RPO) określa, ile danych może zostać utraconych w przypadku odtwarzania systemu. Oto dwa przykłady: zamówienia klientów i dzienniki systemowe. Jeśli firma utraci jedno zamówienie klienta, straci określone dochody. Z tego powodu wiele firm stwierdza, że nie mogą stracić żadnych zamówień klientów. Oznacza to zatem, że RPO w przypadku zamówień klientów wynosi w tych firmach zero sekund. Dzienniki systemowe mogą w niektórych firmach być użyteczne jedynie w przypadku usuwania problemów i w trakcie audytów systemowych. Jeśli zostanie utraconych kilka dni z tych dzienników, problem pojawi się jedynie wówczas, gdy niezbędne będzie zidentyfikowanie problemu, który wydarzył się w tym okresie. Jeśli jednak przyjmie się, że pewien okres i tak został utracony (wskutek awarii, która stała się przyczyną odtwarzania tych danych), z pewnością ważniejsze będzie przywrócenie do sprawności systemu przyjmowania zamówień klientów, zatem system dzienników systemowych nie jest aż tak krytyczny dla organizacji. Z tego powodu utrata dzienników systemowych z całego tygodnia nie stanowi zagrożenia dla kluczowych funkcji biznesowych. Oznacza to, że w przypadku dzienników systemowych RPO wynosi tydzień. Po ustaleniu priorytetów odtwarzania systemów i określeniu sytuacji przestojów, przed którymi mają być chronione, należy określić RTO i RPO dla każdego chronionego systemu. Większości klientów nie interesują przyczyny niedostępności systemów, dlatego RTO i RPO powinny mieć tę samą wartość dla większości typowych systemów, z wyjątkiem rozległych katastrof, jak trzęsienie ziemi obejmujące cały region geograficzny. W zależności od poziomu krytyczności większość systemów powinna mieć takie same wartości RTO i RPO dla różnych typów katastrof. W przypadku niektórych systemów można jednak uznać, że większe wartości RPO i RTO są dopuszczalne lub nieuniknione w przypadku niektórych typów katastrof.
Określenie grup integralności Często zdarza się, że niezbędne jest odtwarzanie kilku systemów w tym samym punkcie czasu. Powodują to przede wszystkim aplikacje wymieniające się danymi. Weźmy pod uwagę firmę produkcyjną, w której procesami biznesowymi są sprzedaż i produkcja towarów na zamówienie. W tych procesach mogą być wykorzystywane różne systemy: obsługi klienta, zamówień, zaopatrzenia i produkcji. Jeśli klient zamawia produkt, informacja o tym (w różnej postaci) znajdzie się w każdym z tych systemów. Co się zatem stanie, gdy na przykład został wyprodukowany produkt na zamówienie, a zostały utracone dane jego zamówienia? Lub gdy zamówienie jest dostępne, ale nie wiadomo, którego klienta dotyczy? Co się stanie, jeśli zamówienie zostało przyjęte, ale uszkodziła się baza danych systemu produkcyjnego i produkt nie zostanie wyprodukowany? Każda z tych sytuacji to przykład poważnego problemu integralności. Z tego powodu w przypadku, gdy firma posiada kilka systemów wykonujących powiązane procesy biznesowe, te systemy muszą się znaleźć w grupie integralności (spójności danych).
724
|
Rozdz ał 24. Ochrona danych
Oprócz określenia RTO i RPO należy w przypadku grup integralności ustalić procedury odtwarzania w tym samym punkcie czasu. Ważne jest również, aby zidentyfikować okno integralności, czyli okno czasu, w którym nie wszystkie systemy z grupy integralności są modyfikowane. Jeśli okno integralności jest większe niż okno wykonywania kopii zapasowej lub mu równe, wówczas w przypadku takiej grupy integralności dość łatwo jest zapewnić integralność danych odtwarzanych z kopii. Na przykład okno obejmujące czas od 17:00 do 8:00 obejmuje 15 godzin. Jeśli systemy są nieczynne w godzinach od 17:00 do 8:00 (nie są modyfikowane żadne dane) i w tym okresie jest wykonywana kopia zapasowa, nie będzie miało znaczenia, jeśli kopia zapasowa systemu A zostanie wykonana o 22:00, a systemu B — o 2:00. Dane tych systemów w kopiach nadal będą spójne. Jeśli jednak okno integralności jest za krótkie, aby w jego trakcie wykonać kopie zapasowe wszystkich systemów w grupie integralności, należy zastosować jeden z dwóch środków zapobiegawczych. Jeden z nich polega na utworzeniu okna wykonywania kopii zapasowej dla tych systemów i zapewnieniu, że ta kopia wykona się w tym czasie. Ta opcja jest preferowana, ponieważ nie wprowadza znaczących komplikacji w systemie wykonywania kopii zapasowych. Jeśli okno integralności jest za krótkie, drugie rozwiązanie polega na zastosowaniu mechanizmu wspomagającego system wykonywania kopii zapasowych, takiego jak mechanizm migawek lub business continuance volumes (BCV). Rozwiązania tego typu pozwalają wykonać „wirtualne kopie zapasowe” w bardzo krótkim czasie, po czym systemy wracają do standardowego działania, a wirtualna kopia zapasowa jest kopiowana na rzeczywisty nośnik (na przykład migawka jest kopiowana na taśmę).
Określenie zagrożeń każdego krytycznego systemu Po określeniu priorytetów funkcji biznesowych i przypisaniu systemów do poszczególnych funkcji należy zidentyfikować zagrożenia, które mogą stać się przyczyną wykorzystania scenariusza odtwarzania systemu po katastrofie. „Katastrofa” to dość szerokie pojęcie. Po pierwsze, należy stworzyć listę różnych poziomów katastrof, które mogą wystąpić w danym obszarze biznesowym. Disaster Recovery Institute stwierdza, że każda firma powinna określić własny zbiór poziomów katastrof. Przedstawiam własną definicję dla jednego z systemów, w podziale na poziomy zagrożeń, począwszy od awarii pojedynczego systemu.
Poziom 1. Katastrofy, które mogą wyłączyć jedną aplikację lub jeden serwer: • awaria dysku lub macierzy dyskowej, • wewnętrzny sabotaż korporacyjny, • terroryzm elektroniczny (atak blokady usług), • atak niezadowolonego pracownika.
Poziom 2. Katastrofy, które mogą wyłączyć całe centrum danych: • pożar lub powódź całego budynku, • klęski naturalne (huragan, tornado, trzęsienie ziemi), • skażenie budynku (wyciek substancji trujących),
Wszystko zaczyna s ę od b znesu
|
725
• terroryzm fizyczny (bomba), • desperacki atak niezadowolonego pracownika, • utrata łącza internetowego, • utrata zasilania elektrycznego.
Poziom 3. Katastrofy odcinające całe miasteczko akademickie, miasto lub region geograficzny: • zagrożenia naturalne o dużej skali, • terroryzm fizyczny (bomba w elektrowni), • działania wojenne.
Określenie kosztów przestoju Po określeniu wszystkich możliwych typów katastrof i prawdopodobieństwa ich wystąpienia należy określić koszt, który firma poniesie w wyniku katastrofy w przypadku każdego z tych systemów. Na przykład, jeśli pożar dosięgnie serwer testowy i awaria potrwa tydzień, koszt dla firmy może być bliski zeru (pomijając koszt sprzętu). Jeśli jednak pożar ogarnie serwer, który został zidentyfikowany jako krytyczny dla realizacji misji organizacji, strata czasu rzędu kilku minut może kosztować miliony, w zależności od poziomu krytyczności systemu i typu biznesu. Tego typu koszty mogą pochodzić od wielu zagadnień, włącznie z utratą możliwości prowadzenia biznesu. Gdy systemy nie działają, firma nie może przyjmować zamówień, wytwarzać produktów lub dostarczać usług. Następnym kosztem jest utrata reputacji, co może skutkować utratą możliwości prowadzenia biznesu w przyszłości. Żadna firma nie będzie zadowolona, jeśli w telewizji CNN pojawi się informacja, że straciła dane. Do tego należy doliczyć koszty pracy nad odtworzeniem danych. W zależności od typu biznesu znaczącym kosztem może być również utrata materiałów wykorzystywanych do wytworzenia produktu. Na przykład, jeśli firma wytwarza produkty żywnościowe i zepsuje się system automatycznej kontroli produkcji, półprodukty mogą się przeterminować przed zakończeniem produkcji. Innym zagadnieniem, które należy wziąć pod uwagę przy kalkulowaniu kosztu przestoju, jest zjawisko logarytmicznej skali kosztów. Niektóre koszty w ogóle nie występują, jeśli przestój jest minimalny. Pięciominutowy przestój może być potraktowany przez pracowników po prostu jako dodatkowa przerwa na kawę. Jeśli jednak przestój się wydłuża, koszty zaczynają się nawarstwiać i łączny koszt rośnie dynamicznie. Zanim się zorientujemy, odbiorcy czekający na nasz towar zaczną rozglądać się za innymi dostawcami, po czym sprawy wymkną się zupełnie spod kontroli.
Planowanie działań dla wszystkich typów katastrof Wiele firm próbuje oszacowywać zagrożenie wszystkimi możliwymi katastrofami, oceniając ich prawdopodobieństwo w każdym centrum danych. Na przykład nadbrzeżne regiony USA z reguły powinny liczyć się z występowaniem huraganów i tsunami. W stanach: Texas, Oklahoma, Kansas i Nebraska występuje tak wiele tornad, że nazywa się je aleją tornad. Inne części świata są zagrożone trzęsieniami ziemi. Nie wolno lekceważyć zagrożeń stwierdzeniem „to nie ma prawa się przydarzyć”. Prawa Murphy’ego działają. Najwięcej szkód może wyrządzić ta katastrofa, której nie przewidzimy.
726
|
Rozdz ał 24. Ochrona danych
Klęski naturalne czy złośliwe działania to najbardziej oczywiste przyczyny przestojów, ale prawdopodobnie najbardziej powszechne są po prostu sytuacje losowe. Wiele osób omyłkowo usuwa ważne pliki lub zmienia ich położenie, co utrudnia ich znalezienie, ale przypadki kompletnej utraty danych mogą być spowodowane na przykład przecięciem linii zasilania przez pracowników budowlanych. Do powszechnych należą również przypadki uszkodzeń w wyniku zalania z powodu uszkodzonych rur. Czasem usunięciem wszystkich danych kończą się aktualizacje wersji oprogramowania. Należy poświęcić nieco pracy na analizy możliwych katastrof i zapewnienie, aby plany odtwarzania systemów po awarii uwzględniły te zagrożenia.
Uzasadnienie kosztów Po rozpoczęciu procesu wyboru systemów ochrony danych należy uzasadnić koszt każdego z tych zakupów. Warto do tego celu przygotować dokumentację zawierającą następujące elementy:
1. Określić RTO, RPO, okna wykonywania kopii i wymagania grup integralności. 2. Określić, co ma być chronione w każdym z krytycznych systemów. 3. Oszacować koszt każdego przestoju. 4. Zaplanować działania w reakcji na każdy typ katastrofy. Po przygotowaniu takiej dokumentacji uzasadnienie kosztów wdrożenia systemów ochrony danych powinno stać się w pełni wiarygodne. Należy po prostu określić RTO, RPO, zagrożenia i to, ile będzie kosztował system chroniący te dane. Wystarczy wyjaśnić, w jaki sposób na spełnienie tych wymagań wpłynie wyłączenie jednego z tych systemów.
Bezpieczeństwo składowania Szczegóły dotyczące bezpieczeństwa składowania danych znacznie wykraczają poza tematykę tej książki, ważne jest jednak, aby zrozumieć znaczenie tego zagadnienia w ochronie danych. Ten podrozdział omawia podstawowe typy zagrożeń w systemach składowania danych.
Nieszyfrowana komunikacja Związany z danymi ruch sieciowy w sieciowym systemie składowania określa się terminem in-band. Kiedyś wszelka taka komunikacja odbywała się bez szyfrowania. Jeśli ktoś może przechwycić ruch in-band, może zdobyć dostęp do danych, których nie powinien widzieć, lub uzyskać informacje pomocne w przeprowadzeniu ataku. Komunikację sieciową występującą niezależnie od składowanych danych, na przykład w celu realizacji zadań administracyjnych w urządzeniu składowania danych, określa się terminem out-of-band. Jeśli ktoś przechwyci tego typu komunikację, może przejąć kontrolę nad siecią nośników składowania danych i uzyskać dostęp do zapisanych na nich danych. Może też przeprowadzić atak blokady usług. Kluczem do oddalenia obydwu tych zagrożeń jest szyfrowanie. W przypadku komunikacji out-of-band dostawcy urządzeń udostępniają narzędzia obsługiwane za pośrednictwem szyfrowanych protokołów, jak ssh i https, z wykorzystaniem ich dedykowanych portów administracyjnych. W przypadku komunikacji in-band wykorzystuje się szyfrowanie na poziomie hosta oraz sprzętowe urządzenia szyfrujące. Tylko szyfrowanie na poziomie hosta może Bezp eczeństwo składowan a
|
727
szyfrować dane od samego punktu nadania, ale zadania kryptograficzne z reguły bardzo obciążają procesor, co może obniżyć transfer danych nawet o 50%. Innym wyborem w przypadku komunikacji in-band jest urządzenie szyfrujące umieszczane przy urządzeniu składowania, co zapobiega uzyskaniu dostępu do danych w przypadku uzyskania fizycznego dostępu do urządzeń.
Słabe mechanizmy uwierzytelniające i autoryzujące Systemy NFS (Unix) i CIFS (Windows) pozwalają na współdzielenie plików między różnymi serwerami. Rozwiązania tego typu określa się wspólnym terminem network-attached storage, w skrócie NAS. Główny problem z technologiami NFS i CIFS polega na tym, że wykorzystują mechanizmy uwierzytelniania na poziomie hosta. Jeśli adres IP komputera jest powiązany z określoną, uprawnioną nazwą hosta, automatycznie uzyskuje on dostęp do współdzielonych zasobów. Ponadto większość mechanizmów uwierzytelniających działa w trybie nieszyfrowanym, co daje włamywaczowi wyraźne wskazówki co do adresów IP, które musi sfałszować. Napastnik może bez przeszkód sfałszować adresy IP i uzyskać dostęp do poufnych informacji. Rozwiązania typu SAN wykorzystujące technologię Fibre Channel również mają słabe punkty, jeśli chodzi o uwierzytelnianie. Istnieją dwa bardzo mało bezpieczne, ale też bardzo popularne rozwiązania, wykorzystujące strefowanie WWN (word wide name zoning, WWN zoning) oraz tzw. miękkie strefowanie (soft zoning). Strefy to odpowiedniki sieci VLAN dla technologii Fibre Chanel (z pewnymi różnicami). W pierwszej kolejności wyjaśnię problemy z uwierzytelnianiem, a następnie z autoryzacją. Problem z uwierzytelnianiem w sieciach Fibre Chanel jest typowy dla wszystkich stref WWN, w których przynależność do strefy jest określana na podstawie adresu WWN hosta, będącego odpowiednikiem adresu MAC. Problem z tą techniką polega na tym, że adresy WWN jest bardzo łatwo sfałszować. Możliwość zmiany WWN jest bowiem wbudowana bezpośrednio w sterownik. O wiele bardziej bezpieczna, choć nieco trudniejsza w zarządzaniu technika polega na określaniu przynależności do strefy na podstawie portu przełącznika, do którego przyłączone jest urządzenie. Wiązanie portów, ostatnie udoskonalenie w przełącznikach Fibre Channel, może wpłynąć na poprawę bezpieczeństwa technik uwierzytelniania wykorzystujących WWN. W przypadku tej metody adres WWN jest związany z określonym portem przełącznika i uzyska dostęp do zasobu wyłącznie wtedy, gdy jest rzeczywiście przyłączony do tego portu. W sieciach SAN wykorzystujących Fibre Channel problem mogą sprawiać również mechanizmy autoryzacji, szczególnie w przypadku wykorzystania techniki miękkiego strefowania. W tej technice nie ma możliwości odpytania serwera stref o nazwę w danej strefie, jeśli nie jest się jej członkiem, ale można komunikować się z urządzeniem, znając jego WWN, co dość łatwo można wykryć. Przeciwieństwem techniki miękkiego strefowania jest technika strefowania twardego (hard zoning), w której urządzenia strefy mogą być wykorzystywane wyłącznie przez urządzenia należące do strefy. Wiele osób wierzy, że miękkie strefowanie i strefowanie WWN to dokładnie to samo. Ten mit bierze się z tego, że od dawna obie te techniki są dostępne razem, jednak są to zupełnie odmienne koncepcje. Strefowanie WWN i strefowanie z użyciem portów określają przynależność do strefy. Twarde i miękkie strefowanie określa tylko to, czy komunikować się z urządzeniem w strefie mogą urządzenia, które do niej nie należą.
728
|
Rozdz ał 24. Ochrona danych
Kuszące wydaje się rozwiązanie polegające na wykorzystaniu wyłącznie twardego strefowania, ale to nie jest tak proste. Miękkie strefowanie w połączeniu z uwierzytelnianiem wykorzystującym WWN było od dawna wykorzystywane w celu uproszczenia mechanizmów uwierzytelniania i wprowadzania w nich zmian. Współczesne przełączniki pozwalają decydować w sposób niezależny, jaka będzie stosowana technika uwierzytelniania i strefowania. Najbezpieczniejsze jest oczywiście strefowanie twarde z uwierzytelnianiem z wiązaniem portów.
Słabe punkty kopii zapasowych Najbardziej oczywistą wadą zabezpieczeń systemu kopii zapasowych jest taśma z danymi zapisanymi w postaci nieszyfrowanej. Istnieje obecnie duża liczba opcji szyfrowania, które pozwalają uniknąć tej słabości. Techniki te działają na poziomie systemu plików, jak również aplikacji, jak mechanizmy szyfrowania danych w programie do wykonywania kopii zapasowych. Ponadto istnieją dedykowane urządzenia szyfrujące dane w drodze między systemem a napędem taśmowym (często takie mechanizmy są wbudowane w napęd taśmowy). Rozwiązania sprzętowe są najbardziej kosztowne, ale o wiele łatwiej jest je zaimplementować i wykorzystywać w porównaniu z innymi opcjami. Rozwiązania te oferują optymalną prędkość szyfrowania (zgodną z prędkością zapisu), a dodatkowo oferują opcje kompresji. Dane zaszyfrowane nie nadają się do kompresji, przez co kompresja jest wykonywana przez dedykowany układ przed wykonaniem szyfrowania. To daje rozwiązaniom sprzętowym dużą przewagę nad rozwiązaniami na poziomie aplikacji lub programu do wykonywania kopii zapasowej, ponieważ dane zaszyfrowane wcześniej nie mogą być już kompresowane przez napęd taśmowy. Innym słabym punktem systemów do wykonywania kopii zapasowych jest to, że z reguły wykorzystują uwierzytelnianie na podstawie nazwy hosta. Włamywacz może uzyskać dostęp do danych kopii zapasowej, wykorzystując sfałszowany adres IP. Istnieją dwa zagrożenia: utworzenie fałszywego klienta kopii zapasowej i zmuszenie serwera do odtworzenia na tym kliencie rzeczywistej kopii zapasowej, przez co zostaną ujawnione poufne informacje. Taki fałszywy klient może również zapisywać w kopiach zapasowych różne rodzaje złośliwych plików. Włamywacz może również utworzyć fałszywy serwer kopii zapasowych, skłaniając stacje klienckie do wykonania na nim swoich kopii zapasowych. To jest oczywiście idealny sposób na kradzież lub uszkodzenie różnych rodzajów danych. Niektóre z systemów do wykonywania kopii zapasowych, również produkty open source opisane w tej książce, rozwiązały ten poważny problem przez zastosowanie dodatkowych poziomów autoryzacji (oprócz samej nazwy hosta). Niestety, to powoduje dodatkowe skomplikowanie systemu autoryzacji, co zmniejsza atrakcyjność tych produktów dla administratorów. Większość systemów do wykonywania kopii zapasowych stosuje podejście typu „wszystko albo nic”. To oznacza, że osoba albo może zrobić wszystko, jeśli chodzi o administrowanie systemem, albo nie ma żadnych uprawnień. Na przykład dając nowemu administratorowi możliwość wyciągania taśm z napędu, daje mu się również możliwość usuwania kopii zapasowych, a nawet zmiany całej polityki wykonywania kopii zapasowych, usuwania całej historii kopii zapasowych i nadpisywania dowolnymi danymi wszystkich taśm. Początkujący administrator może „nacisnąć niewłaściwy klawisz” i usunąć zawartość wszystkich taśm z biblioteki. Kilka lat temu taki wypadek wydarzył się w jednej z firm z branży prywatnej ochrony zdrowia. Niektóre produkty programowe wprowadziły już pewne rozwiązania tego problemu: administrację opartą na rolach, dzięki czemu konkretnej osobie można nadać uprawnienia tylko do określonych działań, blokując inne.
Bezp eczeństwo składowan a
|
729
Wprowadzenie administracji opartej na rolach w oprogramowaniu do wykonywania kopii zapasowych wraz z nowymi funkcjami zabezpieczającymi zapisane dane to dowód, że dostawcy tych rozwiązań otworzyli oczy na wagę ochrony danych. Jeśli wykorzystywane produkty nie oferują tego typu rozwiązań, warto poinformować ich dostawców, że są to funkcje istotne dla klienta, aby zrozumieli znaczenie bezpieczeństwa danych chronionych przez ich rozwiązania.
Podsumowanie Wszelkie organizacje, niezależnie od wielkości, muszą upewnić się, że właściwie dbają o wszystkie elementy ochrony danych. Niestety, projekty open source z tej dziedziny na razie oferują funkcje archiwizacji, bezpieczeństwa i odtwarzania po katastrofach na poziomie znacznie mniej rozbudowanym w porównaniu z funkcjami wykonywania i odtwarzania kopii zapasowych. Niektóre aspekty archiwizacji, bezpieczeństwa i odtwarzania po katastrofach są jednak obsługiwane w oprogramowaniu open source, jednak szczególnie brakuje kompletnych odpowiedników open source oprogramowania komercyjnego oferującego tego typu rozwiązania. Gdy doczekamy się produktów archiwizujących zasoby poczty elektronicznej szyfrujących z wydajnością równą prędkości zapisu oraz produktów do replikacji danych na poziomie bloków dyskowych, to będzie znak, że nadszedł czas na drugie wydanie tej książki. Na razie jednak mam nadzieję, że ta książka była pomocna. Każdemu rozdziałowi tej książki poświęcony jest osobny dział wiki w serwisie BackupCentral.com. Zapraszamy wszystkich do zapoznania się z materiałem dostępnym pod adresem http://www.backupcentral.com i do współpracy przy rozwijaniu tego serwisu.
730
|
Rozdz ał 24. Ochrona danych
Skorowidz .rhosts, 265 /boot, 232
A ACID, 430, 434, 647, 662 ACL, 63, 141 Acronis, 366 Active Directory, 45 administrator baz danych, 427 adres IP, 65 Advanced Maryland Automated Network Disk Archiver, 149 Advanced Metal Evaporative, 296 AFS, 203 AIT, 295, 695 AIX, 323, 389 powielanie systemów, 405 przywracanie systemu, 403 rozmiar bloku, 699 AIX 4.x, 405 AIX 5.x, 405 akceptowalna możliwość odtworzenia danych, 35 aktualizacja, 265 alter database open, 494 alter database open resetlogs, 493, 509 Amanda, 83, 149 .amandahosts, 156 amlabel, 162 amrecover, 170 amrestore, 170 architektura klient-serwer, 152 archiwizacja danych za pośrednictwem protokołu NFS, 168 archiwizacja danych za pośrednictwem protokołu Samba, 168 archiwizacja klientów, 167 bezpieczeństwo transportowanych danych, 156 cykl zrzutu, 159
definicja typu taśmy, 162 długość taśmy, 163 dysk magazynujący, 157 faza planowania, 159 faza szacowania, 159 harmonogramowanie kopii zapasowych, 158 host taśmowy, 155 instalacja serwera, 164 klony, 163 kod źródłowy, 153 konfiguracja, 164 nakładanie się danych w kolejnych archiwizacjach, 161 napędy taśmowe, 157 NFS, 167 odtwarzanie danych, 170 opcje wsparcia, 171 OpenSSH, 156 optymalny poziom archiwizacji, 159 pliki konfiguracyjne, 165 RAIT, 163 rozmiary kopii zapasowych, 161 Samba, 167 SELinux, 157 serwer, 155 shoe-shining, 157 sieć, 151 sieć SAN, 155 społeczność użytkowników, 171 szyfrowanie kopii zapasowych, 156 szyfrowanie po stronie klienta, 156 typ zrzutu, 166 urządzenia taśmowe, 162 zabezpieczenia, 155 zarządzanie taśmami, 162 zarządzanie urządzeniami, 162 amanda.conf, 165, 166 amandahosts, 156 amandapass, 169 amcheck, 165
731
AME, 296 amlabel, 162, 165 amrecover, 170 amrestore, 170 API, 249 aplikacje CAD, 256 Apple System Restore, 83, 86 AppleDouble, 87 architektura archiwizacji, 306 architektura baz danych, 419 DB2, 558 MySQL, 660 Oracle, 451 PostgreSQL, 647 Sybase, 516 architektura klient-serwer, 152 architektura VMware, 677 architektura wymiennych wtyczek silników składowania, 659 Archive, 659 archive logging, 562, 564 archivelog, 460, 499 archiwa, 250, 253, 714, 717 archiwizacja, 27 administrowanie, 49 Amanda, 167 automatyzacja, 60 bardzo duże pliki, 233 bardzo duże systemy plików, 233 bez udziału serwera, 237 bez udziału sieci lokalnej, 235 cały system, 48, 50 cpio, 116 D2D2T, 30, 246 dane zdalnego oddziału firmy, 235, 244 dd, 133 ditto, 140 dump, 92 dysk-dysk-taśma, 246 Flash Archive, 323 harmonogram tygodniowy, 53 komputer z systemem Mac OS X, 196 komputer z systemem Windows, 195, 217 lista dołączeń i wykluczeń, 46 mksysb, 394 moment przeprowadzania, 50 niesformatowane partycje, 232 niski budżet, 27 ntbackup, 87 oparta na dysku, 30
732
|
Skorow dz
oszczędność przestrzeni nośnika, 48 pliki specjalne, 231 powody, 32, 41 poziomy, 50 przygotowanie na najgorsze, 42 rekord MBR, 360 środki finansowe, 76 tar, 127 wszystkie dane, 39 wybór danych, 42 wybór metody, 56 wybrane napędy, 48 wybrane systemy plików, 48 zmieniające się duże pliki, 216 archiwizacja baz danych, 13, 417 API, 440 baza danych, 422 DB2, 441, 557 dd, 436 dedykowany napęd taśmowy, 440 dysk pośredniczący, 439 Exchange, 441, 615, 623 fizyczne elementy środowiska bazodanowego, 427 fizyczne kopie zapasowe, 436 gorąca kopia zapasowa, 436 Informix, 442 interfaces, 438 logiczne elementy bazy danych, 421 logiczne kopie zapasowe, 436 menedżer magazynowania, 440 metody sporządzania fizycznych kopii zapasowych, 436 MySQL, 442, 659 narzędzia komercyjne, 436 niesformatowane urządzenia, 437 ntbackup, 441 onbar, 441 ontape, 442 Oracle, 442, 449 oratab, 438 pg_dump, 442 pg_dumpall, 442 plik danych, 428 plik systemu plików, 437 PostgreSQL, 442, 647 poziomy automatyzacji, 418 przyrostowa kopia zapasowa, 438 RDBMS, 435 recovery, 441
Recovery Manager, 442 rman, 436, 441, 442, 450 rsync, 216 skrypty powłoki lub wsadowe, 440 SQL Backtrack, 436 SQL Server, 442, 599, 602 struktura bazy danych, 421 Sybase, 442, 515 tbtape, 442 tworzenie fizycznej kopii zapasowej, 436 tworzenie logicznej kopii zapasowej, 437 tworzenie narzędzia archiwizującego, 439 unikatowe wymagania baz danych, 447 uwzględnianie każdej instancji, 438 wyłączanie bazy danych, 420 zimna kopia zapasowa, 436 złożoność, 420 zrzut dziennika transakcji, 438 ASE, 515, 519, 520 asr, 83, 86 at, 440 ATA, 305 atime, 62, 119 resetowanie, 62 Atomicity Consistency Isolation Durability, 430 atomowość, 434 atrybuty, 426 Oracle, 453 AUM, 457 automatyczna zmieniarka, 304 automatyczne monitorowanie systemów plików, 255 automatyzacja, 270 przywracanie komputera od podstaw, 363 automatyzacja archiwizacji, 60 mechanizm archiwizacji, 60 autoryzacja oparta na rolach, 266 awaria dysk, 58, 711 komputer, 58 nośnik, 694 oprogramowanie, 58 sprzęt, 57
B backup, 566 backup controlfile to trace, 456, 483 backup server, 520, 528 BackupPC, 30, 83, 173
bezpieczeństwo, 177 config.pl, 182 configure.pl, 181 HFS, 181 instalacja systemu, 179 instrukcje instalacyjne, 176 interfejs CGI, 181 klient, 175, 182 klient DHCP, 175 konfiguracja klienta, 176, 182 kontrola procesu archiwizowania, 175 łatwość obsługi, 177 mod_perl, 174, 176 narzędzia, 175 określanie wymaganej przestrzeni dyskowej, 178 pakiety instalacyjne, 181 Perl, 174 przestrzeń dyskowa, 178 przyszłość systemu, 183 pula archiwizacji, 176 pula dyskowa, 174 serwer, 174, 176, 181 społeczność, 183 uruchamianie serwera, 181 VPN, 176 wymagania systemu, 177 zasady działania, 174 Bacula, 185 architektura oprogramowania, 185 archiwizacja danych inicjowana przez klienta, 203 archiwizacja komputera z systemem Mac OS X, 196 archiwizacja komputera z systemem Windows, 195 automatyczne zmieniarki, 200 autonomiczny proces przywracania, 191 bimagemgr, 189 btape, 191 certyfikaty, 199 demon magazynowania, 187 demon plików, 187, 203 dokumentacja, 191 dvd-handler, 189 etykiety taśm ANSI i IBM, 201 format przechowywania, 190 graficzny interfejs użytkownika, 202 interakcja między składnikami, 188 katalog, 187
Skorow dz
|
733
Bacula katalog SQL, 189 klient z systemem Linux, 193, 194 konfiguracja, 189, 192 konfiguracja serwera, 192 konsola administracyjna, 187 kopie zapasowe na wielu woluminach, 189 migracja puli, 202 mtx-changer, 200 nadzorca, 187 obciążenie generowane przez archiwizację, 199 obsługa dodatków demonów plików, 203 obsługa nośników, 189 obsługa podstawowego zadania, 203 obsługa systemu plików HFS+, 190 obsługa usługi VSS, 191 obsługa wielu pul, 190 podstawowe zadanie, 203 poziomy archiwizacji, 189 przywracanie komputera od podstaw, 197 serwer, 192 serwer bazodanowy, 187 skalowalność, 191 składniki oprogramowania, 186 skrypty klienta, 200 skrypty Python, 199 szyfrowanie magazynowanych danych, 199 śledzenie plików usuniętych i ze zmienioną nazwą, 202 testowanie napędu taśmowego, 191 TLS, 199 tunelowanie danych, 199 uwierzytelnianie, 188 wstępna archiwizacja, 193 wstępne odtwarzanie, 194 wx-console, 196 wykrywanie intruzów, 201 bacula-dir.conf, 195 bacula-fd, 198 bardzo duże pliki, 233 bardzo duże systemy plików, 233 aktywne systemy plików, 719 bardzo ważne aplikacje, 235 BartPE, 198 baza danych, 45, 249, 417, 419, 422 ACID, 430, 434 administrator, 427 architektura, 419 atrybuty, 426 awaria kontrolera, 435
734
|
Skorow dz
BLOB, 425 blok, 427 częściowe odtwarzanie w trybie online, 445 częściowo zapisywalna, 478 DB2, 429, 439, 441, 557 duże obiekty danych, 425 dysk danych, 443 dziennik transakcji, 431 dziennik wycofań, 431 Exchange, 421, 441, 615 fizyczne elementy środowiska, 427 główna baza, 430 indeksy, 425 Informix, 419, 442 instancja, 422, 423 kopa zapasowa, 436 krotka, 426 logiczne elementy, 421 logiczne uszkodzenie, 435 mechanizm składowania, 429 migawki, 426 modyfikacja stron, 432 MySQL, 429, 432, 442, 659 obiekty, 426 obszar tabel, 428, 429 odtwarzanie systemu RDBMS, 443 Oracle, 419, 442, 449, 452 partycje, 429 partycjonowanie tabeli, 429 plik danych, 428 plik kontrolny, 430 PostgreSQL, 425, 442, 647 procedury składowane, 522 punkt kontrolny, 432 RDBMS, 421 rekordy, 426 relacje, 423 segmenty, 429 serwer, 422 SQL Server, 442, 585, 587 strona, 427 struktura, 421 Sybase, 430, 442, 515, 520 tabele, 423 transakcje, 430 unikatowe wymagania, 447 utrata dysku nieprzechowującego dane, 443 utrata dysku z danymi, 444 utrata głównej bazy danych, 445 widoki, 425
wiersz, 426 zakresy, 428 zmiana uprawnień urządzenia, 435 zmiana właściciela urządzenia, 435 zniszczenie lub awaria dysku, 435 BCH, 372 bcp, 517 BCV, 725 BDB, 659 BEGIN TRANSACTION, 649 bezpieczeństwo, 177, 265 składowanie, 727 wewnętrzne, 708 zewnętrzne, 708 BFILE, 453 biblioteka, 304 biblioteka taśmowa, 280 big-endian, 697 Bill-of-Materials, 141 Binary Large Object, 422 bit archiwizacji systemu Windows, 52 BlackHole, 659 blat, 71 bless, 413 BLOB, 422, 425, 453, 649 blok, 427 blok rozruchowy, 232 błędne ustawienia poziomu, 696 błędy obsługa techniczna komputerów, 57 użytkownik, 57 bom, 141 BOM, 141 boot cdrom, 330 BOOTP, 370 bootpd, 370 bootptab, 370 bootsys, 386 bosinst.data, 405 broker usług, 585 btape, 191 budżet, 27, 33 business continuance volumes, 725 ByteA, 649
C CA, 199 CAD, 256 CD, 300, 301
CD-R, 301 cdrecord, 369 CD-RW, 301 celowe usunięcie, 714 change journal, 52 chdev, 700 check_net_recovery, 383 checkpoint, 647 ciągła ochrona danych, 242, 243 CIFS, 45, 316, 712, 728 circular logging, 564 circular logs, 621 CLOB, 453 CLP, 570 codzienna kopia poziomów, 53 codzienna przyrostowa kopia (wieża Hanoi), 54 codzienna różnicowa kopia poziomu 1, 53 cofanie strony, 431 COMMIT, 649 Configure Automatic Maintenance, 570 cp, 83 cpio, 30, 83, 85, 116, 144, 261 archiwizacja, 116, 117 archiwizacja na zdalnym urządzeniu, 120 częściowe odtwarzanie danych, 122 dowiązania symboliczne, 126 dziwny rozmiar bloku, 122 format ASCII, 119 generowanie listy plików woluminu, 124 interaktywny proces zmiany nazw plików, 125 kopiowanie katalogów, 126 niepoprawny typ nagłówka, 122 odtwarzanie całego systemu plików, 124 odtwarzanie danych, 120, 124 odtwarzanie danych do innego katalogu, 126 odtwarzanie danych zgodnych ze wzorcem, 124 określanie rozmiaru bloku, 120 określanie trybu wyjściowego, 119 określanie współczynnika bloków, 119 określanie wyjściowego urządzenia lub pliku, 120 opcje, 118, 125 opcje odtwarzania, 122 potokowanie do programu rsh lub ssh, 120 przywracanie czasów dostępu, 119 rozmiar bloku, 120, 122 składnia, 116 typ nagłówka, 122
Skorow dz
|
735
cpio uporządkowanie bajtów, 121 wersja GNU, 118, 126 wersje narzędzia, 121 współczynnik bloków, 119 wybór urządzenia, 123 wyjściowe urządzenie lub plik, 120 zamiana bajtów miejscami, 125 żądanie wyświetlania szczegółowych informacji, 119 CpMac, 83 crash recovery, 563 CRC, 627 create controlfile, 489, 491 create table, 559 cron, 29, 165, 440 CSV, 659 ctime, 52, 62 CVS, 137 cyfrowa taśma audio, 296 cyfrowy rejestrator wideo, 30 cykl roboczy urządzenia archiwizującego, 277 cykl zrzutu, 159 cykl życia posiadanych danych, 257 czas, 34 czas cyklu, 282 czas dostępu do danych, 281 czas odtwarzania, 234 czas wykonywania kopii zapasowych, 55 częstość wymiany nośnika, 285 częściowe odtwarzanie bazy danych w trybie online, 445 częściowo zapisywalna baza danych, 478 czytelność danych po odtworzeniu, 717
D D2D2T, 30, 246 DAC, 589 dane BLOB, 423 klientów, 715 operacyjne, 716 relacyjna baza danych, 248 wymagające specjalnego traktowania, 248 zdalny oddział firmy, 235 DAS, 712 DAT, 296 data mining, 585 Database Consistency Checker, 530
736
|
Skorow dz
database managed spaces, 561 database node, 560 datafile, 523 data-only locked, 522 db_recovery_file_dest, 458 db_recovery_file_size, 458 DB2, 429, 439, 441, 557 alias bazy danych, 568 analiza historii kopii zapasowych, 569 architektura, 558 archive logging, 562, 564 archiwizacja dzienników, 562 automatyczne kopie zapasowe, 573 automatyzacja utrzymania, 570 backup, 566, 569 Backup to Disk, 572 baza danych, 558 CLP, 570 Configure Automatic Maintenance, 570 crash recovery, 574 database managed spaces, 561 database node, 560 db.db_backup_req, 571 db.tb_reorg_req, 571 db.tb_runstats_req, 571 db2_all, 560 db2look, 574 db2nodes.cfg, 560 db2start, 558 dbluextl, 566 DMS, 561 drugorzędne dzienniki transakcyjne, 563 dziennik archiwalny offline, 563 dziennik archiwalny online, 563 dzienniki pierścieniowe, 564 dzienniki transakcyjne, 562 EDU, 559 egzemplarz UDB, 568 egzemplarze, 558 engine dispatch units, 559 gromadzenie dzienników transakcyjnych, 582 gromadzenie kopii zapasowych, 577 gromadzenie statystyk, 584 grupa partycji bazy danych, 560 GUI, 570 Health Center, 570, 573 health monitor, 570 ibmcatgroup, 560 ibmdefaultgroup, 560 ibmtempgroup, 560
indeksy, 559 kolekcje stanu, 571 kontenery, 561 kontenery przestrzeni SMS, 561 konwencje nazewnictwa, 568 kopie zapasowe, 557 large tablespace, 562 LOB, 562 logarchmeth1, 565, 566 logarchmeth2, 563 logarchmethl, 563 logfilsiz, 563 logprimary, 563 logretain, 565, 567 long tablespace, 562 lowerbounded threshold-based, 571 mierniki z ustalonym dolnym progiem, 571 mierniki z ustalonym górnym progiem, 571 minimalny punkt w czasie, 582 minimum point in time, 581 monitor bazy danych, 570 niepełne kopie, 569 obiekty LOB, 562 odtwarzanie bazy danych, 566, 577 odtwarzanie bazy po zatrzymaniu awaryjnym, 562 odtwarzanie bazy z przekierowaniem, 579 odtwarzanie crash, 564 odtwarzanie danych, 575 odtwarzanie kopii zapasowej z opcją redirect, 579 odtwarzanie po awarii, 574 odtwarzanie rollforward, 564, 575 odtwarzanie transakcji, 579, 580 odtwarzanie version, 564 odtwarzanie wersji, 575 odtwarzanie wersji w miejscu, 577 odtwarzanie z przekierowaniem, 577 partycja bazy danych, 560 perspektywy, 559 podstawowe dzienniki transakcyjne, 563 połączenie z bazą, 559 poziomy kopii zapasowych, 568 przestrzenie nazw, 561 przestrzeń tabel katalogu, 560 przestrzeń tabel tymczasowych, 560 przestrzeń tabel użytkownika, 560 przyrostowa kopia zapasowa, 439 recover, 566, 576, 578 reorg, 573
reorganizacja danych, 580, 584 restore, 566, 569, 575, 578 rollforward, 566, 569, 576, 579, 581, 582, 583 rollforward pending, 581 runstats, 573 schematy, 558 SMS, 561 stan oczekiwania na sprawdzenie, 583 storage device, 561 syscatspace, 560, 562 system managed spaces, 561 ścieżka do plików bazy, 563 ścieżka kopii zapasowej, 568 tabele, 558 tabele katalogu systemowego, 559 tablespace, 561 tempspace1, 560, 562 transakcje, 562 transakcje utrwalone, 563 tryb archiwizacji dzienników, 564 tryb oczekiwania na operację rollforward, 581 TSM, 572 tworzenie kopii zapasowej, 567 typy odtwarzania, 563, 574 upperbounded threshold-based, 571 userexit, 563, 566 userspace1, 562 Web Health Center, 570 węzły bazy, 560 wskaźniki stanu zdrowia bazy, 571 zapis dziennika z wyprzedzeniem, 563 zarządzanie dziennikami, 564 db2 backup, 441, 567, 574 db2 connect, 559, 584 db2 list history, 570 db2 list tablespaces, 562 db2 reorgchk update statistics, 584 db2 restart db, 574 db2 restore, 580 db2 rollforward, 583 DB2 UDB, 557 db2 update db, 565 db2_all, 560 db2look, 574 db2nodes.cfg, 560 db2start, 558 dbcc, 530, 592 checkalloc, 531 checkcatalog, 531 checkdb, 531
Skorow dz
|
737
dbcc checkstorage, 531 checktable, 530 tablealloc, 530 wywołania conocne, 531 dbluextl, 566 dbspace, 428 DCLZ, 696 dd, 84, 133, 349, 362, 436 archiwizacja, 133 identyfikacja formatu kopii zapasowej, 136 konwersja danych, 135 konwersja danych mających nieprawidłowy format, 135 konwersja danych przekazywanych innemu poleceniu, 135 kopiowanie zawartości pliku, 135 liczba odczytywanych rekordów, 135 niesformatowane urządzenia, 135 niezależne określanie rozmiaru bloków wejściowych i wyjściowych, 134 odtwarzanie danych, 133 określanie pliku wejściowego, 134 określanie pliku wyjściowego, 134 określanie rozmiaru bloku na taśmie, 136 opcje, 134 plik wejściowy, 134 plik wyjściowy, 134 rozmiar bloku, 134 dd_rescue, 363 dd_rhelp, 363 DDS, 296 deduplikacja, 315 deduplikacyjny system archiwizacji, 239 dedykowany napęd taśmowy, 440 default, 524 definicja podstawowej funkcji organizacji, 722 device, 523 dezinformacja, 41 DHCP, 45 dhcptab, 370 diff, 129 differential change map, 593 differential partial, 599 Digital Audio Tape, 296 Digital Data Storage, 296 Digital Linear Tape, 296 Digital Video Recorder, 30 direct-attached storage, 712 disaster recovery, 721
738
|
Skorow dz
disk staging, 246 disk striping, 534 disk-to-disk-to-tape, 30, 246 diskutil, 408, 409, 412 distribution, 588 ditto, 83, 84, 261, 409 ACL, 141 archiwizacja, 140, 141 kolejki FIFO, 141 nazwane gniazda, 141 nazwane potoki, 141 odtwarzanie danych, 140, 143 opcje, 142 rozszerzone listy kontroli dostępu, 141 składnia, 141 wyświetlanie listy plików archiwum, 143 znaczniki BSD, 141 DLT, 292, 296, 695 DLT-S, 296 DLT-V, 297 dławienie, 258 długoterminowa natura archiwizacji danych, 716 DML, 522 DMS, 561 DNS, 48 docelowa przepustowość, 288 docelowe magazyny dyskowe, 305 deduplikacja, 315 dysk-jako-dysk, 307 dysk-jako-dysk sieci SAN, 309 dysk-jako-dysk technologii NAS, 309 dysk-jako-taśma, 310, 318 klastry systemów plików, 310 pakiety, 315 powiadamianie, 318 replikacja, 316 rozpoznawanie zawartości, 316 stertowanie, 318 wirtualne biblioteki taśmowe, 310 wtórna prezentacja, 316 zasobniki wirtualnych taśm, 318 dokumentacja, 73 konfiguracja serwerów, 45 zmiany, 715 DOL, 522 dostawca narzędzia archiwizującego, 273 dostawca zdalnego składowania danych na nośnikach, 67 dostęp losowy, 303 dostępność danych, 708
dowiązania symboliczne, 126 twarde, 206, 212 dowody elektroniczne, 710 DR, 721 dsedit, 518 DSQUERY, 519 dsync, 523 DTF, 297 dump, 30, 70, 82, 84, 144, 261, 534, 686, 687, 694 aktualizacja pliku dumpdates, 96 archiwizacja, 92 definiowanie pełnej kopii zapasowej, 95 definiowanie przyrostowej kopii zapasowej, 95 etapy zrzutu, 690 format taśmy z danymi, 102 gęstość, 97 indeks, 101 kopia zapasowa, 101 Linux, 92 Mac OS, 92 ograniczenia, 114 opcje, 94 plik urządzenia archiwizującego, 99 powiadamianie operatorów archiwizacji, 97 rekordy, 689 rozmiar, 97 różnice w uporządkowaniu bajtów, 106 składnia, 93 tworzenie kopii zapasowej na wielu woluminach, 98 tworzenie tabeli zawartości z indeksu, 102 wersje narzędzia, 106 współczynnik bloków, 96, 105 wyświetlanie systemów plików, 100 zapisywanie na woluminie indeks, 101 dump transaction, 534 dump transaction with truncate_only, 527 dumpdates, 95, 96, 97 dumpsdates, 687 duża liczba plików, 720 duże aplikacje, 235 duże ilości danych, 719 duże obiekty danych, 425 Oracle, 453 duże pliki, 233 duże systemy plików, 233 DVD, 300, 301 DVD Forum, 302
DVD Random-Access Memory, 302 DVD+R, 301, 302 DVD+RW, 302 DVD+RW Alliance, 302 DVD-R, 301, 302 DVD-RAM, 302 DVD-Recordable, 302 DVD-Rewritable, 302 DVD-RW, 302 DVR, 30 dysk danych, 443 dysk magazynujący, 157 dysk pośredniczący, 439 dysk twardy, 30, 31, 280 elastyczność, 31 koszt, 31 niezawodność, 31 RAID, 31 dysk-jako-dysk, 305, 307 dysk-jako-taśma, 310, 318 dzienniki, 46 pierścieniowe, 564 powtórzeń Oracle, 458 wycofań, 431 zmian, 52 dzienniki transakcyjne, 431 DB2, 562 Exchange, 618 fizyczne, 432 logiczny, 432 MySQL, 432, 665 SQL Server, 592 Sybase, 525 dziury, 299
E EDU, 559 egzemplarz, 558 egzemplarz silnika MySQL, 660 ekstent, 523, 593 elastyczność, 31 urządzenia archiwizujące, 279 elektroniczne składowanie danych, 69 elektroniczne włamania, 58 elektroniczne żądania identyfikacyjne, 252 elektroniczny materiał dowodowy, 710 endian-independent, 697 engine, 520 engine dispatch units, 559
Skorow dz
|
739
EOM, 701 EP, 289 ESE, 615, 616 Example, 659 Exchange, 421, 441, 615 architektura serwera, 615 automatyzacja utrzymania bazy danych, 623 baza danych, 615 circular logs, 621 CRC, 627 DML, 616 dzienna kopia zapasowa, 625 dzienniki pierścieniowe, 621 dzienniki rezerwowe, 620 dzienniki śledzenia wiadomości, 626 dzienniki transakcyjne, 618 E00tmp.log, 622 ESE, 615, 616 ESENT, 615 ExIFS, 622 grupy składowania, 616, 618 indeks wyszukiwania pełnotekstowego, 626 informacje o dziennikach, 621 JET, 615 kopia cienia, 628 kopia przyrostowa, 625 kopia strumieniowa, 627 kopia zapasowa offline, 627 kopia zapasowa online, 627 Mailbox Merge, 637 Mailbox Store Properties, 638 MAPI, 617 metody odtwarzania, 641 metody wykonywania kopii, 627 migawki, 628 naprawa baz danych, 635 naprawa przez ponowną instalację, 635 naprawa serwera, 635 nazwy plików zasobów składowania, 617 ntbackup, 629, 642 odtwarzanie, 634 odtwarzanie kopii online, 636 odtwarzanie kopii przyrostowej, 636 odtwarzanie kopii różnicowej, 636 odtwarzanie miękkie, 637 odtwarzanie offline, 637 odtwarzanie programem ntbackup, 642 odtwarzanie rollforward, 637 odtwarzanie serwera, 636 odtwarzanie skrzynek pocztowych, 636
740
|
Skorow dz
odtwarzanie twarde, 637 odtwarzanie usuniętych elementów, 642 odtwarzanie usuniętych skrzynek pocztowych, 641 odtwarzanie w punkcie czasu, 637 odtwarzanie zasobów folderów publicznych, 636 odtworzenie sygnału, 640 odzyskanie sygnału, 640 ograniczenia zasobów składowania, 623 określanie zawartości kopii, 625 pełna kopia zapasowa, 624 planowanie, 623 pliki .edb, 617 pliki .stf, 622 pliki .stm, 617 pliki dzienników rezerwowych, 620 pliki dzienników transakcyjnych, 618 pliki IFS, 622 pliki punktów przywracania, 620 punkt przywracania, 620 Recover Deleted Items, 642 Recovery Storage Group, 637 różnicowe kopie zapasowe, 625 RSG, 637, 638 serwer, 615 single instance storage, 622 składowanie pojedynczego egzemplarza, 622 snapshot isolation mode, 616 SRS, 626 storage group, 616 store, 617 strategia wykonywania kopii zapasowych, 623 struktura bazy danych, 615 tmp.edb, 622 transakcje, 616 tryb izolacji na poziomie migawek, 616 tworzenie kopii zapasowych, 623 tworzenie podstawowej kopii, 629 typy kopii zapasowych, 624 usługa replikacji, 626 version store, 616 Volume Shadow Copy Service, 628 weryfikacja kopii, 628, 632 zadania podczas naprawy i odtwarzania, 634 zasoby składowania, 616, 617 zwykła kopia zapasowa, 625 Extended Play, 289 Extensible Storage Engine, 616
F Falcon, 665 FAT, 217 fault tolerance, 647 FCC, 723 fdisk, 356, 681 Federated, 659 Fibre Channel, 236, 244, 277, 728 filegroups, 589 Filer Head, 309 filesystem snapshot, 668, 685 find, 117 FireWire Target Disk Mode, 408 fizyczne elementy środowiska bazodanowego, 427 fizyczny dziennik wycofań, 434 flar, 328 flar create, 324, 328 flar info, 328 Flash Archive, 323 archiwizacja, 323 częstość wykonywania kopii zapasowej, 325 dysk, 325 flar create, 327 interaktywne odtwarzanie, 326, 327 interaktywne przywracanie komputera, 330 Jumpstart, 325 nieinteraktywne odtwarzanie, 326, 332 odtwarzanie danych, 324 OEM, 325 ograniczenia środowiska, 326 pliki konfiguracyjne nieinteraktywnego odtwarzania, 332 procedury wykonywane po ukończeniu przywracania, 338 profile, 333 profile pochodne, 333 przywracanie komputera od podstaw, 329 rules, 334 rules.ok, 334 serwer obrazów, 325 sysidcfg, 334 taśma, 325 tworzenie kopii zapasowej, 324 tworzenie obrazów, 327 tworzenie taśmy z obrazem, 329 umieszczanie na taśmie obrazu nieinteraktywnego procesu odtwarzania, 335
wybór systemów plików do archiwizacji, 327 wymagania systemowe, 324 zapisywanie na dysk obrazu nieinteraktywnego procesu odtwarzania, 335 Flash Recovery Area, 458 Flashback, 471, 476 ForEx, 46 format kompresji, 701 format niezależny od architektury, 697 format SIDF, 262 format wiadomości pocztowych, 216 format zapisu optycznego, 301 CD, 301 CD-R, 301 CD-RW, 301 DVD, 301 DVD+R, 302 DVD+RW, 302 DVD-R, 302 DVD-RAM, 302 DVD-RW, 302 magnetooptyczny, 302 UDO, 303 formatowanie dysku, 350 FRA, 458, 460 FreeBSD, 348 fstab, 350 FUD, 686 funkcje zarządzania magazynem danych, 250
G G4L, 341, 343, 363 Click’ n’ Clone, 364 dostosowywanie narzędzia, 365 File Mode, 364 konfiguracja, 364 Local Use, 364 Network Use, 364 Raw Mode, 364 serwer FTP, 365 stosowanie narzędzia, 364 wady narzędzia, 364 zalety narzędzia, 363 generowanie podsumowania, 70 gęstość, 285 ghost, 363 Ghost, 366 Ghost 4 Linux, 363
Skorow dz
|
741
Gigabit Ethernet, 703 główna baza danych, 430 główny rekord rozruchowy, 232, 346 gorąca kopia zapasowa, 436, 720 Oracle, 465 gorący serwer, 36 growisofs, 369 grupa integralności, 724 grupa magazynowania, 429 grupa magazynu, 429 grupa partycji bazy danych, 560 grupa plików, 429 grupa składowania, 618 grupa spójności, 234 gzip, 355
H HA, 37 hard zoning, 728 harmonogram archiwizacji, 53 Amanda, 158 miesięczna pełna kopia zapasowa i codzienne przyrostowe kopie (wieża Hanoi), 54 same pełne kopie zapasowe, 53 tygodniowa pełna kopia zapasowa i codzienne kopie poziomów, 53 tygodniowa pełna kopia zapasowa i codzienne różnicowe kopie poziomu 1, 53 harmonogram tygodniowy, 53 HBA, 236 Health Center, 570 Health Insurance Portability and Accountability Act, 709 HFS, 181 HFS+, 82, 83 hfspax, 83, 86 hfstar, 83, 86 Hierarchical Storage Management, 255, 716 hierarchiczne zarządzanie magazynowaniem, 255 hierarchiczne zarządzanie zasobami składowania, 716 Hi-Fi, 291 High-Availability, 37 HIPAA, 709 host taśmowy, 155 hot backup, 647, 650, 656 HOWTO, 341 HP Integrity, 372
742
|
Skorow dz
HP9000, 372 HP-UX, 367 HSM, 255, 281, 716
I IA64, 343, 348 IBM 3570, 294 IBM 3590, 294 IBM 3592, 294 IBM 3840, 294 IBM TS1120, 294 identyfikacja baza danych, 264 system plików, 264 IDRC, 696 Ignite-UX, 367 BCH, 372 bezpieczeństwo, 386 BOOTP, 370 bootpd, 370 bootptab, 370 bootsys, 386 check_net_recovery, 383 dhcptab, 370 diagnozowanie operacji przywracania, 384 HP Integrity, 372 HP9000, 372 instalacja serwera, 368 instl_bootd, 370 interfejs TUI, 372 itool, 386 klient, 372 konfiguracja serwera, 368 konfiguracja serwera sieciowego, 377 konfiguracja sieci, 369 konsola Intel EFI, 373 konsola MP, 373 make_net_recovery, 368, 376, 381 make_tape_recovery, 368, 375 planowanie magazynowania archiwum, 374 planowanie przywracania archiwum, 374 powielanie dysków, 387 powielanie systemów, 385 protokoły zdalnego ładowania, 369 przechowywanie archiwów, 369 przywracanie danych komputera, 387 rbootd, 370 rozmiar archiwum przywracanych danych, 376
rozwiązywanie problemów, 369 swinstall, 377 usługi sieciowe, 369 ustalanie rozmiaru archiwum przywracanych danych, 376 wdrożenie, 379 weryfikacja zawartości archiwum, 381 wiersz poleceń, 380 zarządzanie archiwami przywracanych danych, 378 zdalne ładowanie, 369 zdalne ładowanie klientów, 374 ILM, 256 image.data, 393 in-band, 727 indeks kopii zapasowych, 268, 271 indeksy, 425 DB2, 559 klastrowe, 522 nieklastrowe, 522 Oracle, 453 spartycjonowane, 589 SQL Server, 589 Sybase, 522 index statistics, 537 informacje zapisane w bazach danych, 720 informacje zapisane w zasobach współdzielonych, 721 Information Lifecycle Management, 256 Informix, 419, 442 init.ora, 461 InnoDB, 429, 659, 663 instalacja, 265 instancja, 422 Oracle, 452 instl_bootd, 370 instrukcje, 65 Intel EFI, 373 Intel IA64, 585 Intel PXE, 370 intellectual property, 722 interfaces, 438, 518 internet, 250 inwentaryzacja, 44 IP, 722 iSCSI, 236, 712, 721 isql, 517, 531, 548 i-węzły, 212 izolacja, 434
J jednoczesna archiwizacja danych jednego klienta na wielu napędach, 246 jednoczesna archiwizacja wielu klientów przy użyciu jednego napędu, 244 jednoczesne kopiowanie kopii zapasowych, 264 jednokrotny zapis WORM, 300 JET, 615 Jumpstart, 325
K kasety, 286, 293 katastrofy, 725 ke_net_recovery, 369 kill -9, 547 klaster, 647 klastry systemów plików, 310 klasy NAS, 721 klasyfikacja danych, 710 klęski żywiołowe, 59 Knoppix, 347, 348 kolejki FIFO, 141 kolejność bajtów, 697 kolumny, 453 komercyjne narzędzia archiwizujące, 229 archiwa, 250 archiwizacja bez udziału serwera, 237 archiwizacja bez udziału sieci lokalnej, 235 archiwizacja danych zdalnego oddziału firmy, 244 archiwizacja dysk-dysk-taśma, 246 archiwizacja plików specjalnych, 231 automatyzacja, 270 bezpieczeństwo, 265 czas odtwarzania, 234 D2D2T, 246 dane wymagające specjalnego traktowania, 248 deduplikacyjny system archiwizacji, 239 dostawca, 273 format archiwizacji, 260 funkcje zarządzania magazynem danych, 250 grupa spójności, 234 hierarchiczne zarządzanie magazynowaniem, 255 jednoczesna archiwizacja danych jednego klienta na wielu napędach, 246
Skorow dz
|
743
komercyjne narzędzia archiwizujące jednoczesna archiwizacja wielu klientów przy użyciu jednego napędu, 244 koszt, 272 łatwość administrowania, 263 łatwość odtwarzania, 266 niezawodność, 270 obciążenie sieci, 257 obrazy, 240 obsługa używanych platform, 231 ochrona indeksu kopii zapasowych, 268 okna archiwizacji, 234 punkt odtwarzania, 234 replikacja, 241 rygorystyczne wymagania, 233 system ciągłej ochrony danych, 241 system niemal ciągłej ochrony danych, 241 weryfikacja woluminów, 271 zarządzanie cyklem życia informacji, 256 zmiana produktu archiwizującego, 234 kompresja, 284, 285, 701 napędy taśmowe, 288 po stronie klienta, 258 programowa, 284 sprzętowa, 284 komputerowe kopie zapasowe, 37 komunikacja z demonem, 265 konfiguracja baza danych, 45 menedżer NIM, 401 menedżer woluminów, 44 serwer NIM, 401 konie trojańskie, 713 konsolidowanie kopie zapasowe hosta, 264 woluminy zawierające niewielką ilość danych, 264 kontener, 561 kontrola błędów w dużym zakresie, 114 kontroler HBA, 236 kopia kopii zapasowych, 44 kopia przyrostowa, 51 kopia różnicowa, 51 kopia zapasowa, 40, 253, 714, 717 delta, 439 dump, 101 serwer VMware, 677 ulotne systemy plików, 685
744
|
Skorow dz
kopiowanie dowiązania, 137 katalogi, 126 urządzenia, 137 wybrane kopie zapasowe, 263 koszty narzędzie archiwizujące, 272 przestoje, 34, 709, 726 urządzenie archiwizujące, 283 utrata danych, 32 kradzież, 58 krotka, 426 książka operacyjna, 536 księgowanie z wyprzedzeniem zapisu, 647 kupno napędu archiwizującego, 275
L LAMP, 150 Laser Magnetic Storage, 297 LD_LIBRARY_PATH, 519 Linear Tape Open, 297 liniowy zapis serpentynowy, 292 Linux, 341, 348 lista producentów oprogramowania archiwizującego, 231 lista wykluczeń, 46 listy kontroli dostępu, 63 little-endian, 697 Live CD, 344, 346, 347 LMS NCTP, 297 ln, 212 load, 542 load database, 555 LOB, 562 log group, 664 LOG SUSPEND, 549 Logical Volume Manager, 44, 45 logiczne elementy bazy danych, 421 logiczne magazynowanie aktywnych danych, 251 logsegment, 524 lokalne przechowywanie kopii, 66 lsbom, 141 LTO, 292, 297, 319, 695 lvcreate, 669 LVM, 45, 343, 348, 648 lvmcfgbackup, 45
Ł ładowanie systemu z alternatywnego nośnika, 349, 353, 354, 355, 356, 358, 361 łatwość administrowania systemem archiwizującym, 263 łatwość obsługi, 177 łatwość odtwarzania, 266
M MAC, 370 Mac OS, 63, 82 Mac OS X, 83, 196, 407 archiwizacja danych, 410 bless, 413 ditto, 409 FireWire Target Disk Mode, 408 partycjonowanie dysku, 412 proces przywracania komputera od podstaw, 409 przygotowanie do przywracania komputera od podstaw, 408 przywracanie komputera od podstaw, 407 przywracanie systemu, 411 zewnętrzny dysk archiwizacyjny, 408 macierz RAID, 31, 58 magazyn danych, 250 magazynowanie archiwum, 61 magnetooptyczna metoda zapisu, 299 magnetooptyczny format zapisu, 302 magnetowid, 291 Hi-Fi, 291 Magstar MP, 294 Mailbox Merge, 637 maildir, 216 make_ipf_tape, 368 make_medialif, 368 make_net_recovery, 367, 368, 369, 376, 381, 383, 386 make_recovery, 367 make_sys_image, 368, 369 make_tape_recovery, 367, 368, 369, 375, 386 maksymalna ochrona, 37 Mammoth, 298 MAPI, 617 master, 587 maszyna wirtualna, 677 MaximumSize, 52 mbox, 216
MBR, 232, 346, 350 MDB, 413 mechanizm archiwizacja, 60 kopie lustrzane, 534 migawki, 685, 725 składowanie, 429 media recognition system, 695 Memory, 659 Memory In Cassette, 296 menedżer magazynowania, 440 menedżer NIM, 401 menedżer woluminów, 44 Merge, 659 metody archiwizacja, 34, 56 zapis optyczny, 299 MIC, 296 miesięczna pełna kopia zapasowa, 54 miesięczna pełna kopia zapasowa i codzienne przyrostowe kopie (wieża Hanoi), 54 miękkie strefowanie, 728 migawka, 426, 686, 721, 725 system plików, 685 migawkowe kopie zapasowe, 594 migracja do VMware, 680 mini-root, 342 mirroring, 534 mkbom, 141 mkcd, 400 mkfs, 350, 359 mksysb, 323, 389, 391, 699 archiwizacja, 394 archiwizacja grupy rootvg na lokalnie podłączonym napędzie taśmowym, 395 archiwizacja grupy rootvg na zdalnym napędzie taśmowym, 395 archiwizacja na dysku, 396 dodanie do serwera NIM definicji klienta, 402 format danych, 391 image.data, 394 logiczna reprezentacja taśmy, 391 menedżer NIM, 401 mkszfile, 393 przygotowanie do procesu odtwarzania, 393 przygotowanie do zastosowania programu, 392 przywracanie systemu AIX, 403 serwer NIM, 401 tworzenie definicji dla klienta, 402
Skorow dz
|
745
mksysb tworzenie ładowalnego dysku CD/DVD, 397 tworzenie w jednym kroku kopii zapasowej na dysku CD/DVD, 400 weryfikacja kopii zapasowej, 403 MLR 1-3, 298 MO, 299 mod_perl, 176 model, 588 ACID, 434 modyfikacja stron, 432 moment przeprowadzania archiwizacji, 50 monitor bazy danych DB2, 570 monitorowanie kopii zapasowych, 70 generowanie podsumowania, 70 morale, 33 mount, 354 MRS, 695 msdb, 588, 599 mt, 103 fsf, 103 fsr, 103 offline, 103 rewind, 103 status, 103 MTBF, 276 mtime, 52, 62 mtx-changer, 200 multipleksowanie, 245, 280, 456 MultiRead, 301 my.cnf, 660 MyISAM, 430, 659, 662 MySQL, 429, 442, 659 .MYD, 662 .MYI, 662 ACID, 659 architektura bazy danych, 660 BackupDataBufferSize, 672 BackupLogBufferSize, 672 BackupMemory, 672 baza danych, 661 bezpośrednie wykorzystanie dzienników binarnych, 670 datadir, 662 dziennik binarny, 661 dziennik transakcyjny, 432, 665 egzemplarze, 660 Falcon, 665 grupa dzienników, 664 InnoDB, 663, 664
746
|
Skorow dz
katalog danych, 662 kopia klastra bazy, 673 kopia na poziomie systemu plików, 669 kopia tabel InnoDB, 667 kopia tabel MyISAM, 667 kopie zapasowe w locie, 672 log-bin, 661 lvcreate, 669 ładowanie danych z dzienników binarnych z zastosowaniem zakresów dat, 671 migawka systemu plików, 668 my.cnf, 660 MYData, 662 MYIndex, 662 MyISAM, 662 mysqlhotcopy, 666 naprawa uszkodzonych tabel MyISAM, 667 narzędzie do kopii zapasowych na poziomie plików, 668 NDB, 665 obiekty binarne, 661 odtwarzanie bazy z kopii zapasowych na poziomie systemu plików, 669 odtwarzanie danych klastra, 673 odtwarzanie danych w punkcie czasu, 670 odtwarzanie kopii, 665 odtwarzanie kopii na poziomie SQL, 666, 667 odtwarzanie kopii zapasowych na poziomie plików, 668 PBXT, 665 plik danych, 664 przestrzenie tabel, 661, 664 przywracanie kopii zapasowych w locie, 672 segment wycofywania, 664 silnik składowania, 659, 665 skrypty uruchomieniowe, 660 SolidDB, 665 transakcje, 664 tworzenie kopii zapasowych, 665 tworzenie kopii zapasowych na poziomie plików, 668 tworzenie kopii zapasowych na poziomie SQL, 666 tworzenie kopii zapasowych w locie, 672 wtyczkowa architektura silników składowania, 659 wykorzystanie dzienników binarnych z użyciem przejściowych plików tekstowych, 671
mysqlbinlog, 671 mysqld, 660 mysqld_safe, 660 mysqldump, 666 mysqlhotcopy, 666, 669
N napędy, 696 archiwizujące, 38, 244 DLT, 695 dyskowe, 31, 38, 280 dyskowe ATA, 277 LTO, 292 napędy optyczne, 279, 298 CD, 301 DVD, 301 dziury, 299 format zapisu, 299, 301 magnetooptyczna metoda zapisu, 299 metoda zapisu, 299 WORM, 300 zapis barwiony polimeru, 300 zmiennofazowa metoda zapisu, 300 napędy taśmowe, 31, 38, 103, 157, 277, 279, 287 8 mm, 295 9840, 295 9940, 295 AIT, 295 bufor, 287 DAT, 296 DDS, 296 DLT, 296 DLT-S, 296 DLT-V, 297 docelowa przepustowość, 288 DTF, 297 IBM 3570, 294 IBM 3590, 294 IBM 3592, 294 IBM 3840, 294 IBM TS1120, 294 kasety, 293 kompresja, 288 LMS NCTP, 297 LTO, 292, 297 Magstar MP, 294 Mammoth, 298 MLR 1-3, 298 obsługa zmiennej prędkości, 289
prędkość transferu danych, 287 przygotowywanie się do zapisu, 287 pucowanie, 288 stały strumień danych, 288 Super DLT, 296 średnia klasa, 293 T10000, 295 Value DLT, 297 VXA, 298 zapis liniowy, 289, 292 zapis ukośny, 289 zasobniki, 293 naprawa serwera Exchange, 635 naruszenia zabezpieczeń, 710 narzędzia archiwizujące, 12, 81 niemal ciągła ochrona danych, 205 NAS, 150, 712, 721, 728 dysk-jako-dysk, 305, 306, 309 nazwane gniazda, 141 nazwane potoki, 141, 231 NDB, 429, 659, 665 ndb_restore, 673, 674 NDMP, 236, 240 near-continuous data protection, 719 Network Data Management Protocol, 236 Network File System, 167 network-attached storage, 712 NFS, 45, 167, 248, 316, 370, 712, 728 niekompatybilność architektury maszyny, 696 niemal ciągła ochrona danych, 205 niesformatowane partycje, 232 niesformatowane urządzenie, 428 niespójności formatów kopii, 700 niestandardowe skrypty użytkownika, 249 niestandardowy format archiwizacji, 260, 262 nieszczęśliwe wydarzenia, 57, 60 nieszyfrowana komunikacja, 727 niewłaściwy typ nośnika, 695 niezależna wirtualna biblioteka taśmowa, 305, 306 niezależność od platformy, 266 niezawodność, 31, 270 urządzenie archiwizujące, 276 niezmienna postać systemu plików, 685 nieznany format kopii, 700 NIM, 392, 401 NIS+, 178 niszczenie zawartości dysku twardego, 354 NNTP, 71
Skorow dz
|
747
nośniki archiwizacyjne, 31 taśmy, 711 ntbackup, 30, 44, 52, 81, 85, 198, 344, 441 archiwizacja, 87 archiwizacja Exchange, 629 konfiguracja archiwizowania, 88 odtwarzanie danych, 89 plik opcji archiwizacji, 88 tryb kreatora, 629 tworzenie prostej kopii zapasowej, 89 typy kopii, 88 NTFS, 63, 591 ntfsclone, 349 ntfsresize, 681 numer i-węzła, 212
O obciążenie sieci, 257 obiekty, 426 LOB, 562 obrazy, 36, 240, 720 obsługa rozwidleń, 82 obszar tabel, 428, 429 Oracle, 455 OCC, 67 ochrona danych, 205, 707 archiwa, 714 bardzo aktywne systemy plików, 719 bezpieczeństwo składowania, 727 bezpieczeństwo wewnętrzne, 708 bezpieczeństwo zewnętrzne, 708 celowe usunięcie, 714 dane, 715 dokumentacja zmian, 715 dostępność danych, 708 duża liczba plików, 720 duże ilości danych, 719 elektroniczny materiał dowodowy, 710 grupy integralności, 724 informacje zapisane w bazach danych, 720 informacje zapisane w zasobach współdzielonych, 721 klasyfikacja danych, 710 konie trojańskie, 713 kopie zapasowe, 714 koszty przestojów, 709 naruszenia zabezpieczeń, 710 nieszyfrowana komunikacja, 727 nośniki taśmowe, 711
748
|
Skorow dz
odtwarzanie danych po katastrofie, 721 określanie kosztów przestoju, 726 oprogramowanie open source, 718 planowanie działań dla wszystkich typów katastrof, 726 poczta, 712 powody biznesowe, 708 priorytety funkcji biznesowych niezbędnych do realizacji podstawowej funkcji, 722 problemy sprzętowe, 711 przypadkowe usunięcie, 713 redukcja kosztów, 709 robaki, 713 RPO, 724 RTO, 724 słabe punkty kopii zapasowych, 729 strategia archiwizacji danych, 716 system plików urządzeń NAS, 721 system plików urządzeń SAN, 721 udoskonalanie poziomu usług, 711 uzasadnienie kosztów, 727 uzasadnienie techniczne, 711 wirusy, 713 zagrożenia każdego krytycznego systemu, 725 zagrożenia nośników sieciowych, 712 zagrożenia zewnętrzne, 713 zgodność z przepisami, 709 zmniejszenie ryzyka, 708 ochrona indeksu kopii zapasowych, 268 ochrona systemu RDBMS, 435 odczyt „oporne” taśmy, 701 woluminy, 694 ODE, 368 odłączanie, 213 odporność na błędy, 647 odpowiedzialność za archiwizację, 40 odtwarzanie baza danych DB2, 566, 574, 577 baza danych SQL Server, 607, 612 blok rozruchowy, 357, 362 informacje bloku rozruchowego, 350 serwer Exchange, 636 system operacyjny, 354, 357, 359, 362 odtwarzanie danych, 12 Amanda, 170 baza danych Sybase, 541 cpio, 120, 124
dd, 133 ditto, 140, 143 Exchange, 634 Flash Archive, 324 ntbackup, 89 po katastrofie, 721 restore, 104 rsync, 140, 215 tar, 129 w innej lokalizacji, 267 w punkcie czasu, 655 odtwarzanie systemu RDBMS, 443 aktywne dzienniki transakcji, 445 czas ukończenia odtwarzania, 446 częściowe odtwarzanie w trybie online, 445 dokumentacja, 446 dysk danych, 443 fizyczne powiązanie tabel i obszarów tabel, 446 testowanie, 446 unikatowe wymagania baz danych, 447 utrata dysku nieprzechowującego dane, 443 utrata dysku z danymi, 444 utrata głównej bazy danych, 445 odtworzenie sygnału, 640 odzyskiwanie zawartości uszkodzonych dysków, 704 okna archiwizacji, 234 określanie koszty przestoju, 726 rozmiar bloku na taśmie, 136 zagrożenia krytycznego systemu, 725 onbar, 441 onconfig, 430 ones complement, 696, 697 online database, 543, 555 ontape, 442 opcje nadpisywania, 267 Open Firmware, 408 open resetlogs, 510 open source, 30, 153, 341 OpenSSH, 156 oprogramowanie open source, 153, 718 oprogramowanie archiwizujące, 30 optymalna metoda archiwizowania, 34 ora_funkcja_SID, 452 ORA_SID_AUTOSTART, 462 ORA_SID_PFILE, 462 ORA_SID_SHUTDOWN, 462 oraback, 468
Oracle, 419, 442, 449 alter database open resetlogs, 509 architektura bazy danych, 451 archivelog, 460, 514 archivelogs, 459 archiwalne dzienniki powtórzeń, 458, 477 archiwizacja pliku kontrolnego, 466 atrybuty, 453 AUM, 457 automatyczne zarządzanie danymi powrotu, 457 auxiliary system, 455 baza danych, 452 BFILE, 453 BLOB, 453 blok, 454 CLOB, 453 dane powrotu, 457 db_recovery_file_dest, 460 dbshut, 452 dbstart, 452 dodawanie uszkodzonej, nieaktywnej grupy dzienników, 511 dziennik powtórzeń, 458 fizyczna kopia zapasowa, 470 Flashback, 476 FRA, 458 gorąca kopia zapasowa, 465 grupa dzienników, 459 indeks, 453 init.ora, 461 instancja, 452 kolumny, 453 komercyjne metody archiwizacji, 477 kopie zapasowe zarządzane przez użytkownika, 449, 451, 463 log_archive_dest_n,, 459 log_archive_format, 459 logiczna kopia zapasowa, 512 metody archiwizacji, 449 mity związane z „gorącymi” kopiami zapasowymi, 467 monitorowanie dziennika alertów, 514 multipleksowanie, 456 multipleksowanie plików kontrolnych i dzienników powtórzeń, 486 niedostępne jakiekolwiek segmenty wycofywania, 506 numer SCN, 454 obiekt pochodny, 453
Skorow dz
|
749
Oracle obiekty, 453 obszar dyskowy FRA, 458 obszar tabel, 455 obszar tabel powrotu, 455, 457 odtwarzanie, 461, 508 odtwarzanie plików danych w trybie offline, 503 odtwarzanie plików kontrolnych, 490 odtwarzanie uszkodzonych plików danych, 503 odtwarzanie wszystkich plików danych żądanych obszarów tabel, 500 ora_funkcja_SID, 452 oraback, 468 oradim, 452 oratab, 462 parametry inicjalizujące, 460 partycja, 455 plik kontrolny, 455 pliki danych, 454 pliki danych przełączone w tryb offline, 502 podzielony blok, 468 pola, 453 proces przywracania, 480 proces przywracania nośnika, 498 przełączenie uszkodzonego pliku danych w tryb offline, 502 przygotowywanie bazy danych do przywracania, 490 przywracanie, 461 przywracanie bazy danych, 479, 491, 504 przywracanie bazy danych przy użyciu logicznej kopii zapasowej, 513 przywracanie nośnika, 461 przywracanie obszaru tabel, 503 przywracanie obszaru tabel przechowującego niedostępny segment wycofywania, 507 przywracanie plików danych, 503 przywracanie plików danych w trybie offline, 503 przywracanie wszystkich plików danych, 508 punkt kontrolny, 458, 510 Recovery Manager, 449 rekordy, 453 rman, 449, 450 SCN, 455 segment, 454 spfile.ora, 461
750
|
Skorow dz
sysaux, 455 systemowy obszar tabel, 455 szukanie instancji, 462 tabele, 453 transakcje, 457 tworzenie fizycznych kopii zapasowych, 463, 470 tworzenie gorącej kopii zapasowej, 465 tworzenie logicznej kopii zapasowej, 513 tworzenie zimnej kopii zapasowej, 464 typy danych dużych obiektów, 453 undo_retention, 457 uruchamianie bazy danych, 490 usuwanie uszkodzonej, nieaktywnej grupy dzienników, 511 uszkodzona grupa dzienników online, 505 uszkodzone pliki danych wymaganych obszarów tabel, 500 uszkodzony aktywny dziennik powtórzeń trybu online, 510 uszkodzony bieżący dziennik online, 508 uszkodzony nieaktywny dziennik powtórzeń trybu online, 511 uszkodzony plik danych niewymaganego obszaru tabel, 501 v$datafile, 464 weryfikacja stanu bazy danych, 481 wiersz, 453 zakresy, 454 zarządzanie archiwalnymi dziennikami powtórzeń, 477 zastąpienie brakującego pliku kontrolnego, 483 zimna kopia zapasowa, 464 Oracle Data Pump, 512 OracleServiceSID, 452 oradim, 452 oratab, 47, 438, 462 oszczędność przestrzeni nośnika, 48 out-of-band, 727
P page, 593 Paragon, 366 parametry inicjalizujące, 460 partial backup, 598 Partition Magic, 351
partycje, 44, 232 /boot, 232 niesformatowane, 232 partycje bazodanowe, 429 DB2, 560 Oracle, 455 SQL Server, 594 partycjonowanie dysk, 350, 412 napęd systemu operacyjnego, 344 tabele, 429 PATH, 519 pax, 86, 344 PBXT, 665 pdisk, 408 pełna automatyzacja, 50 pełna kopia zapasowa, 29, 50, 53 Perl, 174 personel odpowiedzialny za archiwizację, 40 perspektywy, 559 pg_ctl, 648 pg_dump, 442, 649, 651, 652, 653, 654 pg_dumpall, 442, 649, 651, 652, 654 pg_hba.conf, 658 pg_restore, 652, 653, 657 pg_start_backup, 651, 652 pg_stop_backup, 651, 652, 656 ping, 176 plan archiwizacji wieży Hanoi, 54 plan działania, 45 plan odtwarzania po katastrofie, 721 plan rozbudowy, 61 Planowanie zadań, 89 plik danych, 428 plik kontrolny, 430 Oracle, 455 plik systemu plików, 428 podstawowa funkcja organizacji, 722 podsumowanie dla zarządu, 77 podział na partycje, 44 point in time recovery, 647, 650 pojemność urządzenia archiwizującego, 282 pola, 453 połączenie z bazą DB2, 559 porównywanie suma kontrolna z indeksem, 272 tabela zawartości indeksu, 272 zawartość kopii zapasowej z systemem plików, 272
Portable Archive Exchange, 86 PostgreSQL, 425, 442, 647 ACID, 647 architektura serwera, 647 archiwizacja dziennika WAL, 651 BLOB, 649 ByteA, 649 domyślna przestrzeń tabel, 648 duże dane tekstowe, 649 dziennik wycofywania transakcji, 650 dziennik zapisu z wyprzedzeniem, 650 format tekstowy, 654 klaster, 647 kopie zapasowe, 651 księgowanie z wyprzedzeniem zapisu, 647 LVM, 648 obiekty binarne, 649 odporność na błędy, 647 odtwarzanie, 651, 653 odtwarzanie danych w punkcie czasu, 647, 650, 655, 657 pg_ctl, 648 pg_dump, 649, 651, 652, 653, 654 pg_dumpall, 649, 651, 652, 654 pg_hba.conf, 658 pg_restore, 652, 653 pg_start_backup, 651, 652 pg_stop_backup, 651, 652, 656 pliki graficzne, 649 pliki stron danych, 648 postmaster, 657 proces wycofania zmian, 649 przestrzenie tabel, 647, 648 psql, 652, 654 punkt przywracania, 647 recovery.conf, 658 roll forward, 657 skrypty startowe, 648 tabele systemowe, 649 Text, 649 tworzenie kopii zapasowej, 652 tworzenie kopii zapasowych w locie, 647 tworzenie kopii zapasowych z myślą o odtwarzaniu danych w punkcie czasu, 655 tworzenie przestrzeni tabel, 648 WAL, 650, 655 wycofywanie zmian, 649 zarządzanie klastrami, 648 potokowanie, 120 powiadamianie, 114, 265, 318
Skorow dz
|
751
powielanie dyskowe, 246, 305 powielanie systemów, 385 powody wykonywania kopii zapasowych, 41, 206 poziom archiwizowania, 50 poziom zabezpieczeń, 36 prawie ciągła ochrona danych, 719 prawie lokalne magazynowanie danych, 287 prezentacja, 76 prędkość transferu urządzenia archiwizującego, 278 priorytety funkcji biznesowych niezbędnych do realizacji podstawowej funkcji, 722 probe-scsi-all, 329, 336 problemy sprzętowe, 711 procedury składowane, 522, 590 procedury wdrożeniowe, 72 proces odtwarzania przeprowadzany przez użytkownika, 267 produkty ciągłej ochrony danych, 242 profile, 333 profile pochodne, 333 protokoły NDMP, 240 NFS, 248 prtvtoc, 44 przechowywanie kopii zapasowych, 65, 251 dostawca zdalnego składowania danych na nośnikach, 67 lokalne przechowywanie, 66 poza obrębem firmy, 67 testowanie usługi wybranego dostawcy, 68 zdalne elektroniczne składowanie danych, 69 przegląd, 77 przenoszenie katalogu, 132 przenośność urządzenia archiwizującego, 283 przeprowadzenie oficjalnej prezentacji, 76 przestrzenie tabel, 524, 648 przetwarzanie symetryczne, 520 przygotowanie na najgorsze, 42 przypadkowe usunięcie, 713 przyrostowa kopia zapasowa, 50, 438 przywracanie baza danych Oracle, 479 system AIX, 403 system Windows, 91 przywracanie komputera od podstaw, 13, 197, 267, 323, 342 archiwizacja rekordu MBR, 360 archiwizacja systemu operacyjnego za pomocą wbudowanego narzędzia, 349, 353, 356, 358, 360
752
|
Skorow dz
archiwizacja ważnych metadanych, 347, 353, 355, 358, 360 automatyzacja, 363 cały dysk, 345 dd, 349 Flash Archive, 323, 329 formatowanie nowego głównego dysku, 350 G4L, 343, 363 Ignite-UX, 367 ładowanie alternatywne, 344 ładowanie systemu z alternatywnego nośnika, 349, 353, 354, 355, 356, 358, 360, 361 make_net_recovery, 367 make_recovery, 367 make_tape_recovery, 367 MBR, 350 metoda archiwizacji, 343 metoda obrazu partycji i alternatywnego ładowania, 346, 355 metoda pełnego obrazu i alternatywnego ładowania, 346, 353 metoda systemu plików i alternatywnego ładowania, 347, 360 metoda trybu online, 347, 357 mkfs, 350 mksysb, 389, 391 narzędzia komercyjne, 365 ntfsclone, 349 odtwarzanie bloku rozruchowego, 357, 359, 362 odtwarzanie informacji bloku rozruchowego, 350, 354 odtwarzanie na większe dyski twarde, 351 odtwarzanie systemu operacyjnego, 354, 357, 359, 362 odtwarzanie systemu operacyjnego na nowy główny dysk, 352 partycje, 345 partycjonowanie nowego głównego dysku, 350 poziom obrazu, 345 poziom systemu plików, 345 proces, 354, 356, 358, 361 przygotowanie nowego głównego dysku, 354, 357, 359, 362 QTParted, 351 rekord MBR, 348 savevg, 389, 391 serwer DHCP, 352 system AIX, 389 system FreeBSD, 348, 349
system HP-UX, 367 system Linux, 341, 348, 349 system Mac OS X, 407 system Solaris, 323 system Solaris x86, 348, 349 system Windows, 341, 348, 349 tabela partycji, 348 tryb online, 344 tworzenie kopii zapasowej, 353, 355, 358, 360 warianty archiwizacji, 346 Przywracanie systemu, 85, 90 przywracanie systemu Windows, 91 punkt przywracania, 90 tworzenie punktów przywracania, 90 psql, 652, 654 psync, 83, 86 pucowanie, 285, 288 punkt kontrolny, 432 Oracle, 458 punkt odtwarzania, 234 punkt przywracania, 90 Python, 199
Q Qmail, 216 QTParted, 351, 681
R RAID, 31, 58, 150, 167, 277 RAID 1, 58 RAID 5, 58 RAID 6, 58 RAIT, 163 raw partition, 523 rbootd, 370 RDBMS, 420, 421, 557 archiwizacja systemu, 435 kopia zapasowa, 436 ochrona systemu, 435 rdiff-backup, 205, 216, 221 Mac OS X, 224 wady, 223 Windows, 224 zalety, 222 rdump, 93 recover, 566, 576 recover database using backup controlfile, 493 recover database, recover tablespace, 498
recover datafile, 503 recovery log, 558 Recovery Manager, 442, 449 recovery point objective, 724 Recovery Storage Group, 637 recovery time objective, 724 Redundant Array of Inexpensive Tapes, 163 rejestrowanie usuwanych plików, 267 rekordy, 426, 453 relacje, 423 reorg, 532 reorg compact, 532 reorg forwarded_rows, 532 reorg rebuild, 532, 533 reorg reclaim_space, 532 replikacja, 205, 241, 316 offsite, 721 report schema, 500 repozycjonowanie, 245 reputacja w branży, 33 restore, 43, 84, 93, 95, 102, 534, 566, 575 całkowite odtworzenie systemu plików, 108 interaktywne odtwarzanie plików, 110 nieprzerwane działanie podczas odtwarzania, 114 odczytanie woluminu z kopią zapasową, 105 odtwarzanie danych, 104 odtwarzanie plików do innej lokalizacji, 111 odtwarzanie plików według nazwy, 109 ograniczenia, 114 określanie napędu archiwizacyjnego lub pliku, 113 określanie współczynnika bloków, 113 opcje, 107 pomijanie plików, 112 różnice w uporządkowaniu bajtów, 106 składnia, 107 sposób przebiegu procesu odtwarzania, 108 tworzenie tabeli zawartości woluminu, 108 typ operacji, 107 współczynnik bloków, 105, 113 żądanie wyświetlania szczegółowych komunikatów, 112 restore filelistonly, 599 restore headeronly, 600 restore sequence, 608 restore spfile, 473 restoresmtable, 108 restoresymtable, 108 rm -r, 59
Skorow dz
|
753
rman, 436, 441, 442, 449, 450 archiwizacja plików parametrów serwera, 473 automatyczne archiwizowanie pliku kontrolnego, 473 automatyczne generowanie nazwy kopii zapasowej, 473 automatyzacja zadań, 474 configure controlfile, 473 create catalog, 473, 474 create controlfile, 484, 489 crosscheck, 472 delete, 472 drop catalog, 473 dzienniki powtórzeń, 485 inwentaryzacja kopii zapasowych, 472 katalog przywracania, 474 kompresja kopii zapasowych, 474 kopie zapasowe zarządzane przez użytkownika, 495 niedostępne jakiekolwiek segmenty wycofywania, 506 obszar dyskowy FRA, 473 odtwarzanie plików kontrolnych, 490 odtwarzanie uszkodzonych dzienników powtórzeń, 486 odtwarzanie uszkodzonych plików danych, 486, 503 odtwarzanie wszystkich plików danych żądanych obszarów tabel, 500 odtwarzanie z kopii zapasowej, 508 optymalizacja archiwizacji, 471 optymalizacja odtwarzania, 471 optymalizacja przyrostowych kopii zapasowych, 473 otwieranie bazy danych, 491 pliki danych, 485 proces przywracania nośnika, 498 przyrostowe aktualizowanie kopii zapasowych, 450, 473 przyrostowe kopie zapasowe, 450 przywracanie bazy danych, 480, 491, 504 przywracanie bloków nośnika, 473 przywracanie obszaru tabel, 503 przywracanie plików danych, 503 przywracanie plików danych w trybie offline, 503 przywracanie wszystkich plików danych, 508 recover database, 495 recover tablespace system, 501 report schema, 500
754
|
Skorow dz
restore database, 501 ręczne przywracanie bazy danych, 492 skrypt tworzący przyrostowe kopie zapasowe poziomu 1, 476 skrypty, 475 sprawdzanie spójności danych, 450 trwałe konfiguracje, 473 trwałe parametry, 475 tworzenie fizycznych kopii zapasowych, 463, 470 tworzenie katalogu przywracania, 474 tworzenie skryptów, 475 tworzenie trwałych parametrów, 475 upgrade catalog, 473 uszkodzona grupa dzienników, 497 uszkodzona grupa dzienników online, 505 uszkodzone pliki danych wymaganych obszarów tabel, 500 uszkodzony aktywny dziennik powtórzeń trybu online, 510 uszkodzony niezbędny obszar tabel, 497 uszkodzony plik danych, 496 uszkodzony plik danych niewymaganego obszaru tabel, 501 uszkodzony segment wycofywania, 497 RMP, 370 robaki, 713 roll forward, 657, 665 rollback, 562 rollback log, 650 rollback segment, 664 rollforward, 566, 576, 581, 582 rollforward recovery, 563 rootdb, 430 rootdbs, 444 rootvg, 392 rozmiar bloku, 697 rozpoznawanie zawartości, 316 rozwiązanie NAS typu dysk-jako-dysk, 305 rozwidlenie dane, 63, 87 zasoby systemu Mac OS, 63 równoległe odtwarzanie, 267 RPO, 724 RSG, 637, 638 rsh, 100, 115, 146 rsnapshot, 205, 217 ACL, 219 configtest, 220 konfiguracja, 219
Mac OS X, 218 obsługa platform, 218 społeczność użytkowników, 221 Windows, 218 rsnapshot.conf, 220 rsync, 44, 85, 137, 205, 211 anonimowy demon, 137 archiwizacja baz danych, 216 archiwizacja komputerów z systemem Windows, 217 częściowe transfery, 217 dowiązania twarde, 212 duże systemy plików, 217 format wiadomości pocztowych, 216 jednolitość, 217 kopie oparte na dowiązaniach twardych, 213 kopiowanie często modyfikowanych plików, 211 Mac OS, 140 migawki, 206 odtwarzanie danych, 140, 215 opcje, 216 opcje wykluczające, 137 rozmiar kopii zapasowej, 215 skalowanie pamięci, 217 składnia, 138 synchronizacja lokalnych plików, 211 tryb pobierania, 212 usuwanie plików, 138 uwierzytelnianie, 137 Windows, 139 wysyłanie zmienionych bloków zmodyfikowanych plików, 137 rsync_hfs, 83 RSYNC_PASSWORD, 139 RSYNC_RSH, 137, 138 rsyncx, 86 RTO, 724 ruch sieciowy związany z archiwizowaniem, 257 rules, 334 rules.ok, 334
S Samba, 167 SAN, 155, 235, 236, 259, 712, 721 SATA, 305 save_config, 368
savevg, 389, 391, 402 archiwizacja grupy woluminów, 403 format danych, 391 przygotowanie do zastosowania programu, 392 weryfikacja kopii zapasowej, 403 schadenfreude, 28 schemat bazy danych, 520, 558 schemat przywracania komputera od podstaw, 342 SCN, 454, 455 SCSI, 200, 245, 277 SCSI over Fibre Channel, 721 Secure Backup, 472 segment, 454, 524 SELECT, 425 SELinux, 157 service broker, 585 serwer, 422 BackupPC, 181 danych, 422 NIM, 392, 401 NIS+, 178 nośników, 268 Sybase, 516, 519 urządzeń, 268 shoe-shining, 157, 285 show databases, 661 shutdown, 546 nowait, 546 with nowait, 546 SID, 452 SIDF, 262 sieciowy system archiwizujący, 257 sieć SAN, 235, 236, 259 dysk-jako-dysk, 305, 306, 309 silnik, 520 silnik składowania, 659, 665 silos, 304 single instance storage, 622 składowanie pojedynczego egzemplarza, 622 skrypt inicjujący, 333 skumulowana kopia przyrostowa, 51 słabe mechanizmy uwierzytelniające, 728 słabe punkty kopii zapasowych, 729 smbclient, 169 smit, 401 SMS, 561 SMTP, 71 snapshot, 36
Skorow dz
|
755
snapshot isolation mode, 616 SNMP, 265, 304 soft zoning, 728 Solaris, 323 Solaris x86, 348 SolidDB, 665 Solstice Disk Suite, 44 SOX, 709 sp_addsegment, 524 sp_helpdb, 533, 588, 596 sp_helpdevice, 533, 553 sp_recompile, 533, 537 sp_who, 549 specjalne atrybuty pliku, 82 spfile.ora, 461 Spotlight, 87 spójność, 55, 434 SQL Backtrack, 436, 477 SQL Server, 442, 585, 586 administracja, 586 analiza informacji o bazach danych, 588 automatyczny przyrost dziennika, 611 backup set, 602 baza danych, 587 baza danych użytkownika, 587, 588 baza różnicowa, 598 broker usług, 585 częściowe kopie zapasowe, 598 DAC, 589 data copy, 608 data mining, 585 data ważności kopii, 602 datafile, 590 dbcc, 592 differential partial, 599 distribution, 588 domain policy, 586 drugorzędne pliki danych, 590 duże typy danych, 594 dziennik fizyczny, 592 dziennik logiczny, 592 dziennik transakcyjny, 592 egzemplarz, 587 ekstenty, 593 ekstenty jednolite, 593 ekstenty mieszane, 593 elementy odtworzenia, 608 filegroups, 589 full backup, 597 grupy plików, 591, 599
756
|
Skorow dz
grupy plików użytkownika, 591 indeksy, 589 indeksy spartycjonowane, 589 informacje o kopii zapasowej, 599 konta domenowe, 586 kopie na poziomie logicznym, 607 kopie zapasowe, 595, 597 kopie zapasowe bazy master, 605 kopie zapasowe copy-only, 598 kopie zapasowe dziennika transakcyjnego, 598, 603 logfile, 590 mapa alokacji indeksów, 593 mapa zmian grupowych, 593 mapa zmian różnicowych, 593 master, 587 migawkowe kopie zapasowe, 594 model, 588 model bulk z odtworzeniem dzienników, 596 modele odtwarzania, 596 monitorowanie pliku dziennika, 592 msdb, 588, 599 odtwarzanie bazy danych, 607, 612 odtwarzanie bazy master, 614 odtwarzanie danych w modelu bulk logged, 612 odtwarzanie danych w modelu full, 612 odtwarzanie danych w modelu simple, 611 odtwarzanie danych za pomocą języka Transact-SQL, 613 odtwarzanie kopii zapasowych systemowych baz danych, 599 partial backup, 598 partycje, 594 pełna kopia zapasowa, 597 pełny model odtwarzania, 596 plan odtwarzania, 608 planowanie kopii zapasowej, 606 pliki, 599 pliki bazy danych, 590 pliki danych, 590 pliki dzienników, 590 podłączanie do bazy master, 609 podstawowa grupa plików, 591 podstawowe pliki danych, 590 point in time, 598 polityki domenowe, 586 połączenie z serwerem, 586 primary datafile, 590 procedury składowane, 590
prosty model odtwarzania, 596 przeglądanie informacji o kopii zapasowej, 599 przycinanie dziennika, 605 przygotowanie do procedury odtwarzania, 611 przywracanie bazy danych, 607 przywracanie kopii, 608 recovery model, 596 restore filelistonly, 599 restore headeronly, 600 restore sequence, 608 rollforward set, 608 różnicowa kopia zapasowa, 598 różnicowe częściowe kopie zapasowe, 599 secondary datafile, 590 sekwencja odtwarzania, 608 sp_helpdb, 588, 596 sprawdzenie błędów sprzętu lub serwera, 609 SSMS, 586 stany bazy danych, 587 stany plików dzienników, 591 strony danych, 593 system plików, 591 systemowa baza danych, 587 systemowe konto lokalne, 587 szczegóły techniczne tabel i indeksów, 594 tabele, 589 tabele spartycjonowane, 589 tabele systemowe, 589 tabele tymczasowe, 589 tempdb, 588 transaction log, 592 Transact-SQL, 588, 590 tworzenie kopii zapasowych, 602 tworzenie kopii zapasowych dziennika transakcyjnego, 604 tworzenie kopii zapasowych systemowych baz danych, 599 typy danych, 594 typy kopii zapasowych, 597 urządzenia do wykonywania kopii zapasowych, 595 uwierzytelnianie, 586 uwierzytelnianie usługi, 586 uwierzytelnianie użytkownika, 586 WAL, 592 wersje, 586 weryfikacja kopii zapasowych, 600 wolna przestrzeń, 593
wykonywanie migawkowych kopii zapasowych, 594 zarządzanie pamięcią, 590 zmniejszanie rozmiaru dziennika fizycznego, 593 SQL Server 2005, 585 SQL Server Management Studio, 586 SQL*Plus, 452 sqlplus, 481 SRM, 716 SRS, 626 ssh, 115, 146 SSMS, 586 stacking, 318 stały strumień danych, 288 standardowy format archiwizacji, 260, 261 cpio, 261 ditto, 261 dump, 261 tar, 261 stderr, 119 stdin, 117 stdout, 117 stertowanie, 318 Storage Area Network, 155, 712 storage engine, 659 Storage Manager, 540 storage resource management, 716 strata danych, 28 strategia, 74 archiwizacja danych, 716 strefowanie twarde, 728 WWN, 728 strefy, 728 stripping, 534 strona, 427 Sybase, 523 strony danych, 593 struktura bazy danych, 421 stunnel, 199 subfile incremental backup, 679 Super DLT, 296 Support Media, 368 surowa partycja, 523 swinstall, 377 Sybase, 430, 442, 515 aktualizacja statystyk, 532 alokacja pamięci współdzielonej, 551 architektura bazy danych, 516
Skorow dz
|
757
Sybase archiwizacja serwera, 534 ASE, 515, 519 automatyzacja kopii zapasowych, 536, 538 awaria urządzenia dyskowego, 552 backup server, 520, 528, 540 baza danych, 520 bcp, 517 błąd podstawowego urządzenia master, 552 bsp, 517 conocne wywołania dbcc, 531 Database Consistency Checker, 530 dbcc, 530 default, 524, 526 disk striping, 534 DML, 522 dsedit, 518 DSQUERY, 519 dsync, 523 dump, 534 dziennik błędów serwera, 550 dziennik transakcyjny, 525 edytor pliku interfaces, 518 eksportowanie tabel, 517 ekstent, 523 fail over, 518 fizyczna kopia zapasowa, 540 gorąca kopia zapasowa, 529 importowanie tabel, 517 indeksy, 522 indeksy klastrowe, 522 indeksy nieklastrowe, 522 informacje niezbędne do odtworzenia bazy, 554 interfaces, 518, 528 isql, 517, 548 kompresja kopii zapasowej, 535 kopia zapasowa serwera, 534 książka operacyjna, 536 LD_LIBRARY_PATH, 519 load, 542 load database, 555 load transaction, 543 logiczna kopia zapasowa, 538 logsegment, 524, 526 ładowanie bazy danych, 555 master, 521 max online engines, 520 mechanizm kopii lustrzanych, 534 mirroring, 534
758
|
Skorow dz
model, 521 naprawa bazy, 548 odblokowanie procesów, 549 odporność na awarie, 530 odtwarzanie bazy danych, 554 odtwarzanie danych, 541 odtwarzanie danych do określonego punktu czasu, 543 odtwarzanie danych w przypadku katastrofy, 541 odtwarzanie danych z kopii, 542 odtwarzanie danych ze skompresowanych kopii, 544 odtwarzanie logicznej kopii zapasowej, 539 online database, 543, 555 PATH, 519 plik danych, 523 plik interfejsów, 528 plik konfiguracyjny, 525 podział kopii zapasowej, 535 polecenia wiersza poleceń, 517 połączenie z serwerem, 548 ponowne uruchomienie serwera, 550 problemy z uruchomieniem serwera, 550 procedura naprawcza bazy danych, 548 procedury, 544 procedury składowane, 522 prowadzenie książki operacyjnej, 536 przestrzenie tabel, 524 przetwarzanie symetryczne, 520 przygotowanie danych do audytu, 540 reorg, 532 restore, 534 schemat bazy danych, 520 segment, 524 serwer, 516, 519 shutdown nowait, 546 shutdown with nowait, 546 silnik, 520 skrypt aktualizujący statystyki, 537 skrypt archiwizacji, 536 skrypt tworzący kopię plików dzienników transakcyjnych, 538 sp_addsegment, 524 sp_helpdb, 533 sp_helpdevice, 533, 553 sp_who, 549 sprawdzanie stanu bazy, 530 sprawdzanie zawartości dziennika błędów serwera, 550
sprawdzenie działania serwera, 545 Storage Manager, 540 stripping, 534 strona, 523 surowa partycja, 523 SYB_BACKUP, 545 SYB_MYDB, 545 SYBASE, 519 SYBASE.csh, 528 SYBASE.sh, 528 SYBASE_ASE, 519 SYBASE_OCS, 519 sybsystemdb, 521 sybsystemprocs, 521 sygnał kill -15 wysłany do procesu dataserver, 547 syslogs, 525 system, 524 tabele, 521 tabele stron typu, 522 tabele systemowe, 522 tempdb, 521, 524 tmpfs, 523 transakcje, 521 tworzenie fizycznych kopii zapasowych, 540 tworzenie kopii zapasowej serwera, 534 tworzenie logicznej kopii zapasowej, 539 uruchamianie bazy, 555 uruchamianie serwera, 544 urządzenia, 523 urządzenie zrzutu, 529 ustawianie opcji bazy danych, 547 ustawianie opcji serwera, 547 usuwanie uszkodzonej bazy, 554 weryfikacja konfiguracji, 533 wysyłanie e-mailem wyniku poleceń crontab, 538 wywoływanie poleceń SQL, 517 wywoływanie zapytań, 548 zabezpieczanie bazy danych, 529 zamknięcie serwera bez oczekiwania, 546 zamykanie serwera, 546 zapełnienie dziennika transakcyjnego, 526 zatrzymanie tworzenia dziennika, 549 zimna kopia zapasowa, 529 zmiana organizacji danych w tabelach, 532 zmiana rozmiaru dziennika transakcyjnego, 527
zmienne środowiska, 519 zrzut, 529 zwykłe zamknięcie serwera, 546 SYBASE, 519 Sybase Backup Server, 519 SYBASE.csh, 528 SYBASE.sh, 528 SYBASE_ASE, 519 SYBASE_OCS, 519 symmetric multiprocessing, 520 sysaux, 455 sysback, 699 syscatspace, 562 sysidcfg, 334 syslogs, 525 Sysmaster, 430 system, 524 system archiwizowania i odtwarzania, 27 system ciągłej ochrony danych, 241 system HA, 37 System Independent Data Format, 262 system kontroli wersji, 137 system managed spaces, 561 system niemal ciągłej ochrony danych, 205, 241 system plików, 43, 232 HFS+, 82, 87, 92 podłączany za pośrednictwem sieci, 248 system Mac OS, 82 UFS, 82 urządzenia NAS, 721 urządzenia SAN, 721 XFS, 106 system RDBMS, 434 system rozpoznawania nośnika, 695 system tworzący archiwa, 253 szybkość tworzenia kopii zapasowych, 56 szyfrowanie, 266 kopie zapasowe, 156 po stronie klienta, 156
Ś ścieżki archiwizacji danych w sieci, 258 śledzenie plików, 202 średni czas międzyawaryjny, 276 średnia prędkość transferu, 278 środki finansowe niezbędne do archiwizowania, 76
Skorow dz
|
759
T tabela partycji, 348 tabela zawartości z woluminu archiwizacyjnego, 115 tabele, 423 BLOB, 422 DB2, 558 indeksy, 425 Oracle, 453 partycjonowanie, 429 spartycjonowane, 589 SQL Server, 589 struktura, 424 Sybase, 521 wirtualne, 425 tablespace, 524, 648 tar, 30, 44, 85, 127, 144, 261, 652 archiwizacja, 127 lista plików standardowego wejścia, 128 odtwarzanie danych, 129 odtwarzanie danych do alternatywnej lokalizacji, 133 odtwarzanie wybranych elementów kopii zapasowej, 130 opcje, 128 przenoszenie katalogu, 132 rozmiar bloku, 128 składnia, 127 szukanie wszystkiego, co jest zawarte w katalogu, 132 urządzenie, 128 wersja GNU, 129 współczynnik bloków, 128 wzorzec, 128 zmiana właściciela, uprawnień i atrybutów, 131 znaki wieloznaczne, 131 taśmy, 38, 276 magnetowidowe, 291 tbtape, 442 TCO, 711 TCP, 186 TCP/IP, 712 techniczna specyfikacja, 77 technika obrazów, 720 tempdb, 524, 588 tempspace1, 562
760
|
Skorow dz
testowanie odtwarzanie kopii zapasowych, 236 usługi wybranego dostawcy przechowywania kopii, 68 testowanie kopii zapasowych, 69 częstość operacji, 70 Text, 649 TFTP, 370 Tiger, 83 TLS, 186, 199 tmpfs, 523 tradycyjna architektura archiwizacji, 306 Transact-SQL, 588, 590 transakcje, 430 ACID, 434 DB2, 562 dziennik transakcji, 431 Exchange, 616 MySQL, 664 Oracle, 457 Sybase, 521 wycofanie, 430 zatwierdzanie, 431 złożone, 430 truncate log on checkpoint, 534 trwałość, 434 TSM, 572 tworzenie fizyczna kopia zapasowa bazy danych, 436 kopia zapasowa serwerów VMware, 677 kopia zapasowa ulotnych systemów plików, 685 logiczna kopia zapasowa bazy danych, 437 ładowalny dysk CD/DVD, 397 punkt przywracania, 90 twos complement, 696, 697 tygodniowa pełna kopia zapasowa, 53 tygodniowa pełna kopia zapasowa i codzienne kopie poziomów, 53 tygodniowa pełna kopia zapasowa i codzienne różnicowe kopie poziomu 1, 53 typy interfejsów, 264 typy napędów, 696
U UDO, 300, 301, 303 udoskonalanie poziomu usług, 711 UFS, 82
ufsdump, 93, 101, 686 opcje, 101 ulimit, 397 ulotne systemy plików, 681 brakujące pliki, 682 ekstremalne testowanie kopii zapasowych, 683 migawki, 685 nieczytelna kopia zapasowa, 683 tworzenie kopii zapasowych, 685 uszkodzona kopia zapasowa, 683 uszkodzone pliki, 682 więzy integralności, 682 Ultra Density Optical, 303 undo_retention, 457 Unix File System, 82 update index statistics, 537 update statistics, 532, 533, 537 uproszczenie wykonywania kopii, 64 UPS, 37 uruchamianie serwer Sybase, 544 system z alternatywnego nośnika, 342 urząd certyfikacji, 199 urządzenia archiwizujące, 275 cykl roboczy, 277 czas dostępu do danych, 281 częstość wymiany nośnika, 285 czynniki decyzyjne, 275 docelowe magazyny dyskowe, 305 elastyczność, 279 kasety, 286 kompresja, 284 koszt, 283 kupno, 275 MTBF, 276 napędy dyskowe, 280 napędy optyczne, 279, 298 napędy taśmowe, 279, 287 niezawodność, 276 pojemność, 282 prawie lokalne magazynowanie danych, 287 prędkość transferu, 278 przenośność, 283 RAID, 277 taśmy, 276 zastosowanie, 284 zautomatyzowany sprzęt archiwizujący, 303 zewnętrzne magazynowanie danych, 287
urządzenia peryferyjne, 44 wielodyskowe, 45 use_db_recovery_file_dest, 458 userexit, 566 userspace1, 562 usługa NIS+, 178 uszkodzenie danych, 694 uszkodzona taśma, 695 uszkodzone archiwum, 701 uszkodzony dysk, 704 utraceni klienci, 33 utrata danych, 32 utrata głównej bazy danych, 445 utrzymywanie archiwów danych, 251 uwierzytelnianie komputer, 265 użytkownik, 266 użyteczność danych po odtworzeniu, 717
V V$DATAFILE, 481 V$LOG, 481 V$LOGFILE, 481 V$TABLESPACE, 481 Value DLT, 297 value-added reseller, 696 VAR, 696 vdump, 93 Veritas Volume Manager, 44 vfstab, 47 VMware, 677 architektura, 677 bare metal recovery, 678 ESX, 677 funkcja wstrzymania systemu, 679 kopiowanie maszyn wirtualnych jako maszyn fizycznych, 678 kopiowanie wstrzymanych maszyn wirtualnych, 678 mechanizm migawek, 679 migracja, 680 pliki dziennika wznawiania, 679 procedury niskopoziomowego odtwarzania systemów, 680 przyrostowa kopia zapasowa na poziomie części plików, 679 redo log, 679
Skorow dz
|
761
VMware service console, 677 subfile incremental backup, 679 tworzenie kopii zapasowych, 677 vmware-cmd, 679 volatile filesystems, 681 Volume Shadow Copy Service, 628 VSS, 154, 191 VXA, 298
W WAL, 592, 650, 655 wandalizm, 58 warstwowy magazyn, 303 ważne aplikacje, 235 Web Health Center, 570 wersje narzędzia dump, 106 weryfikacja woluminów, 271 wiadomości pocztowe, 216 widoki, 425 wiele partycji na taśmie, 703 wiele wersji, 267 wielostrumieniowość, 246 wiersz, 426 wieża Hanoi, 54 Windows, 341, 348 Windows Dynamic Drives, 44 Winternals, 366 wirtualna kopia urządzenia, 240 wirtualna kopia zapasowa bazy danych, 240 wirtualne biblioteki taśmowe, 280, 307, 310 wady, 312 wyciąganie wirtualnej taśmy, 313 zalety, 310 wirtualne tabele, 425 wirusy, 205, 713 własna prędkość transferu, 278 własność intelektualna, 715, 722 woluminy, 38 word wide name zoning, 728 WORM, 283, 300 write ahead log, 650 write ahead logging, 647 Write-Once-Read-Many, 300 współczynnik bloków, 105 współczynnik wielkości bloku, 699 wtórna prezentacja, 316 WWN zoning, 728 wx-console, 196
762
|
Skorow dz
wybór metody archiwizowania danych, 56 wycofywanie transakcji, 650 wykluczanie plików, 264 wykonywanie duplikatów woluminów na potrzeby przechowywania na zewnątrz firmy, 263 wykrywanie intruzów, 201 wymagany poziom zabezpieczeń, 36 wymienne wtyczki silników składowania, 659 wymogi czas odtwarzania, 724 proces odtwarzania danych, 35 punkt w czasie, 724
X xdump, 93 XFS, 106 xfsdump, 93, 106 xtar, 83, 86
Z zabezpieczenia, 37 zabrudzona taśma, 695 zagrożenia krytyczny system, 725 nośniki sieciowe, 712 zakresy, 428 Oracle, 454 zamykanie serwera Sybase, 546 zapis barwiony polimeru, 300 dane na taśmie, 38 liniowy, 292 optyczny, 299 ukośny, 290 zarchiwizowane informacje, 60 zarządzanie cykl życia informacji, 256 kopie zapasowe, 44 magazyn danych, 250 taśmy, 162 zasoby składowania, 716 zasobniki, 293 wirtualne taśmy, 318 zastosowanie sprzętu archiwizującego, 284 zatwierdzanie transakcji, 431
zautomatyzowany sprzęt archiwizujący, 303 automatyczna zmieniarka, 304 biblioteka, 304 nierozszerzalne, 304 podłączalne, 304 rozszerzalne, 305 silos, 304 warstwowy magazyn, 303 zdalne elektroniczne składowanie danych, 69 zewnętrzne magazynowanie danych, 287 zgodność wstecz, 717 zimna kopia zapasowa, 436, 720 Oracle, 464
zintegrowana wirtualna biblioteka taśmowa, 313 ZIP, 84 zjawisko pucowania, 285 złożona transakcja, 430 zmiana produktu archiwizującego, 234 zmiennofazowa metoda zapisu, 300 znacznik końca nośnika, 701 znaczniki BSD, 141 zrzut dziennika transakcji, 438
Ż żywotność nośników, 717
Skorow dz
|
763
764
|
Skorow dz
O autorze W. Curtis Preston w ochronie danych specjalizuje się od 1993 roku, gdy był odpowiedzialny za kopie zapasowe w firmie zarządzającej kartami kredytowymi o wartości 35 miliardów dolarów amerykańskich, w której wymagana była dostępność w trybie 24/7. Właśnie w tej pracy Curtis dokonał pierwszego w swoim życiu wyboru komercyjnego oprogramowania do wykonywania i odtwarzania kopii zapasowych. Opuścił tę firmę, aby jak to określił, „uwolnić się od kopii zapasowych i zająć się prawdziwą administracją”. Jego nowym pracodawcą była inna wielka korporacja, która jak się okazało, nie miała porządnego systemu do zarządzania kopiami zapasowymi. I to by było na tyle, jeśli chodzi o unikanie kopii zapasowych. Skrypt do wykonywania kopii zapasowych bazy Oracle, który napisał, okazał się na tyle użyteczny, że zdecydował się opisać go w swoim pierwszym artykule. Około setki e-maili z całego świata wystarczyło, aby zaszczepić w Curtisie zamiłowanie do pisania. Nagle zdał sobie sprawę z tego, że istnieje spore zapotrzebowanie na wiedzę, którą zgromadził na przestrzeni lat. Natychmiast rozpoczął pracę nad swoją pierwszą książką, Unix Backup & Recovery. Po niej napisał sporo artykułów, po czym przystąpił do pisania następnej książki, Using SANs and NAS, oraz odbył sporo podróży po świecie z wykładami o tej tematyce. Curtis świadczył usługi konsultingowe z zakresu ochrony danych największym firmom na świecie, wliczając w to trzy z pierwszej dziesiątki rankingu Fortune. Curtis jest obecnie wiceprezesem działu ochrony danych w GlassHouse Technologies, największej firmie oferującej profesjonalne usługi w dziedzinie technologii składowania danych, wliczając w to pełne zarządzanie systemami kopii zapasowych. Jest przez wielu fachowców uważany za największego eksperta od kopii zapasowych i ochrony danych.
Kolofon Zwierzę z okładki tej książki to gawial (zwany również gawialem gangesowym), mieszkaniec głębokich, rwących rzek w Indiach i krajach sąsiedzkich. Wyrastający do siedmiu metrów gawial należy do największych przedstawicieli rzędu krokodyli. Jego charakterystyczną cechą jest niezwykle długi i wąski pysk. Ten pysk, najeżony ostrymi zębami, jest doskonałym narzędziem do łapania ryb, które są podstawowym pożywieniem gawiala. Wąski kształt wpływa na obniżenie oporu wody, dzięki czemu zwierzę może podczas polowania z bardzo dużą prędkością obracać głową na boki. Duża liczba ostrych zębów pomaga przytrzymać wyrywające się, śliskie ryby. Krótkie, słabo umięśnione nogi gawiala powodują, że po lądzie porusza się dość nieporadnie, dlatego wychodzi z wody jedynie po to, aby złożyć jaja i wygrzewać się w słońcu. Gawial, jak większość krokodyli, jest często oskarżany o polowanie na ludzi. Znacząco przyczyniły się do tego znajdowane w trzewiach gawiala ludzkie szczątki oraz ozdoby, ale prawdopodobnie prawdziwym powodem są tu zwyczaje pogrzebowe Hindusów, polegające na paleniu zwłok na brzegach rzek w okolicach zamieszkiwanych przez gawiale. W praktyce można stwierdzić, że anatomia gawiala jest w takim samym stopniu nieprzystosowana do pożerania ludzi, w jakim jest przystosowana do pożerania ryb. Gawiale są gatunkiem zagrożonym, a w latach siedemdziesiątych były bliskie wyginięcia. Dzięki staraniom przyrodników udało się zachować ten gatunek. Od lat siedemdziesiątych gawiale są pod ochroną, ale nadal zdarzają się przypadki kłusownictwa ze względu na pyski, które są uznawane za afrodyzjak. Gawiale wpadają też w sieci rybackie, co również bywa przyczyną śmierci. Jak to skomentował autor książki: „Duże, przerażające, brzydkie stworzenia, które nie stanowią zagrożenia dla ludzi… Zupełnie jak kopie zapasowe!”. Ilustracja na okładce to dziewiętnastowieczna rycina pochodząca z Dover Pictorial Archive.
![2009.03_Technologie OLAP i Data Mining_[Bazy Danych]](https://docer.tips/img/300x300/200903technologie-olap-i-data-miningbazy-danych_5a68d329d64ab21fc1ee44e3.jpg)
