Zálohy Proxmoxu na TrueNAS přes NFS: jedno tlačítko, hook skript a ověřená obnova kontejneru

Kontejnery s weby a cloudem zálohuji z Proxmoxu na domácí NAS s TrueNASem přes NFS. NAS neběží nonstop, a tak zálohu spouštím jedním tlačítkem, kdykoli ho zapnu. Stejné tlačítko uloží i konfiguraci samotného Proxmoxu. Zálohu jsem ověřil zkušební obnovou do kopie kontejneru s odpojenou sítí.

Výchozí stav a cíl

Na Proxmoxu běží několik LXC kontejnerů: web server s Drupalem, Nextcloud a později i Omada controller. Do té doby jsem měl jen snapshoty, které leží na stejném disku jako kontejner, takže při poruše disku nepomohou. Cílem bylo:

• zálohovat všechny kontejnery jedním tlačítkem,
• zálohovat i konfiguraci hostitele (úložiště, síť, nastavení kontejnerů),
• počítat s tím, že NAS je většinu času vypnutý,
• ověřit, že se ze zálohy dá opravdu obnovit.

Místo pro zálohy na TrueNASu

Na šifrovaném poolu pro zálohy jsem vytvořil nový dataset s presetem Generic a kvótou 1 TiB, aby zálohy nikdy nezaplnily celý pool. Šifrování se zdědí z poolu a dataset se po startu NASu odemyká automaticky.

Ke sdílení jsem zvolil NFS, které Proxmox podporuje nejlépe a nepotřebuje hesla. Přístup jsem omezil na jedinou adresu, Proxmox server. Aby mohl Proxmox zapisovat jako root, je v pokročilém nastavení sdílení Maproot User a Maproot Group nastaveno na root.

Past: velká a malá písmena v cestě

Při vytváření sdílení NFS hlásil TrueNAS [ENOENT] Path /mnt/Backup/proxmox not found. Dataset jsem pojmenoval Proxmox s velkým P a Linux velikost písmen rozlišuje. Stačilo cestu vybrat ve stromu místo ručního psaní.

NAS jako úložiště v Proxmoxu

V Datacenter → Storage → Add → NFS jsem zadal adresu NASu, vybral export a jako obsah nechal jen Backup. Když je NAS vypnutý, Proxmox úložiště jen ukáže jako nedostupné a nic se nerozbije. Kontrola, že Proxmox na NAS opravdu zapíše:

pvesm status
touch /mnt/pve/NAZEV_ULOZISTE/test && ls -la /mnt/pve/NAZEV_ULOZISTE && rm /mnt/pve/NAZEV_ULOZISTE/test

Záloha konfigurace hostitele

Proxmox zálohuje kontejnery a virtuální počítače, ale ne vlastní konfiguraci. Při havárii systémového disku je nejrychlejší nainstalovat čistý Proxmox, vrátit konfiguraci a obnovit kontejnery. Konfiguraci proto ukládá malý hook skript, který vzdump spustí na konci každé zálohovací úlohy:

#!/bin/bash
# Po dokonceni zalohovaci ulohy zazalohuje konfiguraci hostitele na NAS
[ "$1" = "job-end" ] || exit 0
DEST=/mnt/pve/NAZEV_ULOZISTE/pve-host
mkdir -p "$DEST"
tar -czf "$DEST/pve-config-$(date +%Y%m%d-%H%M).tar.gz" \
  /etc/pve /etc/network/interfaces /etc/hosts /etc/hostname /etc/resolv.conf \
  /etc/vzdump.conf /etc/ssh /root/.ssh /etc/apt /etc/cron.d /etc/lvm /etc/default \
  /var/spool/cron/crontabs /usr/local/bin/vzdump-hook-host.sh 2>/dev/null
# ponechat 10 nejnovejsich archivu
ls -1t "$DEST"/pve-config-*.tar.gz | tail -n +11 | xargs -r rm -f
exit 0

Skript je uložený v /usr/local/bin/vzdump-hook-host.sh a do /etc/vzdump.conf stačí přidat řádek script: /usr/local/bin/vzdump-hook-host.sh. Archiv má kolem 180 kB. Později jsem skript rozšířil i o kopírování konfigurace TrueNASu na Proxmox, viz Zálohování NASu, který běží jen občas.

Zálohovací úloha „jedno tlačítko“

V Datacenter → Backup jsem vytvořil jednu úlohu pro všechny kontejnery:

Úloha se pak spouští tlačítkem Run now.

Past: tlačítko Create je neaktivní

I když je úloha vypnutá, pole Schedule je povinné. Dokud je prázdné, nejde úlohu uložit. Vyplnil jsem formální hodnotu sun 03:00, která se při vypnuté úloze nikdy nepoužije.

První záloha

Záloha dvou kontejnerů trvala necelé 2 minuty: 2,2 GB za web server a 664 MB za Nextcloud včetně datového disku. K tomu přibyl archiv konfigurace hostitele. Při běhu úlohy se v seznamu úloh dál točí položka Shell, pokud je otevřená konzole hostitele. Se zálohou nesouvisí, rozhoduje stav řádku Backup Job.

Zkouška obnovy

Záloha, ze které nikdo nezkusil obnovit, je jen naděje. Zálohu Nextcloudu jsem proto obnovil do nového kontejneru s jiným ID:

1. Úložiště → Backups → Restore, nové ID, úložiště na druhém SSD, volba Unique (nová MAC adresa), bez spuštění po obnově.
2. Před spuštěním odebrat síťové rozhraní. Kopie má stejné IP adresy jako originál a nesmí se s ním v síti potkat.
3. Spustit a v konzoli ověřit data, aplikaci i databázi:

ls -la /mnt/ncdata/data
sudo -u www-data php /var/www/nextcloud/occ status
mariadb -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='NAZEV_DB';"

Kopie obsahovala data uživatele, Nextcloud hlásil installed: true a databáze měla všech 138 tabulek. Archiv konfigurace hostitele jsem ověřil výpisem tar -tzf. Testovací kontejner jsem pak smazal s volbami Purge from job configurations a Destroy unreferenced disks.

Při obnově Proxmox varoval, že součet velikostí disků přesahuje velikost thin poolu. Kopie dočasně zabírala druhých 116 GB na stejném SSD. Thin pool místo skutečně spotřebovává jen podle zapsaných dat, a po smazání kopie varování zmizelo.

Rutina

1. Zapnout NAS a počkat, až úložiště v Proxmoxu přestane být šedé.
2. Datacenter → Backup → Run now.
3. Ověřit stav Backup Job: OK.
4. NAS vypnout.

Nový kontejner stačí přidat do stejné úlohy. Tak jsem později zálohoval i Omada controller (Aktualizace a zálohování Omada controlleru).

Shrnutí

• NFS dataset s kvótou a přístupem jen pro Proxmox, v úložišti Proxmoxu jen obsah Backup.
• Jedna úloha pro všechny kontejnery, vypnutá a spouštěná ručně, protože NAS běží jen občas.
• Hook skript přidá k záloze i konfiguraci hostitele.
• Obnovu testovat do nového ID a s odebranou sítí, aby se kopie nepotkala s originálem.

Článek je součástí série Privátní cloud Nextcloud na domácím Proxmoxu.