Come eseguire il backup di un server Linode in esecuzione?


21

Vogliamo fare un backup di tutto sul nostro server Debian, che è in esecuzione in remoto dall'altra parte del mondo (ospitato da Linode), senza spegnerlo.

Questo sistema esegue shell, e-mail, XMPP / prosody e web, con un paio di semplici configurazioni nginx.
Vogliamo eseguire il backup dei file relativi a queste cose solo per sicurezza. Ad esempio, i file che gli utenti hanno archiviato nelle loro home directory.

Non è necessario copiare esattamente il programma di installazione esistente in ogni singolo file / etc; invece, il motivo per cui stiamo anche eseguendo il backup in primo luogo è che possiamo spostare tutto in una nuova installazione (la versione più recente di Debian è ancora su Linode).

Vedo che Linode offre un servizio di backup. Ma a lungo termine abbiamo anche bisogno dei nostri backup, qui, nel caso in cui vadano sotto o succede qualcosa di strano.

Il motivo per cui esiste questa domanda è che quando ho provato a fare backup in passato ho continuato a commettere uno di questi due errori:

  • Sono andato "OK, copierò /tutto e tutto sotto di esso" e poi mi sono bloccato in uno strano ciclo infinito o perché l'unità su cui stavo copiando era montata su / media / backup e si stava copiando ricorsivamente [obv quel problema specifico non applicabile qui dal momento che faremo il backup su rsync o simili] o si è bloccato nel tentativo di copiare alcune cose "vive" in / proc o / var o altro, come cercare di tenere il passo con i registri in continua evoluzione, o
  • Sono andato "OK, prenderò solo il minimo di ciò di cui abbiamo bisogno ... hmm, le directory home di tutti e le nostre directory dei server web (tutte sotto /var) e prendiamo una copia di /etctutte le vecchie mail in / var / vmail "e poi invariabilmente ho rovinato i permessi dei file o i timestamp (assicurandomi di non eseguire il backup dei file unix su un disco FAT questa volta) o ho dimenticato qualcosa (" oh, spara, avevo alcuni script personalizzati in / usr / local / bin che non ho mai archiviato altrove, ho dimenticato di prenderli, suppongo che ora non ci siano più ").

Quindi la copia obv dell'intero disco in verticale ha portato a insidie ​​e la copia selettiva delle directory ha portato a insidie. Voglio sapere come farlo nel modo giusto.

La domanda di errore del server Cosa è necessario per un sistema di backup completo? copre la filosofia e le buone pratiche, ma sto cercando questi dettagli più specifici di:

  • Quali directory devo copiare e quali escludo (dato che si tratta di un sistema attualmente in esecuzione e che fornisce wiki, chat XMPP, e-mail - con nuovi messaggi in arrivo mentre il processo di copia è in esecuzione)
  • Quali attributi di file quali timestamp, proprietario e gruppo devo presentare e come posso farlo? ← Penso di poter rispondere da solo a questa metà della domanda con qualcosa come ... um ... rsync -HXazPenso che sia una buona opzione per noi? L' -zobv non è in realtà correlato alla domanda che è "cosa conservo"

Molti dei consigli di backup che vedo, come l'utilizzo dd, sembrano presupporre che l'unità sia smontata e non in uso. Ma non mi è dovuto escludere "vivente" directory come / proc e alcune delle sottodirectory / var (tuttavia, alcune delle cose in / var so che sicuramente facciamo necessità di mantenere) e / montaggio? Cos'altro devo pensare in questa situazione? Quindi immagino di poterlo snarf con rsync e usando un mucchio di --excludebandiere.

O ci sono idee migliori, specialmente quelle amichevoli FOSS?


Ho capito che questa domanda sembra estremamente semplice, ma avendo eseguito questo tipo di sistemi per così tanto tempo, l'ho incasinato ancora e ancora e non mi sono mai davvero lamentato di come farlo bene
Sandra,


Per quello che vale, cp -r -amanterrà il maggior numero possibile di attributi di file durante la copia dei file (in base a ciò che supporta il filesystem di destinazione). Il -aflag indica cpdi conservare gli attributi. Per la copia su una rete o tramite un filesystem che non supporta gli attributi richiesti, tar -cha sempre funzionato per me, anche se credo che ci siano alcuni casi limite che non copre e in particolare credo che tardipenda per impostazione predefinita dai nomi utente corrispondenti su entrambi i sistemi. Detto questo, ho copiato un intero sistema Linux (non montato) usando tarsenza problemi apparenti.
Micheal Johnson,

Inoltre c'è qualche motivo particolare per cui è necessario copiare il sistema dal vivo?
Micheal Johnson,

Utilizzare il servizio snapshot di linode?
ivanivan,

Risposte:


15

Quindi vuoi fare il backup di tutto il tuo disco senza tutti quegli errori cattivi e filtrare anche tutte le cartelle / proc e altre cartelle temporanee?

Un'opzione è montare la cartella principale su un'altra cartella all'interno del filesystem, in questo modo:

$ cd /mnt
$ mkdir drive
$ mount --bind / drive

Questo ti darà tutti i file presenti sul tuo disco che non sono considerati temporanei (come le cartelle / proc o / sys).

Ora che hai una visione chiara della tua cartella principale, puoi semplicemente copiarla sul tuo disco di backup usando standard cpo rsync. Qualcosa sulla falsariga di:

cp -R /mnt/drive /mnt/backupdrive

Questo risolve entrambi i problemi citati:

  • Non ricorrere alla ricorsione, perché il disco di backup non è montato all'interno dell'unità (punto di vista)
  • non ti perdi nessun file importante, perché li stai prendendo tutti

Vedi anche: man mount (8)


6
Attenzione, con questa soluzione è possibile copiare i file in fase di scrittura, come i database. Consiglio di eseguire uno script per scaricare il database in un file separato prima di copiarlo. Ad esempio per MySQL puoi usare mysqldump.
Marco Martinelli,

10

In Linux tutto è un file. È possibile tramite rsync, ma ci sono cose di cui tenere conto, che sono (nella migliore delle ipotesi) difficili da aggirare.

Dovresti prima pensare alla replica, specialmente per i database. Inoltre, è una buona idea impostare il proxy / bilanciamento del carico davanti al server primario, in modo da poter passare facilmente avanti e indietro con i server primario e mirror durante la transizione.

A livello hardware, la situazione migliore sarà quella di avere un server mirror-like su un altro lato, con lo stesso numero di porte ethernet, lo stesso layout hdd e così via. Tutto ciò che differisce implica la necessità di modifiche alla configurazione del sistema.

cioè se hai due porte eth, vuoi assicurarti che la configurazione di rete, il firewall e così via corrispondano al nome dell'interfaccia su entrambi i server, e nel caso differisca devi cambiare la configurazione dopo rsync o cambiare il nome del dispositivo sul secondo server (destinazione).

Lo stesso con il layout delle partizioni. Dovresti creare le stesse partizioni del tuo server primario, ma se le crei da zero finirai con UUID diversi, quindi dovrai cambiare fstab, grub, mdadm (se è coinvolto il soft-raid) e così via .

Ma ci sono anche molte cose che potrebbero andare storte, come i database, che possono essere incoerenti se non precedentemente interrotti (prima di fare rsync).

La migliore strategia sarà prima preparare hardware e filesystem (partizioni) - in modo che corrispondano alla configurazione del server primario. Quindi montare i parititoni vuoti tramite il sistema intermedio (come il live CD con ssh-server installato temporaneamente). Si crea vuoto / proc, / dev, / sys e quindi si risincronizza il resto, in questo modo:

rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/

Quindi è necessario installare grub sul dispositivo e lavorare sulla configurazione, per renderlo avviabile, modificare la configurazione di rete, fstab e altre cose menzionate in precedenza.

Puoi anche provare a installare un nuovo sistema (con la stessa versione che stai utilizzando sul tuo server primario), quindi spegnerlo, montarlo tramite un altro sistema temporaneo (come cd live), quindi sostituire qualsiasi cosa diversa da / proc, / sys, / dev e / boot con rsync.

Ma è solo un'idea generale. Le cose potrebbero complicarsi a seconda di ciò che hai effettivamente su questo server, qual è la tua configurazione, rete e configurazione hardware. E alla fine della giornata potrebbe essere davvero difficile o impossibile farlo senza tempi di inattività evidenti.


Re database: se sono presenti le astrazioni del filesystem appropriate (ad es. Un LVM), è possibile eseguire uno snapshot coerente dell'unità senza eseguire la replica completa del DB. Tuttavia, ciò richiede che il database sia kill -9sicuro, altrimenti potrebbe non riuscire a recuperare. Un buon database dovrebbe gestire quella situazione, ma un numero sorprendente di prodotti non lo fanno (o peggio, quasi sempre si riprendono, ma falliscono una volta su una luna blu quando ne hai davvero bisogno per funzionare). Quindi, in pratica, la replica è probabilmente comunque più affidabile.
Kevin,

5

Quello che vuoi veramente sono i ripristini. Qualunque cosa tu faccia, è necessario ripristinare testarlo regolarmente.


Linode ha un servizio di backup. Le istantanee possono essere eseguite in base a una pianificazione predefinita limitata o con un'API.

Un vantaggio dei backup basati su istantanee è che offrono un punto preciso nel tempo, poiché i dati non cambiano durante l'esecuzione di una copia. Le istantanee possono anche essere facilmente ripristinate su un host diverso, in questo caso un nuovo Linode.


Non vedo nulla per garantire che quei backup funzionino ancora se, ad es. Linode fallisce.
Mark

Ho scoperto il servizio di backup di Linode durante la digitazione di una delle modifiche alla mia domanda e ne ho discusso con il mio collega e abbiamo provato. Ha risolto la nostra crisi immediata, ma cercheremo di trovare un modo per archiviare i dati anche nelle nostre case. Quindi + per aver accennato al fatto che hanno quel servizio, non ero a conoscenza quando ho pubblicato per la prima volta. Ma i ripristini hanno il seguente problema: se il nostro server è configurato in modo errato, una palla di gomme da masticare e appendini a filo, non vogliamo necessariamente ripristinarlo esattamente nello stesso stato configurato male. Vogliamo comunque i nostri dati preferiti.
Sandra,

Avevo scritto un po 'di più sull'esportazione di questo backup in un altro archivio se si adattava ai tuoi obiettivi del punto di ripristino e ai domini di errore. Ma l'ho lasciato fuori per essere breve. Un buon piano di continuità aziendale, di cui i backup fanno semplicemente parte, identifica e gestisce tali rischi.
John Mahowald,

1

Sto usando BackupPC per il mio piccolo server privato virtuale, funziona abbastanza bene. BackupPC può utilizzare rsync sotto il cofano e supporta backup completi e incrementali. Dai un'occhiata e vedi se coprirebbe le tue esigenze.


1

Esegui il tuo sistema su ZFS. Quindi puoi scattare un'istantanea atomica istantanea usando qualcosa di simile a:

# zfs snap -r tank@name-of-backup

dov'è tankil nome del tuo pool ZFS. Questa istantanea è garantita come istantanea istantanea del filesystem e di tutti i suoi filesystem figlio.

Dopo aver creato l'istantanea, è possibile trasferirla su un altro host utilizzando zfs sende ssh.


0

A mio avviso Dipende da cosa e dove si esegue il server con il comando linux interno, non è possibile, è necessario simulare / reindirizzare dati completi e librerie. Se in esecuzione su VMware e configurato correttamente, fornisce la migrazione in tempo reale. Altrimenti devi usare strumenti di terze parti. Spero che questo ti possa aiutare. Qualche riferimento in più Come si effettua un backup di un server live?

Rsync è un buon comando per sincronizzare i dati tra i server.


0

Sono disponibili 2 soluzioni, in cui non è necessario fare affidamento (più) sui bit mancanti e manca un elemento dell'elenco a causa di un elenco di controllo incompleto o forse perché è trascurato solo qualcosa di caldo.

In primo luogo, se lo sposti su una piattaforma con un maggiore controllo sulla piattaforma hardware sottostante, puoi scattare istantanee su disco di tutti i file mentre il server è in esecuzione. Ad esempio su AWS è possibile creare un'istantanea di un disco EBS e persino pagare le differenze solo quando si esegue un'altra istantanea in un secondo momento.

In secondo luogo, raccomando di creare script per l'installazione del server completo con un sistema di gestione della configurazione, come Ansible. Questo sarà

  • documentare tutto ciò che è stato configurato nel controllo del codice sorgente

  • consentono di provare a ricreare il server da backup o bare metal per assicurarsi che gli script siano aggiornati

  • ti consente di rieseguire lo script su un sistema operativo più recente, di solito con modifiche abbastanza lievi.


1
Si scopre che puoi anche fare istantanee su Linode. Vado a controllare Ansible! È un po 'un argomento secondario rispetto a ciò che inizialmente desideravo sapere, ma qualcosa del genere - e non ne avevo mai sentito parlare [voglio dire, avevo sentito parlare del dispositivo immaginario dei meravigliosi libri di Hainish] - sembra meraviglioso!
Sandra,
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.