Jak rozwiązać problemy z zarządzaniem siecią, instalacją nowo zakupionego koncentratora, strategią przełączania ATM czy routingiem w naszej firmie? A co ze strategią tworzenia backupów?

Backup wydaje się zadaniem nieskomplikowanym. Zwłaszcza, jeśli odpowiadamy tylko za dwa serwery i ich kilkusetmegabajtowe dyski. Lecz rzeczywistość jest znacznie bardziej skomplikowana. Bardziej prawdopodobnym jest, że nasz "przeciętny" serwer ma 1-5 GB pamięci dyskowej. I chociaż 80% wyposażony jest w macierz dyskową z mirroringiem, nie zwalnia nas to z obowiązku regularnego wykonywania zapasowych kopii.

Podczas gdy ceny nośników magnetycznych spadają (a my nadal musimy targować się z naszymi bossami o więcej dysków dla naszych serwerów), wydaje się, że systemy tworzenia backupów pozostają za nimi znacznie w tyle.

W celu zaprojektowania systemu backupów, zastanówmy się po pierwsze, co będziemy kopiować, a dopiero później, w jaki sposób. Następnie opracujmy metodę posługiwania się zapasowymi taśmami, strategię pracy z napędami dyskowymi i sprawdzania poprawności kopiowania/odtwarzania danych.

Odpowiedź na pytanie, co będzie kopiowane jest prosta - wszystko! Zwykle oznacza to zrzucanie danych z jednego lub więcej serwerów, stacji roboczych i ewentualnie z magazynów (repositories), jakimi zarządza nasz serwer plików. Będą to więc mogły być dane z unixowego Network File System, z VAX-a itp.

Większość sieci LAN składa się obecnie z mieszanych środowisk NetWare, Unix, Windows NT/AS, Vines itp. Jak skoordynować tworzenie backupów z danych wszystkich tych systemów? O ile dołożenie nowego serwera lub usługi do sieci LAN mogło nie przedstawiać większych trudności, to pamiętanie o prawidłowo wykonywanych backupach z różnych systemów sieci może przyprawić o ból głowy.

Odpowiedź na pytanie, w jaki sposób zorganizujemy kopiowanie to wybór nośników przechowywania danych, częstości, metodologii i odpowiedniego oprogramowania. Te elementy strategii zmieniają się wraz z rozbudowywaniem serwerów i rozwojem sieci. Proces planowania backupów w sieci LAN przypomina procesy decyzyjne, jakie przeprowadzają menedżerowie mainframów i mikrokomputerów.

Kiedy rozpoczynałem zarządzanie siecią LAN, do backupu używałem DC600A - 1/4-calowego kartridża (QIC). Zrzucałem w nocy od 600 MB do 1,2 GB danych, pracując na stacji roboczej.

W ciągu ostatnich pięciu lat wykorzystywałem kolejno: napęd taśmowy QIC, 8-mm streamery Exebyte, pojedyncze i wreszcie wielokrotne 4-mm streamery DAT ze zmieniaczem taśmy (tape multichanger) firmy ADIC.

Zmiany sprzętu wynikały z problemów pojemnościowych, czasowych i niezawodnościowych. Wczesne napędy Exebytes ulegały mechanicznym uszkodzeniom. System QIC musiał "odejść na emeryturę" w momencie, gdy backup 2,2 GB danych trwał ponad 12 godzin, wchodząc w kolizję z poranną pracą serwera.

Zastosowanie karty SCSI w charakterze urządzenia sterującego dostępem do magistrali w głównym serwerze plików, łącznie z napędem taśmowym o większej pojemności skróciło czas wykonywania backupu do 4 godzin.

Zmieniacz taśm firmy ADIC rozwiązał syndrom końca taśmy, który szczególnie daje się we znaki w środku nocy. Konieczne było także zastosowanie dodatkowych napędów taśmowych.

A co do systemów wykonywania backupów, to - nazwijmy to paranoją Paula - nie mam zaufania do żadnego z nich. Tworzę zapasową kopię wszystkiego każdego wieczoru.

I jeszcze jeden wniosek: Nie należy ściągać zapasowych kopii "po drutach", (zwłaszcza, jeśli dyski serwerów przekraczają 2 GB), chyba, że serwery są połączone za pomocą 100 MB FDDI. Trwa to długo a rozpowszechnianie danych po drutach naraża je na niebezpieczeństwo utraty poufności.

Podsumujmy: przeznaczając dla celów backupu na każdy serwer jeden napęd bądź system backupowy podłączony lokalnie za pomocą kanałów SCSI zapewnimy sobie najlepsze wykorzystanie czasu, możliwość równoległego tworzenia kopii oraz zmniejszymy ryzyko uszkodzenia całego backupu wskutek nieprzewidzianej awarii.