Jak tiering danych ułatwia mi tworzenie kopii zapasowych w homelabowym NAS-ie

Spis treści
- Dane, które mają znaczenie
- Tiering danych na QNAP TS-664 — od żelaza do folderu
- Foldery współdzielone jako fundament backupu
- Nie wszystkie dane są równe — klasyfikacja i strategia 3–2‑1
- QNAP Hybrid Backup Sync 3 — centrum dowodzenia backupem
- Vendor lock-in kontra open source — mój wybór i dlaczego
- Jak wygląda mój backup w praktyce
- Chmura jako ostatnia linia obrony — Hetzner Storage Box
- Jak walidować poprawność backupu w HBS3
- Podsumowanie
Dane, które mają znaczenie
Mam na dyskach rzeczy, których utrata byłaby dla mnie katastrofą. Nie mówię tu o filmach czy serialach — te można zgrać czy w inny sposób zdobyć ponownie. Mówię o rodzinnych zdjęciach z ostatnich kilkunastu lat, dokumentach prywatnych i projektowych, archiwum korespondencji, konfiguracjach środowisk, które budowałem miesiącami, i materiałach z pracy zawodowej, które reprezentują realną wartość biznesową.
Pracuję na styku marketingu i technologii. Prowadzę projekty dla klientów, buduję automatyzacje, wdrażam systemy oparte na modelach LLM. Każdy z tych projektów generuje dane — konfiguracje, skrypty, dokumenty, bazy wiedzy. Utrata tych zasobów to nie tylko sentymentalna strata, ale realne ryzyko dla ciągłości pracy i reputacji zawodowej.
Przez lata przekonałem się, że backup to nie jednorazowe zadanie do odhaczenia. To proces, który wymaga przemyślanej architektury. I właśnie tutaj zaczyna się historia tieringu danych — czyli świadomego podziału zasobów na warstwy według ich wartości, częstotliwości dostępu i wymagań dotyczących ochrony.
Kiedy zacząłem budować swój homelab oparty na QNAP TS-664, szybko zorientowałem się, że chaotyczne wrzucanie wszystkiego do jednego worka to prosta droga do bałaganu zarówno w organizacji danych, jak i w zarządzaniu kopiami zapasowymi. Tiering wymusił na mnie porządek, który dziś przekłada się na spokój ducha i przewidywalność całego systemu backupu.
Tiering danych na QNAP TS-664
QNAP TS-664 to sześciozatokowy NAS z procesorem Intel Celeron N5095 i obsługą do dwóch dysków NVMe w slotach M.2. Nie mam niestety żadnej karty rozszerzeń ale można storage jeszcze powiększyć czy to za pomocą kart rozszerzeń PCIe, czy zewnętrznych jednostek rozszerzających. Ta kombinacja pozwala na zbudowanie prawdziwego tieringu pamięci masowej — od błyskawicznych nośników SSD po pojemne dyski talerzowe. W moim przypadku wygląda to następująco:
Warstwa pierwsza: szybki magazyn NVMe (pula pamięci 2)
Dwa dyski NVMe Lexar SSD NM620 o pojemności 512 GB każdy, połączone w macierz RAID 1 (lustrzane odbicie), tworzą pulę pamięci 2 o użytecznej pojemności 444 GB. To najszybsza warstwa w całym systemie i celowo przeznaczona dla danych wymagających intensywnego dostępu I/O.
Na serwerze przyjąłem ujednolicone nazewnictwo folderów współdzielonych stworzonych na określonych pulach pamięci, dzięki czemu od razu wiem, gdzie znajduje się dany folder współdzielony. Dla przykładu: foldery współdzielone rozpoczynające z prefiksem “vol2” znajdują się na szybkiej puli pamięci 2. Analogicznie “vol3” czy “vol1” od razu informują mnie, gdzie fizycznie znajdują się dane trzymane w folderach współdzielonych. Czemu tak? Bo to czyste błogosławieństwo przy pracy z większą ilością folderów współdzielonych rozrzuconych po różnych napędach. W domu zwykle tego nie doświadczysz ale w pracy… Wróćmy jednak do mojej najszybszej puli pamięci numer 2.
Co tu trzymam? Przede wszystkim dane kontenerów Docker — folder współdzielony vol2-data zawiera dane wszystkich uruchomionych kontenerów. Przykładowo kiedy Immich przetwarza zdjęcia, gdy n8n wykonuje automatyzacje, gdy Calibre-Web serwuje bibliotekę — wszystkie te operacje “dzieją się” na puli dysków NVMe. Różnica w responsywności w porównaniu z dyskami HDD czy nawet SSD SATA jest odczuwalna natychmiast.
Dlaczego RAID 1 na NVMe? Bo dane kontenerów to konfiguracje i stany aplikacji — ich utrata oznaczałaby konieczność ręcznej rekonfiguracji dziesiątek usług. Lustrzane odbicie daje mi ochronę przed awarią pojedynczego nośnika bez żadnego przestoju i czas na wymianę wadliwego dysku.
Warstwa druga: główny magazyn danych HDD (pula pamięci 1)
Pięć dysków talerzowych Toshiba HDWG480 o pojemności 7,28 TB każdy, połączonych w macierz RAID 5, tworzy pulę pamięci 1 o użytecznej przestrzeni 29,07 TB. To serce całego systemu — tu mieszka zdecydowana większość danych.
RAID 5 to świadomy kompromis: chronię się przed awarią jednego dysku, zachowując przy tym dużą pojemność użyteczną. Pięć dysków po 7,28 TB daje mi 29 TB do dyspozycji — wystarczająco dużo, żeby pomieścić zarówno archiwum mediów, jak i kopie zapasowe wszystkich krytycznych danych.
Na tej puli trzymam m.in.:
- Bibliotekę mediów (filmy, seriale, muzyka), którą serwuję domownikom via Plex. Są to rzeczy zgrane z płyt Blu-ray, DVD czy audio, które trzymam w ramach cyfryzacji swoich zbiorów.
- Kolekcję rzeczy pobranych z internetów.
- Kopie zapasowe z podziałem na podkatalogi tematyczne.
- Foldery domowe użytkowników.
- Różne zasoby, które ogólnie nazwałem “goodies” czyli rzeczy, które z różnych względów przechowuję.
Warstwa trzecia: dysk roboczy SSD (pula pamięci 3)
Pojedynczy dysk Samsung SSD 870 EVO 2 TB (bez RAID, tryb Single) tworzy pulę pamięci 3 o pojemności 1,72 TB. To celowy wybór — ten dysk pełni rolę tzw. scratch disk, czyli miejsca na dane intensywnie obracane przez aplikacje. Trzymam tu głównie rzeczy, do których potrzebny jest szybki dostęp, takie jak biblioteka zdjęć dla aplikacji Immich, biblioteka ebooków dla aplikacji Calibre i Calibre-Web oraz katalog pobierania torrentów. Pobrane torrenty są automatycznie przenoszone do głównej biblioteki na puli HDD. Dzięki takiemu rozwiązaniu (pobieranie na SSD a seedowanie z HDD) operacje IO generowane przez pobierane torrenty nie wbijają obciążenia serwera ponad sensowne wartości, co zapewnia responsywność systemowi.
Brak RAID na tym dysku to świadoma decyzja: dane Immich czy Calibre mają własne, regularne kopie zapasowe skonfigurowane w HBS3, więc awaria nośnika nie oznacza utraty danych — oznacza jedynie konieczność ich przywrócenia z backupu.
Warstwa czwarta: dysk USB — air gap
Do QNAP TS-664 podłączony jest jeszcze zewnętrzny dysk USB — to fizycznie odizolowany nośnik, klasyczny air gap. Codziennie o 02:00 w nocy HBS3 wykonuje na niego pełną kopię zapasową najważniejszych danych trzymanych na NASie (o ile dysk jest podpięty). Nawet jeśli ransomware zaatakuje sieć lokalną, ten dysk pozostaje poza zasięgiem gdyż automatycznie jest odłączany po udanym backupie.
Foldery współdzielone jako fundament backupu
Tiering to nie tylko podział na warstwy sprzętowe. To również logiczny podział danych w ramach folderów współdzielonych. I właśnie ten podział sprawia, że backup staje się prosty i przewidywalny.
Zamiast backupować cały NAS jako jedną bryłę, mogę precyzyjnie wskazać, co, gdzie i jak często ma być kopiowane. Folder współdzielony o nazwie vol1-backup na puli HDD zawiera już wstępnie posegregowane dane takie jak zdjęcia, archiwa i materiały związane z pracą, archiwum prywatne, kopie gier, oprogramowania i inne. Każdy podkatalog to osobna kategoria danych z własnym profilem ryzyka.
Dywersyfikacja nośników i lokalizacji wygląda w moim przypadku tak:
| Lokalizacja | Typ nośnika | Rola w strategii 3–2‑1 |
| QNAP TS-664 | NVMe RAID 1 + HDD RAID 5 + SSD Single | Kopia 1 — oryginał |
| Synology DS213+ | HDD, sieć lokalna (WebDAV) | Kopia 2 — lokalny backup |
| Dysk USB | Zewnętrzny HDD, air gap | Kopia 2b — izolowana lokalnie |
| Hetzner Storage Box | Chmura, centrum danych w Niemczech | Kopia 3 — off-site |
Taki układ oznacza, że nawet w scenariuszu pożaru domu (utrata serwera QNAP i dysku USB) moje krytyczne dane są bezpieczne poza domem na serwerach Hetznera. A w scenariuszu awarii jednego dysku w QNAP — RAID robi swoje a ja mam czas na ogarnięcie awarii.
Nie wszystkie dane są równe — klasyfikacja i strategia 3–2‑1
Kluczowe odkrycie, do którego doszedłem po latach eksperymentowania: nie ma sensu traktować wszystkich danych jednakowo. Backupowanie terabajtów zgranych z płyt mediów z taką samą częstotliwością i na te same nośniki co zdjęcia rodzinne to marnotrawstwo zasobów i przepustowości.
Moja klasyfikacja wygląda następująco:
Dane krytyczne — pełna ochrona 3–2‑1
- Foldery domowe użytkowników — z oczywistych względów wymagają częstych i pełnych kopii zapasowych. To głównie w tych folderach znajdują się dane użytkowników serwera.
- Dane kontenerów Docker — przede wszystkim chodzi o konfiguracje i dane wszystkich uruchomionych usług.
- Archiwa prywatne i z pracy — jedne z najważniejszych danych, które za nic nie mogą zaginąć.
- Biblioteka zdjęć — mam w niej ponad 20 lat zdigitalizowanej w obrazkach historii mojej rodziny i znajomych. To jest absolutny skarb i musi przetrwać wszystko!
Te dane trafiają zarówno na Synology DS213+ (kopia lokalna z deduplikacją QuDedup), jak i na dysk USB oraz do chmury Hetznera (kopia off-site z deduplikacją QuDedup). Deduplikacja na poziomie bloków znacząco redukuje rozmiar transferowanych danych i czas wykonywania kopii.
Dane ważne — kopia lokalna
- Biblioteka mediów — zgrane z płyt filmy, seriale i muzyka. Sporo pracy włożyłem przez lata w zgrywanie zakupionych rzeczy i chcę trzymać ich kopie na wszelki wypadek.
- Goodies — różne zasoby, mniej krytyczne niemniej dla mnie z różnych względów (głównie sentymentalnych :)) istotne. Czyż bowiem nie warto trzymać pełnej, zdigitalizowanej biblioteki miesięcznika Tajemnice Atari?
Te dane kopiuję na Synology DS213+, dysk USB i do chmury Hetznera jako kopia podstawowa (bez deduplikacji, transfer 1:1). Te dane właściwie się nie zmieniają, raz zgrane pozostają w swoim miejscu przez lata, poza tym pliki potrafią mieć sporą objętość. Nie widzę w przypadku tych danych sensu deduplikacji czy wersjonowania.
Dane tymczasowe — bez backupu lub z backupem aplikacyjnym
To kategoria danych, których backupowanie nie ma większego sensu. To przede wszystkim niezbyt istotne dane pobrane z sieci, które w razie problemów mogę pobrać ponownie oraz dane o dużej rotacji — wpadające i wylatujące z dysków. To na przykład torrenty, ściągane obrazy ISO dla mojego serwera Proxmox, gigabajty i terabajty cyfrowego planktonu, w którym sam za bardzo nawet czasami nie wiem, co jest. W miarę potrzeby i zajętości serwera po prostu czyszczę foldery robiąc miejsce na nowe graty. Jestem chomikiem, lubię gromadzić rzeczy, które wydają mi się interesujące i wpadną w moje łapska. Ot taka przypadłość 🙂
QNAP Hybrid Backup Sync 3 — centrum dowodzenia backupem
QNAP Hybrid Backup Sync 3 (HBS3) to aplikacja wbudowana w system QTS, dostępna bez dodatkowych opłat licencyjnych. Jej zadaniem jest centralizacja wszystkich operacji backupu, synchronizacji i przywrócenia danych — zarówno lokalnych, jak i zdalnych oraz chmurowych.
Co wyróżnia HBS3 na tle innych rozwiązań:
- Obsługa wielu protokołów w jednym miejscu: RTRR, Rsync, FTP/FTPS, WebDAV, CIFS/SMB, a także bezpośrednie integracje z chmurami publicznymi (OneDrive, Google Drive, Dropbox, myQNAPcloud i gazylion innych).
- Technologia QuDedup — deduplikacja danych na poziomie bloków z szyfrowaniem u źródła. Dane są zapisywane w formacie .qdff, co znacząco redukuje rozmiar kopii zapasowej i czas transferu.
- Łańcuchy zadań — możliwość ustawienia, że zakończenie jednego zadania automatycznie wyzwala kolejne. To pozwala budować sekwencyjne pipeline’y backupu bez ręcznej interwencji.
- Harmonogramowanie z granulacją do minuty i możliwość nakładania limitów przepustowości na wybrane godziny, kiedy to zazwyczaj serwer jest bardziej używany i wymaga szerszego pasma.
- Wbudowana weryfikacja integralności danych i możliwość przywrócenia z poziomu GUI.
- Nowa funkcja Airgap+ — logicznie odizolowana sieć do tworzenia bezpiecznych kopii zapasowych, chroniąca przed ransomware.
HBS3 obsługuje strategię 3–2‑1–1‑0: trzy kopie, dwa typy nośników, jedna kopia off-site, jedna kopia w środowisku izolowanym (air gap), zero błędów weryfikacji. To nie jest marketing — to rzeczywista architektura, którą da się wdrożyć w homelabowym środowisku w sposób prosty i przejrzysty.
Vendor lock-in kontra open source — mój wybór i dlaczego
To temat, który budzi emocje w środowisku homelabowym. Czy warto uzależniać się od jednego dostawcy, skoro istnieją świetne narzędzia open source?
Argumenty za open source
- Pełna kontrola nad danymi i formatami plików — brak zależności od formatu .qdff.
- Przenośność — narzędzia takie jak Restic, BorgBackup czy rsync działają na każdym systemie operacyjnym.
- Brak ryzyka, że producent zakończy wsparcie dla aplikacji lub zmieni model licencjonowania.
- Aktywna społeczność i transparentność kodu.
Argumenty za HBS3 (mój wybór)
- Centralne zarządzanie wszystkimi zadaniami w jednym GUI — bez pisania skryptów, bez ręcznego zarządzania cronem, bez czasem godzin grzebania under the hood.
- QuDedup — deduplikacja na poziomie bloków zintegrowana z systemem QTS, bez konieczności konfiguracji zewnętrznych narzędzi.
- Łańcuchy zadań — sekwencyjne uruchamianie backupów bez dodatkowego oprogramowania do orkiestracji.
- Natywna integracja z Hetzner Storage Box przez WebDAV i rsync — bez konfiguracji po stronie serwera.
- Hybrid Backup Center — możliwość centralnego zarządzania zadaniami HBS3 na wielu urządzeniach QNAP z jednego panelu w chmurze. Dla środowisk z wieloma NAS-ami to ogromna oszczędność czasu.
W moim przypadku wygrało podejście vendor lock-in z prostego powodu: czas. Konfiguracja i utrzymanie skryptów Restic lub BorgBackup dla kilkunastu zadań backupu, z różnymi harmonogramami, limitami przepustowości i łańcuchami zależności, to projekt na wiele godzin — i projekt, który trzeba utrzymywać. HBS3 daje mi to wszystko out of the box, a format .qdff jest czytelny dla każdego urządzenia QNAP, które mam lub będę mieć. Archiwa .qdff można też przeglądać i odzyskiwać za pomocą aplikacji stworzonej przez QNAPa na Windows, macOS i Ubuntu. Znakomicie ułatwia to dostęp do zarchiwizowanych i zdeduplikowanych danych w każdym z najpopularniejszych systemów operacyjnych.
Vendor lock-in nie musi być zły, jeśli dostawca jest stabilny, a narzędzie rzeczywiście rozwiązuje problem lepiej niż alternatywy. W moim przypadku tak właśnie jest.
Jak wygląda mój backup w praktyce
Moje zadania backupu są zorganizowane w logiczne łańcuchy, gdzie zakończenie jednego zadania automatycznie wyzwala kolejne. Oto jak to działa w ciągu doby:
Łańcuch poranny — backup na Synology DS213+ (od 09:00)
O godzinie 09:00 uruchamia się deduplikowana kopia zapasowa najważniejszych danych na lokalny serwer Synology DS213+ przez WebDAV. Obejmuje foldery domowe użytkowników, dane kontenerów Docker, biblioteki wybranych mediów, archiwa i backupy prywatne i te pracowe. Dane są zapisywane w formacie .qdff z włączoną deduplikacją QuDedup — to oznacza, że każdy kolejny backup transferuje tylko zmienione bloki danych, nie całe pliki.
Po zakończeniu tej kopii automatycznie uruchamia się drugie zadanie — kopia multimediów i innych zasobów na DS213+ jako backup podstawowy (bez deduplikacji, transfer 1:1). Obejmuje moje goodies, filmy, seriale i zgrane albumy muzyczne. Ze względu na charakter tych danych (duże pliki, rzadko zmieniane) deduplikacja nie przyniosłaby tu istotnych korzyści.
Łańcuch off-site — backup na Hetzner Storage Box
Po zakończeniu backupu na DS213+ automatycznie uruchamia się kopia off-site na Hetzner Storage Box przez WebDAV. To deduplikowana kopia kluczowych danych wycelowana poza sieć domową. Na dni robocze nałożony jest limit przepustowości — żeby backup nie blokował łącza w godzinach pracy.
Po zakończeniu tej kopii uruchamia się kolejne zadanie — kopia zbiorów multimedialnych na Hetzner jako backup podstawowy (bez deduplikacji).
Backup nocny na dysk USB (02:00)
O godzinie 02:00 w nocy HBS3 wykonuje pełną kopię zapasową na podłączony dysk USB. Obejmuje dane kontenerów, kopie Immich, multimedia i dokumenty. To logicznie odizolowany nośnik — air gap, który nie jest dostępny przez sieć.
Operacje codzienne (17:00)
O 17:00 uruchamia się wewnętrzna synchronizacja biblioteki zdjęć Immich — zdjęcia wędrują z katalogu z oryginałami zdjęć aplikacji do folderu moich kopii zapasowych w ramach tego samego serwera. Bezpośrednio po tym uruchamia się synchronizacja z serwera produkcyjnego pracodawcy — synchronizuję postępy prac w poszczególnych projektach, assety (przy obróbce grafiki potrafią to być spore pliki) i dokumentację, co pozwala mi mieć dostęp do kluczowych danych na poziomie sieci lokalnej. Na wypadek, gdybym musiał pracować zdalnie, mam zawsze zsynchronizowane i gotowe do pracy środowisko.
Chmura jako ostatnia linia obrony — Hetzner Storage Box
Hetzner Storage Box BX21 to 5 TB przestrzeni dyskowej w centrum danych w Niemczech lub Finlandii, za około 14 euro miesięcznie. To moje „1” w strategii 3–2‑1 — kopia off-site, fizycznie oddalona od mojej sieci domowej. Research rozwiązań chmurowych zajął mi sporo czasu, więc bierzcie z tego wszyscy. Hetzner udostępnia jedną z najlepszych usług na rynku biorąc pod uwagę możliwości i stosunek ceny do jakości.
Co sprawia, że wybrałem właśnie Hetzner Storage Box:
- Obsługa wielu protokołów, w tym między innymi WebDAV — HBS3 łączy się przez WebDAV bez żadnej dodatkowej konfiguracji po stronie serwera Hetznera.
- Snapshoty — do 20 automatycznych snapshotów, co daje dodatkową warstwę ochrony przed przypadkowym nadpisaniem danych.
- Lokalizacja w UE — dane podlegają RODO, centrum danych znajduje się w Niemczech i korzysta z ochronnych regulacji UE.
- Nieograniczony transfer — brak opłat za ruch sieciowy, który potrafi być znaczny w skali miesiąca.
- Brak minimalnego okresu umowy — można zrezygnować z usługi w każdej chwili.
W HBS3 mam skonfigurowane trzy punkty montowania dla Hetzner Storage Box: WebDAV (główny protokół dla zadań backupu), rsync przez SSH (alternatywa dla dużych transferów) i FTP z SSL. Elastyczność w wyborze protokołu to duży plus — jeśli jeden zawiedzie, przełączam się na inny bez zmiany logiki zadań.
Hetzner Storage Box to nie jest rozwiązanie dla każdego — wymaga pewnej wiedzy technicznej w konfiguracji. Ale dla kogoś, kto i tak zarządza NAS-em i rozumie protokoły sieciowe, to jeden z najlepszych stosunków ceny do pojemności i niezawodności na rynku.
Jak walidować poprawność backupu w HBS3
Backup, którego nie sprawdziłeś, to backup, który nie istnieje. To zdanie brzmi jak truizm, ale liczba osób, które odkrywają uszkodzone kopie zapasowe dopiero w momencie awarii, jest zatrważająca. HBS3 oferuje kilka mechanizmów weryfikacji, z których aktywnie korzystam.
Weryfikacja integralności danych (Check Data Integrity)
Dla zadań backupu z włączoną deduplikacją QuDedup HBS3 oferuje funkcję sprawdzania integralności danych. Operacja weryfikuje sumy kontrolne bloków danych w pliku .qdff i raportuje wszelkie rozbieżności. Uruchamiam ją ręcznie co kilka tygodni dla krytycznych zadań backupu.
Jak to zrobić: w panelu HBS3 przejdź do zakładki Backup i synchronizacja, wybierz zadanie backupu, kliknij ikonę menu (trzy kropki) i wybierz opcję Sprawdź integralność danych. HBS3 uruchomi weryfikację w tle i powiadomi o wynikach.
Logi zadań i historia uruchomień
Każde zadanie backupu generuje szczegółowy log z informacją o liczbie przetworzonych plików, rozmiarze transferu, czasie wykonania i ewentualnych błędach. Regularnie przeglądam logi zadań krytycznych — szczególnie backupu na Hetzner, gdzie problemy z połączeniem mogą powodować ciche niepowodzenia.
Dobre praktyki przeglądania logów:
- Sprawdzaj logi po każdym ważnym zadaniu backupu — szczególnie po pierwszym uruchomieniu nowego zadania.
- Zwracaj uwagę na zadania z ostrzeżeniami — to często sygnał problemów z uprawnieniami lub brakującymi plikami.
- Monitoruj rozmiar transferu — nagły spadek może oznaczać, że zadanie nie obejmuje wszystkich oczekiwanych danych.
Test przywracania — najważniejsza weryfikacja
Najskuteczniejszą metodą weryfikacji backupu jest próba przywrócenia danych. HBS3 oferuje intuicyjny interfejs przywracania — definiujesz zadanie przywracania, w którym możesz wybrać konkretne pliki lub foldery z kopii zapasowej i przywrócić je do wskazanej lokalizacji (niekoniecznie oryginalnej).
Moja praktyka: raz na kwartał wybieram losowy folder z kopii zapasowej na serwerze Synology i Hetznerze i przywracam go do tymczasowej lokalizacji na QNAP. Weryfikuję, czy pliki są kompletne i nienaruszone. To zajmuje 15–20 minut, ale daje pewność, że w razie prawdziwej awarii backup zadziała.
Powiadomienia e‑mail i push
HBS3 integruje się z systemem powiadomień QTS — można skonfigurować alerty e‑mail lub push dla zadań zakończonych błędem lub ostrzeżeniem. To pasywna forma monitoringu, która informuje o problemach bez konieczności ręcznego sprawdzania logów.
Podsumowanie
Tiering danych to nie tylko optymalizacja wydajności — to fundament skutecznej strategii backupu. Kiedy wiem, co gdzie trzymam i dlaczego, backup przestaje być chaotycznym kopiowaniem wszystkiego wszędzie, a staje się precyzyjnym procesem ochrony tego, co naprawdę ma znaczenie.
Kluczowe wnioski z mojej implementacji:
- Podział na warstwy sprzętowe (NVMe RAID 1 → HDD RAID 5 → SSD Single → USB) odzwierciedla rzeczywiste potrzeby danych: kontenery Docker i metadane (okładki książek, metadane wyświetlane w Pleksie itd.) na szybkim NVMe, media na pojemnym HDD, dane tymczasowe na dysku roboczym.
- Logiczny podział na foldery współdzielone sprawia, że zadania backupu są precyzyjne i przewidywalne — backupuję konkretne foldery, nie całe wolumeny.
- Klasyfikacja danych według ważności pozwala racjonalnie alokować zasoby: dane krytyczne dostają pełną ochronę 3–2‑1 z deduplikacją, dane odtwarzalne — tylko kopię lokalną lub żadną.
- HBS3 z QuDedup i łańcuchami zadań to narzędzie, które obsługuje całą tę złożoność z jednego panelu — bez skryptów, bez ręcznego zarządzania cronem, bez konieczności integrowania wielu narzędzi open source. Co ma swoje zalety ale też i wady.
- Hetzner Storage Box BX21 za ok. 14 euro miesięcznie to uczciwa cena za spokój ducha — 5 TB off-site z obsługą WebDAV, rsync i automatycznymi snapshotami.
- Backup bez regularnej weryfikacji to iluzja bezpieczeństwa — test przywracania raz na kwartał to minimum, które warto wdrożyć. Tym bardziej, że test można zautomatyzować tworząc w HBS3 zadanie przywracania z harmonogramem.
Jeśli masz NAS i jeszcze nie wdrożyłeś świadomego tieringu danych — zacznij od prostego ćwiczenia: wypisz, co trzymasz na dyskach, i zadaj sobie pytanie, co by się stało, gdybyś to jutro stracił. Odpowiedź na to pytanie jest najlepszym punktem startowym do budowania sensownej architektury składowania danych i ich backupu.




