raccomandazioni per un'efficiente soluzione di backup remoto fuori sede di VM

Sto cercando consigli per il backup dei miei attuali 6 vm (e presto raggiungerò i 20). Attualmente sto eseguendo un cluster proxmox a due nodi (che è una base debian usando kvm per la virtualizzazione con un front-end web personalizzato da amministrare). Ho due scatole quasi identiche con le schede madri amd phenom II x4 e asus. Ciascuno ha 4 hdd sata2 da 500 GB, 1 per il sistema operativo e altri dati per l'installazione di proxmox e 3 usando mdadm + drbd + lvm per condividere 1,5 TB di spazio di archiviazione tra le due macchine. Montare immagini lvm su kvm per tutte le macchine virtuali. Al momento ho la possibilità di effettuare trasferimenti in tempo reale da una macchina all'altra, in genere in pochi secondi (ci vogliono circa 2 minuti sul più grande vm che esegue win2008 con m $ sql server). Sto usando l'utilità vzdump integrata di proxmox per scattare istantanee di vm ' se archiviati su un disco rigido esterno in rete. Ho quindi il servizio jungledisk (usando rackspace) per sincronizzare la cartella vzdump per il backup remoto fuori sede.

Va tutto bene e dandy, ma non è molto scalabile. Per uno, i backup stessi possono richiedere fino a poche ore ogni notte. Con i trasferimenti incrementali a livello di blocco di jungledisk, la sincronizzazione trasferisce solo una piccola parte dei dati fuori sede, ma ciò richiede ancora almeno mezz'ora.

La soluzione molto migliore sarebbe ovviamente qualcosa che mi permetta di prendere istantaneamente la differenza di due punti temporali (dire cosa è stato scritto dalle 6 alle 7), comprimerlo, quindi inviare quel file di differenza al server di backup che trasferirà immediatamente al archiviazione remota su rack. Ho esaminato un po 'zfs ed è la capacità di inviare / ricevere. Questo accoppiato con una pipe dei dati in bzip o qualcosa del genere sembrerebbe perfetto. Tuttavia, sembra che l'implementazione di un server Nexenta con zfs richiederebbe essenzialmente almeno uno o due più server di archiviazione dedicati per servire volumi di blocchi iSCSI (tramite zvol's ???) ai server proxmox. Preferirei mantenere l'installazione il più minimale possibile (cioè NON avere server di archiviazione separati) se possibile.

Ho anche letto brevemente di zumastor. Sembra che potrebbe anche fare quello che voglio, ma sembra aver bloccato lo sviluppo nel 2008.

Quindi, zfs, zumastor o altro?

Questo potrebbe non essere possibile nella tua situazione, quindi spero di non essere votato in questo caso, ma potrebbe essere più efficiente cambiare la tua strategia di backup. Se si esegue il backup di dati specifici anziché delle istantanee delle macchine virtuali, i backup verranno eseguiti molto più rapidamente e sarebbe più semplice acquisire le modifiche.

A seconda delle macchine virtuali e per cosa vengono utilizzate, è possibile semplicemente fare in modo che eseguano il backup dei dati nel punto in cui vengono archiviate le istantanee quotidianamente (o qualsiasi programma sia appropriato), quindi JungleDisk può eseguire il backup dei soli dati. Ciò trasferirebbe in modo più efficiente i file modificati e ridurrebbe lo spazio richiesto per i backup e il tempo necessario. Inoltre, puoi comunque scattare istantanee da conservare e farlo molto meno spesso (settimanalmente, ad esempio).

In questo caso, è sempre possibile visualizzare una nuova macchina virtuale e ripristinare i dati oppure utilizzare un'istantanea più vecchia per ripristinare la macchina virtuale, quindi utilizzare il backup dei dati per ripristinare il punto più recente.

Se stessi eseguendo backup fuori sede, sceglierei le seguenti opzioni:

(a) script di shell che esegue la copia di SCP sul server remoto, in questo modo è possibile aggiungere un processo cron che esegue automaticamente lo script che crea il backup. Inoltre puoi farlo in modo che crei un file di archivio temporaneo prima di trasferire effettivamente i file risparmiando così la larghezza di banda non trasferendo durante il gziping del davanzale.

o

(b) Installa uno strumento di gestione del server come Webmin e ottieni backup automatici. Attualmente sto cantando questo sui miei server di produzione in questo momento senza problemi, funziona perfettamente. Consiglierei anche cloudmin (a pagamento) per la gestione di molti VM in quanto fornisce una soluzione tutto in uno.

alcuni link extra:

http://www.debianhelp.co.uk/backup.htm

http://ubuntuforums.org/showthread.php?t=35087

Spero che ti aiuti, RayQuang

potresti dare un'occhiata al backuppc.

backuppc può funzionare su rsync che esegue una copia incrementale.

inoltre puoi facilmente scrivere una lista nera di cartelle che non devono essere salvate. Ad esempio: temp / / tmp .garbages / ...

http://backuppc.sourceforge.net/

backuppc ha un'interfaccia web pulita che consente di scaricare alcune parti di un backup direttamente come file zip. Può essere monitorato da nagios usando check_backuppc.

Non sono sicuro di quanti cambiamenti architettonici stavi pianificando di apportare per aumentare la tua scalabilità. Tuttavia, se si fosse aperti al passaggio da una piattaforma VM all'altra, è possibile consultare VMWare.

Esistono molte buone soluzioni di backup VMWare, ho usato personalmente VzionCore. È quindi possibile eseguire alcune operazioni intuitive con le istantanee e il ripristino temporizzato. Esiste persino la possibilità di eseguire il failover su un sito remoto.

zfs lo fa alla grande, lo hai già detto sapendo che però e il rovescio della medaglia di non funzionare alla grande sulla scala dei 2 server. Inoltre non ti darà il failover DRDB, cioè Nexenta sarà un singolo punto di errore.

Puoi provare a provare VirtualBox su OpenSolaris o NexentaCore, ma non è così semplice come ProxMox + DRDB, quindi puoi riutilizzare i tuoi computer esistenti.

Se si misurano le modifiche e le si trovano abbastanza in basso, è possibile provare DRDB con un terzo mirror fuori sede: funzionerà solo se il numero di scritture è estremamente basso nelle macchine virtuali.

Steve Radich - Hosting Windows e prestazioni SQL dal 1995 - http://www.BitShop.com/Blogs.aspx

Gestisco un cluster proxmox di grandi dimensioni e devo suggerire di cambiare la strategia di backup lontano dai backup incorporati in stile snapshot di vzdump, che impiegano anni, sono sempre pieni, quindi di grandi dimensioni e rendono il ripristino di singoli file estremamente lungo.

Considera una soluzione di backup di file "in guest" di cui ce ne sono molti. Backuppc, Urbackup, bacula, amanda ecc ...

Sarà molto più veloce, consumerà molto meno spazio e sarà molto più facile ripristinare file specifici.

Penso di aver trovato la risposta definitiva alla mia domanda:

BUP https://github.com/bup/bup

Caratteristiche:

• Utilizza un algoritmo di checksum continuo (simile a rsync) per dividere file di grandi dimensioni in blocchi. Il risultato più utile di questo è che è possibile eseguire il backup di enormi immagini di dischi, database e file XML di macchine virtuali (VM) in modo incrementale, anche se in genere sono tutti in un unico file di grandi dimensioni e non utilizzare tonnellate di spazio su disco per più versioni.

  Utilizza il formato packfile da git (il sistema di controllo della versione open source), quindi puoi accedere ai dati memorizzati anche se non ti piace l'interfaccia utente di bup.

  A differenza di Git, scrive direttamente i file di pacchetto (invece di avere una fase di raccolta / reimballaggio dei rifiuti separata), quindi è veloce anche con quantità di dati enormemente gratuite. I formati di indice migliorati di bup ti consentono anche di tenere traccia di molti più nomi di file di git (milioni) e di tenere traccia di molti più oggetti (centinaia o migliaia di gigabyte).

  I dati vengono "automagicamente" condivisi tra backup incrementali senza dover sapere quale backup si basa su quale altro - anche se i backup vengono eseguiti da due computer diversi che non si conoscono nemmeno. Dici semplicemente a bup di eseguire il backup delle cose e si risparmia solo la quantità minima di dati necessari.

  È possibile eseguire il backup direttamente su un server bup remoto, senza bisogno di tonnellate di spazio temporaneo su disco sul computer sottoposto a backup. E se il backup viene interrotto a metà, la corsa successiva riprenderà da dove si era interrotto. Ed è facile configurare un server bup: basta installare bup su qualsiasi macchina a cui si abbia accesso ssh.

  Bup può utilizzare la ridondanza "par2" per ripristinare backup danneggiati anche se il disco ha settori danneggiati non rilevati.

  Anche quando un backup è incrementale, non devi preoccuparti di ripristinare il backup completo, quindi ciascuno degli incrementali a sua volta; un backup incrementale si comporta come se fosse un backup completo, richiede solo meno spazio su disco.

  Puoi montare il tuo repository bup come filesystem FUSE e accedere al contenuto in quel modo, e persino esportarlo su Samba.

Modifica: (19 agosto 2015) E viene ancora un'altra grande soluzione ancora migliore: https://github.com/datto/dattobd

Permette lo snapshot live, essenzialmente fornendo funzionalità come COW a qualsiasi vecchio file system normale in Linux.

Modifica: (15 luglio 2016) E anche un'altra ottima soluzione che fa esplodere bup dall'acqua: https://github.com/borgbackup/borg

È particolarmente meglio di bup in potatura. Sembra avere un ottimo supporto per la compressione, la crittografia e la deduplicazione efficiente. dattobd + borg ftw !!!