Proxmox Backup Server su VPS: guida a backup e restore

Cosa offre realmente Proxmox Backup Server su un VPS

Proxmox Backup Server (PBS) su un VPS è una destinazione off-site che usa lo stesso protocollo già utilizzato dal cluster Proxmox VE (virtual environment). Di conseguenza, ogni backup successivo al primo è incrementale, deduplicato tra i guest, cifrato prima di lasciare la sede e verificabile in seguito. Si noleggia un VPS con un volume a blocchi, si installa PBS su Debian 13, si crea un datastore su quel volume e lo si aggiunge in Proxmox VE come storage di tipo pbs. L'installazione richiede dieci minuti. Tutto ciò che viene dopo, ovvero namespace, garbage collection, gestione delle chiavi e un ripristino eseguito realmente, determina se il backup sarà ancora utile tra un anno.

Il motivo per usare PBS invece di copiare i file vzdump su un disco noleggiato è il chunk store. Il client suddivide ogni disco guest in chunk di circa 4 MiB, calcola gli hash e carica soltanto i chunk che il datastore non contiene già. Per una macchina virtuale in esecuzione, dopo il primo backup QEMU tiene traccia dei blocchi modificati tramite una dirty bitmap. L'esecuzione successiva legge quindi dal disco locale soltanto quei blocchi. Un guest da 200 GB che modifica 3 GB al giorno invia circa 3 GB al giorno. Questo permette di usare insieme la connessione uplink di casa e un volume noleggiato. Per questo un VPS come destinazione di backup off-site è una soluzione migliore di un disco di riserva a casa di un amico. Se stai ancora decidendo dove eseguire l'hypervisor, Proxmox a casa o su un VPS noleggiato tratta separatamente questo aspetto.

Dimensionare il volume prima di noleggiarlo

Il dimensionamento si basa su calcoli eseguiti sui propri dati. Considera lo spazio effettivamente utilizzato da ogni guest, non la dimensione del relativo disco virtuale. Poi aggiungi la variazione giornaliera moltiplicata per il numero di giorni di conservazione. Compressione e deduplicazione riducono entrambi questo valore, quindi considera il risultato un limite massimo e non un obiettivo.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Queste righe sono un esempio di calcolo, non una misurazione. Leggi lo spazio utilizzato da df -h all'interno di ogni guest. Leggi la variazione giornaliera dalla dimensione del secondo e del terzo backup nel log dell'attività PBS, quando saranno disponibili.

Nel guest di posta dell'esempio vengono utilizzati 120 GB e la variazione è di circa 3.0 GB al giorno. Trenta snapshot giornalieri richiedono quindi circa 210 GB: una copia completa più trenta giorni di variazioni. Somma l'ultima colonna per tutti i 3 guest: il totale è di circa 619 GB. Aggiungi un quinto per indici, metadati e spazio necessario alla garbage collection. Il risultato indica un volume da 1 TB.

Il resto della configurazione è contenuto. PBS funziona con 2 GB di RAM e opera comodamente con 4 GB, perché le operazioni più onerose vengono eseguite sul cluster: il nodo Proxmox VE legge i dischi dei guest ed esegue il chunking e l'hashing. Il VPS scrive i chunk ed esegue i due job più pesanti, la garbage collection e la verifica. Noleggia il datastore come volume a blocchi separato, invece di usare un unico disco root di grandi dimensioni. In questo modo puoi espandere il volume in seguito senza ricreare il server.

Installare Proxmox Backup Server su Debian 13

Ad agosto 2026, la combinazione corrente è Proxmox Backup Server 4 su Debian 13, nome in codice trixie. Le guide meno recenti associano PBS 2 a Debian 11. Il nome in codice fa parte della definizione del repository, quindi copiare il nome di una suite precedente produce un errore di apt relativo a un file di release mancante. Partire da un'immagine Debian 13 minimale. Eseguire tutti i comandi seguenti come root oppure con sudo, come mostrato.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

La somma deve essere 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. In caso contrario, fermarsi. Un keyring errato indica che si stanno per installare pacchetti firmati da una chiave non verificata.

Scrivere /etc/apt/sources.list.d/pbs.sources con il repository no-subscription, corretto per un server senza contratto di supporto:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

L'interfaccia web risponde sulla porta HTTPS 8007. Accedere come root@pam usando la password dell'utente root del sistema, perché PBS autentica questo utente tramite PAM (pluggable authentication modules), cioè gli stessi account usati dal sistema operativo. Il certificato è autofirmato e il browser lo segnalerà. L'impronta digitale del certificato è il valore che Proxmox VE associa in seguito, quindi l'avviso è previsto e non indica un problema da correggere.

La porta 8007 espone un modulo di accesso su Internet, quindi non va lasciata aperta a chiunque. Un solo file nftables è sufficiente per gestire questa configurazione. La scrittura di /etc/nftables.conf esegue il flush del ruleset corrente, quindi saltare questo passaggio se il firewall del server è già gestito da un altro componente.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Applicare la configurazione con sudo systemctl enable --now nftables e mantenere aperta una seconda sessione SSH durante l'operazione: policy drop più un solo errore nella regola SSH può bloccare l'accesso al proprio server. Sostituire 203.0.113.7 con l'indirizzo da cui il cluster si connette. Se l'indirizzo è dinamico, ampliare la regola all'intervallo del provider oppure terminare la connessione in un tunnel. Tenere inoltre presente che la maggior parte dei pannelli VPS dispone di un firewall di rete separato davanti alla macchina, che deve consentire la stessa porta.

Posizionare il datastore su un volume dedicato

Il datastore non deve trovarsi sul filesystem root. Quando un datastore riempie un filesystem root condiviso, il backup non riesce e anche tutte le altre funzioni del server si bloccano, inclusa la registrazione dei log necessaria per individuare la causa. Collegare il volume a blocchi, formattarlo, montarlo e solo dopo creare il datastore all’interno del punto di mount.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Ricavare il nome del dispositivo da lsblk. Nella maggior parte delle immagini KVM è /dev/vdb, mentre in altre è /dev/sdb: non è mai sicuro dare per scontato il nome. Aggiungere il mount a /etc/fstab usando l’etichetta, così un eventuale cambio del nome del dispositivo dopo un riavvio non può indirizzare il datastore verso il disco errato:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt dovrebbe visualizzare il dispositivo, il percorso e le opzioni, inclusa rw,relatime. Quella riga può nascondere due problemi. Se il mount non è presente e si crea comunque il datastore, PBS scrive nel filesystem root sottostante il punto di mount. Il mount successivo, quando viene eseguito correttamente, nasconde quei dati senza eliminarli: il datastore appare quindi vuoto, mentre il filesystem root resta pieno. Se le opzioni indicano noatime, PBS rifiuta di funzionare, perché esegue un controllo di sicurezza sugli access time quando il datastore viene creato e di nuovo durante ogni garbage collection.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Questo crea una directory .chunks contenente 65536 sottodirectory, denominate da 0000 a ffff. Un datastore contiene centinaia di migliaia di file piccoli, non pochi file di grandi dimensioni. Ne seguono due conseguenze. Copiare un datastore con un normale strumento a livello di file è abbastanza lento da risultare inutilizzabile. Inoltre, uno snapshot del volume del provider acquisito mentre i backup sono in esecuzione non è una copia coerente del datastore. Per lo stesso motivo, gli snapshot non sostituiscono i backup in nessun altro contesto.

I namespace impediscono collisioni tra host

Per impostazione predefinita, un datastore ha una struttura piatta. I backup hanno nome vm/100, ct/101 e host/<name>. Se due cluster che hanno entrambi un guest con ID 100 scrivono nello stesso gruppo, i relativi snapshot si intercalano e una regola di conservazione configurata per uno dei due conta anche gli snapshot dell'altro. Le namespace assegnano a ogni origine un albero separato all'interno dello stesso datastore.

Createle sull'host PBS. L'argomento --repository ha il formato [[auth-id@]server[:port]:]datastore, quindi una namespace locale è indicata come root@pam@localhost:store1; il comando richiede la password di root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

La deduplicazione non risente di questa separazione. I chunk sono condivisi nell'intero datastore, quindi dieci guest Debian distribuiti su tre namespace conservano una sola copia del sistema di base. Questo è il vantaggio di usare un datastore con namespace invece di un datastore per host: datastore separati significano pool di chunk separati, e pool di chunk separati significano pagare più volte la stessa installazione Debian.

Assegnate a ogni origine un account distinto, limitato alla relativa namespace. Un token API (application programming interface) è una credenziale associata a un utente e dotata di autorizzazioni proprie. È la soluzione corretta su una macchina che potrebbe essere sottratta.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Il comando per creare il token visualizza il secret una sola volta:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Copiatelo subito, perché PBS non conserva alcuna forma del secret che possa mostrarvi nuovamente. Controllate due volte il comando di controllo degli accessi. Il comando indica il token, backup@pbs!pve-home, e non l'utente, perché le autorizzazioni del token vengono calcolate solo a partire dalle voci che indicano direttamente il token. Una voce per il solo backup@pbs lascia il token senza alcun accesso e il primo backup fallisce per un problema di autorizzazioni, non per qualcosa di visibile nella rete. Anche il percorso è determinante: un token limitato a /datastore/store1/pve-home non può leggere o eliminare nulla nella namespace dell'ufficio, quindi un cluster compromesso non può distruggere la cronologia di un altro sito.

Aggiungere il VPS come storage di backup in Proxmox VE

Leggere prima l'impronta digitale del certificato sull'host PBS.

sudo proxmox-backup-manager cert info | grep Fingerprint

Quindi, su un nodo qualsiasi del cluster:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Incollare il valore cert info stampato al posto del segnaposto nella terza riga. Passare --password senza un valore fa sì che pvesm lo richieda, evitando così di memorizzare il secret del token nella cronologia della shell. Il secret viene memorizzato in /etc/pve/priv/storage/pbs-offsite.pw, mentre la definizione dello storage viene salvata in /etc/pve/storage.cfg. Quest'ultima viene replicata su ogni nodo del cluster, quindi la configurazione va eseguita una sola volta per l'intero cluster.

--prune-backups keep-all=1 indica a Proxmox VE di non eliminare nulla. La conservazione dei backup si configura sul lato PBS, come descritto più avanti. Il motivo è importante: in questo modo il token non richiede il permesso di eliminazione e un cluster cifrato da ransomware non può raggiungere lo storico offsite e applicarvi la potatura che dovrebbe consentire il ripristino.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status stampa active nella colonna dello stato, con lo spazio totale e quello utilizzato dal datastore accanto. inactive indica che il nodo non ha potuto completare una sessione TLS (transport layer security) sulla porta 8007. Il problema riguarda il firewall o l'impronta digitale, non le credenziali.

Il primo backup carica tutti i dati, quindi calcolare prima i tempi necessari. 200 GB corrispondono a 1600 gigabit e un uplink da 100 Mbit trasferisce 0.1 gigabit al secondo. Il tempo minimo è quindi di circa quattro ore e mezza, ma nella pratica sarà più lungo. Avviare il backup quando la banda non è necessaria. Le esecuzioni successive inviano soltanto i nuovi chunk.

Crittografia lato client e posizione della chiave

Il VPS è un computer che non possiedi. Esegui la crittografia sul client: il datastore conterrà blocchi che il provider non può leggere.

sudo pvesm set pbs-offsite --encryption-key autogen

Questo comando scrive una nuova chiave in /etc/pve/priv/storage/pbs-offsite.enc, leggibile solo da root, e la replica insieme al resto di /etc/pve. Dal backup successivo, il client cifra ogni blocco prima di inviarlo. Il server può comunque elencare i tuoi snapshot e le relative dimensioni, ma non può leggerne il contenuto.

Ora viene la parte che trasforma questa configurazione in un backup invece che in un rischio. Una chiave generata non ha una passphrase ed esiste solo sul cluster che protegge. Se quel cluster viene rubato o i dati vengono cifrati da terzi, il VPS contiene dati che nessuno può aprire. Copia la chiave fuori dal cluster il giorno stesso in cui la crei.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey stampa la chiave come documento da stampare su carta e conservare in un altro luogo. Considera il file stesso come un secret, perché chiunque ne disponga può decifrare ogni backup creato con quella chiave. In configurazioni più grandi, PBS supporta anche una master key: una coppia di chiavi RSA (Rivest Shamir Adleman) creata con proxmox-backup-client key create-master-key. Ogni backup memorizza la propria chiave di crittografia cifrata con la metà pubblica, mentre la metà privata resta offline per il ripristino.

È importante conoscere una conseguenza di questo design prima di iniziare, non dopo. Nei backup cifrati, il digest del blocco viene calcolato dal contenuto in chiaro combinato con la chiave di crittografia. Di conseguenza, due blocchi identici cifrati con chiavi diverse producono digest diversi e non vengono mai deduplicati tra loro. Se cambi la chiave, il backup successivo carica nuovamente tutto e i blocchi precedenti restano disponibili finché i relativi snapshot non vengono eliminati e raccolti. Decidi se usare la crittografia prima del primo caricamento.

Potatura e garbage collection recuperano spazio

Questa è la sezione che viene spesso saltata, ma è quella che riempie il volume. La potatura di uno snapshot rimuove i relativi metadati: il manifest, gli indici, il log e le note. Non elimina alcun chunk. I chunk sono condivisi tra gli snapshot, quindi non è possibile sapere che un chunk non è più utilizzato finché non vengono letti tutti gli indici rimanenti. Questo è il compito della garbage collection. Un datastore con una pianificazione della potatura ma senza una pianificazione della garbage collection continua soltanto a crescere.

Configura entrambe le pianificazioni. Prima la retention, con un job per ogni namespace:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Poi la pianificazione della collection sul datastore, a qualche ora di distanza dal job di potatura e al di fuori della finestra dei backup:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Verifica una volta la distinzione direttamente sull'host PBS:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Esegui il job di potatura, quindi df: il valore dello spazio utilizzato non cambia. Esegui la garbage collection, quindi di nuovo df: a quel punto cambia.

La garbage collection viene eseguita in 2 fasi. Nella prima fase percorre ogni indice del datastore e aggiorna l'ora di accesso di ogni chunk a cui gli indici fanno riferimento. Nella seconda fase elimina i chunk la cui ora di accesso è precedente alla soglia, impostata a 24 hours e 5 minutes prima dell'avvio dell'esecuzione, oppure all'inizio del backup più vecchio ancora in scrittura, scegliendo il momento precedente. Questo margine è necessario perché Linux monta i filesystem con relatime per impostazione predefinita. Questa opzione aggiorna l'ora di accesso circa una volta al giorno invece che a ogni lettura. Di conseguenza, un chunk scritto un'ora fa non viene mai eliminato, anche se nessun indice lo referenzia ancora. Inoltre, lo spazio liberato dalla potatura diventa visibile nella prima collection eseguita più di un giorno dopo l'ultimo accesso al chunk. Se un datastore sembra non avere recuperato spazio, spesso si trova semplicemente all'interno di questa finestra temporale.

Su un piccolo VPS, questo è il job più pesante eseguito dal server, perché esegue stat su ogni file di chunk presente nel volume. Il log del task termina con un riepilogo degli elementi rimossi e di quelli ancora in attesa a causa del periodo di tolleranza. Se molti elementi sono ancora in attesa, esegui di nuovo il job il giorno successivo. PBS espone gc-atime-safety-check e gc-atime-cutoff come opzioni di ottimizzazione del datastore. Entrambe devono essere lasciate invariate: esistono per gli storage che non possono registrare le ore di accesso. Disattivare il controllo di sicurezza su un filesystem montato con noatime è il modo in cui si perdono chunk ancora referenziati da snapshot attivi.

La verifica dimostra che i chunk sono ancora leggibili

Un backup caricato correttamente può diventare illeggibile anche dopo un anno. La verifica rilegge i chunk e li confronta con i checksum memorizzati nell'indice. In questo modo i danni vengono rilevati secondo una pianificazione, invece che durante un ripristino.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Su un VPS di piccole dimensioni, mantieni basso il numero di thread. La verifica è limitata dalle prestazioni del disco e della CPU e, in caso contrario, compete con le altre attività del server. Per pianificare l'operazione, usa la scheda Verify Jobs del datastore nell'interfaccia web: un job settimanale che salta gli snapshot già verificati e verifica nuovamente quelli più vecchi di 30 giorni consente di coprire nel tempo l'intero datastore senza ripetere il lavoro.

Uno snapshot che non supera la verifica viene contrassegnato come non riuscito nella vista del datastore. Non ignorarlo. I chunk sono condivisi, quindi un singolo chunk danneggiato di un'immagine di base causa in genere il fallimento di ogni snapshot che lo utilizza. Per risolvere il problema, dimentica gli snapshot non riusciti ed esegui un nuovo backup, che caricherà nuovamente i chunk mancanti. Se i problemi continuano a comparire, sospetta un problema nello storage sottostante il datastore e configura il monitoraggio dello stato del disco sul VPS, in modo che sia l'unità a segnalartelo prima del job di verifica.

Testare un ripristino, quindi testarlo senza il cluster

Non puoi sapere se un backup funziona finché non ne hai ripristinato uno. Esegui due test: verificano aspetti diversi.

Intero guest, sul cluster:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

La prima colonna di pvesm list contiene l'ID del volume e il timestamp ne fa parte. Copia il tuo valore invece di digitare quello dell'esempio. Ripristina il guest con un ID non utilizzato e su uno storage diverso, quindi avvialo con l'interfaccia di rete disconnessa. Non ripristinare mai sopra un guest in esecuzione per verificare che i backup funzionino: se il ripristino fallisce a metà, perderesti anche la copia funzionante.

Il secondo test è quello che quasi nessuno esegue. Supponi che l'edificio in cui si trova il cluster sia andato distrutto e ripristina il backup da una macchina che non ne ha mai fatto parte. Su un qualsiasi sistema Debian 13, aggiungi il repository contenente solo il client come /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Sostituisci i tre segnaposto racchiusi tra virgolette con i tuoi valori e ricava il nome dell'archivio nell'ultima riga dall'output di snapshot files. Questo dimostra ciò che il primo test non può verificare: che la copia del file della chiave consenta di decrittografare dati reali e che tu possa utilizzare il client da una macchina che non ha mai contenuto la configurazione del cluster. Annota i quattro valori richiesti: la stringa del repository, il secret del token, l'impronta digitale e il file della chiave. Conservali insieme nel luogo indicato dal tuo piano di disaster recovery.

Cosa fa e cosa non fa la deduplicazione sui costi di storage

La deduplicazione è effettiva e opera sull'intero datastore. Dieci guest Debian condividono una sola copia del sistema di base, quindi il secondo guest identico occupa quasi nessuno spazio aggiuntivo. Riduce anche la larghezza di banda necessaria per l'upload, perché il client invia un checksum invece dei dati per ogni chunk già presente sul server.

È importante chiarire cosa non fa.

• Non riduce i dati che cambiano. Un database che riscrive ampie parti dei propri file ogni notte genera nuovi chunk ogni notte, e la retention li moltiplica.
• Non attraversa il confine definito da una chiave di cifratura, come spiegato sopra.
• Non attraversa il confine di un datastore, che è il motivo principale per usare i namespace.
• Non impedisce che un volume si riempia. Quando il datastore è pieno, i backup falliscono e le uniche soluzioni sono aumentare la dimensione del volume o ridurre la retention.

Non aggiungere un altro livello di deduplicazione sotto questo sistema. I chunk arrivano già deduplicati e compressi dal client, quindi la deduplicazione ZFS sotto un datastore usa RAM per cercare corrispondenze che sono state rimosse prima della scrittura. In questo caso, la scelta corretta sul volume è usare ext4 o xfs senza deduplicazione.

L'interfaccia web mostra un fattore di deduplicazione per il datastore. Questo valore descrive i tuoi guest ed è l'unico utile per la pianificazione, perché i rapporti pubblicati descrivono i dati di altri utenti. Se ti servono anche backup a livello di file per macchine che non sono guest Proxmox, eseguili in parallelo sullo stesso VPS: PBS è una destinazione consapevole dell'hypervisor per interi guest, mentre restic e BorgBackup operano sulle directory e i backup restic su un VPS sono adatti a laptop e server standalone che PBS non è mai stato progettato per coprire.

Modalità di errore e sintomi osservabili

Lo storage risulta inattivo. pvesm status --storage pbs-offsite restituisce inactive quando il nodo non riesce a completare una sessione TLS sulla porta 8007. Controllare il firewall sul VPS, quindi il firewall di rete separato del provider e infine l'impronta digitale. Un'impronta che non corrisponde più al certificato produce lo stesso sintomo visibile di una porta bloccata e cambia ogni volta che il certificato viene sostituito.

Il primo backup fallisce per problemi di permessi. La voce di controllo degli accessi deve indicare il token, non l'utente, e deve coprire lo spazio dei nomi a cui punta lo storage. Verificare entrambi gli aspetti nella scheda dei permessi del datastore nell'interfaccia web prima di controllare altro.

La garbage collection non si avvia. Il controllo di sicurezza sull'ora di accesso non è riuscito. Nella maggior parte dei casi, il filesystem del datastore è montato noatime. Eseguire findmnt -no OPTIONS /mnt/datastore/store1 per confermarlo, correggere l'opzione in /etc/fstab e rimontare il filesystem. Non disabilitare il controllo per aggirare il problema.

Il datastore continua soltanto a crescere. I job di pruning vengono eseguiti, ma non viene recuperato spazio. Non esiste una pianificazione per la garbage collection oppure ogni raccolta avviene entro la finestra di tolleranza di 24 ore, perché viene eseguita subito dopo i backup. Controllare la pianificazione con proxmox-backup-manager datastore show store1.

Un backup che prima era rapido ora richiede ore. Un guest che è stato arrestato, migrato o ripristinato perde la dirty bitmap. Di conseguenza, l'esecuzione successiva legge l'intero disco sul lato cluster, anche se carica una quantità minima di dati. Il log dell'attività mostra una durata elevata e una quantità caricata ridotta. L'esecuzione successiva torna a essere rapida. Se invece tutti i job sul VPS sono lenti, la causa è generalmente esterna al datastore. Il primo controllo da eseguire è il tempo di steal della CPU causato da un vicino rumoroso.

FAQ

Perché il datastore di Proxmox Backup Server continua a crescere quando viene eseguito il processo di prune?

Perché il pruning rimuove soltanto i metadati degli snapshot: il manifest, gli indici, il log e le note. I chunk restano sul disco finché la garbage collection non elimina quelli a cui non fa più riferimento alcun indice. Imposta una pianificazione per il datastore con proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' e verifica il risultato eseguendo df -h sul percorso del datastore prima e dopo proxmox-backup-manager garbage-collection start store1. Considera un ritardo di almeno un giorno, perché la seconda fase rimuove soltanto i chunk il cui tempo di accesso è anteriore di oltre 24 ore e 5 minuti.

Quanto spazio su disco richiede una VPS con Proxmox Backup Server?

Somma lo spazio effettivamente utilizzato da ogni guest, quindi aggiungi la variazione giornaliera di ogni guest moltiplicata per il numero di giorni di conservazione. Questo totale rappresenta un limite massimo, perché compressione e deduplicazione riducono entrambe lo spazio necessario. Aggiungi circa un quinto per gli indici e il margine operativo, quindi arrotonda per eccesso alla dimensione del volume che puoi acquistare. Dopo due settimane verifica nuovamente il valore confrontandolo con l'utilizzo reale nella vista del datastore, perché una stima fatta prima del primo backup è sempre errata in una direzione o nell'altra.

Dove deve essere conservata la chiave di crittografia del backup?

In qualsiasi posizione, ma non soltanto sul cluster che protegge. Proxmox VE la conserva in /etc/pve/priv/storage/<storage>.enc, che viene replicato su ogni nodo e quindi va perso insieme al cluster. Copiala all'esterno il primo giorno, stampala con proxmox-backup-client key paperkey e conserva la copia in un edificio diverso. Tieni inoltre presente che la chiave contribuisce al digest dei chunk, quindi sostituirla in seguito fa sì che il backup successivo carichi nuovamente tutto.

Serve un datastore per ogni host Proxmox oppure sono sufficienti i namespace?

Usa un datastore e un namespace per ogni host o cluster di origine. La deduplicazione funziona all'interno di un datastore, non tra datastore diversi; separare i dati per host memorizza quindi più volte le stesse immagini di base. I namespace mantengono separati i gruppi di backup, impedendo collisioni tra due host che hanno entrambi un guest con ID 100. Inoltre, un percorso di controllo degli accessi nella forma /datastore/store1/pve-home limita il token API di ogni host al proprio namespace.

Una VPS di piccole dimensioni riesce a sostenere il carico come server di backup Proxmox?

Di solito sì, in un homelab, perché il chunking e l'hashing vengono eseguiti sul nodo Proxmox VE, non sul server di backup. La VPS scrive i chunk ed esegue i due processi più onerosi: garbage collection e verifica. Assegna 4 GB di RAM e mantieni bassi i conteggi dei thread di verifica. Pianifica entrambi i processi al di fuori della finestra dei backup. Se richiedono comunque molto più tempo di quanto dovrebbe essere necessario per il disco, misura lo steal time prima di acquistare un piano più grande.