Backuppc

Backuppc e` un software di backup con interfaccia web (e anche da command line) che usa rsync o samba per fare il backup incrementale o totale di macchine Linux o Windows. C'e` tantissimo da dire sui vantaggi e sulle limitazioni di questo software, e non e` certo questa la sede per farlo. PRO: il sistema di pooling di backuppc permette di salvare una sola volta su disco i file uguali anche tra macchine diverse.

Installazione

Per installare Backuppc su Debian e` sufficiente installare il pacchetto "backuppc", il quale si porta dietro un mucchio di dipendenze. Deve essere usato in combinazione con Apache o Apache2, di default si installa Apache2.

Configurazione email

Di default il pacchetto di backuppc crea un alias che fa si che le mail di backuppc vadano a root. Se le si vuole mandare a qualcun altro, tipo il ricevitore degli allarmi gravi, modificare questo alias.

Configurazione

Backuppc viene installato con un utente di default per la sua interfaccia web, che ha username "backuppc" e una password generata a caso. Questa password puo` essere cambiata con il comando

htpasswd /etc/backuppc/htpasswd backuppc

L'accesso via web e` disponibile di default all'indirizzo http://<server>/backuppc/ ma è limitato solo a localhost. Per abilitarlo a tutti (o solo alla vostra lan, vedete voi) dovete modificare il file /etc/backuppc/apache.conf e riavviare Apache.

Lo storage dei files di default viene fatto in /var/lib/backuppc, se lo si vuole spostare, al momento non e` possibile farlo se non ricompilando, quindi occorrera` linkare la destinazione con un symlink, oppure montare li` dentro un eventuale disco di backup, ovvero fare un mount in bind di una directory. Ad esempio, posto che /backupdisk sia il mount point del mio disco di backup, faro`:

/etc/init.d/backuppc stop
mv /var/lib/backuppc /backupdisk
ln -s /backupdisk/backuppc /var/lib/
/etc/init.d/backuppc start

Nel file di configurazione /etc/backuppc/config.pl c'e` il parametro TopDir che dovrebbe servire a cambiare percorso di backup, ma NON va modificato, si incasina tutto.

Velocizzare rsync via ssh

Per velocizzare rsync su ssh si può impostare un algoritmo crittografico meno pesante del default. Allo stato attuale (anno 2020) sembra che il più performante sia aes128-ctr, almeno sulle CPu che supportano AES-NI. Nota che il più veloce non è detto che sia il più sicuro, anzi... quindi poniamoci anche il problema della sicurezza, a meno che non stiamo lavorando in rete locale.

Per impostare questo algoritmo in ssh (si può fare singolarmente per ogni host, quindi possiamo scegliere quali impostare in questo modo e quali no) occorre modificare la configurazione del "RsyncClientCmd" e del "RsyncClientRestoreCmd" aggiungendo "-c aes128-ctr" ai parametri di ssh. Rispetto al default, quindi, risulta così: (per backuppc versione 3.x, per la 4 e` diverso e non ho ancora verificato come impostarlo)

$sshPath -c aes128-ctr -q -x -l root $host $rsyncPath $argList+

Configurazione aggiuntiva per Debian 10 e successive / Devuan Beowulf

Nell'ultima versione di default viene negato l'accesso in http se non da localhost. Occorre quindi modificare il file /etc/backuppc/apache.conf togliendo la direttiva "Require local" e riavviare Apache2. La scelta se attivare o meno https la lascio a voi.

Rischedulare i nightly job

Backuppc esegue i suoi job di pulizia (Backuppc_Nightly) di default all'una di notte. Il che e` a mio avviso assolutamente stupido in quanto e` molto probabile che proprio in quel momento ci siano dei backup in corso, e l'accesso altamente randomico al disco contenente i backup ammazza le prestazioni del backup stesso. E` possibile modificare questo comportamento modificando il parametro WakeupSchedule nella configurazione "principale" del server (non del singolo host). Il trucco e` modificare la sequenza in modo che il PRIMO valore sia quello dell'ora alla quale vogliamo che parta il Nightly.

Per esempio, il default e`:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23

Se voglio che il Nightly parta a mezzogiorno, sposto il "12" e lo metto in testa alla sequenza:

12, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23

Eseguire funzioni di backuppc da command line

Backuppc ha un potenziale difetto: schedula i backup quando vuole lui, basandosi sulla logica di quanto tempo è passato dall'ultimo backup. Questo significa che risulta impossibile configurarlo per fare i backup full solo nel weekend, per esempio. Una possibile soluzione per ottenere questo risultato consiste nell'impostare un tempo per i full lungo (che so, 10 giorni) e poi lanciare i full a mano da cron usando BackupPC_serverMesg. La sintassi dei comandi è stata più o meno ricavata a forza di Google, e non è detto che resti stabile e valida, tuttavia questo è quanto ho raccolto.

• Lanciare un backup: BackupPC_serverMesg backup HOSTIP HOST USER 0/1 (dove 0=incrementale e 1=full , HOSTIP e HOST possono essere tutti e due il nome host e USER è backuppc a meno che non sia diversamente impostato)

• Interrompere un backup: BackupPC_serverMesg stop HOST REQ_USER BACKOFF (HOST è il nome dell'host, REQ_USER è l'utente e BACKOFF è il numero di ore prima che venga di nuovo lanciato un backup)

• Vedere lo stato di un host: BackupPC_serverMesg 'status host(HOSTNAME)'

• Vedere lo stato di tutti gli host: BackupPC_serverMesg status hosts

• Vedere lo stato dei job in corso in questo momento: BackupPC_serverMesg status jobs

• Vedere lo stato di tutto il sistema BackupPC_serverMesg status info

• Lanciare il processo di pulizia interno di backuppc: BackupPC_serverMesg BackupPC_nightly run

Se vogliamo lanciare i full la domenica, per esempio, possiamo farlo in crontab in questo modo:

# alle 10.00 di domenica faccio il backup full dell'host "mail" usando l'utente backuppc
00 10   * * 7   backuppc        /usr/share/backuppc/bin/BackupPC_serverMesg backup mail mail backuppc 1 > /dev/null

Limitare l'accesso

Backuppc e` accessibile di default tramite Apache, quindi se si possiede un web server con dei siti visibili al pubblico e si installa backuppc, anche esso (previa autenticazione via password) e` visibile su internet. Per stringere la sicurezza e` possibile limitare l'accesso a determinati gruppi di indirizzi IP. Per farlo, va modificato il file /etc/backuppc/apache.conf, aggiungendo in fondo al blocco <Directory /usr/share/backuppc/cgi-bin/> tre righe:

Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128 192.168.0.0/16

Ovviamente vanno indicate le reti che ci interessano.

Generazione delle chiavi per usare rsync su SSH

Sul server di backuppc e` opportuno generare delle chiavi per poter usare ssh come metodo di trasporto per i backup. Per farlo, occorre diventare l'utente backuppc e poi usare il comando per generare le chiavi asimmetriche. Siccome devono essere usate per un processo automatico, e` opportuno NON impostare una passphrase per le chiavi.

su - backuppc
ssh-keygen

A questo punto, la chiave generata, che si trova in ./ssh/id_rsa.pub, puo` essere copiata come chiave autorizzata all'accesso in ssh sulle macchine che dobbiamo backuppare.

Configurazione di una macchina (client) Linux con rsync su SSH

Per usare rsync ci sono due alternative: la prima e` creare un utente (non root) sulla macchina remota, dandogli il permesso di usare rsync limitatamente alla lettura e non alla scrittura, in modo da limitare i danni nel caso in cui ci fosse una violazione della macchina che gestisce i backup (e` possibile leggere i files come root, ma non scriverli).

La seconda, piu` semplice e che permette anche di fare un restore in-place, e` quella di usare direttamente l'utente root sulla macchina remota.

Versione semplice: usando root sulla macchina remota

• Installare "rsync" se non c'e` gia`
• Copiare la chiave pubblica dell'utente backuppc sul server di backup come chiave autorizzata all'accesso sulla macchina di cui vogliamo fare il backup. In pratica, questo significa che il contenuto del file /var/lib/backuppc/.ssh/id_rsa.pub (che si trova sul server di backuppc) deve essere scritto (nella macchina client) dentro a /root/.ssh/authorized_keys.
• A questo punto, provare a fare ssh dal server backuppc al client che vogliamo backuppare. Eseguendo (come utente backuppc) il comando seguente, si dovrebbe trovarsi in shell sull'altra macchina senza dover fare null'altro. La prima volta che lo eseguiamo, ci verra` chiesto ragionevolmente se vogliamo procedere con la connessione. Dobbiamo rispondere di si`, ovviamente. A questo punto chiudiamo la connessione e riproviamo, per verificare che si entri senza alcun impedimento o domanda. In totale i comandi da dare sulla macchina locale (dove gira backuppc) sono due: con il primo divento l'utente backuppc sulla macchina locale, e con il secondo faccio ssh come root sulla macchina remota (quella di cui devo fare il backup)

  su - backuppc
  ssh root@server_remoto

Se tutto ha funzionato, ora backuppc puo` lanciare il backup via ssh e rsync.

Versione complessa: con un utente che puo` solo leggere usando rsync

• Installare "rsync" se non c'e` gia`
• Installare "sudo" se non c'e` gia`
• Creare un utente backuppc (o un nome a vostra scelta)

  adduser --disabled-password --ingroup nogroup backuppc

• Permettere a tale utente di eseguire rsync come root
  • Eseguire il comando "visudo"
  • Inserire nel file questa riga:

    backuppc ALL=(root) NOPASSWD: /usr/bin/rsync --server --sender *

• Copiare la chiave pubblica dell'utente backuppc sul server di backup come chiave autorizzata all'accesso sulla macchina di cui vogliamo fare il backup. In pratica, questo significa che il contenuto del file /var/lib/backuppc/.ssh/id_rsa.pub (che si trova sul server di backuppc) deve essere scritto (nella macchina client) dentro a /home/backuppc/.ssh/authorized_keys.
• A questo punto, provare a fare ssh dal server backuppc al client che vogliamo backuppare. Eseguendo (come utente backuppc) il comando seguente, si dovrebbe trovarsi in shell sull'altra macchina senza dover fare null'altro.

  ssh backuppc@server_remoto

• Nella configurazione dell'host dentro backuppc, la riga di comando per eseguire rsync (dentro alla configurazione dell'host, alla voce RsyncClientCmd va modificata come segue:

  $sshPath -q -x -l backuppc $host sudo $rsyncPath $argList+

Questo serve a inserire nel comando l'utente giusto (non piu` root ma backuppc) e il comando "sudo".

Questo setup e` piu` sicuro del default, pero` e` fatto in modo da permettere soltanto il backup e non il restore "in place", in quanto il comando impostato con visudo in /etc/sudoers limita la funzionalita` di rsync alla sola lettura dei dati. Se occorre usare il restore diretto sulla macchina, questo setup e` totalmente inutile, tantovale accedere direttamente come root.

Backup di una macchina locale con tar

Se si vuole fare il backup di una macchina su se` stessa, si può usare tar e non rsync su ssh. Per farlo, occorre pero` modificare la configurazione di backuppc per poter eseguire tar come root.

NOTA BENE: non sono affatto convinto che tar risulti più efficiente di rsync su ssh su localhost, quindi forse fate prima e avete risultati migliori usando rsync anche in locale

• Installare sudo
• Eseguire visudo e aggiungere questa riga:

  backuppc ALL = NOPASSWD: /bin/tar

• modificare nella configurazione dell'host dentro backuppc i comandi di backup e restore con tar, inserendo sudo ed eliminando ssh, cosi`:

  • Alla voce TarClientCmd modificare in questo modo:

    # originale:
    $sshPath -q -x -n -l root $host env LC_ALL=C $tarPath -c -v -f - -C $shareName+ --totals
    
    # modificata:
    env LC_ALL=C /usr/bin/sudo $tarPath -c -v -f - -C $shareName --totals --one-file-system

  • Alla voce TarClientRestoreCmd modificare in questo modo:

    # originale:
    $sshPath -q -x -l root $host env LC_ALL=C $tarPath -x -p --numeric-owner --same-owner -v -f - -C $shareName+
    
    # modificata:
    env LC_ALL=C /usr/bin/sudo $tarPath -x -p --numeric-owner --same-owner -v -f - -C $shareName+

Usare un disco in XFS

Dal momento che backuppc usa un pacco di inodes, e` opportuno usare XFS che ha gli inode dinamici.

• Installare il pacchetto xfsprogs
• Partizionare il disco di backup con il tipo 83 come per ext3
• formattare con mkfs.xfs -f /dev/sdXX
• Gli do` un nome con xfs_admin -L nomevolume /dev/sdXX
• Ora lo posso montare in fstab con una riga tipo:

  LABEL=nomevolume /path      xfs     defaults        0       2

Backup di Windows

Vale la pena di ricordare che occorre fare login alla macchina windows con il dominio se necessario, tipo "dominio/utente".

Problema dei nomi UTF-8 con XferMethod "smb"

Con backupp e Samba presenti in Debian 8 (e Devuan 1), ovvero con Samba superiore alla 4.1.qualcosa, se i files o le directory sulla macchina windows da backuppare hanno nomi con caratteri superiori ai 7 bit standard, succede che backuppc si perde interi sottoalberi di directory. Nel log degli errori dentro backuppc troviamo solo errori di tipo "NT_STATUS_UNSUCCESSFUL", ma se apriamo il log completo (non solo degli errori) vedremo che prima di ogni "NT_STATUS_UNSUCCESSFUL" c'e` una riga che dice piu` o meno: tar:943 Fatal: Can't translate pathname './Documenti/buste/mav 1° trim 2015 cessaz/' to UTF-8.

Nella specifica configurazione presente in Devuan 1 (e suppongo anche in Debian 8) e` sufficiente aggiungere allo script di avvio di backuppc (/etc/init.d/backuppc) una variabile di environment che forzi il charset ad essere UTF-8 per il client samba (smbclient) che viene lanciato da backuppc. Basta aggiungere all'inizio dello script due righe con scritto

LANG=en_US.UTF-8
export LANG

e riavviare backuppc.

In questa condizione, non dovremmo piu` avere errori nella lettura dei files con nomi non-ascii 7 bit. In compenso pero` ci rimarranno in giro per l'albero dei backup (in backuppc) delle directory di nome PaxHeader contenenti uno o piu` files. Queste directory sono il modo in cui tar codifica informazioni che nel formato tar originale non possono essere codificate (guardate il "man" di un tar recente e cercate "pax"). Evidentemente la funzione tar di smbclient usa questo formato (e il tar moderno lo riconosce correttamente) ma il sistema di gestione del formato tar presente in backuppc NON sa leggere queste informazioni. Direi che non sia una cosa grave, i dati vengono comunque backuppati. Devo pero` provare a fondo se crea problemi nel restore.

Workaround per i problemi di smbclient

Ho l'impressione che l'uso di smbclient sia quantomeno instabile, specie perche` con ogni aggiornamento di samba potrebbe rompersi qualcosa. Se si deve fare il backup di macchine windows, suggerisco di pensare all'idea di montare gli share usano mount sulla macchina dove gira backuppc e poi configurare un backup con rsync "in locale".

Connettersi a winNT

WinNT è così vecchio che occorre modificare il comando di backup, aggiungendo la chiamata a un file di confg "alternativo" da usare con smbclient: -s /etc/samba/smb-client.conf. Questo vale per tutti i comandi di backup e restore, per esempio, per il full e` cosi`:

$smbClientPath -s /etc/samba/smb-client.conf \\$host\$shareName $I_option -U $userName -E -d 1 -c tarmode\ full -Tc$X_option - $fileList

Poi occorre creare il file di conf /etc/samba/smb-client.conf che abbiamo indicato prima, mettendoci dentro:

client use spnego = no
client ntlmv2 auth = no

Estrazione di un TAR da backuppc

Per estrarre un file di tipo tar con dentro i dati di uno specifico backup da backuppc si puo` usare un comando come questo:

 su backuppc -c "/usr/share/backuppc/bin/BackupPC_tarCreate -h <hostname_macchina_backuppc>  -s <path> -n -1 ." > /mnt/backup_pippo_pluto.tar

L'hostname e` quello indicato nella configurazione di backuppc come host da backuppare. Il path e` quello indicato nella config dell'host come path di partenza del backup, oppure anche una parte di esso (credo). Per esempio, per una macchina linux potrebbe essere "/" mentre per una windows lo share samba che stiamo accedendo "c$" o "documenti" o altro. In pratica e` il path cosi` come e` noto a backuppc stesso. La voce "-n -1" significa "prendi l'ultimo backup che hai" ovvero il piu` recente. Il punto in fondo indica il percorso (dentro al path di partenza) da restorare. In pratica se vogliamo restorare "/etc" dal path "/" dovremmo mettere "etc" al posto del punto in fondo.

Per avere una lista dei files e non fare il restore possiamo aggiungere "-l" come primo parametro e togliere la ridirezione. Tipo:

 su backuppc -c "/usr/share/backuppc/bin/BackupPC_tarCreate -l -h <hostname_macchina_backuppc>  -s <path> -n -1 ."

Monitoraggio di backuppc

Backuppc ha un "problema" concettuale: manda email solo se ci sono problemi. Il che andrebbe benissimo, se non fosse che nel caso in cui backuppc stesso muoia (il processo, intendo) nessuno ci avvisera`, e i backup non verranno fatti.

Se si usa backuppc su una macchina dedicata, l'unica soluzione sensata e` monitorarlo da un'altra macchina, usando per esempio un tool come Zabbix o altro sistema di monitoraggio.

Se lo si usa sulla stessa macchina che fa anche da server per gli utenti, usare un tool di monitoraggio potrebbe essere eccessivamente complesso. Un semplice script in cron che verifichi se backuppc gira e` sufficiente. Se muore tutta la macchina saranno gli utenti ad avvisarci che non sta andando piu` niente. Mettendo in cron questo script si puo` avere un avviso se backuppc muore:

03 8    * * *   backuppc        /usr/share/backuppc/bin/BackupPC_sendEmail -c

si ricevera` una mail contenente l'avviso "Non riesco a comunicare con il server di backuppc" solo nel caso in cui backuppc non risponda.

Ricevere una mail con lo stato dei backup

Oltre al monitoraggio che ci dica semplicemente se backuppc sta girando, puo` essere comodo avere un report per mail dello stato dei backup (la stessa cosa che vediamo sull'interfaccia web). Per questo ho trovato uno script qui: https://github.com/moisseev/BackupPC_report che fa questi report.

Per farlo funzionare su Debian / Devuan occorre modificare una delle primissime righe dentro lo script stesso per indicare il path corretto per le librerie Perl di backuppc:

use lib '/usr/share/backuppc/lib/';    # Questo e` il path giusto in Debian

Fatto questo, potremo poi eventualmente mettere in cron il lancio dello script per avere una mail di stato ogni giorno. Notare che questo script non è un sistema di allarme, in quanto si limita a mostrare lo stato delle cose ma non è in grado di gestire una logica del tipo "ti mando una mail solo se c'e` un problema"