Backup serwera Linux w firmie – konfiguracja krok po kroku

Dlaczego backup serwera Linux to nie tylko kopia plików

Serwer Linux w firmie rzadko jest tylko magazynem dokumentów. Częściej stoi za nim baza danych aplikacji sprzedażowej, konfiguracja serwera pocztowego, panel WWW klienta albo usługi sieciowe, od których zależy codzienna praca firmy. Kopiowanie samych plików bez uwzględnienia specyfiki działających usług to najczęstszy błąd, jaki widzimy podczas audytów u klientów.

• Bazy danych wymagają spójnego zrzutu (dump), a nie kopiowania plików na żywo, bo grozi to uszkodzoną kopią.
• Konfiguracje usług (nginx, Postfix, Samba, Docker) zmieniają się częściej niż się wydaje i łatwo o nie zapomnieć.
• Uprawnienia i atrybuty plików (właściciel, grupa, ACL) muszą zostać odtworzone razem z danymi, inaczej po przywróceniu usługa się nie uruchomi.

Dobry plan backupu serwera Linux zaczyna się więc od inwentaryzacji tego, co faktycznie trzeba zabezpieczyć, a nie od wyboru narzędzia.

Strategia 3-2-1 i wybór narzędzia

Zanim wybierzesz konkretne oprogramowanie, ustal zasady. Sprawdzona reguła to 3-2-1: co najmniej trzy kopie danych, na dwóch różnych nośnikach, z czego jedna poza siedzibą firmy (np. w chmurze lub w innej lokalizacji). Dla serwerów Linux najczęściej sprawdzają się trzy typy narzędzi:

• rsync - proste, szybkie kopiowanie przyrostowe plików, idealne do lokalnych kopii i synchronizacji z serwerem backupowym.
• restic - nowoczesne narzędzie z deduplikacją i szyfrowaniem end-to-end, wysyłające dane bezpośrednio do chmury (S3, Backblaze, SFTP).
• borgbackup - podobny do restic, z bardzo wydajną deduplikacją, popularny przy dużych zbiorach danych i długiej historii wersji.

Nie musisz wybierać jednego narzędzia na zawsze - wiele firm łączy rsync do szybkich kopii lokalnych z restic lub borgbackup do archiwizacji poza serwerownię.

Backup plików i konfiguracji - przykład z rsync i cron

Najprostszy, w pełni działający schemat backupu katalogów i konfiguracji można zbudować w kilku krokach:

1. Utwórz dedykowanego użytkownika systemowego do backupu, z ograniczonymi uprawnieniami.
2. Skonfiguruj klucz SSH bez hasła między serwerem źródłowym a serwerem docelowym backupu.
3. Napisz skrypt wywołujący rsync -aAX --delete, który zachowuje uprawnienia, ACL-e i usuwa z kopii pliki skasowane na serwerze źródłowym.
4. Dodaj zadanie do crontab, uruchamiane w godzinach niskiego obciążenia, np. w nocy.
5. Zapisz logi wykonania do osobnego pliku i skonfiguruj powiadomienie e-mail w razie błędu skryptu.

Pamiętaj o katalogach konfiguracyjnych typu /etc, plikach jednostek systemd oraz definicjach kontenerów Docker (docker-compose.yml) - to one pozwalają szybko odtworzyć działanie usługi na nowym serwerze.

Backup baz danych - dump zamiast kopiowania plików

Bazy danych MySQL/MariaDB czy PostgreSQL nie powinny być kopiowane jako surowe pliki na działającym serwerze - grozi to niespójną, bezużyteczną kopią. Zamiast tego stosuje się narzędzia eksportujące dane w spójnym stanie:

• mysqldump lub mariabackup dla MySQL/MariaDB, z opcją transakcyjną dla baz InnoDB.
• pg_dump lub pg_basebackup dla PostgreSQL, w zależności od tego, czy potrzebujesz pełnej kopii binarnej, czy logicznego zrzutu.

Zrzut bazy warto generować cyklicznie do osobnego pliku ze znacznikiem czasu, a dopiero potem obejmować go tym samym mechanizmem backupu, który zabezpiecza pliki i konfigurację serwera. Dzięki temu jedna kopia zawiera zarówno dane aplikacji, jak i bazę, z której korzysta.

Automatyzacja, szyfrowanie i przechowywanie poza serwerem

Backup, który wymaga ręcznego uruchamiania, prędzej czy później zostanie pominięty. Dlatego całość powinna działać automatycznie i być monitorowana:

• Zadania cron lub systemd timer uruchamiające skrypty backupu o stałych porach.
• Wysyłka kopii poza serwer - do innej lokalizacji firmowej, na serwer NAS lub do chmury (S3, Backblaze B2, Azure Blob Storage).
• Szyfrowanie kopii przed wysłaniem poza infrastrukturę firmy - restic i borgbackup robią to natywnie, przy rsync warto dodać szyfrowanie na poziomie transportu (SSH) i nośnika docelowego.
• Rotacja kopii (np. dobowe, tygodniowe, miesięczne) i automatyczne usuwanie najstarszych wersji, aby backup nie zapełnił dysku.
• Monitoring - alert e-mail lub w systemie monitoringu IT, jeśli zadanie backupu nie wykonało się poprawnie.

Testowanie odtwarzania - krok, o którym się zapomina

Kopia zapasowa, której nikt nie próbował odtworzyć, jest tylko hipotezą, że backup działa. W praktyce warto co najmniej raz na kwartał przeprowadzić próbne odtworzenie danych na testowym serwerze:

• Odtwórz zrzut bazy danych i sprawdź, czy aplikacja poprawnie się z nim łączy.
• Przywróć katalog z plikami i zweryfikuj uprawnienia oraz kompletność danych.
• Zmierz czas potrzebny na pełne odtworzenie serwera - to realny wskaźnik RTO (Recovery Time Objective) Twojej firmy.

Dopiero test odtwarzania pokazuje, czy backup rzeczywiście chroni firmę, czy jest tylko procedurą na papierze.