Quali cartelle non dovrei fare il backup su CentOS?


10

Sto usando rsnapshot per iniziare il backup di un'installazione di CentOS 5.5 e ho bisogno di un elenco di cartelle che probabilmente dovrei escludere dai backup. Il server è principalmente un server Web LAMP e verrà servito al momento del backup, sebbene dovrebbe avere un volume relativamente basso. Il backup / var / lib / mysql è una cattiva idea?

Suppongo che non dovrei preoccuparmi del backup / proc, di quali altre cartelle non è necessario eseguire il backup?

Risposte:


10

Si può quasi certamente ignorare /proc, /dev, /tmpe /var/tmp.

Un buon caso può essere fatto per ignorare /var/log(e qualsiasi altra directory di registrazione), /var/cachese ce l'hai, e possibilmente porzioni di /var/db(anche se devi stare attento con /var/db: A volte vengono messe cose davvero importanti ...)

Oltre a ciò, probabilmente vorrai fare un backup, attendere qualche giorno e fare un altro per vedere cosa cambia nel tempo. Se vedi un sacco di "spazzatura" in quei backup, puoi personalizzare il tuo elenco di esclusioni con maggiore attenzione.


Dopo aver selezionato gli elementi di cui si desidera eseguire il backup e adattato gli elenchi di inclusione / esclusione, assicurarsi di eseguire un test di ripristino appropriato : prendere una macchina dal metallo nudo e passare attraverso il processo richiesto per far funzionare nuovamente i dati e il software, senza toccando la macchina originale.

Se non riesci a gestire quel ripristino con ciò di cui hai eseguito il backup, in realtà non hai un backup ...


Anche / sys dovrebbe essere ignorato.
Jmarki,

/sysè un altro buono ignorare - anche se si dispone di BIND in esecuzione in un chroot si vuole ignorare la /dev, /procecc sotto il chroot ...
voretaq7

2
Si prega di non ignorare i file di registro . Questo a meno che tu non abbia qualche altro meccanismo per recuperare i dati di cui potresti aver bisogno per scopi di debug.
Martin M.

@Server Horror - vero, se non hai configurato un syslog remoto potresti voler eseguire il backup dei log anche - L'aspetto negativo di farlo è che la rotazione dei log sembra (alla maggior parte dei software di backup) come ogni file modificato: eseguendo diverse copie di ciascun registro ruotato. Non è un problema per alcuni sistemi, un concerto in più o un giorno per server Web occupati con registri di accesso dettagliati ...
voretaq7

1

Le uniche cartelle che dovresti avere sono /var/wwwe /var/lib/mysqlper ottenere il tuo sito web e i tuoi dati. E backup /etc/httpdper ottenere la configurazione di Apache, se necessario. Vedi qui per una discussione sul backup /var/lib/mysqlrispetto all'utilizzo mysqldump.

Se è possibile utilizzare un'istantanea lvm per eseguire il backup, sarebbe ancora meglio, ma assicurarsi di distruggere l'istantanea appena possibile. Le istantanee Lvm distruggono le tue prestazioni.


5
È un buon inizio per il backup di MySQL, ma dire "Le uniche cartelle che dovresti avere" è ESTREMAMENTE pericoloso, specialmente quando non hai familiarità con l'ambiente - Potrebbero esserci elementi critici in altre posizioni (ad es. Informazioni utente / password in /etc/passwd& /etc/shadowChiavi SSH sotto /home, script personalizzati sotto /usr/local...). Generalmente è meglio creare un elenco di ciò che può essere tranquillamente escluso da un backup piuttosto che cercare di acquisire tutto ciò di cui hai bisogno con inclusioni specifiche.
voretaq7,

0

Troppe poche informazioni, scusa.

È questo un server web, un server database, un server samba, un nameserver. Dipende completamente dal tipo di servizi in esecuzione.

Di solito non eseguo il backup di tutto ciò che viene fornito dalla distribuzione (tutto ciò che proviene da un pacchetto). Le cose per cui ho i backup sono:

  • file di configurazione
  • file di registro (nel caso in cui accada qualcosa di brutto)
  • " dati " - sarebbero i file di zona per bind, ldap "dump", dump del database e quant'altro.
  • home directory se ci sono utenti umani reali che accedono ai server
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.