Domácí NAS s TrueNASem zapínám jen na pár hodin měsíčně. Při kontrole jsem zjistil, že jeho vlastní záloha naposledy proběhla před rokem: naplánované úlohy se nespouštěly, protože byl NAS v tu dobu vypnutý. Nastavil jsem proto snapshoty a replikaci tak, aby proběhly při každém zapnutí, bezpečně jsem navázal na rok starou zálohu a konfiguraci se šifrovacími klíči kopíruji automaticky do druhého stroje.
Audit: co jsem našel
NAS má tři pooly: hlavní data, pool pro zálohy na samostatných discích a pool pro filmy a hudbu. Než jsem na něj začal ukládat zálohy Proxmoxu, prošel jsem nastavení:
| Zjištění | Závažnost | Co jsem udělal |
|---|---|---|
| Replikace hlavních dat do záložního poolu naposledy před rokem | vysoká | snapshotová úloha a replikace po startu |
| Chyběla úloha pro periodické snapshoty | vysoká | doplněna |
| Systém běžel na testovací (beta) verzi | vysoká | přechod na kandidáta na vydání (RC) |
| Scrub a SMART test se nespouštěly (NAS byl v danou dobu vypnutý) | střední | čtvrtletní ruční noc |
| Pool s médii bez redundance | vědomé riziko | ponecháno, média jsou nahraditelná |
| Konzole bez hesla | nízká | vypnuto |
Před změnou: konfigurace a klíče mimo NAS
Oba pooly s daty jsou šifrované. Bez klíčů by data nešla obnovit, proto jsem je stáhl jako první:
- Konfigurace NASu: System → Advanced Settings → Manage Configuration → Download File se zaškrtnutým Export Password Secret Seed. Bez této volby soubor neobsahuje použitelné klíče.
- Klíče datasetů: Export All Keys u každého šifrovacího kořene. Záložní pool má vlastní klíč. Klíče hlavního poolu zároveň otevírají zamčené repliky v záložním poolu, protože replikace přenáší data zašifrovaná.
Soubory jsem uložil mimo NAS na šifrované místo, ne nešifrovaně do cloudu. Po každé větší změně je potřeba stáhnout konfiguraci znovu. Klíče se mění jen při vytvoření nového šifrovacího kořene.
Beta, nebo RC?
Profil aktualizací General (stabilní verze) nebyl v tu chvíli dostupný. Řada 26 se přejmenovala na 27 a finální verze měla vyjít až za několik týdnů. Návrat na starší stabilní verzi by vrátil i půl roku starou konfiguraci, a tak jsem zvolil kandidáta na vydání. RC obsahovalo mimo jiné opravu pádu při opětovném připojení klientů NFS, a NFS jsem se právě chystal používat. Pooly jsem po aktualizaci neupgradoval. Nové funkce ZFS by znemožnily návrat na starší verzi.
Navázání na rok starou replikaci
Přírůstková replikace potřebuje snapshot, který existuje na zdroji i v cíli. Kdyby chyběl a úloha měla zapnuté Replication from scratch, TrueNAS by smazal celou zálohu a posílal několik terabajtů znovu. Několik hodin bych pak neměl žádnou zálohu. Proto jsem nejdřív ověřil:
- Replication from scratch je vypnuté, takže v nejhorším případě úloha jen skončí chybou,
- formulář replikace hlásí 1 of 8 existing snapshots would be replicated, tedy navazující snapshot na zdroji pořád existuje.
Snapshotová úloha
| Nastavení | Hodnota |
|---|---|
| Dataset | hlavní pool, rekurzivně, bez datasetu s cache |
| Naming Schema | auto-%Y-%m-%d_%H-%M, stejné jako u staré zálohy |
| Schedule | každou hodinu, dokud NAS běží |
| Snapshot Lifetime | 6 měsíců |
U doby uchování jsem zprvu omylem zvolil týdny místo měsíců. Při krátké době uchování by se staré snapshoty mohly smazat dřív, než se zreplikují.
Napojení replikace
Do replikační úlohy jsem doplnil novou snapshotovou úlohu, zapnul Run Automatically (replikace se spustí hned po snapshotu) a Save Pending Snapshots (nezreplikovaný snapshot se nesmaže, ani když bude NAS dlouho vypnutý). První běh přenesl jen změny za rok a skončil za pár minut. Záloha je zase aktuální.
Spuštění při každém zapnutí
Naplánovaná úloha se u vypnutého NASu nespustí a ani se později nedožene. Snapshotová úloha navíc v rozhraní nemá tlačítko Run Now. Přes API ale spustit jde. Číslo úlohy jsem zjistil v System → Shell:
midclt call pool.snapshottask.query | jq -r '.[] | "\(.id) \(.dataset)"'
midclt call pool.snapshottask.run 1Druhý příkaz jsem pak přidal jako Init/Shutdown Script typu Command s volbou Post Init. Při každém zapnutí NASu teď vznikne snapshot a hned po něm proběhne replikace.

Scrub: ručně jednou za čtvrt roku
Scrub je jediná kontrola, která odhalí tiše poškozená data. Na poolu s redundancí (zrcadlo, RAIDZ) je navíc opraví. Uvažoval jsem i o spouštění po startu, ale scrub jednoho poolu trvá kolem 15 hodin. Při 1–2 hodinách provozu měsíčně by se táhl celé měsíce a celou dobu zpomaloval NAS. Zvolil jsem proto jednoduchou rutinu: jednou za čtvrt roku nechat NAS běžet přes noc, spustit Scrub Now na všech poolech, ráno ověřit nulový počet chyb a spustit SMART test.
Konfigurace NASu automaticky na Proxmoxu
Klíče a konfigurace staženou ručně by bylo potřeba po každé změně stahovat znovu. TrueNAS proto každou hodinu a po startu ukládá konfiguraci do sdílené složky, kterou vidí Proxmox. Jde o stejný formát jako ruční export se Secret Seed:
mkdir -p /mnt/POOL/DATASET/truenas-config && cd /mnt/POOL/DATASET/truenas-config && \
sqlite3 /data/freenas-v1.db ".backup freenas-v1.db" && cp /data/pwenc_secret . && \
tar -cf truenas-config-$(date +%Y%m%d-%H%M).tar freenas-v1.db pwenc_secret && \
rm -f freenas-v1.db pwenc_secret && chmod 600 truenas-config-*.tar && \
ls -1t truenas-config-*.tar | tail -n +11 | xargs -r rm -fDatabáze se kopíruje přes sqlite3 .backup, ne prostým cp, aby kopie byla konzistentní i za běhu. V TrueNASu je příkaz uložený dvakrát: jako Cron Job spouštěný každou hodinu pod uživatelem root a jako Post Init skript. Hook skript Proxmoxu (viz Zálohy Proxmoxu na TrueNAS) pak při každé záloze zkopíruje nejnovější soubor k sobě do adresáře přístupného jen rootovi.
Když odejde hardware NASu a disky přežijí, stačí nainstalovat TrueNAS, nahrát poslední soubor přes Manage Configuration → Upload File a pooly se načtou i s daty. Soubor obsahuje šifrovací klíče, proto má práva jen pro roota.
Co tohle řešení chrání a co ne
| Situace | Chráněno? |
|---|---|
| Porucha disku v hlavním poolu | ano (replika v záložním poolu na jiných discích) |
| Smazané nebo přepsané soubory, ransomware přes sdílení | ano (snapshoty na 6 měsíců) |
| Porucha hardwaru NASu, disky přežijí | ano (konfigurace na Proxmoxu) |
| Porucha Proxmoxu | ano (zálohy kontejnerů a konfigurace na NASu) |
| Požár, přepětí nebo krádež obou strojů | ne, řešením je externí disk uložený mimo dům |
Poslední řádek zatím zůstává otevřený. Nejlevnější cestou je jednorázově koupený externí disk, na který se jednou za čas zreplikují data a který leží mimo dům.
Shrnutí
- U NASu, který běží jen občas, nespoléhat na naplánované úlohy. Navázat je na start přes Post Init a
midclt. - Před navázáním replikace ověřit společný snapshot a nechat vypnuté Replication from scratch.
- Konfiguraci se Secret Seed a klíče všech šifrovacích kořenů mít mimo NAS. Nejlépe automaticky ve druhém stroji.
- Scrub dělat ručně přes noc jednou za čtvrt roku.
- Zálohy v jednom domě nechrání před požárem ani přepětím.
Článek je součástí série Privátní cloud Nextcloud na domácím Proxmoxu.