Server di backup remoto vs storage di oggetti cloud per i backup delle VM domestiche
Un server di backup remoto è generalmente la scelta migliore come destinazione per le VM domestiche quando servono ripristini completi rapidi, attività incrementali frequenti, un comportamento prevedibile del repository e il controllo sull'intero stack di ripristino. Lo storage a oggetti nel cloud è solitamente più indicato quando la separazione geografica e l'eliminazione di un secondo server dalla lista delle attività di manutenzione contano più del controllo locale. La decisione dipende dalle dimensioni del ripristino, dalla larghezza di banda in upload, dal comportamento del recupero dallo storage a oggetti, dai requisiti di immutabilità e dalla quantità di infrastruttura che si è disposti a gestire fuori sede.
Definisci l'attività di ripristino della VM prima di scegliere la destinazione
Un backup di una VM non è solo una cartella di documenti. Il ripristino di un hypervisor domestico guasto può richiedere immagini disco, configurazione della VM, metadati del guest, materiale di crittografia, note sulla rete e una velocità sufficiente per ricostruire diversi guest di grandi dimensioni nell'ordine corretto.
Proxmox documenta che la sua integrazione per i backup può creare backup pianificati di macchine virtuali e container, mentre Proxmox Backup Server aggiunge un'infrastruttura di backup deduplicata. La scelta della destinazione diventa quindi parte di un flusso di lavoro completo per il ripristino delle VM, non una semplice decisione sullo storage dei file.
Definisci prima il risultato da ottenere: quanti terabyte devono essere ripristinati, quanto rapidamente deve avviarsi la prima VM critica e se la perdita completa del sito rientra nel modello di minaccia. Le risposte determinano se il vincolo più difficile viene risolto meglio da un server raggiungibile o da uno storage a oggetti gestito dal provider.
Un server di backup remoto è la scelta migliore quando i ripristini di grandi dimensioni devono iniziare immediatamente
Un server situato in un'altra sede affidabile può mantenere il formato del backup online e pronto per il ripristino, senza attendere la riattivazione di un livello di archiviazione. Se il collegamento tra le sedi è sufficientemente veloce, può inoltre supportare incrementali frequenti e la verifica del repository utilizzando gli stessi strumenti del laboratorio domestico principale.
Questo modello offre il controllo diretto su cache, percorsi di rete, conservazione, sostituzione dei dischi e software del repository. È particolarmente utile quando si prevede di ripristinare intere VM anziché pochi file, perché la destinazione del ripristino può rimanere continuamente raggiungibile.
Il costo nascosto è che il “backup fuori sede” diventa un altro server di cui occuparsi. Qualcuno deve garantire alimentazione, rete, spazio fisico, aggiornamenti, monitoraggio, sostituzione delle unità e un piano di ripristino per lo stesso nodo remoto. Questa soluzione è interessante solo se tale lavoro operativo offre un vantaggio reale in termini di RTO.
Lo storage a oggetti nel cloud è la scelta migliore quando la priorità è eliminare la seconda sede
Lo storage a oggetti sostituisce chassis, dischi, UPS e dipendenza dalla rete domestica remota con un servizio di storage gestito dal provider. In questo modo è possibile ottenere una netta separazione geografica senza chiedere a un amico o a un parente di ospitare una seconda macchina.
Amazon S3 supporta policy del ciclo di vita che spostano o eliminano gli oggetti di backup, mentre altri provider di storage a oggetti offrono primitive simili. Il vantaggio operativo principale non è l'elenco delle funzionalità di un singolo fornitore: è che la sostituzione dei supporti e la manutenzione dell'hardware di storage non sono più a tuo carico.
Lo storage a oggetti nel cloud è la scelta migliore quando il ripristino è raro, l'upload tramite WAN è accettabile e l'applicazione di backup può utilizzare il provider in modo sicuro. Diventa meno interessante quando i ripristini completi di diversi terabyte sono urgenti o quando i tempi di recupero del provider e il trasferimento di rete dominano la finestra di ripristino.
La classe di recupero può modificare l'RTO del cloud prima ancora che inizi il download
Non tutti gli oggetti nel cloud sono leggibili immediatamente. Le classi di archiviazione a basso costo possono richiedere una richiesta di ripristino prima che i dati diventino disponibili, quindi “archiviato nel cloud” non significa automaticamente “pronto per essere ritrasmesso ora”.
AWS documenta finestre di recupero da pochi minuti a molte ore per i livelli di archiviazione. Se un repository di VM viene collocato in una classe di archiviazione, quel tempo di attesa rientra nell'RTO, prima ancora di conteggiare il download da Internet.
Usa uno storage immediatamente accessibile per i punti di ripristino che devono avviarsi rapidamente e archivia solo le generazioni il cui RTO consente un ritardo. Se servono contemporaneamente il basso costo dello storage di archiviazione profonda e la velocità di un server remoto pronto all'uso, i requisiti sono in conflitto e dovrebbero essere suddivisi su più livelli.
Immutabilità e separazione delle credenziali possono ribaltare il vincitore sul piano della sicurezza
Un server remoto che utilizza le stesse credenziali amministrative del laboratorio principale può essere più facile da gestire, ma anche più facile da distruggere dallo stesso piano di controllo compromesso. Lo storage a oggetti nel cloud può creare un confine più solido se i blocchi di conservazione e le credenziali limitate sono configurati correttamente.
Backblaze documenta Object Lock per limitare l'eliminazione o la modifica durante il periodo di conservazione, insieme ai controlli del ciclo di vita. Il valore deriva da un limite di conservazione applicato in modo indipendente, non dalla parola “cloud”.
Anche un server remoto può offrire una separazione solida con repository append-only, account distinti, restrizioni firewall e credenziali di ripristino offline. Scegli l'architettura il cui isolamento puoi realmente dimostrare in uno scenario in cui il sistema principale è compromesso.
L'economia dello storage a oggetti e le policy di rete contano con la crescita del repository
Il cloud elimina l'acquisto dei dischi, ma introduce dimensioni di fatturazione del provider come capacità archiviata, operazioni, classe di storage e talvolta recupero o traffico in uscita. Un server remoto sposta una parte maggiore dei costi iniziali su hardware, dischi, energia e manodopera per le sostituzioni.
Cloudflare R2 pubblica le dimensioni di fatturazione dello storage e delle richieste, mostrando perché lo storage a oggetti dovrebbe essere valutato come un servizio continuativo anziché come un acquisto una tantum di dischi. Non basare un'architettura destinata a conservare anni di cronologia delle VM sul prezzo odierno del provider.
Il server remoto diventa più interessante con l'aumentare del volume dei ripristini e degli accessi ripetuti, a condizione che sede e hardware rimangano affidabili. Il cloud è più interessante quando il repository è utilizzato principalmente per scritture una tantum, viene ripristinato raramente e il valore di evitare un altro sistema fisico è elevato.
Il test dei ripristini conta più dell'etichetta della destinazione di backup
Un server remoto può guastarsi senza dare segnali evidenti a causa di dischi difettosi, credenziali obsolete, sincronizzazioni interrotte o metadati delle VM mancanti. Lo storage a oggetti nel cloud può presentare problemi operativi dovuti a credenziali scadute, software del repository incompatibile, chiavi di crittografia dimenticate o ipotesi sui tempi di recupero mai verificate.
La documentazione di ripristino di restic consiglia di utilizzare il ripristino di uno snapshot completo anziché il solo accesso in modalità esplorazione per i recuperi di grandi dimensioni. Il principio vale indipendentemente dalla destinazione: esegui una vera esercitazione di ripristino di una VM, non limitarti a elencare il repository.
Il confronto sul ripristino di ZimaSpace relativo alle dipendenze dal sistema host per il ripristino dello storage virtualizzato è un utile approfondimento. Smetti di confrontare le destinazioni quando un'architettura soddisfa, in base a test documentati, l'RTO, il requisito di isolamento e il budget di manutenzione previsti.
Scegli la destinazione che rende banale il peggior ripristino accettabile
Scegli un server di backup remoto quando i ripristini di grandi VM devono iniziare senza il ritardo degli archivi del provider, apprezzi una stretta integrazione con lo stack di backup e sei disposto a mantenere un secondo sistema fisico e una seconda sede.
Scegli lo storage a oggetti nel cloud quando la separazione geografica e l'eliminazione della manutenzione dell'hardware remoto valgono più del massimo controllo e quando il volume di ripristino previsto è compatibile con il modello di accesso del provider e con la tua connessione Internet.
Per le VM domestiche critiche, può essere giustificato un approccio ibrido: punti di ripristino recenti su un server remoto pronto all'uso e generazioni immutabili più vecchie nello storage a oggetti. Aggiungi questa complessità solo quando i due livelli proteggono requisiti di RTO o di guasto realmente diversi.
Prodotti consigliati
Confronti tra prodotti
Altro da leggere
Docker vs macchina virtuale per Plex: quale modalità di distribuzione fa al caso tuo?
Un verdetto condizionale sulla distribuzione di Plex tramite Docker, macchine virtuali o Docker all’interno di una macchina virtuale, basato su requisiti operativi condivisi.
8 GB vs 16 GB vs 32 GB di RAM per Plex: quale livello è più adatto al tuo carico di lavoro?
Scegli 8 GB per un Plex essenziale, 16 GB per app condivise di media entità oppure 32 GB per VM e spazi di lavoro...
L'accelerazione hardware dedicata offre a Plex un vantaggio significativo?
L’accelerazione hardware è vantaggiosa per le transcodifiche ripetute supportate; l’uso della sola CPU resta valido per la riproduzione diretta, le conversioni occasionali e le...
