Truedoc

h1. Backup con BackupPC

"BackupPC":https://backuppc.github.io/backuppc/ è una piattaforma libera (Open Source) per la gestione dei backup via rete, che consente di centraliizzare i backup aziendali su un server dedicato. Il sistema supporta funzionalità avanzate la gestione delle modalità di backup (integrali e differenziali), le impostazioni per la data retention, la deduplicazione dei dati per un minore consumo di spazio disco, notifiche via email, e molto altro. Fornisce inoltre una comoda interfaccia di gestione via web che consente con una discreta facilità d'uso anche lato utente.  Un grande vantaggio di BackupPC è che non è necessario installare nessun agent proprietario sui PC di cui si effettua il backup, in quanto tutto l'accesso può essere eseguito tramite l'uso di comandi standard di sistema come @rsync@ o @tar@ (via SSH) per le macchine unix/Linux e delle condivisioni via rete (protocollo SMB/CIFS) per le macchine Windows. 

h2. Installazione

Il progetto fornisce i sorgenti ma è supportato direttamente da diverse distribuzioni linux, e la modalità consigliata per l'installazione è quella di usare i pacchetti della propria distribuzione. Nel caso di _Debian_ e  derivate l'installazione può essere effettuata semplicemente con il comando:

<pre>

apt-get install backuppc

</pre>

inoltre può essere utile per la diagnostica installare alcuni dei pacchetti suggeriti, che di default non vengono installati, con:

<pre>

apt-get install rsync par2 cifs-utils librrds-perl

</pre>

All'installazione del pacchetto vengono richieste alcune scelte di configurazione, in particolare viene proposta l'auto-configurazione del programma con il server Web Apache (che verrà installato e configurato insieme al pacchetto), con una richiesta come:

!Debconf-ApacheConf.png!

a cui (a parte esigenze specifiche di usare altro rispetto ad Apache) si dovrà rispondere affermativamente. Una volta fatto questo ci verrà riportato come accedere all'interfaccia web, con il realtivo link (nel seguente esempio un dominio fittizio interno, @http://bookworm.fi.tr/backuppcl@, ma potrà essere effettuato in generale con qualunque nome a dominio possa esser raggiunta la macchina su cui si installa). Viene inoltre riportato l'username da usare per l'accesso (impostato al default @backuppc@) ed la relativa password generata automaticamente (che è opportuno segnarsi, anche se può comunque esser cambiata in un qualunque momento successivo): 

!DebconNotifyAccess.png!

h2. Gestione utenti

L'accesso al programma infatti deve essere sempre autenticato, e si possono avere diversi utenti, a cui è possibile demandare operazioni in maniera ristretta (torneremo su questo più avanti). Questi accessi vengono effettuati con l'autenticazione HTTP standard, e il meccanismo di auto-configurazione del pacchetto prevede che i dati relativi siano mantenuti nei classici file @htpasswd@, gestibili tramite il comando omonimo. In particolare nella configurazione generata dal pacchetto viene usato il file @/etc/backuppc/htpasswd@ e come indicato nella schermata precedente si potrà cambiare la password preimpostata con il comando:

<pre>

root@bookworm:~# htpasswd /etc/backuppc/htpasswd backuppc

New password: 

Re-type new password: 

Updating password for user backuppc

</pre>

si potranno eventualmente creare un nuovo utente con:

<pre>

root@bookworm:~# htpasswd /etc/backuppc/htpasswd nuovoutente

New password: 

Re-type new password: 

Adding password for user nuovoutente

</pre>

e cancellarne uno da rimuovere con:

<pre>

htpasswd -root@bookworm:~# htpasswd -D /etc/backuppc/htpasswd  vecchioutente

Deleting password for user vecchioutente

</pre>

h2. Configurazione di Apache

L'installazione di default di BackupPC consente l'accesso all'interfaccia web di gestione soltanto in locale, dalla macchina stessa su cui lo si installa; l'autenticazione HTTP infatti esegue la trasmissione delle credenziali in chiaro, e pertanto non è sicura fintanto che non si sia configurato Apache per l'uso di HTTPs. Questo non viene fatto di default, richiedendo l'utilizzo di appropriati certificati SSL, si può comunque attivare l'uso del protocollo HTTPS a scopo di test usando un certificato autogenerato; per questo occorre prima attivare il modulo @ssl@ con:

<pre>

root@bookworm:~# a2enmod ssl

Considering dependency setenvif for ssl:

Module setenvif already enabled

Considering dependency mime for ssl:

Module mime already enabled

Considering dependency socache_shmcb for ssl:

Enabling module socache_shmcb.

Enabling module ssl.

See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.

To activate the new configuration, you need to run:

  systemctl restart apache2

</pre>

e poi abilitare un virtual host che consenta l'accesso in HTTPs sulla porta 443, l'istallazione di Apache su Debian ne fornisce uno di default, inattivo, che potrà essere abilitato con:

<pre>

root@bookworm:~# a2ensite default-ssl

Enabling site default-ssl.

To activate the new configuration, you need to run:

  systemctl reload apache2

</pre>

A questo punto si dovrà riavviare Apache con @systemctl restart apache2@ (il restart è necessario per poter utilizzare la posta 443) e si potrà raggiungere la macchina con @https://bookworm.fi.trl@, ma avendo usato un certificato SSL autogenerato, questo non verrà considerato valido dai browser e dovrà essere accettato esplicitamente impostando una eccezione. Per una configurazione di SSL valida in generale si rimanda a [[UsareLetsEncrypt|questo articolo]]. 

Una volta abilitato l'uso di SSL da parte di Apache, occorrerà modificare la configurazione di BackupPC per consentire l'accesso anche da remoto. La configurazione di Apache che contiene tutte le direttive necessarie per il funzionamento di BackupPC viene mantenuta nel file @/etc/backuppc/apache.conf@, ma viene utilizzata con il sistema di gestione previsto per le estensioni di configurazione di Apache, con un link simbolico creato automaticamente  in @/etc/apache2/conf-available/@ e poi abilitato su @/etc/apache2/conf-enabled/@. Pertanto ogni cambiamento di configurazione dovrà essere eseguito sul file  @/etc/backuppc/apache.conf@, ricordandosi che per renderlo effettivo occorre richiedere la rilettura ad Apache, con il comando @systemctl reload apache2@. 

Per consentire l'accesso da remoto occorrerà anzitutto eliminare la restrizione all'accesso soltanto locale, commentando, come scritto nel file di configurazione stesso, la riga @Require local@; al contempo occorrerà de-commentare la precedente riga @#SSLRequireSSL@ per evitare di collegarsi in chiaro. Fatto questo ci si potrà collegare su @https://bookworm.fi.trl/backuppc@ per accedere all'interfaccia web: si dovrà chiedere al browser di accettare il certificato non valido, e si dovranno poi inserire utente e password, ed a quel punto si verrà portati sulla pagina di accesso che riassume lo stato:

!BackupPC-Status.png!

h2. La configurazione del servizio

Il passo successivo è la configurazione del programma. Questa si basa su due file, mantenuti insieme a tutti gli altri in @/etc/backuppc@. Il primo file è @hosts@ che contiene l'elenco delle macchine di cui eseguire il backup. Il file ha un formato diviso in quattro colonne: la prima indica il nome della macchina, che deve poter essere risolto direttamente (si fa riferimento o ad un hostname nel proprio dominio, o a un nome di una macchina Windows risolvibile via netbios). La seconda colonna indica se deve essere fatta o meno una ricerca netbios sul range fornito dal DHCP, ed in genere deve restare impostata a zero. La terza colonna indica l'utente locale per conto del quale viene eseguito il backup (usato pure per l'accesso all'interfaccia web) che con la versione installata dal pacchetto deve essere sempre @backuppc@.  Nella quarta ed ultima colonna se possono poi specificare in una lista di username separata da virgole, eventuali altri utenti (da aggiungere ad @htpasswd@) che potranno controllare i backup della relativa macchina dall'interfaccia web; se non si hanno esigenze specifiche al riguardo la si può lasciare vuota. Il file installato dal pacchetto è seguente:

<pre>

...

host        dhcp    user    moreUsers     # <--- do not edit this line

#farside    0       craig   jill,jeff     # <--- example static IP host entry

#larson     1       bill                  # <--- example DHCP host entry

localhost   0       backuppc

</pre>

che predefinisce se stessi (come @localhost@) come unica macchina di cui eseguire il backup. Per aggiungere altre macchine occorrerà aggiungere altrettante righe al file, questo può essere fatto anche dall'interfaccia web, con il link "Edit Hosts" che compare nella sezione a sinistra della stessa. Per ciascuna macchina inserita in questo file, si potranno definire delle configurazioni specifiche in altrettanti corrispondenti file @.pl@ (ad esempio quelle per @localhost@ si troveranno nel file @localhost.pl@). Pertanto per eseguire i backup della macchina @client@ occorrerà aggiungere in coda al file una riga:

<pre>

client   0       backuppc

</pre>

Il secondo file di configurazione principale è @config.pl@, che contiene la definizione ai rispettivi valori di default di una lunga serie di variabili con le quali viene controllato il comportamento del programma. Il file è ben commentato, e le variabili sono numerosissime. Anche in questo caso valori possono essere modificati direttamente dall'interfaccia web, usando il link "Edit config" nella sezione sinistra della pagina, che consente di navigare le varie opzioni di configurazione, organizzate per schede, e modificare i singoli valori. In genere non c'è necessità di modificare queste impostazioni, tranne forse la variabile @FullKeepCnt@, che indica quanti backup completi mantenere. 

Il default è uno, che indica uno solo per settimana ma si può richiedere un periodo più lungo specificando un array di valori, questo ha un significato complicato in cui ogni numero successivo al primo indica il numero di backup completi da mantenere per il successivo multiplo di due settimane, ad esempio indicando: 

<pre>

$Conf{FullKeepCnt} = [4, 0, 4];

</pre>

si richiedono quattro copie dei backup completi a cadenza settimanale, nessuna copia per i backup completi a cadenza bisettimanale e 4 copie dei backup completi a cadenza circa mensile (ad esser precisi quadrisettimanale). Con questa direttiva si possono stabilire quali sono le politiche di default di ritenzione dei dati che si vogliono applicare a tutte le macchine di cui si esegue il backup.

Come accennato però la modalità più comune di configurazione del backup di una macchina è modificare le variabili nel file @.pl@ ad essa associata. In questo caso si dovranno inserire solo i valori delle variabili di configurazione che si intendono cambiare rispetto ai default. Tutti questi file possono essere anche creati e modificati direttamente dall'interfaccia web, per farlo occorrerà portarsi sulla pagina della singola macchina selezionandola dal menù a tendina nella sezione "Hosts":

!BackupPC-Host.png!

e da li usare il link "Edit Config".  Questo è il motivo per cui tutti i suddetti file appartengono all'utente @backuppc@ ed hanno come gruppo @www-data@, se li si creano manualmente si abbia cura, se si vuole poterli modificare in seguito via web, di impostarne correttamente utente e gruppo proprietario.

La configurazione specifica di una macchina consiste per lo più nel modificare le variabili attinenti alla tipologia di backup da eseguire. La prima variabile da impostare è @XferMethod@, che indica come eseguire il backup; il default è @tar@ che indica l'uso del programma omonimo, ma quelli più usati sono comunque @rsync@ (con il programma omonimo) per le macchine Linux, e @smb@  (per usare una condivisione) per le macchine Windows. 

Dopo aver indicato il metodo da usare con @XferMethod@ occorre indicare di quali directory si vuole eseguire il backup, in tal caso le variabili di controllo dipendono dal tipo di metodo usato, ad esempio si deve usare @TarShareName@ con il metodo @tar@ e @RsyncShareName@ col il metodo @rsync@. Entrambe queste direttive prendono come valore un array di pathnames. Se allora si intende usare il comando @rsync@ ed eseguire il backup delle directory @/etc@, @/var@, @/home@ e @/root@ il file di configurazione @client.pl@ del nostro client dovrà essere qualcosa del tipo: 

<pre>

$Conf{XferMethod} = 'rsync';

$Conf{RsyncShareName} = [ '/etc', '/var', '/home', '/root' ];

</pre>

che imposta il backup delle directory in cui sono normalmente mantenuti i dati e le configurazioni di una installazione. 

Altre variabili rilevanti per la configurazione sono @BlackoutPeriods@ che consente di indicare una lista di orari in cui evitare di eseguire il backup, @BackupFilesExclude@ che consente di indicare quali sottodirectory di quelle indicate da @RsyncShareName@ o @TarShareName@ deveono essere escluse dal backup, @RsyncClientCmd@ che consente di modificare le modalità con cui si invoca il programma @rsync@ sul client, @TarClientCmd@ che fa la stessa cosa per il comando @tar@, e la stessa @FullKeepCnt@ per modificare la data retention della singola macchina rispetto al default. 

h2. La configurazione di SSH sul server

Per poter eseguire i backup di una macchina remota, sia che si usi il metodo @rsync@, sia che si usi il metodo @tar@, si deve comunque passare attraverso SSH che consente una connessione cifrata e sicura. Per questo sarà necessario installare una chiave per l'accesso nelle macchine remote di cui si vuole fare il backup, e questo richiede che si generi sul server una coppia di chiavi per l'utente @backuppc@.  Per farlo si potranno usare i comandi:

<pre>root@bookworm:~# su - backuppc

$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/var/lib/backuppc/.ssh/id_rsa): 

Created directory '/var/lib/backuppc/.ssh'.

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in /var/lib/backuppc/.ssh/id_rsa

Your public key has been saved in /var/lib/backuppc/.ssh/id_rsa.pub

The key fingerprint is:

SHA256:R1N9e+db1tE4M+WKWq06Ye77KkkJ3C3mE/Wg1jDYUyM backuppc@bookworm

The key's randomart image is:

+---[RSA 3072]----+

|       oE.o ..   |

|      . =.oo  . o|

|     . . Ooo   =o|

|      o B.o.. =o=|

|       =S+.  o *=|

|        =.o o o =|

|       . = + . .o|

|        o + .  . |

|         o=*.    |

+----[SHA256]-----+

</pre>

avendo cura di usare una passphrase vuota per la chiave, premendo due volte invio alla relativa richiesta; il file @/var/lib/backuppc/.ssh/id_rsa.pub@ è quello che dovrà essere installato sulle macchine di cui si vuole fare il backup, aggiungedolo al file @.ssh/authorized_keys@ nella home dell'utente remoto usato per il backup (in una configurazione elementare questo deve essere @root@ per poter avere accesso a tutti i file). Si tenga presente che se si usa il metodo @rsync@ detto programma deve essere installato anche sulla macchina di cui si vuole effettuare il backup.

Ci si ricordi inoltre di effettuare una connessione di prova verso ciascuna macchina remota, per far accettare all'utente @backuppc@ la chiave del server SSH della stessa; questa operazione dovrà essere eseguita manualmente una prima volta per tutte le macchine a cui ci si deve collegare, in modo da generare in  @/var/lib/backuppc/.ssh/known_hosts@ la voce che le identifica come server noti. Questa operazione è necessaria, perché altrimenti si otterrà un fallimento dei backup per l'impossibilità di eseguire questa accettazione in modalità non interattiva quando il programma si collega per la prima volta.

h2. Impostazioni per la sicurezza dell'accesso ai client

Dato che la compromissione del server con BackupPC comporterebbe anche la possibilità di ottenere la chiave privata dell'utente @backuppc@, può essere opportuno evitare un accesso indiscriminato di quest'ultimo ai dati dei client. Per questo esistono diversi approcci, miranti a ridurre le possibilità di abuso, ed evitare che una compromissione del server di backup dia accesso completo anche alle macchine di cui si fanno i backup.

Il primo approccio è quello in cui si cerca di evitare l'uso di @root@ come utente sulla macchina di cui si vuole effettuare il backup, quello che serve infatti è soltanto poter eseguire il comando di backup con privilegi di amministratore per consentirgli di leggere tutti i file (altrimenti non si avrebbero i backup di quelli con accesso ristretto). Per questo la procedura più comune è quella di creare sulla macchina remota un utente non privilegiato da usare per i backup, e ricorrere a @sudo@ (che andrà installato) per consentire a questo utente soltanto l'esecuzione del comando necessario.

Ad esempio per usare in maniera sicura @tar@ per i backup remoti, si può creare anche sulla macchina di cui eseguire il backup un utente @backuppc@, copiare nel file @.ssh/authorized_keys@ della sua home la chiave pubblica precedentemente creata, ed infine configurare @sudo@ per consentirgli di usare @tar@ nella maniera opportuna. In questo caso  occorrerà aggiungere a @/etc/sudoers@ sulla macchina remota la riga: 

<pre>

backuppc  ALL=NOPASSWD: /bin/tar -c *

</pre>

che consente solo la creazione di archivi.  Occorrerà poi modificare la variabile @TarClientCmd@ nella configurazione di BackupPC per quel client con qualcosa del tipo: 

<pre>

$Conf{TarClientCmd} = '$sshPath -q -x -n -l backuppc $host'

                      . ' env LC_ALL=C /usr/bin/sudo $tarPath -c -v -f - -C $shareName+'

                      . ' --totals';

</pre>

Qualora si esegua questa modifica può risultare utile eseguire una volta la prova di funzionamento del comando sul server BackupPC, con qualcosa del tipo:

<pre>

su backuppc

/usr/bin/ssh -q -x -n -l backuppc client env LC_ALL=C /usr/bin/sudo /bin/tar -c -v -f - -C /etc  .

</pre>

Un secondo approccio, più sicuro, ma utilizzabile però soltanto con il metodo @rsync@, è quello che si appoggia allo script @rrsync@ distribuito insieme al programma @rsync@, che consente di restringere l'utilizzo di quest'ultimo in modo da dare accesso in sola lettura (eventualmente ad una singola directory). Lo script viene installato in @/usr/bin/rrsync@, ed in questo caso non è necessario usare @sudo@, in quanto @rrsync@ è stato scritto per essere usato come comando di accesso per SSH. Consemte cioè di appoggiarsi ad una funzionalità dell'autenticazione a chiavi di SSH che permette di specificare, in testa alla linea di @.ssh/authorized_keys@ che fornisce accesso con la chiave di un utente, una serie di restrizioni (per i dettagli si consulti la pagina di manuale di @sshd@).

Fra queste restrizioni c'è la possibilità di indicare il comando che verrà utilizzato quando viene effettuato l'accesso, al posto di quello inviato nella riga di comando di @ssh@. A detto comando sarà passato quello richiesto in origine nella variabile di ambiente @SSH_ORIGINAL_COMMAND@ in modo da poter decidere cosa fare.  Per poter utilizzare questa funzionalità tutto quello che serve è apporre alla chiave pubblica di @backuppc@ inserita nell'@.ssh/authorized_keys@ di root della macchina di cui fare il backup la seguente stringa:

<pre>

command="nice -n 19 ionice -c 3 /usr/bin/rrsync -ro /",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

</pre> 

(cui far seguire, separato da uno spazio, il contenuto della chiave pubblica). 

In questo caso ad ogni collegamento verrà lanciato @rrsync@ e non si potrà più avere un accesso alla shell, perché @rrsync@ consente solo l'uso del comando @rsync@, con una opportuna serie di restrizioni. Il comando prende come argomento una directory, alla quale viene ristretto l'accesso (si potranno cioè indicare directory al di sotto di essa), e l'opzione facoltativa @-ro@, che blocca l'accesso in sola lettura.  Dato che solo @rsync@ è consentito occorrerà però impostare nel @.pl@ relativo alla macchina per cui si esegue questa configurazione, la variabile @$Conf{RsyncClientPath} = 'rsync'@, dato che il comando eseguito di default con il metodo @rsync@ è @/usr/bin/rsync@ (che verrebbe rifiutato). 

Nel precedente esempio inoltre. invece di invocare direttamente lo script @rrsync@, si è preferito lanciarlo attraverso un passaggio preliminare per i comandi @nice@ e @ionice@ che consentono ridurre il carico dell'esecuzione del backup per non impattare troppo sulle operazioni ordinarie della stessa. Inoltre si è usato @/@ come directoru per partenza per @rrsync@ per  dare accesso a qualunque file, ma in sola lettura usando l'opzione @-ro@. Le ulteriori opzioni indicate di seguito (@no-agent-forwarding@, ecc.) consentono infine di eliminare una serie di ulteriori funzionalità aggiuntive del collegamento via SSH, che potrebbero essere usate in caso di compromissione della chiave sul server di BackupPC, ma che non servono per l'esecuzione di un backup. 

Si verifichi inoltre che sulla macchina di cui si fanno i backup la localizzazione (da @dpkg-reconfigure locales@) sia correttamente impostata, altrimenti lo script @/usr/local/bin/rrsync@ risponderà con un errore di mancata configurazione del locale bloccando la comunicazione con il server subito dopo l'avvio del backup, senza che nulla venga trasmesso. Si può verificare la sussistenza del problema andando ad esaminare dall'interfaccia web gli errori dell'ultimo XferLog, dove comparirà qualcosa come:

<pre>

Got remote protocol 1819436400

Fatal error (bad version): perl: warning: Setting locale failed.

perl: warning: Please check that your locale settings:

	LANGUAGE = (unset),

	LC_ALL = (unset),

</pre>

Si tenga presente che entrambi gli approcci (@tar@ via @sudo@ o chiave SSH con limitazioni) non consentono a BackupPC di scrivere sulla macchina remota di cui esegue il backup, pertanto non sarà possibile utilizzare la funzionalità di ripristino direttamente sulla destinazione fornita dalla piattaforma. Nel caso la perdita di questa funzionalità comporti un aggravio amministrativo non giustificato da un rischio di compromissione ritenuto sufficientemente ridotto, nella seconda delle due ipotesi si può riabilitare la scrittura (anche in forma temporanea) rimuovendo l'opzione @-ro@ dagli argomenti di @rrsync@.

h2. Alcune configurazioni avanzate

L'uso del file @/etc/backuppc/apache.conf@ è soltanto uno fra i possibili meccanismi per gestire gli utenti fornito da Apache, qualora si disponga ad esempio di un meccanismo di autenticazione centralizzata che supporta LDAP si potrà usare lo stesso sostituendo la riga @AuthUserFile /etc/backuppc/htpasswd@ con una configurazione del tipo (per i dettagli sulle direttive e i moduli necessari per il funzionamento si veda [[Apache22DavLdap]]):

<pre>

        AuthBasicProvider ldap

        AuthzLDAPAuthoritative off

        AuthLDAPURL ldaps://ldap.fi.trl/ou=People,dc=fi,dc=trl

</pre>

Il programma mantiene i dati del backup in @/var/lib/backuppc@, questo significa che si deve avere spazio sufficiente sul filesystem di @/var@ per i backup. Se si desidera allocare lo spazio su una partizione separata si deve spostare la directory sunnominata nella destinazione voluta, inserendo al suo posto un link simbolico verso la nuova collocazione.