Truedoc

BackupPC » Cronologia » Versione 29

Versione 28 (Simone Piccardi, 06-05-2024 10:22) → Versione 29/31 (Simone Piccardi, 06-05-2024 15:15)

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 l'autoconfigurazione 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.trl@, ma potrà essere effettuato in generale con qualunque nome a dominio possa esser raggiunta la macchina su cui si installa). macchine). 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 creare 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 autoconfigurazione 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 

 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@.  

 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; stessa, l'autenticazione HTTP infatti esegue prevede la trasmissione delle credenziali in chiaro, e pertanto non è sicura fintanto che non si sia configurato Apache per l'uso di HTTPs. HTTPS. Questo non viene fatto di default, richiedendo l'utilizzo di appropriati certificati SSL, ma si può comunque attivare l'uso del protocollo HTTPS a scopo di test usando un certificato autogenerato; HTTPS, 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, usi SSL, l'istallazione di Apache su Debian apache 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 443 ed https://); si potrà raggiungere tenga comunque conto che la macchina con @https://bookworm.fi.trl@, ma avendo usato configurazione di default di Apache usa un certificato SSL autogenerato, questo fittizio, che non verrà considerato viene riconosciuto come valido dai browser e dovrà essere accettato esplicitamente impostando con una eccezione. Per 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 Questo comunque non è ancora sufficiente a consentire l'accesso anche da remoto. La configurazione di Apache che contiene tutte le direttive necessarie a BackupPC, occorre riconfigurarlo per il funzionamento l'uso di BackupPC viene mantenuta nel file @/etc/backuppc/apache.conf@, ma viene utilizzata con SSL, 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. Si tenga presente infine prevede, commentato, l'uso della direttiva @SSLRequireSSL@, che 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 suggerisce di abilitare sempre. Se si dispone di un meccanismo sistema di autenticazione gestione centralizzata che supporta degli utenti su LDAP si potrà usare lo stesso sostituendo questo può essere utilizzato usando la riga @AuthUserFile /etc/backuppc/htpasswd@ con una seguente configurazione del tipo (per i dettagli sulle direttive e i moduli necessari per il funzionamento si veda [[Apache22DavLdap]]): 

 <pre> 
 Alias /backuppc /usr/share/backuppc/cgi-bin/ 

 <Directory /usr/share/backuppc/cgi-bin/> 
         AllowOverride None 
         Allow from all 

         SSLRequireSSL 

         Options ExecCGI FollowSymlinks 
         AddHandler cgi-script .cgi 
         DirectoryIndex index.cgi 

         AuthType basic 
         AuthName "BackupPC admin" 
         AuthBasicProvider ldap 
         AuthzLDAPAuthoritative off 
         AuthLDAPURL ldap://127.0.0.1/ou=People,dc=truelite,dc=it 
         require valid-user 
 </Directory> 
 </pre> 

 h2. La configurazione Il programma mantiene i dati del servizio 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. 

 Il passo successivo è la configurazione del programma. Questa programma, questa è mantenuta, insieme a tutti gli altri file, in @/etc/backuppc@, il file principale è @config.pl@, che contiene la definizione di una serie di variabili (nel linguaggio Perl), Perl, con le quali viene controllato il comportamento del programma. Il file è ben commentato, e le variabili sono numerosissime, per cui ci concentreremo solo sul sottoinsieme di quelle utilizzate nei vari file di configurazione relativi alle singole macchine.  

 Il file @config.pl@ contiene infatti i valori di default, usati in maniera generica quando non ve ne sono indicati di specifici, il sistema infatti richiede che si indichi nel file @hosts@ l'elenco delle macchine di cui si vuole effettuale il backup (in genere usando il relativo hostname) e poi si inseriscano le chiavi di configurazione specifiche da applicare per ciascuna di esse in un corrispondente file @hostname.pl@. Il pacchetto Debian ad esempio inserisce un @localhost.pl@ per il backup locale delle configurazioni. 

 Per quanto riguarda @config.pl@ la direttiva probabilmente più significativa è @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, 12]; 
 </pre> 

 si richiedono quattro copie dei backup completi a cadenza settimanale, nessuna copia per i backup completi a cadenza bisettimanale e 12 copie dei backup completi a cadenza circa mensile (ad esser precisi quadrisettimanale). 

 Il file @hosts@ ha un formato diviso in quattro colonne, la prima colonna indica il nome della macchina, questo 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. Il terzo campo indica l'utente (locale) per conto del quale viene eseguito il backup (usato pure per l'accesso all'interfaccia web). Se ne possono specificare altri, sempre per username, in un elenco separato da virgole nella quarta ed ultima colonna. Un esempio di questo file potrebbe essere il seguente: 

 <pre> 
 ... 
 host          dhcp      user      moreUsers       # <--- do not edit this line 
 ... 
 localhost     0         backuppc 
 client        0         backuppc 
 </pre> 

 Utilizzando per @hosts@ l'esempio precedente le configurazioni specifiche per la macchina @client@ dovranno essere inserite nel file @client.pl@. Come accennato, si tratterà di modificare solo le configurazioni attinenti alla tipologia di backup da eseguire, in questo caso la prima variabile utilizzata è @XferMethod@, che indica come eseguire il backup e può assumere quattro valori; quelli più usati sono comunque @rsync@ per il backup attraverso @rsync@ e @tar@ per il backup attraverso l'omonimo comando. Il primo è più efficiente per i trasferimenti via rete, ma quando si deve eseguire un backup di moltissimi file, comporta un grande consumo di memoria per cui spesso si rivela troppo lento e problematico per la macchina ospite. 

 Dopo aver indicato il metodo da usare occorre indicare di quali directory si vuole eseguire il backup, in tal caso le variabili di controllo sono due, @TarShareName@ se si usa il metodo @tar@ e @RsyncShareName@ se si usa @rsync@, entrambe prendono come valore un array di pathnames. Se allora si intende usare il comando @tar@ il file di configurazione del nostro @client.pl@ sarà qualcosa del tipo:  

 <pre> 
 $Conf{XferMethod} = 'tar'; 
 $Conf{TarShareName} = [ '/etc', '/var', '/home', '/root' ]; 
 $Conf{BackupFilesExclude} = [ '/var/cache', '/var/run' ]; 
 </pre> 

 Si tenga presente comunque che tutti questi file possono essere anche creati e modificati direttamente dall'interfaccia web (motivo per cui 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. 

 Per poter eseguire i backup, sia che si usi il metodo @rsync@ sia che si usi il metodo @tar@ comunque si deve passare attraverso SSH, per questo sarà necessario installare una chiave per l'accesso alle macchine remote di cui si vuole fare il backup, questo richiede che si generi sul server una coppia di chiavi per l'utente @backuppc@ (o per l'utente col quale si vuole effettuare il backup come indicato in @hosts@) per farlo si potranno usare i comandi: 

 <pre> 
 su - backuppc 
 ssh-keygen 
 </pre> 

 avendo cura di mettere una password vuota per la chiave.  

 Per poter effettuare il collegamento si dovrà poi copiare sulle macchine di cui si vuole fare il backup la suddetta chiave nel file @.ssh/authorized_keys@ nella home dell'utente remoto usato per il backup (in una configurazione elementare @root@ per 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 accettare la chiave del server SSH della stessa; questa operazione dovrà essere eseguita manualmente una priva volta per tutte le macchine a cui ci si deve collegare, in modo da    generare la voce di @.ssh/known_hosts@ che le identifica come server noti, altrimenti si otterrà un fallimento dei backup per l'impossibilità di eseguire l'accettazione in modalità non interattiva. 

 h2. Modifica della directory dove si mantengono i dati 

 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. 


 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@, un accesso indiscriminato di quest'ultimo ai dati dei client è da evitare. 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 questo la procedura più corretta è creare su questa un utente non privilegiato da usare per i backup e ricorrere a @sudo@ per consentire a questo l'esecuzione del comando necessario. 

 In questo caso si può creare anche sulla macchina di cui eseguire il backup un utente @backuppc@, poi si dovrà copiare nella    @.ssh/authorized_keys@ della sua home la chiave pubblica precedentemente creata, ed infine configurare @sudo@. In questo caso, posto che si intenda utilizzare per il backup il metodo @tar@, occorrerà aggiungere a @/etc/sudoers@ una 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 aggiungendo a @client.pl@ 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> 

 ci si ricordi inoltre eseguire almeno una volta la prova di funzionamento del comando 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 è distribuito in @/usr/share/doc/rsync/scripts/rrsync.gz@ con il pacchetto di @rsync@, ma la versione di _Jessie_ manca dell'abilitazione di alcune opzioni necessarie per BackupPC (vedi https://lists.samba.org/archive/rsync/2014-September/029647.html), il patch citato è stato applicato alla versione allegata a questa pagina.  

 In questo caso non è necessario usare @sudo@, in quanto @rrsync@ è stato scritto per essere usato come comando di accesso per SSH. Si tratta cioè di appoggiarsi ad una funzionalità presente nell'autenticazione a chiavi di SSH, che consente 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 un comando che verrà utilizzato quando viene effettuato l'accesso, al posto di quello inviato nella riga di comando di @ssh@ (il quale sarà passato nella variabile di ambiente @SSH_ORIGINAL_COMMAND@). In questo modo non si avrà mai un accesso alla shell, in quanto @rrsync@ consente solo di eseguire @rsync@ (neanche @/usr/bin/rsync@, pertanto occorrerà impostare per la macchina la variabile di configurazione @$Conf{RsyncClientPath} = 'rsync'@). Lo script inoltre prende come argomento una directory, alla quale viene ristretto l'accesso, e l'opzione facoltativa @-ro@, che blocca l'accesso in sola lettura.  

 Per poter utilizzare questo secondo approccio, a parte la modifica alla configurazione citata, tutto quello che serve è preporre alla chiave pubblica di @backuppc@ inserita in @.ssh/authorized_keys@ sulla macchina di cui fare il backup la seguente stringa: 

 <pre> 
 command="nice -n 19 ionice -c 3 /usr/local/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 esempio, invece di invocare direttamente lo script @rrsync@, si è preferito un passaggio preliminare da @nice@ e @ionice@ per ridurre il carico dell'esecuzione del backup sulla macchina, e poi con @rrsync@ si è dato accesso a qualunque file in sola lettura. Le ulteriori opzioni indicate consentono di eliminare tutte le funzionalità aggiuntive di SSH che potrebbero essere usate in caso di compromissione della chiave 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@.