Soluzione 1:
Quindi vuoi eseguire il backup di tutta la tua unità senza tutti quei brutti errori e anche filtrare tutte le /proc e altre cartelle temporanee?
Un'opzione è quella di montare la cartella root su un'altra cartella all'interno del filesystem, come questa:
$ 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 sull'unità di backup utilizzando lo standard cp o rsync . Qualcosa sulla falsariga di:
cp -R /mnt/drive /mnt/backupdrive
Questo risolve entrambi i tuoi problemi citati:
- Non si entra in 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)
Soluzione 2:
In Linux tutto è un file. È possibile tramite rsync, ma ci sono cose di cui essere consapevoli, che sono (nella migliore delle ipotesi) difficili da aggirare.
Dovresti pensare prima alla replica, specialmente per i database. Inoltre, questa è una buona idea per impostare un proxy/bilanciamento del carico davanti al tuo server primario, in modo da poter passare facilmente avanti e indietro con i tuoi 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, stesso layout hdd e così via. Tutto ciò che differisce implica la necessità di modifiche alla configurazione del sistema.
ad esempio, se si dispone di due porte eth, assicurarsi che la configurazione di rete, il firewall e così via corrispondano al nome dell'interfaccia su entrambi i server e, nel caso in cui sia diverso, è necessario modificare la configurazione dopo rsync o modificare il nome del dispositivo sul secondo server (di destinazione).
Lo stesso con il layout delle partizioni. Dovresti creare le stesse partizioni del tuo server principale, ma se le crei da zero finirai con UUID diversi, quindi dovrai cambiare fstab, grub, mdadm (se è coinvolto soft-raid) e così via .
Ma ci sono anche molte cose che potrebbero andare storte, come i database, che possono essere incoerenti se non vengono fermati in precedenza (prima di eseguire rsync).
La migliore strategia sarà quella di preparare prima l'hardware e il filesystem (partizioni) - in modo che corrispondano alla configurazione del server primario. Quindi montare partizioni vuote tramite un sistema intermedio (come un live CD con ssh-server installato temporaneamente). Crei /proc, /dev, /sys vuoti e poi rsync il resto, in questo modo:
rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/
Quindi devi 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 principale), quindi spegnerlo, montarlo tramite un altro sistema temporaneo (come live cd), 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 cosa hai effettivamente su questo server, qual è la tua configurazione, rete e configurazione hardware. E alla fine potrebbe essere davvero difficile o impossibile farlo senza notevoli tempi di inattività.
Soluzione 3:
Quello che vuoi veramente è il ripristino. Qualunque cosa tu faccia, devi ripristinarla e testarla regolarmente.
Linode ha un servizio di backup. Gli snapshot possono essere acquisiti in base a una pianificazione predefinita limitata o con un'API.
Un vantaggio dei backup basati su snapshot è che offrono un punto preciso nel tempo, poiché i dati non cambiano mentre viene eseguita una copia. Le istantanee possono anche essere facilmente ripristinate su un host diverso, in questo caso un nuovo Linode.