soluzione di backup abilitata per btrfs


14

Con btrfs che ha colpito la produzione in Oracle EL 14th questo mese (insieme a lavorare con fsck e scrubbing da Linux 3.2) stavo pensando di ridisegnare la mia attuale soluzione di backup per utilizzarla. Si noti che sto pensando di farlo per piccole quantità di dati, meno di 10 TB, che è abbastanza statico (meno dell'1% è cambiato giornalmente). In breve una soluzione di backup SMB / SOHO.

Cosa dovrebbe fare il backup:

  1. eseguire un'istantanea LVM di ext [234] / XFS / JFS sul server di produzione
  2. rsync/ trasferisce i dati modificati su btrfs sul server di backup
  3. istantanea del filesystem btrfs
  4. rilasciare vecchie istantanee quando lo spazio libero si sta esaurendo

Professionisti:

  • Tutti i file facilmente disponibili, nessuna decompressione o montaggio in loop necessari
  • Le istantanee passate sono anche facilmente disponibili ...
  • ... così posso condividerli come condivisioni Samba di sola lettura (con supporto per la copia shadow)
  • Le snapshot occupano una quantità minima di spazio grazie a copy-on-write (l'istantanea senza modifiche richiede letteralmente pochi KiB su disco)
  • Elevata coerenza del backup: checksum sui file, pulizia di tutti i dati e ridondanza integrata

Domande:

  • Esiste una soluzione di backup (in forma di Bacula, BackupPC, ecc.) Che è o può essere facilmente resa consapevole del file system copia-su-scrittura?
  • O dovrò usare la rsyncsoluzione domestica ?
  • Cosa fanno le persone con box ZFS dedicati al backup per eseguire il backup dei loro computer Linux?

Non ci vedo cons! Uno di questi sarebbe che le istantanee di Btrfs sono equivalenti solo ai backup incrementali (nessuna copia fisica per backup del file sul disco). Quale potrebbe essere importante quando si affrontano problemi di superficie del disco. Si noti che è possibile forzare una duplicazione con il supporto RAID1 nativo incluso in Btrfs.
vaab,

1
@vaab: questo è un pro- più di due copie non sono realmente necessarie se hai checksum e attivamente freghi l'FS, tre probabilmente arriveranno con il supporto RAID6. Come ho già detto, è una configurazione per un sistema di backup dedicato, non copie di "backup" all'interno di FS su un singolo computer. Sarebbe "RAID non è backup" e "Istantanee non sono backup". cp -ae lo rsyncsono ...
Hubert Kario,

Sto anche considerando di eseguire il backup su btrfs, ma stavo solo pensando rsync -a --delete /home/user /mnt/butterfs/backups/ && snapper create: a parte la creazione di un'istantanea dopo il backup, cosa intendi con COW-aware?
unhammer,

1
@unhammer: usando rsyncsenza --inplaceotterrai più copie degli stessi dati nel file system remoto. (rsync normalmente copia i dati in un file nascosto temporaneo e poi li sposta sul vecchio file, con un file system Copy-On-Write ottieni due copie su dati invariati in questo modo)
Hubert Kario

Risposte:


5

Ho fatto qualche ricerca approfondita nell'ultima settimana per qualcosa di simile. Non ho trovato soluzioni per fare tutti e 4 i passaggi. Esistono numerosi blog di utenti domestici che provano il tipo di backup ' rsync to btrfs ' e tutti i principali wiki di Btrfs descrivono come eseguire le istantanee di Btrfs.

Ci sono anche alcune persone che stanno tentando modi diversi di ruotare le istantanee di Btrfs . Tuttavia, sei la prima persona che ho visto che vuole ruotare le istantanee in base allo spazio su disco. Sto giocando con btrfs-snap me stesso che crea una serie di istantanee orarie, settimanali e mensili ed è bello e semplice.

Il progetto Dirvish sembra soddisfare molte delle tue esigenze. Alcuni sviluppatori stanno tentando di integrare Dirvish con Btrfs . Tuttavia, il progetto Dirvish sembra un po 'bloccato .

A questo punto, sei davanti alla curva.


Bene, voglio solo una soluzione di backup indolore come BackupPC: quando lo spazio su disco è basso, cancella solo i vecchi dati (vecchie istantanee). Mentre temevo di essere davanti alla curva, non è che ZFS non sia stato con noi negli ultimi anni ...
Hubert Kario,

3

Secondo Avi Miller (il suo discorso durante LinuxConf.AU) è in fase di elaborazione un invio / ricezione di btrfs. Sarà più veloce di rsync poiché non è necessario attraversare le directory per trovare le modifiche ai file .. Non so se ci sia ancora una data di rilascio prevista.

Esiste, tuttavia, un'utilità integrata in btrfs-progs che elenca tutti i file che sono stati modificati tra istantanee / ecc. Sottovolume btrfs find-new


2
Voglio fare il backup su btrfs, non da ...
Hubert Kario,

2

Sto lavorando su un sistema di backup del sistema operativo simile a BackupPC. Ci ho pensato. Ciò che mi ha impedito di implementare effettivamente è che non è possibile stabilire un collegamento fisico tra sottovolumi. È inoltre possibile creare solo istantanee di sottovolumi -> Un sottovolume per client di backup. Pertanto, la funzionalità di deduplicazione a livello di file non può coesistere con questo approccio. E quella deduplicazione a livello di file di solito consente di risparmiare molto spazio. Vuoi eseguire il backup di un solo server?

Se btrfs aveva una deduplicazione a livello di blocco, questo problema può essere probabilmente evitato, ma di solito è anche insopportabilmente lento ...

Quindi un tale approccio comporterebbe ovviamente una stretta integrazione con un filesystem (btrfs), quindi questa dovrebbe essere una funzionalità opzionale.

Lo sto chiedendo perché sto pensando di aggiungere una simile funzionalità di mucca, ma non so se dovrei a causa degli svantaggi elencati sopra.

Modifica: UrBackup supporta i backup come descritto nella domanda ora con kernel Linux> = 3.6 (con supporto reflink cross-volume). Guarda come configurarlo.


1
la copia reflink cross-subvolume (un semi-hardlink creato da cp --reflink) è già implementata o verrà implementata nel prossimo futuro. La deduplicazione online in FS è lenta (lessfs) o necessita di enormi quantità di RAM (ZFS), quindi a seconda di ciò sarebbe davvero una cattiva funzionalità nel software di backup. Ad ogni modo, il software di backup orientato a btrfs avrà un vasto pubblico, dopotutto dovrebbe essere il prossimo ext3.
Hubert Kario,

Ancora una cosa: è possibile aggirare questo problema mantenendo tutti i server in un sottovolume: è possibile ricollegare la copia tra di loro (per eseguire la deduplicazione) preservando allo stesso tempo la capacità di istantanea. Devi solo creare un'istantanea dopo aver eseguito la deduplicazione, puoi comunque eseguire l'istantanea dopo aver eseguito il backup di un solo server! I backup non occuperanno più spazio se si eseguono i backup uno alla volta. In alternativa, è possibile eseguire il backup di tutti i server, della deduplicazione e solo successivamente dell'istantanea. In questo modo è possibile eseguire il backup di pochi server contemporaneamente.
Hubert Kario,

Hai ragione. Non ci ho pensato. Per comodità, puoi quindi collegare simbolicamente alle istantanee giuste in un altro volume. Ho anche visto una patch per hardlink cross-volume (o --reflink) ma non sembrava averlo fatto / o lo farà diventare mainline. Lo esaminerò davvero! Ora probabilmente fai i tuoi backup su ssh. Il mio progetto è specializzato per le reti locali ... (rilevamento automatico e così via)
UrOni

Sì, la patch è viva e funzionante, sfortunatamente non nella mainline, non so perché. Sto cercando di infastidire Chris Mason al riguardo. Per quanto riguarda il tuo progetto, sentiti libero di farmi una battuta, sarò lieto di testarlo (tempo permettendo). Sembra sicuramente interessante.
Hubert Kario,

Alla fine quella patch è arrivata nel kernel 3.6 della mainline Linux. Con il reflink cross-device in realtà non è stato poi tanto lavoro. Ho scritto qui al riguardo: urbackup.org/blog/?p=83 Il codice è nel ramo "successivo" nel repository git. Attualmente lo sto provando.
UrOni,

1

La pagina wiki di btrfs " Usa casi " elenca alcuni strumenti: SnapBtr , Snapper, btrfs-time-machine, UrBackup.

C'è una proposta per uno strumento integrato chiamato autosnap :

Usando la funzione autosnap, puoi configurare btrfs per scattare istantanee regolari o basate su eventi e gestire ulteriormente le istantanee automaticamente.

Autosnap non riguarda solo lo snapshot, ma anche la gestione degli snapshot creati, a partire da ora è possibile configurare autosnap per eliminare gli snapshot in base allo spazio utilizzato dal filesystem.

Tuttavia, a partire da ottobre 2013, il wiki afferma che "La funzionalità di autosnap non è attualmente inclusa nella versione upstream di btrfs".


1

Ho avuto frustrazioni simili, quindi ho finito per creare alcuni script che sto chiamando snazzer . Insieme offrono snapshot, potatura, misurazione e trasporto via ssh (ma ad oggi possono anche inviare / ricevere da / verso filesystem locali). Le misurazioni sono solo rapporti di sha512sum e firme PGP di percorsi di istantanee. Non è del tutto pronto per il rilascio, ma mi piacerebbe ricevere feedback se qualcuno ha il tempo di esaminarlo in questa fase iniziale.

CLI-solo a questo punto, ma ho preso un po 'di tempo per rendere più facile da usare su sistemi con molti btrfs sottovolumi - in genere ho sottovolumi separate per /var/cache, /homee così via, che potrebbero dover essere esclusa dalla snapshotting o hanno più / meno programmi di potatura aggressivi.

Temo che l'algoritmo di potatura prenda decisioni sulla presenza dell'insieme di istantanee e delle loro date, non c'è nulla che continui a potare fino a quando non viene soddisfatto un vincolo di utilizzo del disco - quale si elimina per primo? Ridurre prima il numero di ore o i giorni? Forse far cadere il più vecchio, ad es. yearlies? Distribuzioni diverse avranno priorità diverse; e non posso sapere se questo è l'unico livello di backup (nel qual caso non dovresti eliminare i backup più vecchi in caso di obbligazioni legali / assicurative), o solo uno intermedio (nel qual caso probabilmente hai quegli annuari archiviati in un posto sicuro altrove).

Aggiungerò il supporto ZFS e / o l'interoperabilità a un certo punto; è scritto principalmente in shell posix-ish e perl a causa di un forte desiderio di dipendenze "zero" al momento, spero di avere un'implementazione alternativa di Python più pulita mantenuta in parallelo a un certo punto.


a meno che la tua FS non sia molto grande e spesso cambi, c'è ben poca differenza tra mantenere un'istantanea di un mese fa e solo 1 al giorno dell'ultima settimana rispetto a uno al giorno per l'intero mese - btrfs dovrà memorizzare la differenza tra lo stato attuale e quello del mese fa - tengo solo i quotidiani, ma poiché è compresso e diffuso posso mantenerli facilmente per un anno e mezzo indietro - lasciando cadere le garanzie più vecchie per liberare almeno un po 'di spazio
Hubert Kario

Bene, ho un numero non banale di VM di cui tenere traccia, alcune con file transitori di grandi dimensioni (ad esempio istantanee con estensioni uniche) che, come hai suggerito, possono trarre vantaggio dalla potatura di istantanee intermedie. Quindi, mentre è vero che gli intermedi di potatura non liberano tanto il disco quanto il rilascio del più vecchio, cosa posso dire ... mantenere solo il numero minimo di istantanee e farlo con il filesystem COW come btrfs sembra essere tanto efficiente quanto capisco, ma mi rendo conto che c'è di più nella scelta di una soluzione adeguata di così :)
csirac2

@ csirac2 stai mantenendo snazzer? Sto cercando questo tipo di soluzione. Sono interessato a snazzer se viene attivamente mantenuto. GitHub non sembra mostrare attività recenti ...
MountainX-for-Monica

@MountainX Quando non ho ricevuto molti feedback iniziali su Snazzer, ho perso l'entusiasmo. Quando ho iniziato a scriverlo, c'erano davvero solo lo snapper di OpenSUSE e una manciata di script shell / python che fluttuavano per automatizzare btrfs. Quando sono arrivato a condividerlo con il mondo, sono apparse molte altre opzioni, e direi che btrbk sembra avere molto slancio (la mancanza di test automatici [forse risolti ora?] Riguardava però). Se dovessi rifare tutto, probabilmente avrei collaborato con l'autore sanoid per aggiungere lì la compatibilità di btrfs. Interessato ad ascoltare i tuoi pensieri.
csirac2,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.