RFc -Restori Fabrizio Consulenze- S.da Buffolara, 67 -43126 Parma- Tel. +39 335 240228 Fax +39 0521 940035 P.IVA 01788460341
AMANDA (Advanced Maryland Automatic Network Disk Archiver) è un prodotto open source per la gestione dei backup. Inizialmente sviluppato presso il dipartimento di informatica dell’università del Maryland, è ora disponibile ad uso gratuito (http://amanda.org/copyright.php [1]). E’ disponibile anche il supporto commerciale. L’azienda più nota che fornisce un supporto commerciale è ZMANDA (http://zmanda.com/ [2]) . Zamanda integra AMANDA con diverse funzionalità, una di queste è la console di management. E’ disponibile anche una console di management in ambiente open source che verrà descritta in seguito.
AMANDA è disponibile per diverse distribuzioni linux, tra queste SUSE. La installazione e configurazione in SUSE verrà descritta in dettaglio.
La parte server di Amanda è disponibile per le più diffuse distribuzioni di linux e Solarix, Sloaris e OpenSolaris. I client supportati (quindi gli ambienti per i quali è possibile fare il backup) sono le varie distribuzioni Linux, Solaris, AIX, Windows, Mac OS X. Zamanda mette a disposizione vari agent per Oracle, Exchange, SQL Server ed altri.
Il backup può essere eseguito su dischi locali (nella macchina server) o remoti, nastri, librerie, autocharger, supporti ottici. E’ possibile anche salvare i dati su server Amazon ( Amazon S3 online storage)
Amanda si rivela, quindi, un ottimo strumento per la gestione e il salvataggio dei dati.
Il software è disponibile per il download a http://www.amanda.org/download.php [5]. La versione attuale è la 3.12, ma diverse distribuzioni includono il software e quindi è possibile installare Amanda direttamente dalla distribuzione.
Nell'esempio di configurazione che segue si fa riferimento SUSE Linux Enterprise Server 11. La versione Amanda inclusa nella distribuzione è la 2.5.2p1.
L’installazione è semplice. Si usa Yast -> Software management, si individua il prodotto (search Phrase-> amanda) e si installa. Yast provvede a risolvere le dipendenze e installa sia la parte server che la parte client di Amanda.
Amanda, se installato nella versione della distribuzione SLES, è un prodotto gestito da Novell [6]e quindi riconosciuto dal supporto tecnico di Novell.
I principali files di configurazione sono sul server e alcuni sul lato client. Qualora si vogliano salvare i dati del server stesso, il server si comporta anche da client. L’installazione di Amanda in SLES installa sia la parte server che la parte client (in altre distribuzioni le due parti sono da installare separatamente).
Amanda si configura attraverso l’editing di files. Il più importante è amanda.conf da creare nella directory /etc/amanda/conf/ dove conf è un nome definito dall’amministratore.
Possono coesistere diverse configurazioni in differenti cartelle conf. /etc/amanda/example riporta una configurazione di esempio. Il suggerimento è di creare una cartella con un nome che ricorda il tipo di backup, ad esempio per il backup giornaliero(/etc/amanda/giornaliero/amanda.conf) e il backup mensile (/etc/amanda/mensile/amanda.conf).
Una prima semplice configurazione è disponibile in http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes [8] ed è quella presa a riferimento per questa descrizione. Si rimanda al documento per i dettagli.
Questa configurazione salva i dati su virtual tape: il disco. La sua implementazione è semplice, perchè non implica la configurazione di device come il tape, e riporta un esempio di gestione di libreria, simulata con diverse cartelle (slot).
In questo documento, la configurazione di Amanda sarà suddivisa nelle seguenti parti:
Con riferimento alla configurazione di test citata, questo è il file (/etc/amanda/test/amanda.conf), principale responsabile del comportamento di Amanda.
org "Acme Inc."
mailto "you@example.com [9]"
dumpcycle 7
runspercycle 5
tapecycle 5
dumpuser "amanda"
tpchanger "chg-disk" # a virtual tape changer
tapedev "file:/space/vtapes/test/slots"
changerfile "/var/lib/amanda/test/changerfile"
labelstr "TEST-.*"
#
logdir "/var/lib/amanda/test"
infofile "/var/lib/amanda/test/curinfo"
indexdir "/var/lib/amanda/test/index"
tapelist "/var/lib/amanda/test/tapelist"
holdingdisk hd1 {
directory "/space/amandahold/test"
}
define dumptype comp-tar {
program "GNUTAR"
compress fast
index yes
record no # Important! avoid interfering with production runs
auth "bsdtcp"
}
define tapetype DVD_SIZED_DISK {
filemark 4 KB
length 4482 MB
}
Il file /etc/amanda/test/disklist indica quali files salvare e da quali client. (test è la cartella di questo esempio di configurazione)
/etc/amanda/test/disklist
sles11.rex.it /var/log comp-tar
srv-smt.rex.it /srv/www comp-tar
I campi sono separati da spazio. Il primo campo indica l’host client, il secondo la cartella (e sottocartelle) da salvare, il terzo la modalità di archiviazione. La modalità di salvataggio, in questo caso comp-tar, è definita nel file di configurazione amanda.conf.
Nell’esempio vengono salvate la cartella /var/log del client sles11.rex.it (che è anche il server amanda) e la cartella /srv/www del server srv-smt.rex.it.
Amanda individua i vari host con il Full Qualified Name (FQN), quindi necessita del supporto DNS. Per le prove si può usare il files /etc/hosts per definire i nomi e gli IP dei vari componenti.
Alcune direttive in amanda.conf definiscono il device di destinazione del backup.
tapedev "file:/space/vtapes/test/slots"
......
tapetype DVD_SIZED_DISK
......
define tapetype DVD_SIZED_DISK {
filemark 4 KB
length 4482 MB
}
La chiave tapedev "file:/space/vtapes/test/slots" definisce il device su cui salvare. Nel caso specifico una cartelle del file system del server di backup. Lo spazio disco viene trattato da Amanda come un nastro le cui caratteristiche sono definite attraverso la chiave tapetype DVD_SIZED_DISK e la corrispondente descrizione nella sezione define tapetype.
Nell’esempio è stato definito uno spazio di 4,4 GB, quanto un DVD. Questo consente di masterizzare le cartelle di backup su DVD.
Nell'esempio, lo spazio disco è usato da Amanda come una libreria di 5 nastri (slot), ognuno della capacità di 4482 MB.
Amanda userà uno o più slot, in funzione dello spazio richiesto per i dati da salvare.
Il primo salvataggio è completo. Tutti i file vengono slavati. I successivi bachup sono incrementali, solo i file modificati vengono salvati. Dopo 4 (5-1) backup incrementali si ricomincia con il salvataggio completo (runspercycle 5). Il backup completo sarà eseguito almeno una volta alla settimana (dumpcycle 7). In ogni ciclo di 7 giorni vengono eseguiti 5 backup (runspercycle 5)
I nastri utilizzati saranno 5 (tapecycle 5). Il che presuppone che non è previsto che un backup richieda più di un nastro.
dumpcycle 7 (giorni)
runspercycle 5
tapecycle 5
Amanda usa un nuovo nastro per ogni backup (amdump). Sovrascrive i nastri una volta completato il tapecycle.
I nastri utilizzati vanno preventivamente inizializzati con una label. Nella configurazione di esempio viene definito il prototipo della label. Questo evita l’uso errato dei nastri. Ad esempio evita che il nastro del salvataggio mensile sia usato nel salvataggio giornaliero..
La label è definita con labelstr "TEST-.*" Qualunque nastro con label che inizia con TEST- è valido per il backup di test.
Amanda non si prende cura del formato di salvataggio. Amanda non ha alcun formato proprietario. Amanda usa strumenti disponibili nel sistema operativo client. Nel caso di linux frequente è l’uso del tar (gtar). Con un client windows è preferibile un formato ZIP.
Questo svincola Amanda da attività che, con strumenti nativi come il tar, sono ben consolidate e standardizzate. Il recupero dei files diventa semplice anche in assenza di amanda: il tar sarà sempre disponibile su un sistema linux. Amanda fornisce comunque propri tools come amrecover e amrestore per il ripristono dei dati
Lo strumento usato da Amanda per salvare i dati è definito nella sezione define dumptype name {....}
L'esempio usa gtar (GNUTAR) e relativa compressione.
define dumptype comp-tar {
program "GNUTAR"
compress fast
index yes
record no
auth "bsdtcp"
}
comp-tar è lo stesso nome richiamato in disklist e definisce lo strumento per salvare i dati e quindi il loro formato.
auth è il tipo di autenticazione prescelto per la comunicazione con il client (il defaul è bsd).
Diverse opzioni sono possibili. Seguendo il file di configurazione di test:
La chiave org è dedicata al nome dell’azienda, ma spesso usata per indicare il tipo di backup, ad esempio “Test” o "Giornaliero"; di fatto org è un commento.
Amanda comunica all’amministratore i risultati del backup via e-mail agli indirizzi indicati con la chiave mailto (gli indirizzi, se più di uno, vanno separati da uno spazio). Senza particolari configurazioni, Amanda usa il servizio di posta presente sul server linux, es. postfix, e i messaggi possono essere gestiti con il comando mail di linux
org "Acme Inc."
mailto "you@example.com [9] other@example.com [14]"
dumpuser indica l’utente linux che dispone dei permessi per il backup. Normalmente l’utente è amanda. Ma può essere modificato. Importante è definire i corretti permessi di accesso ai files e alle procedure.
dumpuser "amanda"
Amanda può gestire librerie o changer la chiave tpchanger definisce la procedura, normalmente una script, per la gestione della libreria. Le script predefinite sono in /usr/lib/amanda.
Le script possono richiedere il supporto di comandi linux. Occorre verificare che questi comandi siano disponibili. Ad esempio la script chg-zd-mtx, fa uso del comando mtx che in SLES deve essere installato: è incluso nella distribuzione.
tpchanger "chg-disk" # a virtual tape changer
changerfile "/var/lib/amanda/test/changerfile"
changerfile definisce un file utile ella script di gestione della libreria. Come, e se, impiegare questa chiave è correlato alla script utilizzata.
logdir indica la directory dei file di log.
infofile e indexdir sono directory usate da Amanda per memorizzare informazioni relative al backup.
tapelist è un file usato da Amanda per la corretta gestione dei nastri (fisici o virtuali)
logdir "/var/lib/amanda/test"
infofile "/var/lib/amanda/test/curinfo"
indexdir "/var/lib/amanda/test/index"
tapelist "/var/lib/amanda/test/tapelist"
Holdingdisk definisce una area di buffer usata da Amanda prima di trasferire i dati sul nastro.
holdingdisk hd1 {
directory "/space/amandahold/test"
}
Numerose altre chiavi sono utilizzabili in amanda.conf. Per un dettaglio si rimanda al man amanda.conf.
Amanda è una tipica applicazione client-server. La parte server di Amanda comunica con la parte client via IP. Il server ‘richiede’ al client i dati da salvare e il client li deve fornire. Questo meccanismo è vero anche se il client è lo stesso server.
Il client è composto da tre processi o daemon principali: amanda, amandaidx e amidxtape. Questi daemon (servizi in Windowds) sono gestiti tramite xinetd e vanno abilitati.
Normalmente i tre daemon comunicano tramite le porte 10080, 10082 e 10083 TCP o UDP (dipende dalla configurazione).
Occorre verificare se le porte citate sono incluse nel file /etc/services. Eventualmente occorre inserirli
amanda 10080/tcp # Amanda
amanda 10080/udp # Amanda
amandaidx 10082/tcp
amidxtape 10083/tcp
Il server (amdump) per connettere il client si deve autenticare. Amanda può usare diversi metodi di autenticazione compreso kerberos e ssh (in questo caso anche il traffico fra client e server è criptato). I metodi più semplici e simili fra di loro sono denominati bsd, bstudp e bsdtcp. Questi ultimi meccanismi di autenticazione usano il file .amandhosts per definire l’utenza autorizzata all’esecuzione dei processi sul client.
/var/lib/amanda/.amandahosts permette di definire quale server può contattare il client, l’utenza e il servizio abilitato con tale utenza.
Il file è nella home directory dell'utente amanda: di default /var/lib/amanda.
Ci sono due modalità di configurazione: via Yast -> Network services – Network services (xinetd) ed è la più semplice perché guidata da yast o modificando manualmente i files di configurazione di xinetd.
Di seguito si riporta la configurazione dei file della cartella /etc/xinetd.d, se modificati manualmente, occorre ricaricare il servizio xinet con rcxinetd reload.
amanda
sles11:/etc/xinetd.d # cat amanda
# default: off
# description: Amanda backup client
service amanda
{
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
}
In questo caso è stato usato il protocolla TCP (e non UDP) con autenticazione bsdtcp.
amandaidx
sles11:/etc/amanda/test # cat /etc/xinetd.d/amandaidx
# default: off
# description: Amanda backup server with indexing capabilities
service amandaidx
{
socket_type = stream
protocol = tcp
flags = IPv4
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amindexd
}
amidxtape
sles11:/etc/amanda/test # cat /etc/xinetd.d/amidxtape
# default: off
# description: Amanda backup server with indexing capabilities
service amidxtape
{
socket_type = stream
protocol = tcp
flags = IPv4
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amidxtaped
}
.amandahosts, come già indicato, è nella home directory dell’utente che esegue il backup (amanda). Normalmente il file è in /var/lib/amanda.
sles11:~ # cat /var/lib/amanda/.amandahosts
sles11.rex.it amanda amdump amindexd amidxtaped
Il file .amandahosts richiede i permessi di lettura/scrittura per l’owner e nessun permesso per il gruppo e per gli altri (chmod 700 /var/lib/amanda/.amandahosts).
Il proprietario del file è l’utente di backup (amanda) il gruppo di default disk.
Nell'esempio sles11.rex.it è il server accettato dal client, amanda l’utenza e di seguito i processi client.
Il file /etc/amanda/amanda-client.conf indica al client quale server gestisce gli indici e il nastro. Il file è utilizzato da amrecover
sles11:/etc/amanda # cat amanda-client.conf
conf "test"
index_server "sles11.rex.it"
tape_server "sles11.rex.it"
auth "bsdtcp"
Conf indica il tipo di configurazione da usare nella controparte server. index_server e tape_server indicano il server di gestione del nastro e degli indici (creati durante il backup).
auth indica il tipo di autenticazione richiesta e deve essere conforme con quanto indicato in amanda.conf
amrecover consente il ripristiono di singoli files da un backup, in contrapposizione a amrestore usato per il ripristino di un intero backup.
Il lancio del programma amrecover -C giornaliero
dove giornaliero è il profilo del backup da gestire, Altre opzioni sono possibili per indicare il tape, l'host da ripristinare ed altro. Per i dettagli si rimanda a man amrecover
Il comando amrecover apre un ambiente interattivo dove è possibile indicare le date di ripristino, il disco da ci ripristinare, ecc.
Il comando listdisk elenca i dischi interessati dal backup
amrecover> listdisk
200- List of disk for host oes.ditta.it
201- /media/nss/DATI/dati-ditta
201- /media/nss/DATI/
201- /etc
200 List of disk for host oes.ditta.it
amrecover>
Il comando setdisk fissa il disco sul quale operare (generalmente una directory).
amrecover> setdisk /media/nss/DATI/dati-ditta
200 Disk set to /media/nss/DATI/dati-ditta.ù
Il sottocomando history elenca la cronologia dei backup e i nastri interessati (SetGiornalieroxx)
amrecover> history
200- Dump history for config "giornaliero" host "oes.apa.it" disk "/media/nss/DATI/dati-ditta"
201- 2011-02-04 0 SetGiornaliero04 2
201- 2011-01-24 0 SetGiornaliero01 2
201- 2011-01-21 0 SetGiornaliero05 2
201- 2011-01-20 0 SetGiornaliero03 2
201- 2011-01-19 0 SetGiornaliero02 2
200 Dump history for config "giornaliero" host "oes.apa.it" disk "/media/nss/DATI/dati-ditta"
amrecover>
Il comando setdate fissa la data del ripristino, fra quelle disponibili in history
amrecover> setdate 2011-01-24
200 Working date set to 2011-01-24.
A questo punto è possibile navigare i files del backup con i comandi cd e ls.
2011-01-24 .
2011-01-24 Direzione-tecnica/
2011-01-24 Eugenio/
2011-01-24 ISO 9001-2000/
2011-01-24 Posta/
2011-01-24 Recycled/
2011-01-24 USR/
2011-01-24 panda/
lines 1-8/8 (END)
il comando add consente di addoungere uno o più files alla lista da estrarre (si possono usare wildcards o liste regolari addx)
amrecover> add Posta
Added dir /Posta at date 2011-01-24
Il comando list elenca i files/directory selezionati
TAPE SetGiornaliero01 LEVEL 0 DATE 2011-01-24
/panda
/Posta
er.
Il comando extract estrae i files / directory selezionati nella cartella corrente (quella dalla quale è stato lanciato il comando amrecover
L’utente amanda deve essere l’owner di tutti i file di configurazione (vedere l’esempio di test, sul sito zamanda, citato). Il gruppo predefinito è disk. Per motivi di sicurezza è bene togliere i permessi a agli altri.
amdump si occupa del backup e della gestione del tape, occorre modificare i permessi di accesso al tape cambiando l'owner in amanda e gruppo in disk
Per lanciare il backup si usa il comando amdump configurazione (es amdump test). L'utente che esegue amdump deve essere amanda (dumpuser "amanda").
Eventuali errori sono da cercare nei file di log.
Utile è il comando amcheck configurazione (es. amcheck test). amcheck controlla che i files di configurazione del server e dei client siano corretti e coerenti. Leggendo attentamente l’output del comando è possibile risolvere molti problemi.
Utile fonte di informazioni è il web, in particolare il wiki di Zamanda (http://wiki.zamanda.com [19]).
La direttiva define tapetype nel file amanda.conf descrive il dispositivo di backup. Diverse descrizioni sono nel file /etc/amanda/example/amanda.conf. Altre sono disponibili in http://wiki.zmanda.com/index.php/Tapetype_definitions [20]. Nel caso che nessuna descrizione sia valida per il tape in uso, si può ricorrere al comando amtape –f nomedevice. Questo comando accede al device con test di scrittura (il comando è distruttivo: usare una cassetta vuota) fino a determinarne le caratteristiche. Il comando può richiedere anche un tempo di ore prima di restituire l’informazione richiesta.
Completata la configurazione il backup si può eseguire con il comando amdump conf (es. amconf test).
Il comando deve essere eseguito dall'utente amanda.
L'esempio commentato è per 5 backup settimanali nei giorni lavorativi.
Per eseguire il backup automaticamente è utile il cron di linux. Qualora i nastri non siano gestiti da una libreria è bene avvisare l'operatore di cambiare il nastro. Pure questa azione può essere pianificata con il cron usando il comando amcheck.
Un semplice esempio di cron è il seguente:
0 16 * * 1-5 /usr/sbin/amcheck -m test
45 23 * * 1-5 /usr/sbin/amdump test
Il primo comando, amcheck, viene eseguito in orario di lavoro, non produce oputput (opzione -m) ma manda una e-mail agli indirizzi indicati con la direttiva mailto nel file /etc/amanda/test/amanda.conf
Il secondo comando avvia il backup nei giorni dal lunedì al venerdì.
Alcuni appunti per la configurazione di amanda:
amcheck configurazione é un ottimo strumento per il contollo della corretta configurazione di amanda.
Leggere attentamente l'ouput per individuare i problemi. Questo è un esempio:
amanda@oes [25]:~> amcheck giornaliero
Amanda Tape Server Host Check
-----------------------------
ERROR: tapefile /etc/amanda/giornaliero/tapelist: No such file or directory, you must create an empty file.
ERROR: holding dir /dumps/amanda: No such file or directory, you must create a directory.
ERROR: /dev/nst0: not an amanda tape
(expecting a new tape)
NOTE: skipping tape-writable test
NOTE: info dir /var/lib/amanda/giornaliero/curinfo: does not exist
NOTE: it will be created on the next run.
NOTE: index dir /var/lib/amanda/giornaliero/index: does not exist
NOTE: it will be created on the next run.
Server check took 7.438 seconds
Amanda Backup Client Hosts Check
--------------------------------
WARNING: apa-oes.apa.it: selfcheck request timed out. Host down?
Client check: 1 host checked in 30.003 seconds, 1 problem found
(brought to you by Amanda 2.4.5)
Nel caso che la definizione del nastro non sia diaponibile nel citato sito citato nelle osservazioni, è possibile ottenere una definizione corretta usando il comando amtapetype -f device dove device indica il device nastro (es. /dev/nst0).
Il comando scrive sul nastro ne ritorna le caratteristiche. L'operazione può durare anche diverse ore.
Questo è un esmpio di output del comando
oes:~ # amtapetype -f /dev/nst0
Writing 2048 Mbyte compresseable data: 32 sec
Writing 2048 Mbyte uncompresseable data: 101 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 1024 Mbyte: 101 sec = 0 h 1 min
wrote 6120132 32Kb blocks in 18716 files in 100445 seconds (short write)
wrote 5883648 32Kb blocks in 36096 files in 174563 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression on)"
length 199201 mbytes
filemark 435 kbytes
speed 1514 kps
}
oes:~ #
Basta copiare la definizione ottenuta (la parte in grassetto) nel file amanda.conf.
Si suggerisce di modificare unknown-tapetype con un nome più adeguato.
Permessi del dispositivo tape
L'utente che esegue il backup è amanda e fa parte del gruppo disk (se il default non è stato modificato) pertanto il device per il backup (es /dev/nst0) deve avere owner amanda e grpup disk. Questo può essere fatto con il comando chown amanda:disk /dev/nst0, ma al rivvio del server il dispositivo riprenderà utente e gruppo precedenti (di solito root, root)
I device (/dev/nst0 nell'esempio) sono creati al boot della macchina usando i dati del sysfs (/sys) e i meccanismi di udev. udev legge delle regole nella cartella /etc/udev/rules.d e definisce i device, i link simbolici e altro.
Occorre aggiungere o modificare le regolo in questione per fare modificare giaà dal boot user e group del nastro.
Nel caso di SLES 10 la regola modificata è la seguente:
KERNEL=="nst[0-9]*", BUS=="scsi", ENV{ID_SERIAL}=="", IMPORT{program}="/sbin/scsi_id -g -x -s %p -d $tempnode", OWNER="amanda"
nel file: 60-persistent-storage.rules
Il comando per forzare la lettura e l'applicazione della nuova regola è, in SLES 10, udevtrigger.
In SLES 11 c'è una nuova sintassi per i comandi udev (udevadm) e le regole di default sono differenti, ma il concetto non cambi.
Inizializzazione nastro
Il nastro, prima di essere utilizzato deve essere ecorrettamente etichettato, non una etivhetta fisica, ma scritta con il comando amlabel
es amlabel giornaliero SetGiornaliero09
dove giornaliero è il profilo di backup a cui è destinato il nastro definito in amanda.conf
e SetGiornaliero09 rispetta il pattern definito alla linea labelstr sempre in amanda.conf
Cancellare il nastro dall'elenco dei disponibili
Amanda mantiene un elenco di nastri utilizzabili (/etc/amanda/bkconfig/tapelist) e inizializzati con amlabel. Per imuovere un nastro dall'elenco usare alrmtape
es: amrmtape -v giornaliero SetGiornaliero02
Diverse cartelle del file system sono da creare con owner amanda e gruppo disk (almeno nella configurazione riportata).
Creare la directory per il dump di amanda come indicato in amanda.conf nella seszione holdingdisk
(es.directory "/dumps/amanda" ----> mkdir -p /dump/amanda; chown -R amanda:disk /dump).
Creare anche /var/lib/amanda/configurazione e sistemare owner e gruppo.
Creare il file vuoto tapelist nella cartella /etc/amanda/configurazione
(es. touch /etc/amanda/giornaliero/tapelist; chown amanda:disk /etc/amanda/giornaliero/tapelist)
Modificare i permessi di accesso al nastro (o delle cartelle destinate a contenere il backup).
Atenzione sesi tratta di un nastro (es. /dev/nst0 ) i permessi venìgono ridefiniti all'avvio del server quaindo il file system virtuale viene creato.
Attnezione alle varie versioni di amanda.
Ad esempio la versione 2.4.5-17.2, distribuita con SLES 10.3, sembra non supportare l'autenticazione bsdtcp e quindi la riga di configurazione auth "bsdtcp" nel file amanda.conf non è riconosciuta e quindi va tolta, modificando quindi anche la configurazione del file /etc/xinet.d/amanda .
SLES12 SPxx
Amanda non è più supportato in SLES versione 12. E' comunque disponibile al seguente link:
https://software.opensuse.org/download.html?project=Archiving&package=am... [31]
Se durante alcune operazioni (amrecover, amrestore, ecc.) ci sono errori del tipo:
[access as amanda not allowed from root@localhost [33]] amandahostsauth failed
il problema si risolve editando correttamente il file /var/lib/amanda/.amandahosts
per l'errore di cui sopra si suggerisce di aggiungere la riga:
localhost root amindexd amidxtaped
che da i permessi allo user root per l'accesso a localhost
Links
[1] http://amanda.org/copyright.php
[2] http://zmanda.com/
[3] https://www.rfc.it/category/categoria/backup
[4] https://www.rfc.it/category/categoria/linux
[5] http://www.amanda.org/download.php
[6] http://www.novell.com/linux/
[7] https://www.rfc.it/comment/reply/84#comment-form
[8] http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes
[9] mailto:you@example.com
[10] https://www.rfc.it/comment/reply/85#comment-form
[11] https://www.rfc.it/comment/reply/86#comment-form
[12] https://www.rfc.it/comment/reply/87#comment-form
[13] https://www.rfc.it/comment/reply/88#comment-form
[14] mailto:other@example.com
[15] https://www.rfc.it/comment/reply/89#comment-form
[16] https://www.rfc.it/comment/reply/90#comment-form
[17] https://www.rfc.it/comment/reply/91#comment-form
[18] https://www.rfc.it/comment/reply/123#comment-form
[19] http://wiki.zamanda.com
[20] http://wiki.zmanda.com/index.php/Tapetype_definitions
[21] https://www.rfc.it/comment/reply/92#comment-form
[22] https://www.rfc.it/comment/reply/93#comment-form
[23] https://www.rfc.it/comment/reply/112#comment-form
[24] https://www.rfc.it/category/categoria/windows
[25] mailto:amanda@oes
[26] https://www.rfc.it/comment/reply/115#comment-form
[27] https://www.rfc.it/comment/reply/113#comment-form
[28] https://www.rfc.it/category/categoria/amanda
[29] https://www.rfc.it/category/tipologia/applicativi
[30] https://www.rfc.it/comment/reply/114#comment-form
[31] https://software.opensuse.org/download.html?project=Archiving&package=amanda
[32] https://www.rfc.it/comment/reply/116#comment-form
[33] mailto:root@localhost
[34] https://www.rfc.it/comment/reply/122#comment-form