SIECIOWY SYSTEM ARCHIWIZACJI I BACKUPU DANYCH | ||||||||||||||||||||||
Identyfikator artykułu : FS-FBS-20060427-I01 Ostatnia weryfikacja : 29 listopad 2011 Wersja : 1.1 Archiwizacja (backup) otwartych i zablokowanych plikówArtykuł omawia zagadnienia związane z tzw. problemem archiwizacji (backupu) otwartych plików. Wyjaśnia co to są otwarte pliki, powody dla których niektóre pliki są blokowane i pokazuje w jaki sposób taka blokada jest realizowana. Na zakończenie proponowane są dwa różne mechanizmy umożliwiające rozwiązanie problemu archiwizacji otwartych plików.Blokowanie plików przez systemy operacyjneMechanizmy blokowania plików (ang. file locking) są stosowane we wszystkich wielozadaniowych systemach operacyjnych. W niektórych blokady plików są obowiązkowe (np. Microsoft Windows) a w innych opcjonalne (np. UNIX).Poniżej zajmiemy się tylko takimi przypadkami, w których blokady plików są obowiązkowe (ang. mandatory locking), ponieważ tylko w takich przypadkach występuje problem związany z tzw. archiwizacją otwartych plików. Każdy kto musiał kiedyś wykonać kopię bezpieczeństwa ważnych plików stanął zapewne przed takim oto faktem: plik, który trzeba zarchiwizować jest w trakcie wykonywania kopii bezpieczeństwa pomijany lub pojawia się błąd informujący, iż system nie może uzyskać dostępu do pliku ponieważ jest on używany przez inny proces. Rys. 1 Błąd kopiowania zablokowanego pliku "system" Jeśli Ty również spotkałeś się z podobnym problemem lub masz zamiar archiwizować bazę danych, pliki systemowe lub inne pliki używane przez inne aplikacje, do których dostęp jest zablokowany przez system operacyjny, powinieneś zapoznać się z poniższym tekstem. Kilka chwil związanych z jego lekturą na pewno się przyda i prędzej czy później, będziesz mógł zastosować opisane tu informacje w praktyce. Prawa dostępu i tryby współdzieleniaKażdy proces otwierający plik musi podać tryb dostępu (ang. access mode) jakiego potrzebuje oraz tryb współdzielenia. Poprzez wskazanie trybu dostępu proces informuje system operacyjny w jakim celu plik jest otwierany. Dostępne są trzy tryby dostępu: do odczytu, do zapisu, do odczytu i zapisu. Jeżeli określona proces otwiera plik tylko po to, aby odczytać jego zwartość otworzy plik z prawami do odczytu. Jeśli chce wprowadzić do pliku zmiany, musi otworzyć plik z prawem do zapisu lub z prawem do odczytu i zapisu.
Tabela 1. Tryby dostępu do pliku Drugim parametrem, który musi być zdefiniowany przez proces chcący uzyskać dostęp do pliku, jest tryb współdzielenia (ang. sharing mode). Dzięki temu system operacyjny będzie wiedział czy kolejna aplikacja (proces), próbująca otworzyć plik, ma mieć taką możliwość czy należy jej odmówić. Dostępne są cztery tryby współdzilenia: brak zezwoleń, zezwalaj na odczyt, zezwalaj na zpis, brak ograniczeń. Dzięki trybom współdzielenia procesy mogą (z pomocą systemu operacyjnego) blokować dostęp do plików, do których uzyskały dostęp jako pierwsze.
Tabela 2. Tryby współdzilenia pliku Mechanizmów blokowania plików nie należy mylić z zasadami zabezpieczeń i prawami nadawanych przez administratora systemu użytkownikom czy też atrybutami plików. W niniejszym artykule interesuje nas jedynie przypadek, w którym proces otwiera plik w trybie wyłączności (ang. exclusive lock), przez co całkowicie blokuje dostęp do niego innym procesom, uniemożliwiając jego odczytanie lub wykonanie kopii. Nie będziemy rozpatrywać sytuacji, w której nie jest możliwy zapis do pliku lub jego usunięcie, ponieważ nie są to zagadnienia związane z procesem archiwizacji danych. Kto i dlaczego blokuje pliki ?Mechanizmy blokowania plików (ang. file locking) służą do ochrony danych i ich struktury. Dostęp do pliku może być zablokowany (z pomocą systemu operacyjnego) przez proces, który już uzyskał do niego dostęp przez otwarcie lub utworzenie. Mechanizmy blokowania plików pozwalają na przeprowadzenie operacji zapisu lub odczytu danych w sposób atomowy. Przy operacjach tego typu wymagane jest , aby zasób (plik lub jego część) był przez pewien okres niepodzielny. Oznacza to, że w danym momencie dostęp danego typu może uzyskać tylko jeden proces.Wyobraźmy sobie taką sytuację: Proces A zapisuje w kilku miejscach w pliku wyniki obliczeń lub zmienia kilka rekordów w bazie danych, proces B w tym samym czasie odczytuje plik. Dane, które zostaną przeczytane przez proces B mogą być niekoherentne i najprawdopodobniej nie będą nadawały się do użytku. Aby ustrzec się przed możliwością odczytu (np. w celu wykonania kopii bezpieczeństwa) danych, które nie są spójne z punktu widzenia danej aplikacji ( np. systemu bazodanowego), pliki są blokowane w trybie exclusive bez prawa do odczytu. przez inne procesy. Operacje atomowe, takie jak zapis lub odczyt pewnej porcji danych (transakcji), trwają zazwyczaj bardzo krótko, jednak blokada nakładana na plik i uniemożliwiająca jego odczyt jest, w bardzo wielu przypadkach, aktywna nie tylko w czasie przeprowadzania operacji atomowych, ale od czasu otwarcia aż do zamknięcia pliku przez proces.
Taki schemat postępowania jest stosowany w większości wypadków przez aplikacje bazodanowe, które z założeń jakie przyjęto przy ich projektowaniu będą jedynymi "właścicielami" pliku bazy danych i tylko one powinny mieć do niego dostęp. Odczyt pliku bazy danych w tym samym czasie przez inne aplikacje nie jest , z punktu widzenia danego systemu bazodanowego, potrzeby nawet do zachowania równoczesnego dostępu do bazy przez wielu użytkowników . Dodatkowo otwarcie pliku przez inny proces mogłoby zakłócić pracę silnika bazodanowego, uniemożliwiając np. przeprowadzenia transakcji w odpowiednim czasie. Z tych względów oraz w celu uproszczenia implementacji często stosuje się blokady plików, które są aktywne praktycznie przez cały czas i tym samym nie pozwalając aplikacjom archiwizującym na wykonanie kopii bezpieczeństwa. Najczęściej w stanie zablokowanym znajdują się pliki systemowe (np. pliki rejestru systemowego w systemach rodziny Winodws NT), bazy danych (Lotus Notes, Oracle, Microsoft SQL Serwer, Microsoft Access, MySQL, PostgreSQL), pliki systemów pocztowych oraz pliki programów graficznych. Archiwizacja zablokowanych plików przy zastosowaniu Ferro Backup SystemFerro Backup System od wersji 2.4 umożliwia archiwizację zablokowanych plików czyli plików będących w użyciu przez inne aplikacje. Opcja Open File Manager dostępna jest w standardowej wersji (również w wersji demonstracyjnej).Podczas archiwizacji możliwe są dwa scenariusze, w których następuje uruchomienie Open File Manager'a przez modul wykonywania zadań FBS Worker:
W pierwszym wypadku Open File Manager zostanie aktywowany, jeśli otwarcie pliku w sposób standardowy (za pomocą funkcji systemowych) nie powiedzie się w n/2 próbach. Parametr n oznacza liczbę prób otwarcia pliku i jest ustalany module centralnego zarządzania FBS Server. Druga sytuacja zachodzi czasem w przypadku plików baz danych i arkuszy kalkulacyjnych. Program bazodanowy lub arkusz kalkulacyjny może podczas wykonywania zapisu blokować w trybie wyłączności część pliku. Każdy program archiwizujący może bez przeszkód otworzyć taki plik z prawem do odczytu. Problem pojawi się jednak dopiero podczas próby odczytania zablokowanego fragmentu - operacja zostanie przerwana a system wygeneruje wyjątek informujący, że określona część pliku jest zablokowana przez inny proces. W takim wypadku FBS Worker ponownie otwiera plik tym razem przy użyciu Open File Menager i bez problemu kopiuje całą zawartość pliku. Wiemy już zatem w jaki sposób i kiedy OFM jest aktywowany. W dalszej części tego artykułu omówiony zostanie schemat działania menadżera otwartych plików. Open File Manager - backup otwartych plikówW przypadku napotkania zablokowanego pliku archiwizacja danych odbywa się z pominięciem systemu operacyjnego. Open File Menager uzyskuje bezpośredni dostęp do dysku twardego, pomijając w ten sposób blokady jakie nakłada na plik system operacyjny. W ten sposób może odczytać wszystkie informacje zapisane na dysku niezależnie od innych aplikacji i samego systemu operacyjnego.Klaster to najmniejsza, jednostkowa porcja danych dostępna na poziomie systemu plików. Każdy plik zajmuje na dysku pewną liczbę klasterów, których liczba zależy od wielkości pliku i rozmiaru klasterów. Rozmiar klasterów jest stały i jest ustalany podczas formatowania partycji (FAT) lub woluminu (NTFS). Plik może być zapisany w kolejno następujących po sobie klasterach lub może być pofragmentowany, a poszczególne jego części mogą być przechowywane w różnych miejscach na dysku. Informacje o tym które klastery zajmuje określony plik są przechowywane w tabeli alokacji. Dla systemu FAT jest to File Allocation Table, a dla NTFS Master File Table. Aby móc odczytać plik trzeba zatem najpierw odczytać dane na temat pliku z tabeli alokacji, której struktura w przypadku systemu FAT i NTFS jest całkowicie różna. Open File Manager obsługuje oba systemy plików, które dodatkowo mogą występować w różnych wersjach: FAT 12, FAT 16, FAT 32, NTFS 4.0, NTFS 5.0, NTFS 5.1. Rys. 3 Dysk podzielony na woluminy NTFS i FAT Niskopoziomowy dostęp do dysku realizowany przez Open FIle Manager polega zatem na wczytaniu tablicy alokacji plików, odczytaniu z niej wirtualnej i logicznej lokalizacji klasterów wskazujących fragmenty określonego pliku oraz odczycie danych zapisanych w tychże klasterach. OFM stosuje dodatkowe techniki zabezpieczające przed odczytem niespójnych danych. Jeżeli plik jest odczytany przez OFM to znaczy, że jest on spójny (koherentny). W przypadku baz danych będzie to stan po zakończeniu transakcji. Porównanie Volume Shadow Copy Service (VSS) i Ferro Backup System OFMW systemach Windows XP oraz Windows 2003 została wprowadzona usługa kopiowania woluminów w tle (Volume Shadow Copy Service). Usługa ta daje możliwość m.in. archiwizacji zablokowanych plików. Daje możliwość otwarcia i skopiowania dowolnego pliku w każdym momencie. Niestety stosowanie VSS jest dość mocno ograniczone, przez co nie będzie go można wykorzystać w wielu sytuacjach.
Jak już wspomnieliśmy usługa ta pozwala na archiwizację plików zablokowanych, jednak zarówno program archiwizujący, jak i program który zablokował plik muszą być zgodne z VSS. Oznacza to, że aplikacja (np. bazodanowa), której pliki chcemy archiwizować, musi być napisana specjalnie na platformę Windows XP/2003 i wykorzystywać mechanizmy kopiowania w tle. W chwili obecnej jednak niewiele aplikacji sygnowanych inną marką niż Microsoft jest kompatybilnych z tą technologią Poza tym również aplikacja archiwizująca musi być zgodna z VSS. Program wykonywania kopii zapasowych dołączony do systemu Windows XP i Windows Server nie posiada jednak takiej zdolności. Kolejnym ograniczeniem VSS jest to, że zarówno aplikacja archiwizująca, aplikacja która zablokowała plik oraz sam plik muszą znajdować na tym samym komputerze. Jeżeli plik jest zablokowany przez aplikację zdalną uruchomioną na innym komputerze to archiwizacja nie powiedzie się. Jeśli plik oraz aplikacja, która ma do niego wyłączny dostęp znajdują się na jednym komputerze, ale aplikacja archiwizująca próbuje odczytać plik poprzez sieć to również archiwizacja nie będzie skuteczna. Inną niedogodnością jest to, że kopiowanie woluminów w tle wymaga określonej ilości wolnego miejsca na dysku. Przestrzeń ta wykorzystywana jest do wykonywania migawek (ang. snapshot) woluminu. Jeżeli na dysku nie ma wystarczającej ilości wolnego miejsca to archiwizacja zablokowanych plików również nie będzie możliwa. Są jednak zastosowania, w których VSS sprawdzi się lepiej niż FBS OFM. Jeżeli mamy serwer z systemem MS Windows Server 2003, na którym są uruchomione programy takie jak Microsoft Exchange Server 2003 i Microsoft SQL Server 2000 operujące na dużych bazach danych to lepiej wykorzystać usługę kopiowania woluminów w tle oraz odpowiedni program do archiwizacji danych zgodny z tą technologią. Wymienione wcześniej ograniczenia sprawiają, że zastosowanie mechanizmy kopiowania woluminów w tle do archiwizacji otwartych plików jest jednak dość ograniczone:
Zobacz też
|
||||||||||||||||||||||
Archiwizacja otwartych plików, backup zablokowanych plików Wszelkie prawa zastrzeżone. © 2000-2024 FERRO Software |