Fibre Channel: taśma LTO zostaje zastąpiona przy resecie magistrali

Mamy sytuację u naszego klienta, którą chciałbym lepiej zrozumieć.

Oto co się stało:

• Biblioteka z napędami taśm LTO jest podłączona do środowiska Fibre Channel
• Oprogramowanie do archiwizacji działające na systemie Windows Server 2008 zapisuje dane na taśmach
• W pewnym momencie taśma została przewinięta do tyłu, ale oprogramowanie nie wiedziało o tym, a zapis kasował taśmę
• Sytuację wykryto poprzez porównanie oczekiwanej pozycji na taśmie z rzeczywistą

Nie mam szczegółów na temat dostawców sprzętu.

Wygląda na to, że w napędzie taśm nastąpił reset, który spowodował przewinięcie taśmy, ale sytuacja ta nie została zgłoszona jako błąd z powrotem do sterownika i oprogramowania, więc oprogramowanie przyjęło, że zapis się powiódł.

Czytałem dużo dokumentacji, aby zrozumieć, dlaczego tak się stało, ale nie mogę wyciągnąć ostatecznych wniosków, aby pomóc klientowi.

• Czy karta FC HBA lub sama może włączyć retransmisję zapisu SCSI po zresetowaniu magistrali?
  • Czy coś takiego można skonfigurować?
• Czy FC HBA lub przełącznik zignorowały zgłoszoną uwagę jednostki?
• Czy można winić sterownik systemu operacyjnego?
• Czy ten sprzedawca jest specyficzny?

Byłbym bardzo wdzięczny, gdyby ktoś mógł podać mi wskazówki, co dalej.

Jest to znany problem z napędami taśmowymi i ich łatwym przewijaniem do tyłu przez samo patrzenie w bok na urządzenie (tj. Otwieranie go w niewłaściwy sposób - za pomocą urządzenia do przewijania - np. W celu sprawdzenia stanu).

Przynajmniej jeden znaczący element oprogramowania do tworzenia kopii zapasowych w systemie UNIX jest tak zaniepokojony, że po prostu po raz drugi odmawia zapisu na taśmie, dopóki taśma nie będzie gotowa do skasowania; to z Amanda FAQ (które konkretnie wymienia resety magistrali jako obszar problemu):

Dlaczego Amanda nie dołącza się do taśmy?

Jedna seria Amanda = jedna (zestaw) taśm. Amanda raz otwiera urządzenie taśmowe, zapisuje wszystkie obrazy i oznaczenia plików, a raz zamyka urządzenie. Używając tej sekwencji, nie ma możliwości, aby inne programy przerwały sekwencję i przewinęły taśmę, bez zauważenia Amandy.

Wykonanie „mt -f / dev / st0 status” może wystarczyć, a nawet „sprawdzać codziennie”. Ponadto błąd, taki jak reset magistrali scsi, oznacza przewijanie do tyłu.

Jeśli Amanda zamknie i ponownie otworzy napęd taśm dla każdego obrazu kopii zapasowej, istnieje okno podatności na przypadkowe przewinięcie taśmy, a następny obraz zastąpi wszystkie dobre kopie zapasowe na taśmie. I nie wiedziałbyś, gdybyś nie próbował przywrócić z taśmy.

Podczas dołączania do taśmy istnieje możliwość, że między momentem, w którym Amanda ustawi się na ostatnim obrazie (co nie jest już tak naprawdę trywialne!), A otwarciem urządzenia do zapisu, nastąpi przewijanie taśmy, w takim przypadku Amanda z radością usuń WSZYSTKIE taśmy, które mogą zawierać kopie zapasowe na wiele dni.

Bacula podobnie rozwiązuje ten problem, nigdy nie zamykając urządzenia taśmowego, więc nikt inny nie może go nieprawidłowo otworzyć podczas ładowania taśmy. Ale to nie rozwiązuje problemu resetu magistrali.

Zasadniczo jest to problem i jest trudny. Mogę argumentować, że twój sprzęt do tworzenia kopii zapasowych powinien być wystarczająco solidny, aby nie zdarzały się często; jeśli FC wydaje się szczególnie podatny na to, nadszedł czas, aby kupić napęd taśmowy SAS lub przynajmniej bezpośrednio podłączyć napęd taśmowy do serwera kopii zapasowej, aby usunąć przełączniki światłowodowe itp. ze ścieżki. Poza tym nie widzę, jak możesz zrobić o wiele więcej, niż masz, ponieważ złapałeś problem przed zwykłym punktem, tj. „ Nasze przywracanie nie działa, jesteśmy zepsute ”.