Jeśli plik konfiguracji maszyny się zepsuje: gdzie mieszka stara kopia

Każda maszyna wirtualna i każdy kontener ma mały plik tekstowy. Ile rdzeni, ile pamięci, który dysk, która sieć: wszystko tam jest, zapisane w postaci czytelnej dla człowieka.

Co się stanie, jeśli ten plik się zepsuje, gdzie jest stara kopia i na co uważać, gdy edytujesz go ręcznie?

Najpierw dobra wiadomość: zepsuty plik dotyczy tylko własnej maszyny

Każda maszyna ma własny, osobny plik. Literówka w jednym nie kładzie panelu, nie zatrzymuje pozostałych maszyn, nie dotyka serwera.

Objaw jest zwykle taki: ta maszyna przestaje pojawiać się na liście albo odmawia startu. Cała reszta działa normalnie dalej. Wiedz o tym, zanim wpadniesz w panikę, bo pierwsze wrażenie brzmi zwykle, że system się zepsuł, a tak nie jest.

Jak się psuje

Edycja ręczna. To najczęstsza przyczyna. Przecinek, cudzysłów, źle wpisana nazwa klucza.

Edycja przy działającej maszynie. Nawet jeśli plik się nie zepsuje, dzieje się coś, czego nie oczekiwałeś: twoja zmiana wchodzi w życie przy następnym starcie, podczas gdy ty zakładasz, że zadziałała od razu. Albo system sam aktualizuje plik i nadpisuje to, co napisałeś.

Zapis przerwany w połowie. Znika zasilanie, zapełnia się dysk, proces zostaje zabity. Plik zostaje w połowie.

Ten trzeci jest najbardziej podstępny i zasługuje na własny nagłówek.

Plik zapisany w połowie jest gorszy niż brak pliku

Jeśli pliku nie ma, to stan oczywisty. Program patrzy, nie znajduje, mówi, że go nie ma, i idzie dalej z wartościami domyślnymi. Ten stan obsługuje się łatwo.

Plik zapisany w połowie taki nie jest. Wygląda jak plik. Program sprawdza, czy istnieje, znajduje go, ufa mu i próbuje pracować z niekompletnymi danymi w środku. Kłopot ujawnia się nie w chwili odczytu, tylko potem.

Rozwiązanie jest proste i dotyczy każdego zapisu: nie nadpisuj pliku wprost. Zapisz najpierw pod nazwą tymczasową, a potem przenieś na miejsce. Przeniesienie następuje albo w całości, albo wcale; stanu pośredniego nie ma. Dzięki temu zawartość pliku jest albo stara, albo nowa, nigdy połowiczna.

Jeśli piszesz skrypt dotykający konfiguracji Proxmoksa, ten jeden nawyk jest wart więcej niż cała reszta kodu, który napiszesz.

Stara kopia leży w dwóch miejscach

Wewnątrz kopii zapasowej. Kopia maszyny niesie nie tylko dysk, ale i plik konfiguracji w takiej postaci, w jakiej był w tamtej chwili. Gdy odtwarzasz kopię, konfiguracja wraca razem z nią. Większość ludzi myśli o kopii wyłącznie jako o danych i nigdy nie zauważa, że trzyma w ręku drogę odzyskania.

Wewnątrz migawki. Gdy robisz migawkę, konfiguracja z tamtej chwili zostaje zapisana w nazwanej sekcji tego samego pliku. Plik niesie więc w sobie część własnej historii.

Ale te dwie rzeczy się nie zastępują, a różnica ma znaczenie: zapis migawki siedzi wewnątrz tego samego pliku. Jeśli sam plik zostanie zniszczony, ten zapis ginie razem z nim. Kopia zapasowa jest gdzie indziej. Prawdziwą drogą odzyskania jest kopia; migawka to tylko punkt, do którego możesz chcieć wrócić.

Jeśli zamierzasz edytować ręcznie

Najpierw zatrzymaj maszynę.

Przed edycją zrób kopię i połóż ją gdzie indziej. Miejsce, w którym mieszka konfiguracja, zaprojektowano do konfiguracji; nie zostawiaj tam kopii zapasowych.

Po zmianie uruchom maszynę i zobacz, że naprawdę działa. Nie odkładaj tego do następnego restartu i nie zapominaj; zapomniana, niedokończona edycja wraca po miesiącach jako awaria, której nikt z niczym nie łączy.

Reguła ogólna: brak pliku i zepsuty plik to osobne stany

Droga odzyskania w programie pisana jest zwykle z myślą o stanie, w którym pliku nie ma, bo ten przychodzi do głowy pierwszy. Stan, w którym plik jest, ale jego zawartość jest zepsuta, do głowy nie przychodzi.

A to właśnie ten drugi jest naprawdę niebezpieczny, dokładnie dlatego, że o nim nie pomyślano. I wyglądają różnie: brakujący plik niesie oznaczenie, zepsuta zawartość nie.

Co robi Atlas

Atlas prowadzi kilka własnych, małych plików ustawień, i jest tu kilka rzeczy wartych uczciwego opowiedzenia, bo wszystkie znaleziono przez pomiar.

Dwa siostrzane pliki zachowywały się różnie. Jeden naprawiał się sam, gdy jego plik był uszkodzony: odkładał zepsuty na bok i zaczynał od czysta. Drugi nie: zgłaszał błąd i na tym się zatrzymywał, co oznaczało, że ta funkcja stawała się trwale bezużyteczna, bez możliwości naprawy przez użytkownika z poziomu produktu.

Przyczyną była dokładnie powyższa reguła: gałąź odzyskiwania napisano dla stanu, w którym pliku nie ma. Błąd zepsutej zawartości takiego oznaczenia nie niesie, więc gałąź go nie łapała i błąd uciekał w górę.

Odłożone kopie nigdy nie były sprzątane. Każde zdarzenie uszkodzenia zostawiało trwały plik, bez limitu ich liczby. Zmierzono na działającej maszynie: dwie z nich leżały tam od miesięcy. To ta sama reguła, co w innych wpisach tej bazy wiedzy: wszystko, co pisze, potrzebuje sufitu.

Dwa odłożenia w tej samej chwili dawały tę samą nazwę, a druga kopia nadpisywała pierwszą, więc jedna zepsuta wersja znikała po cichu.

Wszystko to poprawiono, a na sam krok odkładania nałożono jedną regułę: nigdy, w żadnych okolicznościach, nie zgłasza błędu. Odkładanie jest krokiem odzyskiwania, a krok odzyskiwania nie może stać się nowym źródłem awarii. To zdanie wygląda drobno, ale to właśnie je powinien powiesić na ścianie każdy, kto pisze kod odzyskiwania.