Zadanie kopii zapasowej stanęło po cichu: najdroższa awaria nie jest tą głośną

Kopia, która zawodzi głośno, zostaje naprawiona tego samego dnia. Kopia, która staje po cichu, zostaje odkryta w dniu, w którym była potrzebna. Różnica nie leży w powiadomieniu, tylko w tym, na co patrzysz.

AtlasPVE ·

Ten wpis odpowiada na

  • proxmox kopie zapasowe nie działają
  • proxmox zadanie kopii nie wykonuje się
  • proxmox powiadomienie o kopii zapasowej
  • proxmox mail o nieudanej kopii
  • proxmox kiedy była ostatnia kopia

Najdroższym sposobem psucia się układu kopii zapasowych nie jest ten głośny. Głośny błąd zostaje zauważony i naprawiony tego samego dnia. Zadanie, które staje po cichu, stoi tygodniami i zostaje odkryte dokładnie w dniu, w którym było potrzebne.

Sposoby na ciche stanięcie

Cel się zapełnił. Udział sieciowy nie zamontował się po restarcie. Pamięć masowa dostała nową nazwę. Zadanie wskazuje na maszynę, której już nie ma. Wygasły dane uwierzytelniające. Wszystkie te rzeczy produkują gdzieś błąd i żadna z nich nie produkuje błędu przed człowiekiem.

Pułapka powiadomienia

Zdanie, że jak się nie uda, to dostanę maila, niesie dwa założenia: że poczta rzeczywiście wychodzi z tej maszyny i że ktoś ją czyta. W większości układów żadne z nich nie jest prawdziwe. Na dodatek powiadomienie odzywające się wyłącznie przy porażce jest nie do odróżnienia od systemu powiadomień, który nigdy nie działał: oba milczą.

Jedynym sposobem, żeby wiedzieć, że powiadomienie działa, jest zobaczenie, jak zadziałało. W dniu, w którym je ustawiasz, wywołaj porażkę celowo i popatrz, jak przychodzi mail. Jeśli nie widziałeś, jak przyszedł, to powiadomienie nie istnieje.

Właściwa rzecz do oglądania: wiek

Zamiast na stan ostatniego zadania patrz na wiek najnowszej kopii zapasowej. Wiek odpowiada od razu na dwa pytania: czy zadanie się wykonało i czy coś wyprodukowało. Zadanie może się wykonać i nic nie wyprodukować, wyglądając nadal na udane; wiek to wyłapuje, stan nie.

Sprawdzenie na minutę, raz w miesiącu

Spójrz na cztery rzeczy: ile lat ma najnowsza kopia każdej maszyny, czy liczba trzymanych kopii zgadza się z twoją regułą przechowywania, ile miejsca zostało w celu i czy któraś maszyna nie ma kopii w ogóle.

To ostatnie znajduje się najczęściej, a powód jest prawie zawsze ten sam: tamta maszyna powstała po napisaniu zadania kopii zapasowej.

Zapisz regułę, a nie listę

Zadanie wybierające maszyny do kopiowania jedna po drugiej jest poprawne w dniu napisania i odrobinę bardziej błędne z każdą nową maszyną. Tam, gdzie się da, zdefiniuj je jako wszystkie oprócz tych. Wtedy stworzenie nowej maszyny samo umieszcza ją w zasięgu kopii, a koszt zapomnienia spada do zera.

Co robi Atlas

Atlas pokazuje istniejące kopie zapasowe razem z ich datami, więc na powyższe pytanie o wiek odpowiadasz, patrząc, a nie zgadując: kiedy zrobiono najnowszą kopię każdej maszyny, siedzi na jednym ekranie.

Atlas Watch obserwuje sam serwer, oczekujące aktualizacje, maszyny wirtualne i wiek kopii zapasowych. Patrzy tam, gdzie ta strona radzi patrzeć: nie na ostatni stan zadania, tylko na wiek najnowszej kopii. Gdy najnowsza kopia maszyny jest starsza niż wybrana liczba dni, mówi o tym w codziennym podsumowaniu; domyślny próg to trzy dni, da się go zmienić z panelu, a jeśli sprawdzenie zostanie podniesione do poziomu krytycznego, jest zgłaszane od razu, bez czekania na podsumowanie.

Jeśli samej pamięci masowej z kopiami nie da się odczytać, Watch nie milczy, tylko mówi, że nie mógł jej odczytać. Traktowanie ciszy jako zdrowia jest dokładnie tą awarią, którą ta strona opisuje, więc pilnujący nazywający coś czystym, choć nie mógł tego odczytać, został świadomie wykluczony. Powyższe comiesięczne sprawdzenie warto mimo to zachować: jedynym przypadkiem, którego sprawdzenie nie obejmuje, jest zupełnie nowa maszyna bez żadnej kopii.

Źródła

Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.

Powiązane wpisy

Jak to wygląda wewnątrz Atlasa?

Przejdź do strony produktu