Nella documentazione la soluzione sembra semplice, ovvero importare il client dalla GUI di Data Protector, e da questa impartire il cancellamento. Ovviamente se come nel mio caso il server Data Protector è pure cambiato le cose si complicano. Nemmeno un upgrade del client è andato a buon fine, quindi non era rimasto che guardare il file di installazione per capire come e dove venisse installato il programma.

Per prima cosa è necessario scaricare da Xinetd il servizio client che tiene occupata la porta 5555.
Ho semplicemente cancellato il file omni da /etc/xinetd.d (in altre distribuzioni può essere che si debba intervenire anche sul file /etc/xinetd.conf ), commentato o cancellato dal file /etc/services il servizio OMNI relativo alla porta 5555 e quindi riavviato il demone xinetd ( sudo restart service xinetd ).

A questo punto il servizio omniback dovrebbe essere fuori gioco, per sicurezza verifichiamo con un netstat -vantp dove non dovremo trovare nulla in ascolto sulla porta 5555. Si procede con una brutale rimozione delle directory di installazione vecchie.
In seguenza ho eliminato con

sudo rm -f -d -r /usr/omni /opt/omni /var/opt/omni /etc/opt/omni 

Se tutto è andato a buon fine il sistema è pulito e si può installare la nuova versione del client Data Protector.

Innanzitutto occorre avere a disposizione i cd di Data Protector etichettati come Solaris e Linux e HP UX. Nel caso in esempio abbiamo preso in esame la versione 6.11, mentre Ubuntu Linux è la versione 10.04 Server, che dovrà essere risolta in reverse DNS come pre-requisito iniziale.

Per iniziare abbiamo bisogno di installare il pacchetto RPM e Xinetd che si occuperà di “ascoltare” le richieste dal Data Protector.

sudo apt-get update
sudo apt-get install rpm xinetd

RPM necessita di una piccola modifica, infatti dobbiamo lanciare il comando con l’opzione –force-debian, quindi automatizzeremo le operazioni. Per prima cosa rinominiamo l’eseguibile:

sudo mv /usr/bin/rpm /usr/bin/rpm-ori

Ora creiamo un file (sudo vi /usr/bin/rpm) che si chiamerà rpm con il contenuto:

#!/bin/sh
/usr/bin/rpm-ori --force-debian $@

Rendiamo eseguibile il file appena creato:

sudo chmod 755 /usr/bin/rpm

Prima di procedere all’installazione vera e propria verifichiamo che la porta 5555 del servizio xinetd sia libera (verrà usata appunto per attendere le istruzioni dal server di Data Protector). Con un editor di testo apriamo il file /etc/services e commentiamo:

#rplay 5555/udp # RPlay audio service

Ora possiamo caricare il cdrom (noi abbiamo usato quello denominato HP-UX), montarlo nel sistema e avviare l’installazione indicando il server e quali componenti installare.

sudo mount /dev/cdrom/ /media/cdrom
cd /media/cdrom/LOCAL_INSTALL
sudo ./omnisetup.sh -server FQDN.server.dataprotector -install da

dove modificheremo ovviamente FQDN.server.dataprotector con il nome del server in questione, mentre per i componenti sarà sufficiente indicare quali scegliere (da = disk agent). Si otterrà un output simile a questo:

  Data Protector version A.06.11 found
  Client detected, installed packets:  da

  Packets going to be installed: omnicf da

  Unpacking selected packets from CD, please wait (5-10 minutes)...
  Unpacking complete!

Data Protector software package successfully installed
  Installing Disk Agent (da)...

Data Protector software package successfully installed
  Importing client to FQDN.server.dataprotector...
Import host successful.

  Installation/Upgrade session finished.

Abbiamo quasi concluso, con l’operazione precedente avremo già inserito tra i client noti all’interno di Data Protector il nostro server Linux (dovreste vederlo attivo alla voce client) tuttavia nel caso abbiate partizionato il vostro sistema con il filesystem Ext4 serve ancora una piccola modifica. Per qualche motivo Ext4 non è tra i filesystem elencati. Dovremo semplicemente indicarlo con una piccola modifica.. In caso contrario vi ritroverete durante il backup un errore simile a “All mountpoints on host “x.y.z” are excluded.“.
Il workaround richiede di modificare il file che si trova sotto /opt/omni/lbin/.util
Alla riga 351 troveremo un comando piuttosto lungo dove sono elencati i vari filesystem. Aggiungeremo dopo -t ext3 il nostro ext4 e la stringa dovrà essere come segue:

/bin/df -P -t ext2 -t SFS -t ext -t minix -t xiafs -t reiserfs -t ext3 -t ext4 -t vfat -t vxfs -t xfs 2>/dev/null | sed '1d' | awk '{print $6}'

A questo punto serve un ulteriore verifica di buon funzionamento. Nel nostro caso il servizio sulla porta 5555 non era attivo, infatti dando il comando netstat -vantp questa non compariva tra quelle attive in ascolto. Forse un bug non ha scritto la porta nel file /etc/xinetd.d/omni. Editato con il nostro solito editor avremo cura che appaia come segue:

service omni
{
disable = no
id = omni
socket_type = stream
protocol = tcp
user = root
wait = no
server = /opt/omni/lbin/inet
server_args = -log /var/opt/omni/log/inet.log
port = 5555
}

Riavviamo il servizio sudo /etc/inet.d/xinetd restart e abbiamo concluso il lavoro nel nostro sistema operativo. Dalla Gui di Data Protector ora siamo pronti a creare e lanciare il backup del server Ubuntu.

Dal menu Start -> Control panel -> Regional and Language Options
si presenta una maschera in cui la prima voce è il set di opzioni predefinito per ogni nazione. Basta spostare questo sotto Italia è il gioco è fatto!

Aprire una console del terminale ( ALT + F2 -> gnome-terminal ), quindi digitare (non serve passare come root) questa breve sequenza di comandi.

gconftool --recursive-unset /apps/panel
rm -rf ~/.gconf/apps/panel
pkill gnome-panel

Con il primo comando scarichiamo i pannelli da Gnome (infatti li vedremo sparire).
Con la seconda riga eliminiamo la configurazione attuale, che andrà persa.
Con la terza “uccidiamo” il demone che verrà riavviato nella configurazione di default.

Ovviamente poi dovremo rimettere le icone (ed eventuale tema grafico) che abbiamo perso nel caso di una configurazione personalizzata.

La sintassi da seguire è:

mysqldump -h localhost -u username -p database_name > database_backup.sql

Ovviamente variate i parametri di conseguenza, localhost dovrebbe andare bene considerando l’uso della shell, mentre username e database_name vanno regolati di conseguenza. Dopo il segno > il nome scelto è a vostra discrezione. Una volta impartito il comando vi verrà richiesta la password del database per accedere al suo contenuto.

E’ anche possibile produrre direttamente un file compresso variando leggermente la sintassi come segue:

mysqldump -h localhost -u username -p database_name | gzip -9 > database_backup.sql.gz

dove gzip effettua la compressione (il parametro -9 indica la miglior compressione possibile), utile se poi il file lo dovete scaricare attraverso internet.