92 è la metà di 99

Proxmox Best Practice Parte 3 – Strategie di backup: Mantenere i dati al sicuro

Bentornati alle best practice per il tuo server Proxmox o cluster Proxmox, oggi esaminiamo in dettaglio l'argomento del backup. A tal fine, abbiamo bisogno – come già sapete – dei colleghi qui presenti:

Server di backup Proxmox (PBS)

PBS è la soluzione di backup professionale di Proxmox e dovrebbe sicuramente essere sul tuo radar. I principali vantaggi non sono solo i discorsi di marketing, ma in realtà fanno la differenza nella pratica:

  • Deduplicazione: I blocchi di dati identici vengono memorizzati una sola volta, spesso salvando fino a 90% Spazio di archiviazione
  • Backup incrementali: Solo le modifiche vengono sottoposte a backup, riducendo drasticamente i tempi di backup
  • cifratura: Crittografia AES-256-GCM lato client, anche se qualcuno compromette il server di backup
  • Limitazione della larghezza di banda: I backup vengono eseguiti in background senza che i sistemi di produzione ne risentano
  • Verifica i lavori: Controllo automatico dell'integrità: sai sempre se i tuoi backup sono davvero utili
  • Politiche di conservazione: Regole di eliminazione intelligenti assicurano che non si sprofonda nel caos di backup
  • GUI del Web: Un'interfaccia utente moderna che è davvero divertente da usare

PBS Setup (configurazione di base)

Requisiti hardware e pianificazione

Prima di iniziare, dovresti pensare all'hardware. Un server PBS è buono solo quanto l'hardware su cui viene eseguito. Ecco requisiti minimi realistici che si sono dimostrati nella pratica:

Raccomandazioni hardware minime per PBS:

  • CPU: 4 core (più se si desidera eseguire il backup di molte VM in parallelo)
  • RAM: Minimo assoluto 8GB, 16GB+ se si vuole fare "seriamente"
  • Stoccaggio: Un SSD veloce per i metadati, HDD di grandi dimensioni per i dati di backup effettivi
  • Rete: Gigabit Ethernet come minimo più basso, meglio 2,5 o 5 GBE e 10GbE se si spostano costantemente grandi quantità di dati

L'installazione stessa è piacevolmente semplice. Dovresti assolutamente installare PBS su un server fisico separato: avere un PBS virtualizzato sullo stesso cluster Proxmox di cui dovrebbe eseguire il backup è come avere un estintore vuoto nella casa in fiamme. ??

# Aggiungi echo Proxmox Backup Server Repository "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg/proxmox-release-bookworm.gpg apt update && apt install proxmox-backup-server # Prima configurazione - creare un utente amministratore proxmox-backup-manager utente creare backup@pbs --email admin@example.com proxmox-backup-manager acl update / Backup@pbs --rule Admin

Ottimizzare la configurazione dello storage

La configurazione dell'archiviazione è al centro del tuo sistema di backup. Vale la pena investire un po 'di tempo qui. ZFS è spesso la scelta migliore qui perché ti dà istantanee, compressione e checksumming out-of-the-box. Ne avevamo già discusso in dettaglio nella seconda parte (Storage).

# Creare ZFS Pool per prestazioni ottimali # Rispecchia due dischi e usa NVMe per la cache e log zpool crea il backup-pool \ mirror /dev/sdb /dev/sdc \ cache /dev/nvme0n1p1 \ log /dev/nvme0n1p2 # Datastore con sofisticate impostazioni di conservazione proxmox-backup-manager datastore crea backup-storage /backup-pool/data \ --gc-schedule 'giornaliero' \ --prune-schedule 'giornaliero' \ --keep-giornaliero 7 \ --keep-settimanale 4 \ --keep-mensile 12 \ --keep-annuale 2 \ --notify-user backup@pbs

Configurare i processi di backup

Configurazione di base

Ora sta diventando interessante: i posti di lavoro di backup effettivi. È qui che decidi se il tuo sistema di backup diventerà un compagno affidabile o una fonte di frustrazione costante!

La variante CLI ti dà molto più controllo sui parametri. La limitazione della larghezza di banda è particolarmente importante! Nessuno vuole che i backup chiudano il resto della rete.

# Lavoro di backup con tutti i parametri importanti pvesh create /cluster/backup \ --schedule "02:00" \ --storage backup-pbs \ --mode snapshot \ --all 1 \ --compress zstd \ --protected 1 \ --notes-template "{{cluster}}: {{guestname}} - {{job-id}}" \ --mailnotification always \ --mailto admin@example.com \ --bwlimit 50000 # Limitazione della larghezza di banda 50MB/s

In alternativa, puoi anche fare il tutto comodamente tramite l'interfaccia web: Datacenter → Backup → Aggiungi. Questo è spesso più chiaro, soprattutto per i principianti.

Parametri importanti spiegati

Questi parametri sono cruciali per un sistema di backup funzionante, quindi ecco i più importanti in dettaglio:

Calendario: Qui si utilizza il formato Cron standard. 0 2 * * * Mezzi alle 2:00 del mattino tutti i giorni. Pianifica i tempi di backup in modo che non siano in conflitto con altre attività ad alta intensità di manutenzione.

mode: Ecco tre opzioni che hanno tutti i loro vantaggi e svantaggi:

  • istantanee: La VM continua a funzionare, si ottiene un'istantanea coerente. Ideale per sistemi produttivi.
  • sospeso: La VM viene brevemente interrotta. Massima consistenza, ma breve interruzione.
  • stop: La VM si sta spegnendo. Consigliato solo per sistemi non critici.

Comprimi: Qui devi bilanciare velocità ed efficienza:

  • lz4 è veloce e richiede poca CPU, ma compresso meno
  • zstd Comprime molto meglio, ma ha bisogno di più potenza di calcolo

Protetto: Protegge il backup dalla cancellazione accidentale. Dovresti sempre attivarlo per backup importanti.

BWLimit: Il limite di larghezza di banda in KB/s. 50000 corrisponde a circa 50MB/s, adattandolo all'infrastruttura di rete.

Abilita la verifica del backup

Un backup senza verifica è come un paracadute senza certificato di prova: si nota solo che non funziona quando ne si ha realmente bisogno, il che può essere troppo tardi nel peggiore dei casi. PBS ti aiuta perché può controllare automaticamente l'integrità dei tuoi backup.

# Verificare il lavoro per l'integrità automatica del backup pvesh creare /admin/verify \ --store backup-storage \ --schedule 'weekly' \ --outdated-after 7 \ --ignore-verified

Il processo Verify viene eseguito una volta alla settimana e controlla tutti i backup precedenti a 7 giorni. I backup già verificati vengono saltati per risparmiare tempo.

Implementare la regola di backup 3-2-1

La regola del 3-2-1

La regola 3-2-1 non è solo un espediente di marketing, ma una pratica comprovata da decenni di esperienza con la perdita di dati. Esso stabilisce quanto segue:

  • 3 Copie dei tuoi dati (1 originale + 2 backup)
  • 2 diversi tipi di supporti/memorizzazione (non tutti sulla stessa tecnologia)
  • 1 Backup fuori sede (separato geograficamente - incendio, alluvione, furto)

Attuazione pratica

In un tipico ambiente Proxmox, questo potrebbe assomigliare a questo:

  1. Dati primari: Sul tuo server Proxmox con ZFS e ridondanza
  2. Backup locale: Sul server PBS nello stesso data center/ufficio
  3. Backup fuori sede: Sincronizzazione PBS con un sito esterno o un provider cloud

La configurazione remota è relativamente semplice, ma è necessario prestare attenzione alla connessione di rete. Una connessione instabile può rendere i tuoi lavori di sincronizzazione un incubo.

# Configurare il backup remoto - Impronte digitali dal server di destinazione pvesh create /admin/remote \ --name offsite-backup \ --host backup.external.com \ --userid backup@pbs \ --password "secure_password" \ --fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD # Lavoro di sincronizzazione con limitazione della larghezza di banda - viene eseguito di notte quando poco sta andando su pvesh create /admin/sync \ --remote offsite-backup \ --remote-store production \ --store local-backup \ --schedule "04:00" \ --rate-in 10000 \ --burst-in 15000 \ --comment "Nighty Offsite-Sync"

Strategie di backup avanzate

Configura la conservazione dei backup

Le politiche di conservazione sono spesso sottovalutate, ma estremamente importanti. Senza regole significative, accumuli gigabyte di vecchi backup nel corso degli anni di cui nessuno ha più bisogno. Allo stesso tempo, non si desidera eliminare accidentalmente l'unico backup utilizzabile del mese scorso.

Una strategia comprovata è il metodo "nonno-padre-figlio": molti nuovi backup, meno vecchi, pochissimi quelli antichi. PBS lo fa automaticamente per te.

# Configurare sofisticati criteri di conservazione proxmox-backup-manager datastore update backup-storage \ --keep-last 3 \ # Tenere sempre gli ultimi 3 backup (emergenze) --mantenere 24 ore su 24 \ # Backup 24 ore su 24 (ultimo giorno) --mantenere-giornaliero 7 \ # 7 backup giornalieri (ultima settimana) --mantenere-settimanale 4 \ # 4 backup settimanali (ultimo mese) --mantenere-mensile 12 \ # 12 backup mensili (l'anno scorso) --mantenere-annuale 5 # 5 backup annuali (archiviazione a lungo termine)

Gestione della larghezza di banda

Negli ambienti di produzione, spesso è necessario budget con larghezza di banda limitata. I backup non dovrebbero rallentare i sistemi di produzione, ma non dovrebbero durare per sempre. La modellazione del traffico ti aiuta a trovare il giusto equilibrio.

# Impostare il modellamento del traffico sul server PBS tc qdisc add dev eth0 root handle 1: htb default classe 30 tc aggiungere dev eth0 genitore 1: classid 1:1 htb rate 1000mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 800mbit ceil 1000mbit tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 400mbit # iptables -A OUTPUT -p tcp --dport 8007 -j CLASSIFY --set-class 1:20

Questa configurazione riserva 80% la larghezza di banda per il traffico normale e limita i backup a un massimo di 40% – con la possibilità di utilizzare il traffico inutilizzato.

Integrazione del backup con lo storage

Ottimizzazioni specifiche per lo storage

Diversi tipi di stoccaggio hanno diversi punti di forza. Usalo a tuo vantaggio memorizzando metadati e grandi blocchi di dati su diversi supporti.

# Archivi di dati separati per esigenze diverse # Veloce NVMe per metadati e piccoli file proxmox-backup-manager datastore creare vm-backups-meta \ /nvme/backup-meta \ --gc-schedule 'giornaliero' \ --prune-schedule 'giornaliero' # Big RAID per il datastore proxmox-backup-manager dei dati di backup reali crea vm-backups-data \ /raid/backup-data \ --gc-schedule 'weekly' \ --keep-daily 14 \ --keep-weekly 8 \ --keep-monthly 24 # Processo di backup che esclude i file non necessari pvesh create /cluster/backup \ --schedule "02:00" \ --storage backup-pbs \ --mode snapshot \ --compress zstd \ --notes-template "{{cluster}}: {{guestname}} ({{mode}}})" \ --protected 1 \ --exclude-path "/tmp/*,/var/log/*,/var/cache/*" # Risparmia spazio e tempo

Strategie di backup per tipo di storage

Istantanea di LVM-Thin

I volumi sottili di LVM sono ampiamente usati e forniscono la funzionalità semplice dell'istantanea. Il trucco è mantenere le istantanee solo per il tempo in cui ne hai davvero bisogno: possono influire sulle prestazioni.

# Backup automatico delle istantanee LVM con risoluzione dei problemi create_lvm_backup() { vmid= locale$1 percorso_disco locale="/dev/pve/vm-${vmid}-disk-0" snap_name locale="vm-${vmid}-snap-$(data +%Y%m%d-%H%M%S)" echo "Crea Backup per VM $vmid..." # Controlla se c'è abbastanza spazio per lo snapshot se ! lvcreate --test --snapshot --name $snap_name --dimensione 10G $percorso_disco; poi echo "Errore: Non c'è abbastanza spazio per un'istantanea!" ritorno 1 fi # Creare snapshot - è quasi istantaneo lvcreate --snapshot --name $snap_name --dimensione 10G $percorso_disco # Backup da snapshot con indicatore di stato dd if=/dev/pve/$snap_name bs=64k status=progress ?? \ gzip -c > /backup/vm-${vmid}-$(data +%Y%m%d).img.gz # Elimina immediatamente lo snapshot per ottenere prestazioni lvremove -f /dev/pve/$snap_name echo "Backup per VM $vmid completato." } # Uso per VM 100: # Crea_lvm_backup 100

ZFS istantanee

ZFS è molto più elegante qui: le istantanee non costano praticamente nulla e puoi effettuare backup incrementali. Ciò consente di risparmiare molto tempo e larghezza di banda, soprattutto con VM di grandi dimensioni.

# Strategia di backup incrementale intelligente di ZFS zfs_incremental_backup() { dataset locale=$1 locale remote_host=$2 corrente locale_snap="${dataset}@backup-$(data +%Y%m%d-%H%M%S)" locale last_snap=$(zfs list -t snapshot -o nome -s creazione ?? grep ${dataset}@ ?? tail -1) eco "Crea ZFS Backup per $insieme di dati..." # Crea nuova istantanea - prende millisecondi zfs snapshot $current_snap se [ -n "$last_snap" ]; poi echo "Invia backup incrementale dal $last_snap" # Trasferire solo le modifiche - molto più veloce zfs inviare -i $last_snap $corrente_snap ?? \ ssh $remote_host "zfs ricevere -F backup/${set di dati##*/}" altrimenti echo "Invia backup completo iniziale" # Il primo backup è sempre completo zfs send $corrente_snap ?? \ ssh $remote_host "zfs ricevere backup/${set di dati##*/}" fi # Pulisci le istantanee - mantieni solo gli ultimi 7 old_snaps locali =$(zfs list -t snapshot -o nome -s creazione ?? grep ${dataset}@ ?? testa -n -7) se [ -n "$old_snaps" ]; poi echo "Elimina vecchie istantanee..." echo "$old_snaps" ?? mentre si legge snap; Gli zf distruggono $snap done fi echo "Backup ZFS per $dataset completato." } # Automazione per tutti i dataset delle VM zfs_replicate_all() { echo "Start ZFS replication for all VMs..." per il dataset in $(lista zfs -H -o nome ?? grep "serbatoio/vm-"); fare zfs_incremental_backup $dataset backup-server.local fatto eco "ZFS replica completata." }

Monitoraggio e allerta

Monitorare lo stato del backup

Un sistema di backup senza monitoraggio è come un rilevatore di fumo senza batterie: si nota solo che non funziona quando è troppo tardi. Pertanto, è necessario impostare controlli automatici.

# script di monitoraggio dello stato di backup #!/bin/bash check_backup_status() { echo "Controlla lo stato del backup..." # Cerca lavori falliti nelle ultime 24 ore local failed_jobs=$(pvesh get /cluster/backup --output-format json ?? \ jq -r '.[] ?? select(.state == "error") ?? .id') se [ -n "$failed_jobs" ]; poi eco "ALARM: I processi di backup non sono riusciti: $fail_jobs" (professioni fallite) # Invia e-mail echo "Lavori di backup $Failed_jobs non riuscito. Si prega di controllare!" ?? \ mail -s "BACKUP FAILURE ALERT" admin@example.com # Facoltativo: Alert to monitoring system curl -X POST "https://monitoring.example.com/alert" \ -H "Tipo di contenuto: application/json" \ -d "{\"messaggio\":\"Errori di backup: $fail_jobs\", \"severity\":\"critical\"}" restituisce 1 altro echo "Tutti i processi di backup vengono eseguiti normalmente." restituisce 0 fi } # Eseguire come un lavoro cron ogni 2 ore # 0 */2 * * * /usr/local/bin/check_backup_status.sh

Controllo dello stato di Proxmox Backup Server

Controlli sanitari regolari ti aiuteranno a identificare i problemi prima che diventino critici. Dovresti tenere d'occhio lo spazio di archiviazione, le prestazioni e lo stato del servizio. Ad esempio, potrebbe assomigliare a questo:

# PBS Health Check completo pbs_health_check() { echo "=== PBS Health Check $(data) ===" # Datastore Status and Storage echo "--- Datastore Status ---" proxmox-backup-manager datastore list echo "--- Storage ---" df -h ?? grep -E "(backup ?? pbs)" ?? mentre si legge la riga; fare uso =$(eco $linea ?? awk '{stampa $5}' ?? tr -d '%«) se [ $utilizzo -gt 85 ]; poi eco "ATTENZIONE: $linea - memoria quasi piena!" altrimenti eco "OK: $linea" fi fatto # Processi in corso echo "--- Processi di backup attivi ---" local active_jobs=$(ps aux ?? grep -E "(proxmox-backup ?? pbs)" ?? grep -v grep ?? wc -l) eco "Lavori attivi: $active_jobs" # Verifica lo stato dei lavori ---" pvesh get /admin/verify --output-format json ?? \ jq -r '.[] ?? "Lavoro \(.id): \(.state) (ultima versione: \(.last_run_endtime // "mai"))"' # testare le prestazioni della rete agli obiettivi remoti eco "--- test di rete ---" se comando -v iperf3 > /dev/null; poi echo "Test larghezza di banda per gli obiettivi di backup..." # iperf3 -c backup-remote.com -t 10 -f M fi echo "=== Controllo dello stato di salute Ende ===" }

Pianificazione del ripristino in caso di catastrofi

Recupero completo del sistema

Verrà il giorno in cui dovrai ripristinare l'intero sistema. Sì, certo, non succede mai, beh, ad un certo punto è sempre la prima volta. La preparazione è tutto qui: testare regolarmente i piani di ripristino in caso di disastro in un ambiente isolato.

# Ripristino completo del cluster dopo il fallimento totale restore_cluster() { backup_location locale=$1 eco "Avviare il recupero del cluster da $backup_location" # 1. Preparare il nuovo eco di installazione di Proxmox "Fase 1: Sistema di base installato (fase manuale)" # 2. Ripristinare la configurazione del cluster echo "Fase 2: Ripristinare la configurazione del cluster..." se [ -f "$backup_location/cluster-config.tar.gz" ]; poi tar -xzf "$backup_location/cluster-config.tar.gz" -C /etc/pve/ systemctl ricaricare pve-cluster fi # 3. Ripristinare la configurazione di archiviazione echo "Fase 3: Ripristinare le piscine di stoccaggio..." # Qui è necessario personalizzare la configurazione di archiviazione specifica # 4. Ripristinare le VM singolarmente eco "Fase 4: Recupero della VM..." se [ -f "$backup_location/vm-list.txt" ]; poi durante la lettura vmid; fare eco "Recuperare VM $vmid..." locale backup_file="$backup_location/vm-${vmid}-latest.vma.gz" se [ -f "$backup_file" ]; poi qmrestore "$file_di_backup" $vmid --storage local-lvm echo "VM $vmid restaurato" altro eco "ATTENZIONE: Backup per VM $vmid non trovato!" fi fatto < "$backup_location/vm-list.txt" fi echo "Recupero cluster completato. Si prega di controllare i servizi!" }

Automatizza la convalida del backup

L'ho già detto oggi? Non importa, non si può dire abbastanza: Testare regolarmente i backup è essenziale. Niente è più frustrante che scoprire un backup corrotto solo in caso di emergenza.

Il PBS inoltre convaliderà automaticamente per voi, ma aggiungerà fino a 100% Anch'io trovo difficile andarmene. Almeno dovresti prendere in considerazione l'effettivo ripristino di tanto in tanto, ad esempio tramite il tuo ambiente di test / staging, solo allora puoi davvero dormire tranquillamente.

# Test di backup automatizzati con test VM backup_validation() { test_vmid=9999 # Riservare VM-ID per i test datastore locale = "backup-storage" echo "Avvia convalida backup..." # Trova l'ultimo backup locale latest_backup=$(proxmox-backup-client elenco --repository $datastore ?? \ grep "vm/$test_vmid" ?? sort -r ?? head -1 ?? awk '{stampa $1}') se [ -z "$latest_backup" ]; quindi echo "Nessun backup trovato per la VM di prova, usa qualsiasi backup della VM" latest_backup=$(proxmox-backup-client elenco --repository $datastore ?? \ grep "vm/" ?? testa -1 ?? awk '{stampa $1}') fi se [ -z "$latest_backup" ]; poi eco "FEHLER: Nessun backup trovato!" ritorno 1 fi echo "Backup di prova: $più recente_backup" # Ripristino del test (senza avvio) se qmrestore --archive "$datastore:backup/$più recente_backup" $test_vmid --stoccaggio local-lvm; poi echo "Recupero riuscito, test VM start..." # Avvio test VM qm start $test_vmid sonno 30 se qm stato $test_vmid ?? grep -q "in esecuzione"; poi eco "SUCCESSO: Convalida del backup con successo - VM si avvia correttamente" qm stop $test_vmid qm distruggere $test_vmid --purge return 0 altro eco "FEHLER: VM non si avvia dopo il recupero" mq distruggere $test_vmid --purge ritorno 1 fi altro eco "FEHLER: Recupero fallito" ritorno 1 fi }

Ottimizzazione delle prestazioni

Sintonizzazione delle prestazioni di backup

La messa a punto delle prestazioni nei backup è spesso un atto di bilanciamento tra velocità, carico del sistema e impatto sulla rete. Qui ci sono impostazioni collaudate per diversi scenari.

# Ottimizzare le impostazioni di backup a livello di data center (Homelab) # /etc/pve/datacenter.cfg max_workers: 3 # Non più di 3 processi di backup paralleli bandwidth_limit: 200 # Larghezza di banda totale di 200MB/s per tutti i lavori ionice: 7 # Priorità di I/O più bassa (0-7) lockwait: 180 # Attendere 3 minuti per le serrature

Queste impostazioni impediscono ai backup di sovraccaricare i sistemi di produzione. Con hardware più potente, è possibile regolare i valori di conseguenza, i dati dell'esempio precedente sono una configurazione homelab piuttosto semplice senza hardware server ad alte prestazioni. Su un server relativamente aggiornato, ad esempio, questo potrebbe anche assomigliare a questo:

# Ottimizzare le impostazioni di backup a livello di datacenter (server) # /etc/pve/datacenter.cfg max_workers: 6 # Non più di 6 processi di backup paralleli bandwidth_limit: 1500 # 1500MB/s larghezza di banda totale per tutti i lavori (NvME Storage) ionizza: 4 # Priorità di I/O media (0-7) lockwait: 60 # Attendere 1 minuto per le serrature

Ottimizzazioni specifiche per lo storage

Le diverse tecnologie di storage richiedono diverse ottimizzazioni. Ciò che è buono per gli SSD NVMe può essere controproducente con dischi rigidi rotanti. Ecco alcuni esempi:

# Ottimizzare gli scheduler I/O per diversi tipi di storage # Per gli SSD NVMe: mq-deadline è per lo più l'eco ottimale mq-deadline > /sys/block/nvme0n1/queue/scheduler # Per gli SSD SATA: none o mq-deadline echo none > /sys/block/sda/queue/scheduler # Per dischi rigidi rotanti: bfq o cfq echo bfq > /sys/block/sdb/queue/scheduler # Ottimizzare readahead per grandi blocchi di accesso sequenziale --setra 4096 /dev/sda # 2 MB di readahead # Per i carichi di lavoro di backup spesso utile eco 32 > /sys/block/sda/queue/nr_requests

Risolvere i problemi più comuni

Appendere i lavori di backup

Appendere i lavori di backup è un problema classico. Ciò è di solito dovuto a blocchi, problemi di rete o sistemi di archiviazione sovraccarichi.

# Identificare e trattare i lavori sospesi find_hanging_jobs() { echo "Cerca lavori di backup sospesi..." # I processi vzdump a lungo termine trovano ps aux ?? grep vzdump ?? grep -v grep ?? mentre leggono la linea; fare pid=$(eco $linea ?? awk '{stampa $2}') runtime=$(ps -o etime= -p $pid ?? tr -d ') eco "PID lavoro $pid è in esecuzione da: $runtime" # I lavori che durano più di 6 ore sono sospetti se [[ $runtime =~ ^[0-9][0-9]:[0-9][0-9]:[0-9][0-9]$ ]]; poi eco "ATTENZIONE: lavoro $pid corre molto lungo!" fi fatto # Controllare i file di blocco se [ -f /var/lock/vzdump.lock ]; poi echo "Vzdump-Lock found, check process..." locale lock_pid=$(cat /var/lock/vzdump.lock) se ! uccidere -0 $lock_pid 2>/dev/null; poi echo "Lock file is orphaned, delete it..." rm /var/lock/vzdump.lock fi } # Pulizia di emergenza per sistemi completamente sospesi emergency_backup_cleanup() { echo "NOTFALL: Termina tutti i processi di backup!" killall -9 vzdump killall -9 proxmox-backup-client rm -f /var/lock/vzdump.lock rm -f /tmp/vzdumptmp* echo "Cleanup completed - check the logs!" }

Gestione dello spazio di archiviazione

Anche i datastore di backup completi sono un problema comune. La raccolta e la potatura dei rifiuti dovrebbero essere eseguite automaticamente, ma a volte è ancora necessario intervenire manualmente.

# diagnosticare e correggere storage_cleanup() { datastore locale=$1 eco "Analisi dello spazio di stoccaggio per $datastore..." # Consumo di memoria corrente df -h $(proxmox backup manager datastore list ?? grep $datastore ?? awk '{stampa $3}') # Trova i gruppi di backup più grandi echo "Gruppi di backup più grandi:" you -sh /backup/$datastore/* ?? sort -hr ?? testa -10 # Eseguire manualmente Garbage Collection echo "Start Garbage Collection..." proxmox-backup-manager garbage-collect $datastore # I pezzi orfani trovano eco "Cerca pezzi orfani..." proxmox-backup-manager datastore verifica $datastore # Spazio di archiviazione dopo la pulizia eco "Spazio di stoccaggio dopo la pulizia:" df -h $(proxmox backup manager datastore list ?? grep $datastore ?? awk '{stampa $3}') # Eseguire manualmente i lavori di Prune quando non si esegue automaticamente l'eco "Esegui lavori di Prune..." proxmox-backup-client prune --repository $datastore \ --keep-giornaliero 7 --keep-settimanale 4 --keep-mensile 12 } # Monitoraggio dello storage con Alerts monitor_storage_space() { per datastore in $(proxmox backup manager datastore list ?? awk 'NR>1 {stampa $1}'); fare percorso locale =$(proxmox backup manager datastore list ?? grep $datastore ?? awk '{stampa $3}') uso locale=$(df "$percorso" ?? awk 'NR==2 {stampa $5}' ?? tr -d '%') eco "Datastore $datastore: ${uso}% evidenziato" se [ $utilizzo -gt 90 ]; Poi echo "CRITICO: $datastore oltre 90% Pieno di esso! # Qui è possibile eliminare automaticamente i vecchi backup elif [ $utilizzo -gt 80 ]; poi eco "ATTENZIONE: $datastore oltre 80% pieno" fi fatto }

Diagnosi dei problemi di rete

I problemi di rete potrebbero anche essere la causa di backup lenti o falliti. Ecco gli strumenti e le tecniche per aiutarti a diagnosticare.

# Diagnostica di rete completa per connessioni di backup network_backup_diagnosis() { local target_host=$1 eco "=== Diagnosi di rete per $destinazione_host ===" # Eco di accessibilità di base "--- Ping Test ---" se ping -c 5 $target_host > /dev/null; poi echo "Host $target_host è raggiungibile" ping -c 5 $target_host ?? coda -1 altro eco "FEHLER: Ospitante $target_host non raggiungibile!" ritorno 1 fi # prova di larghezza di banda con eco iperf3 "--- prova di larghezza di banda ---" se comando -v iperf3 > /dev/null; poi echo "Prova larghezza di banda a $target_host..." timeout 30s iperf3 -c $target_host -t 20 -f M 2>/dev/null ?? \ grep "sender" ?? awk '{print "Carica: " $7 " " $8}' timeout 30s iperf3 -c $target_host -t 20 -f M -R 2>/dev/null ?? \ grep "ricevitore" ?? awk '{stampa "Scarica: " $7 " " $8}' else echo "iperf3 non installato - installa con: apt install iperf3" fi # Test di latenza eco "--- Analisi di latenza ---" locale avg_latency=$(ping -c 100 $target_host ?? tail -1 ?? awk -F'/' '{stampa $5}') echo "Latenza media: ${avg_latency}ms" se (( $(eco "$avg_latency > 100" ?? bc -l) )); poi eco "ATTENZIONE: L'alta latenza potrebbe influire sulle prestazioni di backup # Disponibilità del porto per PBS eco "--- Port Tests ---" per il porto in 8007 8008; fare se timeout 5s bash -c "</dev/tcp/$target_host/$porto"; poi echo "Porto $porto: APERTO" altro eco "Porto $porto: CHIUSO o filtrato" fi fatto # MTU-Discovery eco "--- MTU-Test ---" per la dimensione in 1472 1500 9000; fare se ping -c 1 -M fare -s $dimensione $target_host > /dev/null 2>&1; poi echo "MTU $dimensioni: OK" altro eco "MTU $dimensioni: Frammentazione necessaria" fi fatto }

Emissioni di certificati SSL/TLS

PBS utilizza HTTPS per tutte le connessioni. I problemi di certificazione sono un ostacolo comune, specialmente con i certificati autofirmati.

# Diagnosi del certificato SSL e riparazione check_pbs_certificates() { local pbs_host=$1 echo "=== Verifica certificato SSL per $pbs_host ===" # Ottieni i dettagli del certificato echo "--- Informazioni sul certificato ---" local cert_info=$(echo openssl s_client -nomeserver $pbs_host -connettere $pbs_host:8007 2>/dev/null ?? \ openssl x509 -noout -dates -subject -issuer) echo "$cert_info" # Verifica validità certificato locale expiry_date=$(eco "$cert_info" ?? grep "notAfter" ?? cut -d'=' -f2) locale expiry_seconds=$(data -d "$scadenza_data" +%s) locale now_seconds=$(data +%s) giorni locali_fino a_scadenza=$(((expiry_seconds - now_seconds) / 86400 ))) eco "Il certificato scade in: $days_until_expiry days" se [ $days_until_expiry -lt 30 ]; poi eco "ATTENZIONE: Il certificato scadrà presto!" fi # Impronte digitali per la configurazione remota eco "--- Impronte digitali per la configurazione remota ---" impronta digitale locale=$(echo openssl s_client -nomeserver $pbs_host -connettere $pbs_host:8007 2>/dev/null ?? \ openssl x509 -noout -impronta digitale -sha256 ?? cut -d'=' -f2) eco "Impronta digitale: $impronte digitali" } # Genera nuovo certificato autofirmato regenerate_pbs_certificate() { local pbs_host=$1 eco "Generare nuovo certificato autofirmato per $pbs_host..." # Backup del vecchio certificato cp /etc/proxmox-backup/proxy.pem /etc/proxmox-backup/proxy.pem.backup.$(data +%Y%m%d) # Creare un nuovo certificato openssl req -x509 -newkey rsa:4096 -keyout /tmp/proxy.key -out /tmp/proxy.crt \ -days 3650 -nodes -subj "/CN=$pbs_host" # Combina certificato e chiave cat /tmp/proxy.crt /tmp/proxy.key > /etc/proxmox-backup/proxy.pem # Elimina i file temporanei rm /tmp/proxy.key /tmp/proxy.crt # Servizio riavviare systemctl riavviare proxmox-backup-proxy echo "Nuovo certificato installato. Nuova impronta digitale:" check_pbs_certificates $pbs_host ?? grep "Impronta digitale:" }

Migliori pratiche TL:DR

Dovresti assolutamente prestare attenzione a questo

Ecco i punti chiave che determinano il successo o il fallimento del tuo sistema di backup:

Infrastruttura hardware &:

  • PBS sempre su hardware separato - mai sul sistema di cui si esegue il backup
  • RAM sufficiente per la deduplica (almeno 16 GB per gli ambienti di produzione)
  • SSD veloci per i metadati, HDD di grandi dimensioni per i dati di backup
  • Connessioni di rete ridondanti, se possibile

Configurazione:

  • Configurare correttamente le politiche di conservazione fin dall'inizio - in seguito è noioso
  • Abilitare la limitazione della larghezza di banda in modo da non interferire con i sistemi produttivi
  • Configurare Verify jobs - un backup non testato non è un backup
  • Abilita notifiche e-mail per tutti gli eventi critici

Monitoraggio:

  • Controlli sanitari automatici almeno giornalmente
  • Monitoraggio dell'archiviazione con avvisi a >80% occupazione
  • Ripristino regolare dei test in ambiente isolato
  • Esaminare regolarmente i file di registro – prendere sul serio gli avvertimenti

Sicurezza:

  • Abilita la crittografia lato client per i dati sensibili
  • Credenziali separate per gli utenti di backup - nessun diritto di amministratore
  • Regole del firewall solo per le porte necessarie (8007, 8008)
  • Backup offsite con trasferimento sicuro (chiavi SSH invece di password)

Evitare frequenti errori dei principianti

Errore «PBS virtualizzato»: Non eseguire mai PBS sullo stesso cluster Proxmox di cui dovrebbe eseguire il backup. E' come una cintura di sicurezza fatta di gomma.

Il set e dimentica la mentalità: I backup richiedono una manutenzione regolare. Controllare almeno una volta al mese per vedere se tutto funziona.

Mancanza di limitazione della larghezza di banda: I processi di backup senza limiti possono paralizzare la rete di produzione.

Nessun ripristino dei test: Non sai se i tuoi backup funzioneranno fino a quando non li testerai. La legge di Murphy è particolarmente applicabile ai backup. ??

Politiche di conservazione poco chiare: Definisci fin dall'inizio per quanto tempo vuoi conservare qualcosa. Gli archivi di backup in continua crescita sono un incubo.

Con queste basi, hai una solida base per il tuo sistema di backup Proxmox. Investi tempo in una configurazione adeguata: dirò così, il tuo futuro ti ringrazierò, sia attraverso un sonno tranquillo e rilassato, sia al più tardi quando si verifica la prima emergenza.

Completamento e risorse avanzate

Proxmox è uno strumento potente, ma con grande potenza arriva una grande responsabilità. (winker) Le migliori pratiche qui mostrate sono il risultato dell'esperienza pratica. Inizia con le basi e gradualmente lavora fino alle funzionalità avanzate.

I tuoi prossimi passi:

  1. Costruire un ambiente di testing/staging: Testare tutte le configurazioni in un ambiente separato
  2. Attuare il monitoraggio: Monitora il tuo sistema fin dall'inizio
  3. Strategia di backup di prova: Esegue regolari test di ripristino
  4. Unisciti alla Community: Il forum Proxmox è molto utile

Quindi ricorda: Prenditi il tuo tempo, le basi Comprendi davanti a te Impostazioni più complesse svanisce. Il Guida di amministrazione di Proxmox Come sito web ho collegato più volte nell'articolo come riferimento vale anche l'oro. Dai un'occhiata nel forum intorno, Se hai una domanda. C'è anche un punto di ingresso per Canale YouTube.

Le restanti parti di questa serie di articoli che ho anche collegato qui di nuovo per voi: Parte 1: rete | Parte 2: stoccaggio | Parte 3: rinforzi | Parte 4: sicurezza | Parte 5: prestazioni

Stephan
|
| | | | | | | | |
verso l'alto | homepage | per cercare