Kopia zapasowa i przywracanie

Aplikacja nazywa się „Ticket System Backup & Restore”. Stoi obok systemu zgłoszeń i ma własny skrót na pulpicie.

Jest wersja dla systemu Windows i dla systemu Linux. To ta sama aplikacja, tylko zbudowana dla każdego systemu operacyjnego.

Ma sześć zakładek. „Restore” wypisuje posiadane kopie, „Create Backup” tworzy nową, „Schedule” zajmuje się porą, „Encryption” pokazuje klucz odzyskiwania, „Settings” pokazuje ścieżki, a „Log” protokół.

Ustawienia są już wypełnione. Przy pierwszym uruchomieniu aplikacja sama ustala, gdzie mieszka system zgłoszeń.

Folder na kopie stoi pod „Backup directory”. Możesz go zmienić, na przykład na inny dysk.

W systemie Windows aplikacja przy starcie prosi o uprawnienia administratora. Jej ustawienia obowiązują każdego administratora komputera i mieszkają w „%ProgramData%\SMITEY\backup-app”.

Instalacja sama ustawia codzienną kopię. Działa ona o 23:00 w strefie czasowej systemu zgłoszeń.

Harmonogram mieszka w systemie operacyjnym. W systemie Windows jest to Harmonogram zadań, a w systemie Linux usługa cron. Nie działa więc żadna dodatkowa usługa tylko po to, żeby robić kopie.

Kopia nie potrzebuje zalogowanego użytkownika. Na serwerze, na którym nikt nigdy się nie loguje, i tak działa.

Wiersz pod przyciskami mówi, czy zadanie naprawdę istnieje w systemie operacyjnym. Zaznaczone pole mówi tylko, co zostało zapisane.

Kopie są trzymane w pięciu stopniach: 14 dni, 4 tygodnie, 12 miesięcy, 4 kwartały i 5 lat. Kopia zostaje tak długo, jak długo jest najnowszą kopią swojego okresu w jednym z tych stopni.

Liczą się dni kalendarzowe, a nie pliki. Dwie kopie jednego dnia to jeden dzień.

Kopie utworzone ręcznie nigdy nie są usuwane automatycznie. To znaczy 0 przy „Keep manual”.

Jeśli zmienisz harmonogram, Twoja zmiana przeżyje aktualizację. Instalacja ustawia go tylko wtedy, gdy nigdy nie ustawiłeś harmonogramu. Jeśli wyłączyłeś kopie zapasowe, zostają wyłączone. Trwałe jest też „Remove all scheduled tasks”: aktualizacja nie ustawia potem harmonogramu ponownie.

Kopia zawiera wszystko, co składa się na stan Twojego systemu. To baza danych, załączniki, archiwum i klucze. Brakuje w niej tylko bazy danych poza SMITEY.

Klucze to ta część, którą łatwo przeoczyć. Odszyfrowują zapisane dane dostępowe, na przykład do konta pocztowego. Bez nich przywrócenie wróciłoby z martwymi danymi dostępowymi.

Każda nowa kopia to pojedynczy zaszyfrowany plik z końcówką „.smbk”. Zawiera po jednym pliku na wolumin, listę swojej zawartości i bazę danych jako plik tekstowy, jeśli jest w kopii.

System działa przy tym dalej. Twoi agenci w ogóle nie zauważają kopii.

„Estimate size” mówi z góry, jak duża jest baza danych. Woluminy z załącznikami dochodzą do tego. Kopia nie jest kompresowana.

Nic nigdy nie jest nadpisywane. Każda kopia jest osobnym plikiem, a stare usuwa tylko sprzątanie.

Kopie zapasowe mogą czytać tylko administratorzy. To samo dotyczy pliku konfiguracji i pliku z pierwszym logowaniem w folderze instalacji. Instalator i każda aktualizacja same ustawiają te uprawnienia.

Jeśli Twoja baza danych działa na osobnym serwerze, a nie w kontenerze SMITEY, aplikacja nie może zrobić jej kopii. Zrób jej wtedy kopię własnymi narzędziami. W takim przypadku kopia zawiera tylko załączniki, archiwa i klucze, zaszyfrowane jak zawsze. Aktualizacja sama rozpoznaje taką bazę danych i przestawia aplikację. Do tego czasu codzienna kopia na takiej instalacji nie udaje się, chyba że najpierw przestawisz ją ręcznie. W wierszu poleceń możesz też zrobić to ręcznie poleceniem „config --database external”. Poleceniem „config --database bundled” wracasz do poprzedniego stanu.

Każda nowa kopia jest zaszyfrowana. Dotyczy to kopii z harmonogramu, kopii zrobionych ręcznie i kopii sprzed aktualizacji. Nie musisz niczego włączać.

Kopie są szyfrowane algorytmem AES-256. Instalacja sama tworzy klucz. W istniejącej instalacji powstaje on przy pierwszej aktualizacji do wersji z szyfrowaniem. Jest zapisany na serwerze w chroniony sposób. Mogą go odczytać tylko administratorzy.

To chroni kopie poza serwerem. Kto znajdzie kopię na dysku sieciowym, pamięci USB lub w przechowalni online, nie odczyta jej bez klucza. Kto kontroluje sam serwer, ma też klucz.

Klucz odzyskiwania to ten sam klucz w postaci, którą możesz zapisać. Zaczyna się od „SMBK-”. Znajdziesz go w zakładce „Encryption” i w pliku „SMITEY-credentials.txt” w folderze instalacji. Jeśli ten plik został usunięty, klucz nadal znajdziesz w zakładce „Encryption”.

„Copy” wkłada klucz do schowka. „Save to file...” zapisuje go z identyfikatorem klucza i datą w pliku tekstowym. Przechowuj go na przykład w menedżerze haseł albo na papierze w sejfie.

Dopóki nie potwierdzisz, że klucz jest zapisany, aplikacja pokazuje u góry żółty pasek. Aby potwierdzić, kliknij „I stored the key outside this server” i odpowiedz na pytanie „Yes”. Pasek wtedy znika. Zakładka pokazuje potem, kiedy nastąpiło potwierdzenie.

Identyfikator klucza mówi, do którego serwera należy kopia. Jeśli kopia nie należy do tego serwera, aplikacja podaje jej identyfikator klucza. Następnie prosi o pasujący klucz odzyskiwania.

Jeśli aplikacja nie może odczytać klucza, nie robi kopii. Nie robi też kopii niezaszyfrowanej. W takim przypadku zakładka „Encryption” informuje, że klucza nie można odczytać. Jeśli pliku klucza brakuje całkiem, następna kopia tworzy nowy klucz. Żółty pasek pojawia się wtedy znowu, bo nowy klucz też trzeba zapisać. Starsze kopie nadal da się otworzyć tylko starym kluczem odzyskiwania.

Starsze kopie w formacie ZIP nie są zaszyfrowane. Nadal możesz je przywrócić. Zakładka pokazuje, ile ich jest. Czyszczenie usuwa je według tych samych zasad co każdą inną kopię.

Na serwerze bez pulpitu „key --show” pokazuje to samo w wierszu poleceń.

W zakładce „Restore” wybierasz kopię, którą chcesz odzyskać. Potem klikasz „Restore”.

Aplikacja najpierw pyta. Mówi, co się stanie: dzisiejszy stan zostaje nadpisany, a aplikacja uruchamia kontenery ponownie. Jeśli w dzisiejszym stanie są zanonimizowane osoby, pojawia się drugie pytanie. Podaje ich liczbę i pyta, czy po przywróceniu zanonimizować je ponownie. „Yes” jest wybrane domyślnie. Przy „No” kopia zostaje przywrócona bez tego kroku. Jeśli zamiast tego zamkniesz okno, nic nie zostanie przywrócone.

Zaznaczenie „Wipe target volumes before restore” najpierw opróżnia woluminy. Dzięki temu nie zostaje żaden plik, którego nie było w chwili tworzenia kopii.

Kroki pojawiają się w zakładce „Log”. Widzisz tam po kolei, co aplikacja zrobiła. Jeśli na drugie pytanie odpowiesz „Yes”, wiersz na końcu podaje, ile anonimizacji system zgłoszeń zastosuje ponownie kolejnej nocy. Jeśli nie da się ich przenieść, dziennik pokazuje zamiast tego ostrzeżenie. Jeśli były ostrzeżenia, wiersz stanu na dole okna podaje ich liczbę.

Jeśli kopia zawiera bazę danych, wraca pełny stan. Zgłoszenia, komentarze, historia, załączniki, zapisany czas i baza wiedzy są znowu takie, jakie były w chwili tworzenia kopii.

Potem system znowu nadaje się do pracy. Przy małej instalacji trwa to poniżej minuty.

Jeśli kopia zawiera bazę danych, wraca ona w całości albo wcale. Woluminy idą po niej. Jeśli wolumin się nie uda, baza danych już wróciła, ale może brakować plików. Zakładka „Log” pokazuje, który krok się nie udał. W każdym przypadku aplikacja potem ponownie uruchamia kontenery, nawet jeśli przywracanie się nie powiodło.

Kopię zapasową ze starszej wersji można przywrócić do nowszej. Przy następnym starcie system podnosi bazę danych do swojej wersji.

Zgody i wypisania dotyczące ankiety satysfakcji są przenoszone bez pytania. Dotyczy to także sytuacji, gdy na drugie pytanie odpowiesz „No”. Aplikacja odczytuje je z działającej instalacji przed przywróceniem. Potem wiersz w zakładce „Log” podaje liczbę, na przykład „12 consent and unsubscribe record(s) were carried over.” System zgłoszeń przejmuje je przy pierwszym uruchomieniu. Zgoda albo wypisanie złożone po kopii zapasowej pozostają więc ważne. Jeśli przeniesienie się nie powiedzie, dziennik pokazuje ostrzeżenie. Przywracanie nadal liczy się jako udane.

Aplikacja najpierw sprawdza zaszyfrowaną kopię w całości. W tym czasie wiersz stanu pokazuje „Checking the encrypted backup before anything is changed...”. Dopiero potem zatrzymuje kontenery. Jeśli plik jest uszkodzony albo został zmieniony, aplikacja się zatrzymuje i zgłasza „The backup file is damaged. Nothing was changed.”

Jeśli kopia pochodzi z innego serwera, aplikacja prosi o klucz odzyskiwania tego serwera. Dzieje się to po pytaniach. Okno „Recovery key needed” podaje identyfikator klucza kopii. To samo okno pojawia się, gdy brakuje klucza tego serwera.

Literówka zostaje wykryta, zanim cokolwiek się zmieni. Wiersz stanu zgłasza wtedy „The recovery key has a typing error. Check each character.” Potem okno pyta ponownie. Jeśli klucz należy do innej kopii, wiersz stanu zgłasza „This recovery key does not belong to this backup.” Po kliknięciu „Cancel” aplikacja się zatrzymuje i zgłasza „Restore cancelled. Nothing was changed.”

Aplikacja nie przejmuje wpisanego klucza. Zachowuje własny. Nowe kopie nadal powstają kluczem tego serwera. Jeśli przywracasz na nowym serwerze, zapisz także klucz odzyskiwania tego serwera.

Kopia bez bazy danych przywraca tylko załączniki, archiwa i klucze. Istniejące klucze zostają. Baza danych pozostaje bez zmian. Aplikacja informuje o tym przed przywracaniem i pyta. Po kliknięciu „No” nic się nie zmienia.

Jeśli instalacja jest ustawiona na własną bazę danych, aplikacja pomija część z bazą danych także wtedy, gdy kopia zawiera bazę danych. Dotyczy to na przykład starszej kopii. Aplikacja najpierw pyta. Po kliknięciu „No” nic się nie zmienia.

Serwer często nie ma pulpitu. Dlatego ta sama aplikacja działa też jako polecenie.

Na co dzień potrzebujesz pięciu poleceń: „backup” zapisuje, „list” pokazuje posiadane kopie, „restore” przywraca jedną, „schedule” ustawia porę, a „config” pokazuje ustawienia. Do obsługi klucza dochodzą „key” i „decrypt”.

Za nimi stoi ta sama aplikacja co w oknie. Nie ma drugiej drogi, która robiłaby coś innego.

Aplikacja siedzi w „/opt/smitey/Backup”. Wywołujesz ją przez „sudo” i dopisujesz polecenie. Kontenery działają jako „root”, więc kopia też potrzebuje tych uprawnień.

Sześć pól poniżej możesz skopiować. Obejmują to, co naprawdę jest potrzebne w codziennej pracy.

Przywrócenie pyta również tutaj. Działa dopiero wtedy, gdy dopiszesz „--yes”. Przenosi wtedy także anonimizacje z dzisiejszego stanu, tak jak „Yes” w oknie. Z „--no-reapply” działa bez tego kroku.

Na serwerze jest plik, żeby to wszystko doczytać. Nazywa się „BACKUP-RESTORE.txt” i siedzi w „/opt/smitey”. Przechodzi jeszcze raz przez harmonogram, każde polecenie i drogę powrotną, we własnym tempie. Istnieje po niemiecku i po angielsku: jeśli podczas instalacji wybrałeś niemiecki, dostajesz niemiecką wersję, w przeciwnym razie angielską. Obie wersje siedzą też pod „/opt/smitey/docs”.

„key --show” pokazuje klucz odzyskiwania, identyfikator klucza i liczbę niezaszyfrowanych kopii. Gdy klucz jest zapisany poza serwerem, potwierdzasz to poleceniem „key --confirm-stored”.

Kopię z innego serwera przywracasz opcją „--key-file”. Wskazany plik zawiera klucz odzyskiwania. Działa do tego także plik z „Save to file...”. Zamiast pliku możesz użyć zmiennej środowiskowej „SMITEY_BACKUP_KEY”. Z „sudo” wpisujesz ją bezpośrednio przed programem, czyli „sudo SMITEY_BACKUP_KEY=<klucz> /opt/smitey/Backup/TicketSystemBackup restore …”. Klucz trafia wtedy do historii powłoki. Jeśli klucz nie pasuje, nic się nie zmienia.

„decrypt” zapisuje zawartość kopii jako niezaszyfrowane pliki w pustym folderze. Te pliki nie są zaszyfrowane. Zawierają hasła i dane osobowe. Usuń je, gdy tylko skończysz.

Kopie to pliki w ustawionym przez Ciebie folderze. Ten folder jest na tej samej maszynie co system zgłoszeń.

W typowych przypadkach działa to dobrze. Dane usunięte przez pomyłkę, nieudana aktualizacja albo błąd w danych są tym objęte.

Nie pomaga to przy awarii dysku. Jeśli dysk przepadnie, przepadną razem z nim kopie.

Kopiuj więc pliki gdzie indziej. Wystarczy dysk sieciowy, drugi serwer albo pamięć masowa w sieci.

Skopiowany plik da się wczytać z powrotem na dowolnym serwerze. Na innym serwerze potrzebujesz do tego klucza odzyskiwania. Przyciskiem „Import backup file…” przywracasz plik na listę.

Kopie są zaszyfrowane. Nikt nie odczyta ich bez klucza odzyskiwania. Nie trzymaj więc klucza obok kopii. Starsze kopie z końcówką „.zip” nie są zaszyfrowane.

Aktualizacja robi wcześniej własną kopię. Dzieje się to niezależnie od Twojego harmonogramu i bez zaznaczania czegokolwiek.

Zapisuje to samo co zawsze: bazę danych, załączniki, archiwa i klucze. Jeśli baza danych działa poza SMITEY, aktualizacja zapisuje tylko załączniki, archiwa i klucze.

Tę kopię robi aplikacja „Ticket System Backup & Restore”. Jest zaszyfrowana jak każda inna i leży w tym samym folderze. Na liście jej rodzaj to „Update”. Zachowywane są trzy najnowsze takie kopie. Starsze aplikacja usuwa sama.

Informacja przed aktualizacją tak mówi. Nie musisz sam pamiętać, żeby najpierw zapisać.

Jeśli ta kopia zapasowa się nie uda, aktualizacja zatrzymuje się, zanim cokolwiek zostanie zastąpione. Baza danych poza SMITEY nie wstrzymuje aktualizacji. Aktualizacja przestawia wtedy aplikację tak, że codzienna kopia też pomija bazę danych. Zrób kopię tej bazy danych własnymi narzędziami.