Backup serwerów Linux -
7 najczęstszych błędów
Masz backup. Uruchamia się co noc, zajmuje miejsce na dysku, a skrypt kończy się kodem 0 (bez błędów). Wygląda świetnie. Problem w tym, że większość „działających kopii zapasowych", które widzimy podczas audytów, w momencie realnej awarii okazuje się bezużyteczna lub bardzo problematyczna. Oto błędy, które widzimy najczęściej.
Backup na ten sam dysk lub serwer
Problem
Klasyczny przypadek: skrypt rsync kopiuje /var/www na /backup, obie lokalizacje na tym samym dysku. Awaria dysku niszczy wszystko jednocześnie. Jeszcze częściej: backup VM na lokalny dysk hosta Proxmox bez kopii zewnętrznej.
Rozwiązanie
Docelowy storage kopii zapasowej musi być fizycznie oddzielny od źródła. Minimum: dedykowany NAS lub zewnętrzny dysk. Optymalnie: Proxmox Backup Server (PBS) na osobnym serwerze + kopia off-site (B2, S3, zewnętrzna lokalizacja).
Brak testowania przywracania
Problem
Kopia zapasowa, której nigdy nie testowano, nie istnieje. Dopiero podczas przywracania okazuje się, że archiwum jest niekompletne, pliki uszkodzone lub cały proces zajmuje 8 godzin zamiast 30 minut. Najgorszy możliwy moment na to odkrycie to właśnie realna awaria.
Rozwiązanie
Minimum raz na kwartał: pełny test przywrócenia na środowisko testowe i weryfikacja działania aplikacji. PBS weryfikuje sumy kontrolne każdego chunku automatycznie przy każdym backupie - to znacząco zwiększa pewność integralności.
Brak monitorowania zadań backupu
Problem
Skrypt backupu przestał działać miesiąc temu - nikt nie sprawdzał. Baza danych nie był backupowana od 30 dni. Awaria następuje w dniu 31. Bez monitoringu zadań backupu, "posiadanie backupu" jest iluzją.
Rozwiązanie
Każde zadanie backupu powinno raportować sukces lub błąd. Najprostsze rozwiązanie: skrypt tworzy plik timestamp po sukcesie, monitoring (Zabbix, cron z alertem) sprawdza wiek pliku. Nowszy standard: integracja z API monitoringu (Healthchecks.io, własny Zabbix).
Nieuwzględnienie otwartych plików (bazy danych)
Problem
Backup katalogu /var/lib/mysql za pomocą rsync lub tar podczas gdy MySQL działa = uszkodzona kopia. Pliki bazy danych są aktywnie pisane, skopiowane w niespójnym stanie dają bezużyteczny backup. To samo dotyczy PostgreSQL, MongoDB i każdej aktywnej bazy.
Rozwiązanie
Bazy danych wymagają dedykowanego mechanizmu backupu: mysqldump/mysqlpump z --single-transaction dla InnoDB, pg_dump dla PostgreSQL, mongodump dla MongoDB. Alternatywnie: snapshot systemu plików (LVM snapshot, ZFS snapshot) przed backupem "zamraża" stan w spójnym punkcie. Proxmox automatycznie quiesces guest agent przed snapshotem.
Brak kopii offline lub off-site (złamana zasada 3-2-1)
Problem
Ransomware, który dostanie się do Twojej sieci, zaszyfruje wszystko, do czego ma dostęp - w tym kopie na NAS-ie w tej samej LAN. Backup na NAS bez segmentacji jest równie podatny jak oryginał. To samo tyczy pożaru lub zalania serwerowni. Kopia off-site (najlepiej immutable) jest absolutnie obowiązkowa.
Rozwiązanie
Opcje off-site: Backblaze B2 (najtańszy S3-compatible storage), AWS S3 Glacier, Azure Backup, lub fizyczny dysk w innej lokalizacji (wymiana co tydzień). Kluczowe: kopia off-site powinna być immutable (Object Lock w S3/B2) lub air-gapped - całkowicie niedostępna do modyfikacji z poziomu serwera produkcyjnego. To jedyna skuteczna ochrona przed ransomware kasującym kopie.
Za krótki lub za długi okres retencji
Problem
Przechowywanie backupów przez 24 godziny to za mało - ransomware może działać w tle przez tygodnie zanim zaszyfruje dane. Z kolei przechowywanie backupów co godzinę przez rok generuje koszty storage bez proporcjonalnych korzyści.
Rozwiązanie
Rekomendowane minimum: 7 dni codziennych kopii, 4 tygodniowe, 12 miesięcznych (GFS - Grandfather-Father-Son). PBS implementuje GFS natywnie. Retencja musi uwzględniać wymagania prawne - niektóre branże wymagają przechowywania danych przez 5-7 lat.
Brak warstwowości - kopia wszystkiego albo nic
Problem
Backup całego systemu operacyjnego przez tar (z /proc, /sys, /dev, /run) to podwójny błąd: te katalogi to wirtualne systemy plików jądra - ich kopia jest bezużyteczna i niepotrzebnie zwiększa rozmiar. Z drugiej strony, backup tylko wybranych plików bez baz danych i konfiguracji aplikacji daje kopię, z której nie można nic odtworzyć w całości.
Rozwiązanie
Podziel kopie zapasowe na warstwy: (1) dane aplikacyjne - bazy, pliki użytkowników, konfiguracje aplikacji; (2) snapshot VM w Proxmox - szybkie odtworzenie całego systemu; (3) konfiguracja infrastruktury - playbooki Ansible i reguły firewall w Git. Każda warstwa ma inną częstotliwość i retencję. Razem dają pełne pokrycie bez zbędnego chaosu.
Dobre praktyki backupu serwerów Linux
Kilka dodatkowych reguł, które wdrażamy we wszystkich zarządzanych środowiskach:
- › Kopie inkrementalne - PBS, Borg, Restic używają inkrementalnych kopii z deduplikacją - nawet 10× mniej miejsca niż pełne kopie co noc
- › Szyfrowanie - kopia off-site powinna być szyfrowana po stronie klienta (Restic, Borg, PBS mają szyfrowanie wbudowane); klucz przechowuj osobno od danych
- › Backup konfiguracji aplikacji - pliki .env, konfiguracje Nginx/Apache, parametry baz danych - warto je backupować osobno, bo ich utrata potrafi zablokować odtworzenie nawet przy kompletnych danych
- › Dokumentacja kopii zapasowych - co jest kopiowane, jak często, gdzie, jak długo przechowywane, kto może przywrócić i jak - to nieodłączna część planu przygotowania na awarię serwera
- › Konfiguracja infrastruktury w Git - playbooki Ansible, konfiguracje systemowe, reguły firewall - wersjonowane w repozytorium to kopia, która się nie „psuje"
FAQ - backup serwerów Linux
Jakie narzędzie do backupu wybrać dla serwera Linux?
Zależy od środowiska. Dla VM w Proxmox: PBS (deduplikacja, weryfikacja integralna, GFS). Dla danych aplikacyjnych: Restic (nowoczesny, szyfrowanie, S3/B2) lub BorgBackup (dojrzały, świetna deduplikacja). Dla baz danych: mysqldump/pg_dump jako skrypty cron + przechowywanie na zewnętrznym storage.
Jak wykonać backup bazy MySQL/MariaDB bez przestoju?
mysqldump z opcją --single-transaction dla tabel InnoDB wykonuje spójny backup bez blokowania tabel. Dla dużych baz (>50 GB) lepszym wyborem jest Percona XtraBackup, który robi hot backup (backup podczas działania) i jest wielokrotnie szybszy. Inkrementalne backupy baz danych: binlog replikacja + mysqldump lub Xtrabackup incremental.
Ile miejsca zajmuje backup z deduplikacją?
PBS osiąga typowo 3-10× kompresję dla VM z systemami Linux. Codzienne przyrostowe kopie 10 VM przez tydzień mogą zajmować tyle samo miejsca co 1-2 pełne obrazy. Restic/Borg osiągają podobne wyniki. Przykład: bez deduplikacji 7 nocy × 50 GB VM = 350 GB; z deduplikacją - 60-80 GB.
Jak zautomatyzować monitoring zadań backupu?
Healthchecks.io (self-hosted lub cloud): skrypt pinguje URL po zakończeniu, system alertuje gdy ping nie nadejdzie w oczekiwanym czasie. Zabbix: External check lub UserParameter monitorujący timestamp ostatniej kopii. PBS: wbudowane powiadomienia e-mail/webhook. Każde z tych podejść daje alert „kopia nie zadziałała" bez potrzeby ręcznego sprawdzania.
Czy backup w chmurze (S3, Azure Blob) jest bezpieczny?
Bezpieczny pod warunkiem szyfrowania po stronie klienta. Nigdy nie wysyłaj niezaszyfrowanych danych do chmury - nawet do zaufanego dostawcy. Restic, Borg i PBS szyfrują dane przed wysłaniem. Klucz szyfrujący przechowuj osobno od danych (nie w tej samej chmurze). Immutable backups w S3/Azure Blob (Object Lock) chronią przed ransomware skasowaniem kopii.
Podsumowanie
Kopia zapasowa, która nie jest testowana, monitorowana i przechowywana off-site, to tylko iluzja bezpieczeństwa. Siedem błędów opisanych w tym artykule odpowiada za większość sytuacji, w których firmy „miały backup" - ale i tak traciły dane. Warto pamiętać, że atak ransomware to jeden z najczestszych scenariuszy, w którym błędy w backupie wychodzą na jaw w najgorszym możliwym momencie.
Dobry backup to nie skrypt uruchomiony trzy lata temu. To żywy, regularny, monitorowany i testowany proces. Monitoring serwerów Linux - w tym monitoring zadań backupu - to fundament, bez którego żadna strategia kopii zapasowych nie jest wiarygodna. Sprawdź swój backup już dziś - zanim awaria zrobi to za Ciebie.
Audyt i konfiguracja backupu serwerów Linux
Sprawdzimy Twój obecny backup, wdrożymy monitoring i skonfigurujemy off-site kopie. Bezpłatna wstępna konsultacja.
Backup i DR - ofertaZobacz też na TikToku
Przeczytaj też
Jak przygotować firmę na awarię serwera?
RTO, RPO, HA i plan ciągłości działania IT
Backup maszyn wirtualnych
Proxmox Backup Server w praktyce
Monitoring serwerów Linux
Jak skutecznie monitorować serwery i usługi w firmie.
Atak ransomware - co robić?
Pierwsze kroki po ataku i jak backup chroni firmę.
Porozmawiajmy o Twoim IT
Odpiszemy najszybciej jak to możliwe. Bezpłatna konsultacja i wycena.
Obsługujemy firmy w Szczecinie, Stargardzie i okolicach oraz realizujemy usługi zdalnie na terenie całej Polski.