次の方法で共有

Shadow copy i VSS czyli usługa kopiowania woluminów w tle

  • [アーティクル]

Wiele razy zarówno na tym blogu jak i podczas rozmaitych spotkan "na zywo" obiecywalem, ze w koncu VSS opisze. Obietnice braly sie glównie stad, ze VSS okazuje sie calkiem uzyteczna funkcjonalnoscia a tak naprawde malo kto jej skutecznie i swiadomie uzywa.  Zeby nie pominac niczego waznego, postaram sie przyblizyc VSS od sposobu jego dzialania az po zastosowania praktyczne. Pomine za to czesc zagadnien zwiazanych z wykorzystujacymi VSS operacjami backup/restore wykonywanymi przez aplikacje. Od razu przepraszam za jezykowe potworki. Nie umialem znalezc polskich odpowiedników dla niektórych slów i zamiast kombinowac, po prostu zostawilem angielskie.

Idea

Od strony zalozen, VSS przedstawia sie stosunkowo prosto: dane na dysku skladaja sie z bloków. Kazdy odczyt danych to wczytanie bloku z woluminu a zapis – zapisanie go na dysk. Zapis danych na dysku nadpisuje dane, które w danym miejscu (na przyklad w tresci dokumentu) lezaly wczesniej. A gdyby tak powiedziec woluminowi, zeby przed nadpisaniem danego bloku wykonal jego kopie gdzies na boku? Mielibysmy zapisane wszystkie dane, ale równoczesnie szanse na powrót do ich wersji sprzed ostatniego zapisu. Operujemy na blokach dlatego, ze jeden plik zwykle ma wiele bloków, wiec jezeli zmieni sie tylko jego fragment, to nie musimy kopiowac tego, co i tak pozostaje na dysku bez zmian. Tak jest oszczedniej, a skoro dane w innych blokach sie nie zmienily, to i tak poskladamy z tego co mamy poprzednia wersje pliku.

Implementacja

Mniej wiecej 10 lat temu, w systemie Windows XP, opisana powyzej idea zostala zaimplementowana w praktyce. Oczywiscie, calosc okazala sie nie taka prosta, jak to na pierwszy rzut oka wyglada. Wprawdzie automatyczne przepisywanie nadpisywanych danych w specjalne miejsce nie jest niczym bardzo skomplikowanym, ale diabel tkwi w dwóch szczególach: w spójnosci i w interfejsach. Na poczatek interfejsy, bo to prostsze, przynajmniej na poziomie, na którym VSS poznac powinien typowy ITPro. Zasadniczo, chodzi o to, zeby miec jak zarzadzac tymi kopiami i miec jak dotrzec do starszych, teoretycznie nadpisanych juz danych. Zarzadzanie obejmuje takie aspekty jak na przyklad ilosc miejsca przeznaczonego na wykonane kopie czy tez ich lokalizacje. Dotarcie do danych zostanie jeszcze szerzej omówione, ale rzecz w tym, ze proste podanie poprzedniej zawartosci bloku to zwykle troche za malo. Administrator czy uzytkownik woli operowac znanymi sobie pojeciami pliku, sciezki czy folderu. Wiadomo, ze pod spodem sa bloki, ale z wyjatkiem bardzo specjalnych sytuacji, dostep na tak glebokim poziomie jest zupelnie bezuzyteczny.

Od razu dotkne kwestii miejsca na kopie nadpisanych bloków. W przypadku opisywanego tu systemowego mechanizmu, ilosc miejsca okresla administrator i jezeli zostanie ono w calosci wykorzystane, najstarsze kopie sa nadpisywane. Moze sie przez to zdarzyc, ze jakas naprawde istotna kopia zostanie zniszczona, bo w jej miejscu pojawia sie swiezsze kopie jakichs bzdetów, ale z drugiej strony nie bardzo jest jak podejsc do tematu w inny sposób.

Spójnosc jest tematem duzo ciekawszym. Po pierwsze, w praktyce okazuje sie, ze zapisywanie kazdego zmienionego bloku to troche nieroztropne podejscie. Sa w systemie pliki, które zmieniaja sie co pare sekund, a sa takie, gdzie zmiany zachodza rzadko, za to siegniecie do ich starszych wersji ma dla uzytkownika kluczowe znaczenie. Gdybysmy zapisywali faktycznie kazdy zmieniony blok, to albo kopiami zajmiemy bardzo duzo miejsca albo nadpiszemy to, co wazne. Osobiscie wole moje dokumenty w wersji sprzed tygodnia niz tysiace kopii folderu %temp%. Druga kwestia jest dotarcie do tych danych, które mnie interesuja. Jezeli plik byl nadpisywany dwiescie razy (na przyklad mechanizmami autosave), to czy naprawde chce miec dwiescie kopii? Poza tym, co w sytuacji, gdy potrzebuje odtworzyc wiecej niz jeden plik, bo mam skorelowane ze soba tabele, pliki konfiguracyjne czy cokolwiek innego, gdzie rózne wersje pomiedzy plikami moga byc powodem klopotów?

Zeby rozwiazac ten problem, w systemie Windows zastosowano podejscie polegajace na tworzeniu migawek (zwanych tez przez niektórych snapshotami). To znaczy, nadpisane dane faktycznie kopiowane sa w inne miejsce. Jednak jezeli od pewnego momentu T, dane nadpisywane sa ponownie – ich kolejna kopia archiwalna nie jest wykonywana. Jezeli powiem, ze moim momentem T jest godzina 00:00 kazdego dnia, to pierwsze nadpisanie danych bedzie wiazalo sie z zabezpieczeniem poprzedniej wersji. Kolejne juz nie. Oznacza to, ze tak czesto zmieniajacy sie plik jak i mój wazny, ale tylko raz zmieniony dokument bedzie mial w archiwum jedna kopie. Te z pólnocy. Podejscie takie znaczaco ogranicza rozmiar kopii archiwalnej i zmniejsza ilosc operacji I/O. Dla czesto zmieniajacych sie plików, kolejne zmiany w "normalny" sposób nadpisuja biezaca informacje i nic nie jest kopiowane. Z drugiej jednak strony, oznacza to, ze moge stracic caly dzien pracy. Wprawdzie nadpisujac o 16:59 mój raport dotre do kopii wykonanej o pólnocy, jednak nie mam wersji z 16:50, bedacej wynikiem osmiu godzin stukania w klawiature i skasowanej przez przypadek. Trudno. Cos za cos. Nalezy jednak pamietac, ze podana wczesniej godzina 00:00 to tylko przyklad. Migawke moge wykonac tak czesto jak zechce, oczywiscie w granicach rozsadku, co w praktyce oznacza zwykle raz albo dwa razy dziennie. Prace z calego dnia mozna zwykle wykonac jeszcze raz a zbyt czeste migawki to wiecej klopotu niz korzysci. Cierpi na tym wydajnosc i zajmuja miejsce, w efekcie skracajac czas o jaki mozemy sie cofnac w przeszlosc dzieki naszym kopiom.

OK. Wiemy, ze uzywamy migawek, czyli bloki archiwalne pochodza z danego, okreslonego przez nas momentu w czasie. Byloby to bardzo piekne, gdyby nie to, ze dane na dysku caly czas "zyja". Jezeli zapisujemy na dysku wielki arkusz Excela, to trwa to pare chwil. A jezeli wlasnie w tym czasie nadejdzie moment zrobienia migawki? Poczatek pliku w migawce ma zupelnie inne pochodzenie niz jego koniec. Zlapalismy przeciez aplikacje w polowie pracy. Duza szansa, ze taki archiwalny plik nie zechce sie otworzyc w sytuacji, gdy bedzie to najbardziej potrzebne. A jezeli nie bedzie to plik *.xlsx tylko baza Active Directory? Repozytorium WMI? Baza SQL? Wtedy okaze sie, ze caly misterny plan spalil na panewce, bo wprawdzie mamy wierna kopie z momentu T, za to jest to kopia bezuzyteczna, bo aplikacja nie umie jej otworzyc. I tu przychodzi z pomoca mechanizm tak zwanych Writers.

VSS Writers

Skoro istnieje ryzyko, ze na przyklad SQL nie odczyta swoich wlasnych plików zapisanych w momencie wykonania migawki, to warto byloby jakos zapobiec takiej sytuacji. Mozna do tego podejsc na przyklad w taki sposób, ze z migawka poczekamy az dane na dysku beda w takiej postaci, ze odczytanie bedzie mozliwe. Tylko jak ten wlasciwy moment okreslic? Oczywiscie najlepiej poinformowany o tym jest sam serwer SQL. Dlatego, system Windows wyposazony zostal w mechanizmy pozwalajace na podlaczanie sie róznych aplikacji i uslug "zainteresowanych" spójnoscia danych na dysku. Taka podlaczona aplikacja rejestruje swój VSS Writer i od tej pory VSS bedzie z nia rozmawial. Rozmowa taka to tak naprawde dwa wazne momenty wymiany informacji:

  • VSS oglasza: Uwaga aplikacjo, bedziemy robic migawke, prosze o przygotowanie sie. Co z ta informacja zrobi aplikacja, to juz jej problem. VSS w to nie wnika, ale dal wszystkim szanse.
  • Aplikacja oglasza: ok, moje dane sa spójne, mozna je zamrozic w takiej postaci i gwarantuje, ze jak bedzie taka potrzeba – przeczytam je i uznam za poprawne.

Dzieki temu, migawka wykonuje sie tak naprawde chwile po zaplanowanym czasie, ale w praktyce nie jest to klopotliwe. Gorzej, gdy do zgloszenia przez aplikacje, ze informacje na dysku sa dobre i spójne mija duzo czasu. Aplikacje maja na to dziesiec sekund, wiec nie powinno zdarzyc sie, ze zle napisany writer cos popsuje, ale jezeli 10s to za krótko – migawka po prostu sie nie wykona.  Jest to o tyle wazne, ze dopóki migawka nie zostanie zrobiona, system (przez wyslanie komunikatu o wdziecznej nazwie IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES) czasowo przestawia sterowniki pamieci masowych w tryb, w którym nowe dane nie sa zapisywane. Wszystko dla spójnosci.

Jezeli kogos znuzylo czytanie – moze zrobic krótka przerwe i w wierszu polecen wpisac sobie polecenie vssadmin list writers. Zobaczy wtedy ile w jego systemie jest chetnych na rozmowe z mechanizmami VSS.

VSS Provider

Drugim okresleniem, istotnym i pojawiajacym sie czesto w parze z VSS Writer, jest VSS Provider. W tym obszarze teoretycznych rozwazan bedzie mniej, bo VSS Provider, to ten, kto faktycznie wykonuje kopie archiwalne zmodyfikowanych bloków. Podejrzenie, ze robi to przeciez sam system operacyjny jest sluszne, ale istnieja przypadki (na przyklad w zaawansowanych macierzach), gdy zajmuje sie tym specjalny sprzet. Ktos to w kazdym razie robic musi a VSS musi byc pewny, ze odpowiedzialny za kopiowanie danych provider wywiaze sie ze swojego zadania. Tak naprawde, od providera zalezy jak to dokladnie sie stanie, ze zostanie zachowana archiwalna kopia danych. Kopiowanie zmienianych bloków do specjalnej lokalizacji to tylko jedna z metod. Systemowi Windows w zaden sposób nie zalezy na szczególach rozwiazania tak dlugo, jak dlugo do starszych danych da sie dotrzec. Skupimy sie jednak na kopiowaniu zmienionych bloków (copy on write) dlatego, ze ta wlasnie metoda wbudowana zostala w systemowego providera (swprv.dll i volsnap.sys) i w efekcie, to wlasnie z nia mamy najczesciej do czynienia. Provider ten kopiuje zmienione bloki do specjalnych plików, które dobrze schowane przed uzytkownikiem znajduja sie w folderze "System Volume Information" na kazdym chronionym woluminie. Jezeli kogos *** obejrzenie ich blizej, pomocny bedzie psexec i wiersz polecen uruchomiony w kontekscie localsystem. Warto tez pamietac o parametrze "/a" polecenia dir. Co ciekawe (ale i oczywiste gdy sie chwile zastanowic), sam folder "System Volume Information" nie jest chroniony mechanizmami VSS. To samo dotyczy plików pagefile.sys i hiberfil.sys, co tez ma swój sens. Gdyby ktos chcial zobaczyc jacy providerzy w jego systemie troszcza sie o dane, wystarczy w wierszy polecen wpisac vssadmin list providers

VSS Requestor

Dla scislosci, trzeba w tym miejscu wspomniec o trzecim elemencie rozwiazan bazujacych na VSS. Requestor, to tak naprawde uzytkownik VSS. Ktos, kto zleca wykonanie migawki, ktos kto do niej siega, ktos kto ja kasuje. Nic niezwyklego, ale dla pelnego obrazu pisze, ze i taki element w swiecie VSS sie pojawia.

VSS Service

No i na koniec zostal koordynator, rozmawiajacy z writerami, providerami i requestorami. W systemie Windows ma on postac uslugi systemowej, której szczególy mozna zobaczyc po wydaniu w wierszu polecen komendy sc qc vss. To on odpowiada za to, co sie dzieje ale jak to z rola zarzadzajacego bywa – jego dzialania sa najmniej spektakularne.

Typy migawek

Jak juz wczesniej napisalem, migawki sa widoczna realizacja calej idei zapewnienia dostepu do archiwalnych kopii danych. Migawka jest wykonywana na zadanie i potem mozna z niej skorzystac. I tu tez okazuje sie, ze calosc nie jest taka zupelnie prosta. Nie dlatego, ze trzeba jeszcze jakies techniczne detale uwzglednic, tylko dlatego ze dla wygody uzytkowników migawki wystepuja w wielu róznych typach, rózniacych sie zastosowaniami. W praktyce typowego ITPro wystarczy wiedziec, ze migawki dziela sie na takie, które po utworzeniu sa widoczne i dostepne dla wszystkich i takie, do których dostep ma tylko ich twórca. Dla migawek spotkac sie mozna równiez z okresleniami:

  • Transportable – czyli dajaca sie (samodzielnie, bez oryginalnego woluminu) przeniesc do innego komputera i tam pozwalajaca na dostep do archiwalnych danych. Tym typem nie bedziemy sie zajmowac, poniewaz systemowy VSS Provider nie tworzy takich migawek
  • Surfaced – czyli taka, która zapisana jest w taki sposób, ze mozna do niej siegnac jak do dysku
  • Exposed – czyli migawka widoczna jako dysk lokalny. Co oznacza równoczesnie, ze kazda migawka typu exposed musi byc typu surfaced.
  • Remotely exposed – czyli widoczna jako dysk dostepny przez siec

Ostatnie trzy okreslenia dotycza widocznosci migawek jako dysków i temu zagadnieniu poswiece dalej jeszcze troche miejsca.
Jezeli ktos chce glebiej podrazyc temat typów migawek, powinien siegnac do MSDN i spojrzec na _VSS_SNAPSHOT_CONTEXT i na _VSS_VOLUME_SNAPSHOT_ATTRIBUTES 

Miejsce na dane archiwalne

Po nieco przydlugim wstepie teoretycznym pora zrobic cos uzytecznego – przygotowac miejsce, w które systemowy provider przepisywac bedzie oryginalne dane pierwszy raz zmodyfikowane od ostatniej migawki. W systemie Windows robi sie to (tak jak i cala mase innych rzeczy zwiazanych z VSS) poleceniem vssadmin. Zeby utworzyc miejsce na dane nalezy wiedziec:

  • Dla którego dysku chcemy archiwizowac modyfikowane dane. Nie kazdy dysk daje sie tak zabezpieczyc, wiec zawsze mozemy sprawdzic czy provider podejmie sie ochrony uzywajac polecenia vssadmin list volumes
  • Na który dysk chcemy je kopiowac. Dane archiwalne nie musza przeciez wcale lezec na tym samym woluminie. Wystarczy zaufac, ze systemowy VSS provider sie w tym nie pogubi.
  • Ile miejsca przeznaczamy na archiwalne bloki z danymi. Wyznaczone miejsce, w czasie pracy VSS stopniowo jest zapelniane a gdy sie zapelni – usuwane sa najstarsze migawki. Niestety bardzo trudno jest przewidziec ile miejsca jest potrzebne, zeby móc siegnac do danych na przyklad sprzed dwóch tygodni. Zalezy to mocno od tego jak wolumin "zyje" i tak naprawde przestrzen musi byc dobrana na podstawie intuicji administratora. Minimum to 300MB chyba, ze wieksza wartosc zostanie ustawiona we wpisie MinDiffAreaFileSize w rejestrze. Domyslne ustawienie 10% objetosci zabezpieczanego woluminu jest calkiem dobre na poczatek. Mozna tez nie podac ile przestrzeni rezerwujemy i wtedy w zaden sposób jej nie limitujemy i najwyzej skonczy sie miejsce na dysku.

Administratorowi wiedzacemu trzy opisane powyzej rzeczy pozostaje wydanie polecenia vssadmin add shadowstorage /for=<ForVolumeSpec> /on=<OnVolumeSpec> [/maxsize=<MaxSizeSpec>]

Z czasem, wyznaczone miejsce sie zapelni i najstarsze dane beda usuwane. Gdyby jednak ktos chcial sprawdzic ile miejsca na kopie archiwalne jest zajete – moze to oczywiscie zrobic: vssadmin list shadowstorage. Ewentualny tuning i zmiana ilosci juz zarezerwowanego miejsca tez jest mozliwa. Jak latwo sie domyslic, robi sie to poleceniem vssadmin, tym razem z parametrami resize shadowstorage. Nalezy pamietac, ze zmniejszenie miejsca moze spowodowac skasowanie najstarszych kopii, jezeli nowa ilosc jest mniejsza niz niezbedna do przechowania tych migawek. Jezeli ktos stwierdzi, ze miejsce na migawki w ogóle jest mu nie potrzebne, tez moze zrealizowac swoje checi wklepujac vssadmin delete shadowstorage. Oczywiscie przechowywane w tym miejscu migawki (wiem, ze takie okreslenie to uproszczenie) przestaja istniec.

Podsumowujac zarzadzanie miejscem na migawki mamy:

  • tworzenie – vssadmin add shadowstorage
  • sprawdzenie – vssadmin list shadowstorage
  • zmiana – vssadmin resize shadowstorage
  • usuniecie – vssadmin delete shadowstorage

Czyli w zasadzie wszystko, co moze byc potrzebne.

Migawki

OK. Mamy miejsce na migawki (a tak naprawde miejsce na archiwalne kopie bloków, które po polaczeniu z blokami niezmienionymi dadza nam pseudowolumin, z którego mozemy odczytac dane), wiec pora jakas migawke zrobic. Od strony administratora to proste, bo wystarczy, ze powie, ze migawke chce miec. Od strony systemu widac jednak, ze duzo sie musi wydarzyc nim migawka sie pojawi. Powiedzenie systemowi "chce migawke teraz" sprowadza sie do wydania polecenia vssadmin create shadow /for =<ForVolumeSpec> Mozna do tego jeszcze dodac parametr /autoretry, który bedzie przez zadany czas próbowal utworzyc migawke, jezeli pierwsza próba sie nie uda. Dlaczego moze sie nie udac, napisalem juz wczesniej, przyblizajac idee writera.

Sprawdzenie, czy migawka naprawde istnieje i dowiedzenie sie czegos na jej temat nie jest wiele bardziej skomplikowane. Wystarczy wydac polecenie vssadmin list shadows, ewentualnie rozszerzajac je o parametry ograniczajace wyswietlane informacje. Dla kazdej widocznej dla VSS migawki wyswietlone zostana parametry zawierajace miedzy innymi:

  • Unikalny identyfikator zestawu migawek. Uzyteczny wtedy, gdy migawki sa robione równoczesnie na wielu woluminach. Taki zestaw migawek jest metoda zagwarantowania, ze migawka jest spójna nie tylko w obrebie woluminu, ale w calym komputerze, nawet jezeli woluminów jest wiele. Wykonanie takiego zestawu nie jest (o ile wiem) mozliwe przy uzyciu vssadmin, ale zawsze mozna pobrac bezplatny VSS SDK i uzyc zawartego w nim narzedzia vshadow.exe
  • Unikalny identyfikator migawki (GUID)
  • Dane (litere i GUID) dysku, z którego migawka pochodzi
  • Nazwe migawki
  • Nazwe komputera
  • Nazwe uzytego providera
  • Cechy migawki, omówione pobieznie wczesniej, w czesci "Typy migawek"

Warto wiedziec, ze mechanizmy VSS nie zmienily sie bardzo mocno i dysk z migawkami mozna przeniesc ze starego komputera do nowego, na przyklad z systemem Windows 2008 R2 i nadal do migawek miec dostep.

Mamy juz omówione tworzenie (create shadow) i przegladanie (list shadows) migawek. Do kompletu potrzebne jest jeszcze ich kasowanie. Tu równiez dobrze sprawdza sie vssadmin, tym razem w postaci vssadmin delete shadows. Jako parametry podajemy wolumin, dla którego kasujemy migawke i dane migawki do skasowania. Mozemy podac jej GUID (vssadmin delete shadows /for=<ForVolumeSpec> /shadow=<ShadowID> ), okreslic ze chcemy skasowac najstarsza migawke (vssadmin delete shadows /for=<ForVolumeSpec> /oldest) albo skasowac dla danego woluminu wszystko hurtem (vssadmin delete shadows /for=<ForVolumeSpec> /all).

Nalezy przy tym pamietac (wyszlo to juz przy okazji tworzenia zestawów migawek), ze vssadmin to narzedzie bardzo przydatne, ale nie wszechmocne. Moze sie zdarzyc, ze jego mozliwosci beda zbyt male i na przyklad nie skasuje nietypowej migawki albo nie powie wszystkiego, co chcielibysmy wiedziec. W takiej sytuacji nalezy siegnac po VSS SDK i uzyc vshadow.exe.

Na koniec jeszcze jedna uwaga. Wspominalem (bo tak zazwyczaj sie to robi), ze migawki tworzone sa na przyklad automatycznie o pólnocy kazdego dnia. Nie ma tu zadnej magii ani tajemnej skladni polecenia. Po prostu polecenie tworzace migawke trzeba dodac do harmonogramu zadan zwanego tez Task Schedulerem.

Montowanie migawek

Migawki same dla siebie bylyby bezuzyteczne, gdybysmy nie mogli skorzystac z zawartych w nich danych. Mozemy to wzglednie prosto zrobic, ale najpierw trzeba odczytac nazwe migawki. W zwracanym przez vssadmin list shadows tekscie, nazwy migawek to te wpisy przypominajace na przyklad \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy27 Zeby taka migawke zobaczyc jako pseudowolumin, mozemy wybrac jedna z dwóch dróg:

  • Uzycie funkcji DefineDosDevice() z API. Jezeli programowaniem nazwiemy wywolanie jednej funkcji, to ta metoda faktycznie wymaga programowania. Albo dotarcia do czegos, co "ubiera" te funkcje w narzedzie wiersza polecen. Kiedys bylo takie w Resource Kit, a dzisiaj znajomy programista napisze je doslownie w pare minut. Zeby zamontowac migawke w ten sposób podajemy 1 jako parametr dwFlags, x: czy inna litere dysku jako lpDeviceName a jako lpTargetPath nazwe migawki, zaczynajac od \Device\... , bez czesci z GLOBALROOT. Odmontowanie migawki przebiega w ten sam sposób, tylko jako dwFlags trzeba podac wartosc 3.
  • Uzycie polecenia mklink. Tutaj trzeba uzyc parametru /D (bo montujemy dysk do folderu), nazwy nieistniejacego folderu (na przyklad c:\migawka) i nazwy migawki, podanej dla odmiany w calosci, od znaków \\?\GLOBALROOT\... i z dodanym na koncu znakiem "\" (backslash). Jezeli ktos musi miec migawke zamontowana jako dysk, moze uzyc pamietajacego czasy DOS polecenia subst. Odmontowanie migawki odbywa sie przez skasowanie folderu do którego jest ona zamontowana i w naszym przykladzie bedzie to mozliwe przez polecenie rmdir c:\migawka.

Oczywiscie nietrudno sie domyslic, ze z samej natury migawki wynika, ze taki pseudo dysk bedzie pracowal w trybie tylko do odczytu. Ale dla potrzeb siegniecia po archiwalne dane to w zupelnosci wystarczy.

GUI i "zwykli" uzytkownicy

Zawsze powtarzam, ze GUI jest dla mieczaków, ale skoro ktos je wbudowal w system, to nie wypada o nim nie wspomniec. Dla potrzeb VSS interfejs graficzny istnieje i nie trzeba wszystkiego robic recznie wklepujac polecenia w cmd.exe. Najistotniejsze parametry dostepne sa po kliknieciu prawym przyciskiem myszy na woluminie i wybraniu z wlasciwosci zakladki "Shadow Copies". Mozna tam ustawic polozenie i rozmiar przestrzeni na kopie archiwalne, w prosty sposób ustalic harmonogram wykonywania kopii a takze tworzyc, przegladac i kasowac migawki.

Od strony uzytkownika, VSS objawia sie jeszcze ciekawiej. Na kazdym dysku sieciowym, dla którego na serwerze dziala VSS i automatyczne wykonywanie migawek, uzytkownik we wlasciwosciach foleru ma prosty wglad w dane zebrane na migawkach. Uciazliwe zonglowanie tasiemkami przez administratora ratujacego uzytkownika w sytuacji "mój plik zniknal" zostalo zastapione kilkoma kliknieciami, które uzytkownik tak naprawde moze wykonac samodzielnie.

Rozwiazywanie problemów

Jak kazdy kawalek IT, tak i VSS moze czasem sprawiac klopoty. Nie bardzo istnieje prosta i uniwersalna porada, ale na pewno dobra diagnostyka przyblizy do rozwiazania.

  • Do diagnostyki sredniozaawansowanej sluza dwa narzedzia (dostepne w SDK): vssagent i vssdiagview. Pierwsze potrafi zebrac naprawde szczególowe informacje na temat konfiguracji VSS i zapisac je w pliku XML. Drugie narzedzie sluzy do przegladania zebranych informacji w formie nieco bardziej przyjaznej niz czysty XML.
  • Do diagnostyki glebszej sluza mechanizmy wbudowane w sama usluge VSS. Wystarczy ustawic kilka parametrów w rejestrze w kluczu HKLM\SYSTEM\CurrentControlSet\Services\VSS zgodnie z opisem z KB887013 i VSS skrzetnie zacznie notowac w pliku tekstowym najwazniejsze dla siebie wydarzenia. Na podstawie zawartosci pliku mozna czesto dojsc do tego, skad problem sie wzial no i jak go rozwiazac.
  • Mozna tez, podejsc do diagnostyki VSS glebiej siegajacymi mechanizmami, ale to juz wykracza poza obszar niniejszego opisu. Haslowo wymieniajac, trzeba wspomniec o vsstrace (znowu z SDK), wbudowanym w system narzedziu logman i narzedziu tracelog (tym razem z WDK).

Dla VSS, GUID to 9138500e-3648-4edb-aa4c-859e9f7b7c38 i wartosc ta moze byc potrzebna w drugim i trzecim przypadku.

Dalsze kroki

Co dalej? To zalezy. Jezeli komus nadal malo wiedzy – bardzo mocno zachecam do pogrzebania po SDK i MSDN. Tam jest wszystko o moze byc potrzebne. Pózniej juz zaczynamy z tworzeniem wlasnych writerów, requesterów i providerów. Czyli wyzsza szkola jazdy i duzo programowania.

Warto jeszcze przy okazji wspomniec, ze z mechanizmów VSS dosc mocno korzysta DPM, rozszerzajac je miedzy innymi o funkcjonalnosc gwarantowanego przechowywania migawek przez zadany czas. Troche o szczególach dzialania mozna sie dowiedziec na przyklad tutaj.

Podsumowanie

Jak widac VSS to kawalek naprawde ciekawych wnetrznosci kazdego wspólczesnego systemu Windows. Z wlasnego doswiadczenia wiem, ze w calej masie sytuacji (takich, których opis musialby sie zaczac od "Ups....!") pozwolil mi on uniknac straty wielu godzin pracy. Dlatego warto poswiecic pare chwil zeby dobrze go poznac i zrozumiec, potem raz dobrze i swiadomie ustawic a potem korzystac. Oby jak najrzadziej!

Autor: Grzegorz Tworek [MVP]

Comments

  • Anonymous
    January 01, 2003
    No dziękuję za miły komentarz. Ale że "internalsowej" to trochę przesada. Faktycznie nie wszystko, co opisałem widać w GUI, ale tak naprawdę to całkiem prosta i dostępna dla końcowego użytkownika funkcjonalność. Trochę tylko zmitologizowana i dlatego poczułem potrzebę jej opisania. ;)

  • Anonymous
    January 01, 2003
    Niestety nie.

  • Anonymous
    October 27, 2010
    Grzesiek, jak zwykle milutka dawka internalsowej wiedzy, dzięki! :)

  • Anonymous
    October 27, 2010
    Tak z nieco innej pary kaloszy: bawiles sie moze kiedys zfs-em?

  • Anonymous
    June 11, 2014
    Super nieslychane ale zawarłeś tu wszystko czego szukałem przez ostatni tydzień Bardzo Ci dziękuję

  • Anonymous
    October 09, 2014
    "Zawsze powtarzam, że GUI jest dla mięczaków, ale skoro ktoś je wbudował w system, to nie wypada o nim nie wspomnieć. "
    :D :D