W tej części opisane zostanie odzyskiwanie backupu bazy danych z QNAP-TS-459U-SP. Część pierwsza dotyczyła problemów związanych z utrzymywaniem głównych zasobów systemu, na macierzy dyskowej, w której dwa dyski klasy serwerowej zostały zastąpione dyskami klasy konsumenckiej.
Serwer opisywany w tej części, miał możliwość zamontowania 4 dysków. W tym przypadku były to konstrukcje klasy serwerowej Western Digital RE4 o pojemności 1 TB. (Takie same jak użyte w TS-859U-RP, ale o połowę mniej pojemne).
Moc obliczeniowa jaką dysponował ten model serwera, była identyczna z poprzednio omówioną konstrukcją (Procesor Atom i 1 GB RAM typu DDR 2). Ze względu na mniejszą ilość kieszeni dyskowych, można było w nim uzyskać układy JBOD, RAID 0, RAID 1, RAID 5, RAID 6, RAID 5+ (z dyskiem zapasowym hot spare). Ilość możliwych do zamontowania dysków wykluczała (w przeciwieństwie do modelu omówionego poprzednio) utworzenie układu dysków RAID 6+ (z dyskami zapasowymi hot spare).
Ciekawą funkcją, która nie została opisana w poprzedniej części, jest możliwość spinania wielu serwerów QNAP w ramach jednej infrastruktury. W menu konfiguracyjnym serwerów, w zakładce Disk Management, jest dostępna sekcja Virtual Disk. Pozwala ona na użycie woluminów udostępnianych za pomocą protokołu iSCSI przez inne serwery QNAP, w roli wirtualnych dysków podłączonych do danego serwera.
Podobnie jak w przypadku problemów z macierzą omówioną w pierwszej części, do awarii serwera kopii zapasowych, przyczyniły się oszczędności i brak należytej kontroli stanu dysków. W związku z konfiguracją w układzie RAID 5+, awaria jednego z aktywnych dysków (powstanie błędnych sektorów), która objawiła się na kilka miesięcy przed incydentem, związanym z długotrwałą przerwą w dostępie do energii elektrycznej, nie została zauważona przez osoby administrujące serwerami. Dysk hot spare zastąpił ten uszkodzony, w sposób zupełnie niezauważony przez użytkowników. Brak monitorowania przez administratorów stanu serwera, doprowadził do tego że, awaria kolejnego dysku spowodowała pracę macierzy w stanie zdegradowanym i to przez ponad 3 miesiące, poprzedzające prawidłowe zamknięcie systemu tego serwera, z powodu krytycznego wyczerpania akumulatorów zasilacza awaryjnego. Podczas startu serwera po odzyskaniu zasilania, ujawniła się usterka kolejnego dysku. Uniemożliwiło to start macierzy nawet w stanie zdegradowanym.
Odzyskanie backupu bazy danych udało się dzięki odczytaniu wszystkich sektorów, które były kluczowe dla spójności danych. Błędne sektory występujące w dwóch, z trzech dysków tworzących układ RAID5 (dodatkowy dysk hot spare zawierał dane zdezaktualizowane), spowodowały brak możliwości uruchomienia macierzy. Odbudowa układu macierzy z obrazów dysków, pozwalających na dostęp do danych bez błędów odczytu (ale z oznaczeniem położenia błędnych sektorów) pozwoliła na odbudowę struktur danych i ich odczyt. Weryfikacja odtworzonych danych i adresów błędnych, niemożliwych do odczytania sektorów, wskazała że, kilka kolejnych, ostatnich kopii bezpieczeństwa bazy danych nie uległo uszkodzeniom. Dzięki temu udało się odzyskać jej zawartość, bezpowrotnie utraconą w wyniku uszkodzeń serwera opisanego w części pierwszej. W wyniku naszych prac, przywróciliśmy do działania system oparty o dwa serwery QNAP, a baza danych zapisana w ostatniej utworzonej kopii bezpieczeństwa, zawierała całość danych (backup został wykonany przed awaryjnym zamknięciem systemów obu serwerów).
Warto na zakończenie opisu tego przypadku, jeszcze raz przypomnieć czytelnikom że, spinanie dysków w układy macierzy RAID nie jest rozwiązaniem, które powoduje brak konieczności wykonywania kopii bezpieczeństwa, a dyski twarde nie są urządzeniami bezawaryjnymi, nawet w przypadku sprzętu klasy serwerowej.