Backup przed wdrożeniem i podstawowy rollback
Przygotujesz backup danych i konfiguracji przed wdrożeniem oraz przećwiczysz kontrolowany powrót do zapisanej wersji kodu i bazy.
1. Krótka teoria
Backup przed wdrożeniem ogranicza skutki błędu, ale tylko wtedy, gdy obejmuje właściwe zasoby i da się go odtworzyć. Kod, konfiguracja i dane wymagają różnych metod. Kod ma historię Git, dlatego przed zmianą zapisuje się identyfikator z git rev-parse HEAD. Plik .env i konfigurację usługi należy kopiować z zachowaniem uprawnień do chronionego katalogu. Dane SQLite wymagają spójnej kopii. Najlepiej użyć polecenia .backup klienta sqlite3, które korzysta z API backupu. Przy prostym kopiowaniu pliku bazę powinna wcześniej przestać modyfikować aplikacja, zwykle przez kontrolowane zatrzymanie usługi; samo cp aktywnej bazy może dać niespójny wynik, szczególnie przy dodatkowych plikach WAL. Katalog /opt/example-app/backups powinien mieć ograniczone uprawnienia. Znacznik czasu w nazwie pozwala powiązać pliki z wdrożeniem, lecz trzeba też sprawdzić kod wyjścia, istnienie i rozmiar kopii. Backup bez testu odtworzenia daje fałszywe poczucie bezpieczeństwa. Rollback kodu i rollback danych to osobne decyzje. Do awaryjnego uruchomienia zapisanej wersji można w kontrolowany sposób użyć git switch --detach <commit>, po wcześniejszym sprawdzeniu working tree i historii. Docelowo warto mieć udokumentowaną metodę powrotu brancha lub wydania, aby nie pozostawić serwera bez nazwanego brancha. Przywrócenie bazy wymaga zatrzymania aplikacji, zabezpieczenia bieżącego pliku, odtworzenia sprawdzonej kopii, ustawienia właściciela i restartu. Cofnięcie kodu nie zawsze wymaga cofnięcia danych. Nowy kod mógł jednak zmienić schemat lub zapisać dane niezgodne ze starą wersją. Bardziej złożone systemy potrzebują wersjonowanych migracji oraz osobnych procedur rollbacku danych. Każdy krok, commit, plik backupu i wynik weryfikacji należy udokumentować.
2. Przykłady komend
sudo install -d -o example-app -g example-app -m 700 /opt/example-app/backups
Tworzy chroniony katalog backupów dla użytkownika aplikacji.
$ sudo install -d -o example-app -g example-app -m 700 /opt/example-app/backups
date +%Y%m%d-%H%M%S && git rev-parse HEAD
Generuje znacznik czasu i zapisuje dokładny commit przed wdrożeniem.
$ date +%Y%m%d-%H%M%S
20260806-153000
$ git rev-parse HEAD
sqlite3 /opt/example-app/data/app.db ".backup '/opt/example-app/backups/app-20260806-153000.db'"
Tworzy spójną kopię bazy SQLite przez mechanizm backupu.
$ sqlite3 /opt/example-app/data/app.db ".backup '/opt/example-app/backups/app-20260806-153000.db'"
sudo cp --preserve=mode,ownership /opt/example-app/.env /opt/example-app/backups/.env-20260806-153000
Kopiuje konfigurację z zachowaniem właściciela i uprawnień.
$ sudo cp --preserve=mode,ownership /opt/example-app/.env /opt/example-app/backups/.env-20260806-153000
git log --oneline -5 && git switch --detach <commit>
Pozwala wybrać i tymczasowo uruchomić wcześniej zidentyfikowany commit.
$ git log --oneline -5
$ git switch --detach <commit>
sudo systemctl restart example-app
Uruchamia usługę z wybraną wersją po wykonaniu wymaganych operacji odtworzeniowych.
$ sudo systemctl restart example-app3. Zadanie praktyczne
/opt/example-app/backups i wygeneruj znacznik czasu. Zapisz commit przez git rev-parse HEAD, wykonaj backup bazy przez sqlite3 .backup oraz kopię .env z zachowaniem uprawnień. Sprawdź, że pliki istnieją, mają niezerowy rozmiar i właściwego właściciela. Następnie opisz kontrolowany rollback: zatrzymanie zmian, wybór zapisanego commita, decyzję czy cofać dane, bezpieczne odtworzenie bazy, restart, status, logi i smoke test. Ćwiczenie wykonaj na danych laboratoryjnych.
4. Typowe błędy
- Kopiowanie aktywnej bazy SQLite bez .backup lub zatrzymania zapisującej aplikacji.
- Tworzenie backupu bez sprawdzenia jego istnienia, rozmiaru i możliwości odtworzenia.
- Przechowywanie kopii .env z uprawnieniami umożliwiającymi odczyt innym użytkownikom.
- Rozpoczynanie rollbacku bez zapisanego commita i backupu danych.
- Automatyczne cofanie bazy razem z kodem bez analizy zgodności danych.
- Używanie git reset --hard jako podstawowej metody bez oceny utraty zmian.
- Brak dokumentacji wskazującej użyty commit, backup i wynik weryfikacji.
5. Podsumowanie
Przed wdrożeniem należy osobno zabezpieczyć dane, konfigurację i punkt odniesienia kodu. SQLite najbezpieczniej kopiować przez .backup, a pliki konfiguracyjne przechowywać z ograniczonymi uprawnieniami. Rollback kodu nie oznacza automatycznie rollbacku danych; zgodność wersji i migracji trzeba ocenić przed odtworzeniem. Procedura kończy się restartem i weryfikacją.