Kompletny przewodnik po kopiach bezpieczeństwa aplikacji w TrueNAS SCALE: Strategie lokalne i w chmurze

Andrzej Majewski Written in Bezpieczeństwo, Cron, Docker, Immich, KitchenOwl, Linux, Nextcloud, TrueNAS

Linux devotee and Bournemouth-based IT expert, obsessed with homelabbing, server performance, and elegant Python code.

Spis treści

Toggle

Gdy nadzieja to za mało jako strategia backupu

Każdy użytkownik TrueNAS zna to uczucie: godziny spędzone na starannej konfiguracji idealnego zestawu aplikacji – Nextcloud do synchronizacji plików, Jellyfin do streamingu mediów, Paperless-ngx do archiwizacji dokumentów. Serwer działa jak marzenie, a cyfrowe życie jest wreszcie uporządkowane. Jednak w tle czai się niepokojąca myśl: co, jeśli pewnego dnia dysk ulegnie awarii, aktualizacja się nie powiedzie lub przez pomyłkę usunę kluczową konfigurację?

Poleganie wyłącznie na integralności danych zapewnianej przez system plików ZFS to nie strategia tworzenia kopii zapasowych. Prawdziwe bezpieczeństwo danych opiera się na profesjonalnej zasadzie 3-2-1: posiadanie co najmniej trzech kopii danych, na dwóch różnych nośnikach, z czego jedna kopia znajduje się w innej lokalizacji (off-site).

Ten przewodnik przekształci Twoje obawy w pewność siebie, prowadząc Cię krok po kroku przez proces wdrożenia kompleksowej, dwutorowej strategii backupu dla Twoich aplikacji w TrueNAS SCALE. Zbudujemy dwa uzupełniające się systemy:

1. Lokalna „forteca” (Disaster Recovery): Cotygodniowa, pełna, bit-w-bit kopia całego ekosystemu aplikacji, zapisywana jako pojedynczy plik na dysku USB. To Twoja opcja „atomowa”, pozwalająca na odtworzenie wszystkiego po katastrofalnej awarii.
2. Codzienny „wehikuł czasu” w chmurze: Automatyczna, codzienna synchronizacja plików aplikacji z Dyskiem Google. To Twoja polisa ubezpieczeniowa na wypadek drobnych pomyłek, pozwalająca na błyskawiczne odzyskanie pojedynczego pliku lub konfiguracji.

Zaczynajmy. Po ukończeniu tego poradnika Twoje dane będą bezpieczniejsze niż kiedykolwiek wcześniej.

Pierwsza przeszkoda: Odkrywanie prawdziwej lokalizacji danych aplikacji

Zanim zaczniemy tworzyć kopie zapasowe, musimy odpowiedzieć na fundamentalne pytanie: gdzie TrueNAS SCALE faktycznie przechowuje dane naszych aplikacji? Intuicyjnie szukalibyśmy ich w interfejsie graficznym, ale ze względów bezpieczeństwa i stabilności, system celowo ukrywa te krytyczne zbiory danych (datasety).

Kluczem do odkrycia prawdy jest użycie wiersza poleceń (CLI) i zrozumienie fundamentalnej koncepcji systemu plików ZFS, która często jest źródłem nieporozumień.

Nazwa datasetu kontra punkt montowania: Dwa oblicza tych samych danych

ZFS operuje na dwóch odrębnych, choć powiązanych ze sobą pojęciach:

• Nazwa datasetu: To oficjalna, unikalna nazwa w strukturze ZFS. Używamy jej do wszystkich operacji zarządczych, takich jak tworzenie migawek (snapshotów) czy replikacji. W przypadku aplikacji w nowoczesnych wersjach TrueNAS SCALE, ta nazwa to Pool1/ix-apps (zakładając, że Twoja główna pula nazywa się Pool1).
• Punkt montowania: To fizyczna ścieżka w systemie plików serwera, gdzie możemy przeglądać pliki za pomocą poleceń takich jak cd czy ls. Dla datasetu aplikacji, ta ścieżka to /mnt/.ix-apps.

Niezrozumienie tej różnicy prowadzi do frustracji. Próba nawigacji do cd Pool1/ix-apps/app_configs zakończy się błędem, ponieważ system plików nie zna takiej ścieżki. Prawidłowe polecenie to

cd /mnt/.ix-apps/app_configs

Możemy zobaczyć to powiązanie na własne oczy, wykonując w terminalu polecenie zfs list | grep ’.ix-apps’. Wynik jasno pokaże mapowanie między kolumną NAME (nazwa datasetu) a MOUNTPOINT (punkt montowania).

Mając tę fundamentalną wiedzę, jesteśmy gotowi, aby zbudować naszą pierwszą, pancerną linię obrony.

Strategia 1: „Żelazny” lokalny backup na dysk USB

Ta strategia to nasza ostateczna siatka bezpieczeństwa. Jej celem nie jest odzyskiwanie pojedynczych plików, lecz zapewnienie możliwości odtworzenia całego środowiska aplikacji od zera po katastrofalnej awarii głównej puli dyskowej. Stworzymy w pełni zautomatyzowany proces, który co tydzień będzie generował pojedynczy, przenośny plik zawierający bit-w-bit idealną kopię wszystkich Twoich aplikacji.

3.1. Przygotowanie dysku USB do służby

Najpierw musimy odpowiednio przygotować nasz nośnik. Podłącz dysk USB do serwera TrueNAS i postępuj zgodnie z poniższymi krokami w interfejsie webowym:

1. Przejdź do Storage -> Pools i kliknij Add.
2. Stwórz nową pulę. Nazwij ją TrueNAS_Backup. Wybierz swój dysk USB i przenieś go do sekcji Data Vdevs. Jako typ Vdev wybierz Stripe, ponieważ mamy tylko jeden dysk. Zatwierdź utworzenie puli (spowoduje to usunięcie wszystkich danych z dysku).
3. Wewnątrz nowo utworzonej puli TrueNAS_Backup stwórz nowy zbiór danych (dataset). Nazwij go apps-snapshots. Ważne jest, aby nie używać nazw zaczynających się od prefiksu ix-, ponieważ jest on zarezerwowany dla systemu i spowoduje błąd walidacji.
4. Jako Dataset Preset wybierz opcję Generic. Jest to idealny wybór dla prostego przechowywania plików, bez zbędnego narzutu konfiguracyjnego, który wprowadzają presety takie jak SMB.

3.2. Strojenie wydajności: Optymalizacja rozmiaru rekordu

Zanim zapiszemy dataset, dokonamy jednej, kluczowej optymalizacji. W opcjach zaawansowanych znajdź Record Size. Domyślnie jest to 128 KiB, co jest uniwersalnym ustawieniem. Jednak nasz cel jest bardzo specyficzny: będziemy zapisywać pojedyncze, bardzo duże pliki (wielogigabajtowe strumienie migawek). W takim scenariuszu znacznie większy rozmiar rekordu jest o wiele bardziej wydajny, ponieważ redukuje ilość metadanych, które system musi przetworzyć.

Zmień wartość Record Size na największą dostępną, czyli 1M (lub 16M, jeśli Twoja wersja systemu na to pozwala). Jest to świadoma optymalizacja, która znacząco przyspieszy proces zapisu naszej kopii zapasowej.

3.3. Silnik automatyzacji: Skrypt backup_apps_to_usb.sh

Sercem naszego systemu będzie prosty, ale potężny skrypt powłoki. Ponieważ w niektórych instalacjach TrueNAS może brakować edytora nano, użyjemy uniwersalnego vi. Otwórz Shell w interfejsie TrueNAS i wykonaj

vi /mnt/Pool1/scripts/backup_apps_to_usb.sh

Naciśnij klawisz i, aby wejść w tryb wstawiania, a następnie wklej poniższy kod:

#!/bin/bash
# --- KONFIGURACJA ---
# Nazwa datasetu, który backupujemy
DATASET_DO_BACKUPU="Pool1/ix-apps"

# Nazwa puli USB i datasetu, gdzie zapisujemy backup
POOL_USB="TrueNAS_Backup"
DATASET_USB="apps-snapshots"

# Ile ostatnich backupów na dysku USB chcesz zostawić
ILE_KOPII_ZOSTAWIC=4
# --------------------

# Pełna ścieżka do katalogu docelowego
KATALOG_DOCELOWY="/mnt/${POOL_USB}/${DATASET_USB}"

# Nazwa tymczasowej migawki
NAZWA_MIGAWKI="backup_do_wyslania_na_usb"

# Pełna nazwa migawki z datasetem
PELNA_NAZWA_MIGAWKI="${DATASET_DO_BACKUPU}@${NAZWA_MIGAWKI}"

# Nazwa pliku docelowego z dzisiejszą datą
PLIK_DOCELOWY="${KATALOG_DOCELOWY}/backup-$(date +"%Y-%m-%d").zfs"

echo "--- Rozpoczęcie backupu aplikacji na USB ---"

# 1. Stwórz nową, czystą migawkę (najpierw usuń starą, jeśli istnieje)
echo "1/4: Tworzenie świeżej migawki..."
zfs destroy -r "${PELNA_NAZWA_MIGAWKI}" 2>/dev/null |

| true
zfs snapshot -r "${PELNA_NAZWA_MIGAWKI}"

# 2. Wyślij migawkę do pliku na dysku USB
echo "2/4: Zapisywanie migawki do pliku: ${PLIK_DOCELOWY}"
zfs send "${PELNA_NAZWA_MIGAWKI}" > "${PLIK_DOCELOWY}"

# 3. Usuń tymczasową migawkę z głównej puli, aby nie zaśmiecać
echo "3/4: Usuwanie tymczasowej migawki z Pool1..."
zfs destroy -r "${PELNA_NAZWA_MIGAWKI}"

# 4. Usuń najstarsze pliki backupu z USB, zostawiając zdefiniowaną liczbę kopii
echo "4/4: Czyszczenie starych kopii na USB..."
ls -tp "${KATALOG_DOCELOWY}" | grep -v '/$' | tail -n +$((ILE_KOPII_ZOSTAWIC + 1)) | xargs -I {} rm -- "${KATALOG_DOCELOWY}/{}"

echo "--- Backup na USB zakończony pomyślnie ---"

Aby zapisać plik, naciśnij Esc, wpisz :wq i naciśnij Enter. Na koniec nadaj skryptowi uprawnienia do wykonania:

chmod +x /mnt/Pool1/scripts/backup_apps_to_usb.sh

Skrypt ten w sposób zautomatyzowany:

1. Tworzy tymczasową, spójną migawkę wszystkich danych aplikacji.
2. Używa polecenia zfs send, aby przekonwertować tę migawkę na wysoce wydajny strumień danych i zapisać go jako pojedynczy plik .zfs na dysku USB.
3. Sprząta po sobie, usuwając tymczasową migawkę.
4. Zarządza miejscem na dysku USB, automatycznie usuwając najstarsze kopie i pozostawiając tylko cztery najnowsze.

3.4. Ustaw i zapomnij: Planowanie cotygodniowego zadania Cron

Ostatnim krokiem jest pełna automatyzacja. Przejdź do System Settings -> Advanced Settings -> Cron Jobs i skonfiguruj zadanie zgodnie z poniższą tabelą, która odzwierciedla sprawdzoną i działającą konfigurację.

Po zapisaniu, Twój lokalny system backupu jest gotowy. Co tydzień, bez żadnej interwencji, na dysku USB będzie lądować nowa, kompletna kopia Twoich aplikacji, zapewniając Ci żelazne bezpieczeństwo.

Strategia 2: Codzienny „ratownik” – backup w chmurze na Dysku Google

Lokalny backup jest fundamentem, ale prawdziwy spokój ducha daje dopiero kopia off-site, która chroni dane przed pożarem, kradzieżą czy inną katastrofą w lokalizacji serwera. Ta strategia skupia się na codziennej synchronizacji plików aplikacji z Dyskiem Google, co jest idealne do szybkiego odzyskiwania pojedynczych plików konfiguracyjnych czy danych.

4.1. Złota zasada: Nigdy nie kopiuj „żywych” danych aplikacji

Zanim przejdziemy do konfiguracji, musimy zrozumieć najważniejszą zasadę: kopiowanie plików aplikacji, które są w ciągłym użyciu, to prosta droga do uszkodzonej i bezużytecznej kopii zapasowej. W każdej sekundzie Twoje aplikacje zapisują dane do baz, logów i plików konfiguracyjnych. Próba skopiowania ich „na żywo” jest jak robienie zdjęcia pędzącego samochodu – wynik zawsze będzie rozmazany i nieostry.

Rozwiązaniem jest migawka ZFS. Działa ona jak błyskawiczna „fotografia” całego systemu plików, zamrażając wszystkie pliki w idealnie spójnym stanie w jednej nanosekundzie. Dopiero z tej bezpiecznej, niezmiennej „fotografii” będziemy kopiować dane do chmury. To jedyny sposób, aby zagwarantować, że nasza kopia zapasowa będzie w 100% użyteczna.

4.2. Omijając interfejs: Ręczna konfiguracja rclone

Podczas dogłębnej analizy okazało się, że w testowanej wersji TrueNAS SCALE (25.04 „Fangtooth”) narzędzia wysokiego poziomu, takie jak interfejs Cloud Sync czy polecenie midclt nie były dostępne, lub zmodyfikowane, co uniemozliwiało poprawną konfigurację. Jedyną niezawodną drogą do sukcesu było ominięcie tych abstrakcji i skonfigurowanie fundamentalnego narzędzia, na którym one bazują – rclone – bezpośrednio z wiersza poleceń.

1. W terminalu TrueNAS uruchom interaktywny konfigurator: rclone config.
2. Wybierz n (New remote), aby utworzyć nowe połączenie.
3. Nazwij je GDriveBackup.
4. Z listy wybierz Google Drive.
5. Pozostaw client_id i client_secret puste (naciśnij Enter).
6. Dla scope wybierz 1 (pełny dostęp do dysku).
7. Pozostaw root_folder_id i service_account_file puste.
8. Na pytanie Use auto config? odpowiedz n – to kluczowe, ponieważ działamy na serwerze bez przeglądarki graficznej.
9. rclone wyświetli link. Skopiuj go i otwórz w przeglądarce na swoim komputerze. Zaloguj się na konto Google i zezwól na dostęp.
10. Google wyświetli kod weryfikacyjny. Skopiuj go i wklej z powrotem do terminala TrueNAS.
11. Potwierdź konfigurację, wpisując y (Yes), a następnie zakończ, wpisując q (Quit).

Aby zweryfikować, czy wszystko działa, wykonaj polecenie rclone ls GDriveBackup:. Jeśli na ekranie pojawi się lista plików i folderów z Twojego Dysku Google, oznacza to, że połączenie jest w 100% sprawne.

4.3. Ostateczny skrypt synchronizacji: sync_to_gdrive.sh

Wirtualny system plików migawek (.zfs/snapshot) w tej wersji TrueNAS jest prezentowany w sposób, który sprawia problemy standardowym narzędziom. Ani mount –bind, ani rclone z opcją -L nie potrafiły poprawnie zinterpretować zagnieżdżonej struktury datasetów.

Ostatecznym, niezawodnym rozwiązaniem jest skrypt, który najpierw tworzy jedną, spójną w czasie migawkę dla wszystkich aplikacji, a następnie synchronizuje każdy z kluczowych podkatalogów (które są osobnymi datasetami) z osobna, odwołując się bezpośrednio do ich własnych migawek.

Utwórz skrypt

vi /mnt/Pool1/scripts/sync_to_gdrive.sh 

i wklej do niego poniższą, finalną zawartość:

#!/bin/bash
# === KONFIGURACJA ===
NAZWA_ZDALNEGO_CELU="GDriveBackup"
FOLDER_DOCELOWY_GDRIVE="TrueNAS_AppsBackup"
NAZWA_MIGAWKI="final_gdrive_snapshot"
DATASET_GLOWNY="Pool1/ix-apps"
# ====================

echo "--- Rozpoczęcie ostatecznego, granularnego procesu backupu na Google Drive ---"

# Krok 1: Stworzenie jednej, spójnej migawki dla wszystkich danych
echo "1/3: Tworzenie spójnej migawki @${NAZWA_MIGAWKI}..."
zfs destroy -r "${DATASET_GLOWNY}@${NAZWA_MIGAWKI}" 2>/dev/null |

| true
zfs snapshot -r "${DATASET_GLOWNY}@${NAZWA_MIGAWKI}"

# Krok 2: Synchronizacja każdego ważnego pod-datasetu z osobna, odwołując się do jego własnej migawki
echo "2/3: Rozpoczęcie synchronizacji poszczególnych folderów..."

echo " -> Synchronizowanie app_configs..."
/usr/bin/rclone sync -v --create-empty-src-dirs "/mnt/.ix-apps/app_configs/.zfs/snapshot/${NAZWA_MIGAWKI}/" "${NAZWA_ZDALNEGO_CELU}:${FOLDER_DOCELOWY_GDRIVE}/app_configs"

echo " -> Synchronizowanie app_mounts..."
/usr/bin/rclone sync -v --create-empty-src-dirs "/mnt/.ix-apps/app_mounts/.zfs/snapshot/${NAZWA_MIGAWKI}/" "${NAZWA_ZDALNEGO_CELU}:${FOLDER_DOCELOWY_GDRIVE}/app_mounts"

echo " -> Synchronizowanie docker..."
/usr/bin/rclone sync -v --create-empty-src-dirs "/mnt/.ix-apps/docker/.zfs/snapshot/${NAZWA_MIGAWKI}/" "${NAZWA_ZDALNEGO_CELU}:${FOLDER_DOCELOWY_GDRIVE}/docker"

echo " -> Synchronizowanie truenas_catalog..."
/usr/bin/rclone sync -v --create-empty-src-dirs "/mnt/.ix-apps/truenas_catalog/.zfs/snapshot/${NAZWA_MIGAWKI}/" "${NAZWA_ZDALNEGO_CELU}:${FOLDER_DOCELOWY_GDRIVE}/truenas_catalog"

echo " -> Synchronizowanie głównych plików.yaml z migawki nadrzędnej..."
/usr/bin/rclone sync -v --include "*.yaml" "/mnt/.ix-apps/.zfs/snapshot/${NAZWA_MIGAWKI}/" "${NAZWA_ZDALNEGO_CELU}:${FOLDER_DOCELOWY_GDRIVE}"

# Krok 3: Usunięcie migawki po zakończeniu pracy
echo "3/3: Usuwanie migawki..."
zfs destroy -r "${DATASET_GLOWNY}@${NAZWA_MIGAWKI}"

echo "--- Synchronizacja zakończona pomyślnie ---"

Zapisz plik i nadaj mu uprawnienia do wykonania: 

chmod +x /mnt/Pool1/scripts/sync_to_gdrive.sh.

4.4. Pełna automatyzacja: Zadanie Cron „wszystko w jednym”

Ostatni element układanki to zadanie Cron, które zorkiestruje cały proces. Będzie ono składało się z dwóch poleceń: najpierw stworzy spójną migawkę, a zaraz po tym uruchomi nasz skrypt synchronizujący.

Podsumowanie: Osiągnięcie backupowego zen

Gratulacje! Przeszedłeś przez skomplikowany, ale niezwykle wartościowy proces, którego efektem jest profesjonalny, wielopoziomowy system ochrony danych. Twoje aplikacje są teraz chronione przez dwie, uzupełniające się strategie:

• Backup na USB: Cotygodniowa, pełna, lokalna kopia zapasowa, gotowa do odtworzenia całego środowiska po katastrofalnej awarii sprzętowej.
• Backup na Dysk Google: Codzienna, granularna, zdalna kopia zapasowa, idealna do szybkiego odzyskiwania pojedynczych plików i chroniąca przed awarią całej lokalizacji.

Chociaż konfiguracja wymagała zagłębienia się w wiersz poleceń i ominięcia pewnych ograniczeń interfejsu, wynikowy system jest w pełni zautomatyzowany, niezawodny i daje prawdziwy spokój ducha. Możesz teraz spać spokojnie, wiedząc, że Twoje cyfrowe życie jest bezpieczne.

Andrzej Majewski

Moja fascynacja technologią zaczęła się podczas studiów informatycznych na Uniwersytecie Zielonogórskim. Od czasu przeprowadzki do Wielkiej Brytanii w 2015 roku i osiedlenia się na stałe w Bournemouth, przekułem tę pasję w karierę zawodową poświęconą infrastrukturze o wysokiej wydajności.W głębi duszy jestem entuzjastą Linuxa – to zaangażowanie wykracza poza moją pracę zawodową w SolutionsInc i obejmuje również mój rozbudowany, prywatny homelab. Niezależnie od tego, czy zarządzam złożonymi architekturami serwerowymi przez ISPConfig, buduję systemy VoIP w ramach Phones Rescue, czy tworzę narzędzia do automatyzacji w Pythonie, najlepiej czuję się, podejmując wyzwania związane z projektowaniem wydajnych rozwiązań open-source