Come abbinare le modalità di backup di Proxmox ai database e ai file server

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Match Proxmox Backup Modes to Databases and File Servers - Zima Store Online

Un backup di una VM Proxmox può essere coerente in caso di arresto anomalo senza essere coerente a livello applicativo. Un file server può ripristinarsi correttamente da uno snapshot del filesystem, mentre un database molto impegnato potrebbe richiedere hook di freeze dell'agente guest, un dump dell'applicazione o una breve interruzione per garantire il punto di ripristino previsto.

Scegli la modalità in base al contratto di ripristino del carico di lavoro, non sulla base di una preferenza universale per l'assenza di downtime. Documenta l'interruzione accettabile, il metodo di coerenza, il comportamento dello storage e il test di ripristino che dimostra la validità di ogni classe. Un registro dei job completati correttamente è una prova utile, ma il vero test di accettazione è il ripristino isolato dell'applicazione.

Classifica il carico di lavoro in base al requisito di coerenza

Per ogni VM, elenca l'applicazione, l'intensità delle scritture, il downtime massimo accettabile e l'obiettivo del punto di ripristino. Un file server prevalentemente statico e un database transazionale non dovrebbero ereditare la stessa modalità solo perché condividono un nodo.

Determina se l'applicazione dispone di un proprio meccanismo di backup o dump. Un'immagine della VM può ripristinare la macchina, mentre un dump nativo del database o un backup dei log può fornire il ripristino a livello di transazione e la verifica richiesti dal servizio.

La documentazione dei backup di Proxmox distingue il comportamento delle modalità snapshot, suspend e stop. Usa questa definizione della modalità insieme alle garanzie di coerenza dell'applicazione guest.

Usa la modalità snapshot per i carichi di lavoro con downtime ridotto

La modalità snapshot è il punto di partenza usuale quando il downtime deve essere minimo e lo stack di storage la supporta. Installa e abilita l'agente guest QEMU dove appropriato, in modo che il processo di backup possa coordinare il freeze e il thaw del filesystem.

Il quiescing del filesystem riduce il rischio di scritture in corso, ma non crea automaticamente un backup del database verificato a livello transazionale. Usa hook del database, un dump pre-backup, la replica o un altro metodo consapevole dell'applicazione quando il contratto di ripristino lo richiede.

Conserva i dump al di fuori dei percorsi guest eliminabili e verifica che siano stati completati prima dell'avvio del backup della VM. La guida al backup della configurazione di Immich illustra perché un dump del database generato è utile solo quando ne vengono verificati la coerenza e il percorso di ripristino.

Usa la modalità stop o suspend quando il compromesso è accettabile

La modalità stop fornisce lo stato offline più chiaro, arrestando il guest prima del backup e riavviandolo al termine. È adatta a piccoli servizi con una finestra di manutenzione accettata o a carichi di lavoro la cui coerenza è difficile da coordinare online.

La modalità suspend mette in pausa l'esecuzione, ma può creare un'interruzione visibile più lunga e non sostituisce una preparazione consapevole dell'applicazione. Misura la durata effettiva della pausa sul tuo storage e sul tuo carico di lavoro prima di assegnarla su larga scala.

Per un file server domestico, la modalità snapshot con il coordinamento dell'agente guest è spesso sufficiente quando i client possono riprovare e il filesystem è integro. Scegli la modalità stop quando il servizio è piccolo, la correttezza prevale sulla disponibilità o un test di ripristino evidenzia problemi con l'acquisizione online.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Programma e dimostra ogni classe di backup

Crea job separati o impostazioni esplicite per VM per le classi database, file server e servizi generici. Sfasa i guest più pesanti in modo che la destinazione del backup e il datastore di produzione non siano saturi contemporaneamente.

Dopo ogni modifica della modalità, esegui il ripristino su una rete isolata. Avvia la VM, controlla l'integrità del filesystem, avvia l'applicazione, esegui un controllo di integrità del database o una query di esempio e apri file rappresentativi tramite il normale protocollo del servizio.

Un job di backup completato correttamente non è la condizione di superamento. La classe di backup supera il test solo quando il ripristino soddisfa il requisito documentato di downtime e coerenza; in caso contrario, sposta quel carico di lavoro verso un metodo di preparazione più rigoroso o verso una finestra di arresto.

Domande frequenti

L'agente guest QEMU rende un backup del database coerente a livello applicativo? Non da solo. Può coordinare il freeze e il thaw del filesystem, ma il database potrebbe comunque richiedere il proprio dump, hook, checkpoint o un'integrazione snapshot documentata.

Quale modalità dovrei usare per un piccolo file server domestico? Inizia con la modalità snapshot e un agente guest funzionante, quindi dimostrala con un ripristino isolato. Usa la modalità stop se il servizio tollera il downtime e hai bisogno di uno stato offline più semplice.

Posso usare modalità diverse in un unico job di backup? Usa impostazioni esplicite per VM o job separati, in modo che ogni carico di lavoro segua il proprio contratto documentato di coerenza e downtime.