seozie-img

BackupPC​ e la gestione corretta dei backup

Con BackupPC  è possibile centralizzare i backup aziendali su un server dedicato in quanto si tratta di una piattaforma libera (Open Source) per la gestione dei backup via rete.

Il sistema supporta funzionalità avanzate la gestione delle modalità di backup (integrali e differenziali), la deduplicazione dei dati per un minore consumo di spazio disco, le impostazioni per la data retention, le notifiche via email, e molto altro. Inoltre, fornisce una semplice interfaccia di gestione via web che permette con una discreta facilità d’uso anche dal punto di vista utente.

Uno dei punti di forza di BackupPC è che non è necessario installare nessun agent proprietario sui PC per i quali si effettua il backup, in quanto tutto l’accesso può essere eseguito attraverso le condivisioni via rete (protocollo SMB/CIFS) per le macchine Windows e l’uso di comandi standard di sistema come rsync o tar (via SSH) per le macchine unix/Linux.

Come installare

La modalità consigliata per l’installazione è quella di usare i pacchetti della propria distribuzione in quanto il progetto fornisce i sorgenti ma è supportato direttamente da diverse distribuzioni Linux.

Nel caso di Debian e derivate l’installazione può essere effettuata semplicemente con il comando:

apt-get install backuppc

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

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

Alcune scelte di configurazione vi verranno richieste nel momento dell’installazione del pacchetto, 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:

a cui (a parte esigenze specifiche di usare altro rispetto ad Apache) si dovrà rispondere affermativamente.

Terminata questa fase ci verrà indicato come accedere all’interfaccia web, con il relativo 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).

Inoltre verrà riportato lo username da utilizzare per l’accesso (impostato al default backuppc) e la relativa password generata automaticamente (che è opportuno segnarsi, anche se può comunque esser cambiata in un qualunque momento successivo):

La gestione degli utenti

Si possono avere diversi utenti a cui è possibile demandare operazioni in maniera ristretta ma l’accesso al programma deve essere sempre autenticato (di questo ne parleremo meglio 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:

root@bookworm:~# htpasswd /etc/backuppc/htpasswd backuppc
New password: 
Re-type new password: 
Updating password for user backuppc

si potranno eventualmente creare un nuovo utente con:

root@bookworm:~# htpasswd /etc/backuppc/htpasswd nuovoutente
New password: 
Re-type new password: 
Adding password for user nuovoutente

e cancellarne uno da rimuovere con:

htpasswd -root@bookworm:~# htpasswd -D /etc/backuppc/htpasswd  vecchioutente
Deleting password for user vecchioutente

La 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 esegue la trasmissione delle credenziali in chiaro, e quindi 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:

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

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:

root@bookworm:~# a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  systemctl reload apache2

Successivamente 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 questo articolo.

Abilitato l’uso di SSL da parte di Apache, per consentire l’accesso anche da remoto, sarà necessario modificare la configurazione di BackupPC .

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.

Occorrerà eliminare la restrizione all’accesso soltanto locale, per consentire l’accesso da remoto, 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. Una volta terminata questa operazione 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:

Come configurare il servizio

Vediamo adesso come configurare il programma.

L’attività da svolgere 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: Nella prima è indicato 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). Nella seconda colonna, che conviene lasciare impostata a zero, è indicato se deve essere fatta o meno una ricerca netbios sul range fornito dal DHCP. La terza colonna invece, 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. Infine, nella quarta ed ultima colonna, si possono specificare in una lista di username separata da virgole, eventuali altri utenti (da aggiungere ad htpasswd) che potranno controllare i backup della relativa macchina attraverso l’interfaccia web; è possibile lasciarla vuota se non si avessero esigenze specifiche al riguardo. Il file installato dal pacchetto è seguente:

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

che predefinisce se stessi (come localhost) come unica macchina di cui eseguire il backup.

Con il link “Edit Hosts” che compare nella sezione a sinistra della pagina sarà possibile aggiungere  altre righe al file su altre macchine, attraverso l’interfaccia web. 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:

client   0       backuppc

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, nella sezione sinistra della pagina i valori possono essere modificati direttamente, usando il link “Edit config”, 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:

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

verranno richieste 4 copie dei backup completi a cadenza circa mensile (ad esser precisi quadrisettimanale) 4 copie dei backup completi a cadenza settimanale e nessuna copia per i backup completi a cadenza bisettimanale.

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.

La modalità più comune di configurazione del backup di una macchina è quella di 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”:

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 crea 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. Per eseguire il backup la prima variabile da impostare è XferMethod; il default è tar che indica l’uso del programma omonimo, ma quelli più usati sono comunque smb (per usare una condivisione) per le macchine Windows e rsync (con il programma omonimo) per le macchine Linux.

Occorre indicare di quali directory si vuole eseguire il backup una volta che si è indicato il metodo da usare con XferMethod, in tal caso le variabili di controllo dipendono dal tipo di metodo usato, ad esempio si deve usare RsyncShareName col il metodo rsync e TarShareName con il metodo tar. 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:

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

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 BackupFilesExcludeche consente di indicare quali sottodirectory di quelle indicate da RsyncShareName o TarShareName devono essere escluse dal backup, BlackoutPeriods che consente di indicare una lista di orari in cui evitare di eseguire il backup, , RsyncClientCmd che consente di modificare le modalità con cui si invoca il programma rsync sul client,  FullKeepCnt per modificare la data retention della singola macchina rispetto al default, e la stessa TarClientCmd che fa la stessa cosa per il comando tar.

Come configurare  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.

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:

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]-----+

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.

Come migliorare la sicurezza dell’accesso ai client

Può essere opportuno evitare un accesso indiscriminato dell’utente ai dati dei client in quanto la compromissione del server con BackupPC comporterebbe anche la possibilità di ottenere la chiave privata dell’utente backuppc. 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:

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

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

$Conf{TarClientCmd} = '$sshPath -q -x -n -l backuppc $host'
                      . ' env LC_ALL=C /usr/bin/sudo $tarPath -c -v -f - -C $shareName+'
                      . ' --totals';

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

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  .

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:

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

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

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.

Poichè solo rsync è consentito occorrerà 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).

Nell’esempio qui sopra 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 directory per partenza per rrsync per dare accesso a qualunque file, ma in sola lettura usando l’opzione -ro.

Per eliminare una serie di ulteriori funzionalità aggiuntive del collegamento via SSH si possono usare le opzioni indicate di seguito (no-agent-forwarding, ecc.), che potrebbero essere usate in caso di compromissione della chiave sul server di BackupPC, ma che non servono per l’esecuzione di un backup.

Entrambi gli approcci illustrati (tar via sudo o chiave SSH con limitazioni) non consentono a BackupPC di scrivere sulla macchina remota di cui esegue il backup, e quindi 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 rrsyncnella precedente configurazione di sul client.

                                                                                              La redazione

Share

    BLACK FRIDAY


    TUTTO AL 30%

    con il codice

    NJC-30

    Inserisci il codice nel carrello per attivare lo sconto

    Questo si chiuderà in 0 secondi

    0
      0
      Il tuo Carrello
      Il tuo Carrello è vuotoReturn to Shop