Topic: Problema backup

[killrob]

Salve a tutti
sul server&gateway SME 7.5.1 faccio 2 backup, il primo è quello integrato nel server che parte alle 2.00 di notte ed è un backup su workstation, il secondo è fatto con il contrib DAR2 che parte alle 5.00 del mattino.
Il problema è che il backup integrato non funziona mentre il backup di DAR2 si.
I backup vengono fatti su un disco usb formattato in ext3 montato localmente sul server.
l'errore che mi comunica il server via mail è il seguente:
"==================================
DAILY BACKUP TO WORKSTATION REPORT
==================================
Backup started at Tue Dec 20 02:00:06 2011
Backup of mysql databases has been done
Mounting backup shared directory localhost/media/usbdisk
*** No backup allowed or error during backup ***
Error while mounting /media/usbdisk :
mount: can't find /media/usbdisk in /etc/fstab or /etc/mtab"


Ho appena montato il disco usb e con df -h dato da root me lo vede correttamente dandomi dimensione, spazio utilizzato, spazio usato, percentuale di utilizzo e mount point, il mountpoint è /media/usbdisk.
Seguendo il manuale di SME per i dischi usb nell'fstab ho aggiunto la seguente riga:
LABEL=usbdisk  /media/usbdisk ext3 defaults 0 0

dove sta l'errore?

[nicolatiana]

1) Perchè 2 backup con due sistemi diversi ma sullo stesso disco ? Una manovra simile avrebbe senso solo se facessi uno dei due su un disco di rete;
2) A parte ciò: sei sicuro che i due backup non vadano in sovrapposizione (= DAR2 rimane in hang dal giorno prima ed impedisce il mount a DAR) -> controlla i log in /var/log e facci sapere qualche cosa di più.
 
Saluti
 
Nicola

[killrob]

ok controllerò ma non credo che DAR2 impedisca a DAR di funzionare, non funzionava già prima che installassi il contrib DAR2 (ho installato DAR2 proprio per questo motivo).
Faccio 2 backup perchè con DAR2 (forse non sono capace io) non riesco a fargli fare backup incrementali mentre con DAR è possibile farli

[nicolatiana]

Mi risulta che se DAR trova il disco già montato va in errore e non procede oltre; siccome sembra un errore di mount del disco cerca di capire perchè non riesce a fare il mount dello stesso.
DAR2 non può fare Backup incrementali. Nel caso, per fare le prove con DAR, rimuovi comunque DAR2 a scanso di confusioni pericolose.
 
Nel caso non trovassi soddisfazione e se non sei ancora in produzione prova a cimentarti con Affa (vedi in particolare -> http://wiki.contribs.org/Affa#Alternatively_setup_a_USB_drive) che ti offre il vantaggio di avere delle cartelle accessibili direttamente; non fa compressione dei dati ma usando gli hard-link il problema è trascurabile.
 
Saluti
 
Nicola

[killrob]

DAR2 smonta il disco una volta terminato il suo backup vedrò che mi dice il /var/log e proverò a vedere affa.
nel frattempo grazie e buon anno se non ci si risente prima

[killrob]

allora, rieccomi qui, ho effettuato varie prove ma non ho risolto nulla. DAR continua a dirmi che non riesce a trovare il disco usb mentre DAR2 ci riesce benissimo.
Ho provato disinstallando DAR2 ho riformattato il disco usb in ext3 l'ho collegato su diverse porte ma nulla da fare il backup termina sempre in modo anomalo con il messaggio scritto nel primo post.
ho provato anche a farglielo trovare sian montato che smontato il disco usb ma non cambia nulla.
Ho reinstallato il DAR2 che almeno un backup funzionanate ce l'ho.
Non so più che pesci prendere

[Fumetto]

Non per dire ma... hai letto qui?

[killrob]

ora ho letto ed ho fatto quello che c'era scritto adesso vediamo che succede
grazie

[nicolatiana]

Ciao Tony
 
Ma non era stato risolto ? 
 
Nicola

[Fumetto]

In effetti non ho provato, ma su una macchina sempre aggiornata in produzione ho un

Code: [Select]

login as: root
root@192.168.1.100's password:
Last login: Wed Dec 28 09:43:29 2011 from pc-00250.azienda.lan
[root@sme ~]# rpm -qa hal
avvertimento: only V3 signatures can be verified, skipping V4 signature
avvertimento: only V3 signatures can be verified, skipping V4 signature
avvertimento: only V3 signatures can be verified, skipping V4 signature
hal-0.4.2-9.el4_8
avvertimento: only V3 signatures can be verified, skipping V4 signature
[root@sme ~]#Quindi penso non sia stato risolto se non con qualche workaround... tra l'altro il bug è ancora aperto.

PS: Azz.. niente storia questo lunedì...

[killrob]

niente da fare, nonostante le modifiche suggerite dal quel post l'errore è rimasto. Non riesce a montare il disco

[nicolatiana]

Mmmm . . . . hai provato a guardare se in /var/log/messages riusciamo a trovare qualche info in più rispetto al messaggio di errore che DAR si spedisce per posta ?
 
Nicola

[killrob]

si ho provato a cercare ma non ci sono errori o messaggi di sorta
questo è l'estratto del messages relativo all'orario in cui parte il DAR"

"Jan  4 02:00:03 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: OLD 1325638803=(undefined)
Jan  4 02:00:03 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: NEW 1325638803=backup_record
Jan  4 02:00:03 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: OLD 1325638803=backup_record
Jan  4 02:00:03 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: NEW 1325638803=backup_record|StartEpochTime|1325638803
Jan  4 02:00:03 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: OLD 1325638803=backup_record|StartEpochTime|1325638803
Jan  4 02:00:03 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: NEW 1325638803=backup_record|BackupType|workstation|StartEpochTime|1325638803
Jan  4 02:00:03 sassone01 esmith::event[12609]: Processing event: pre-backup
Jan  4 02:00:03 sassone01 esmith::event[12609]: Running event handler: /etc/e-smith/events/actions/generic_template_expand
Jan  4 02:00:04 sassone01 esmith::event[12609]: expanding /etc/dar/DailyBackup.dcf
Jan  4 02:00:04 sassone01 esmith::event[12609]: generic_template_expand=action|Event|pre-backup|Action|generic_template_expand|Start|1325638803 869292|End|1325638804 745740|Elapsed|0.876448
Jan  4 02:00:04 sassone01 esmith::event[12609]: Running event handler: /etc/e-smith/events/pre-backup/S10mysql-delete-dumped-tables
Jan  4 02:00:04 sassone01 esmith::event[12609]: S10mysql-delete-dumped-tables=action|Event|pre-backup|Action|S10mysql-delete-dumped-tables|Start|1325638804 746315|End|1325638804 897519|Elapsed|0.151204
Jan  4 02:00:04 sassone01 esmith::event[12609]: Running event handler: /etc/e-smith/events/pre-backup/S20mysql-dump-tables
Jan  4 02:00:05 sassone01 esmith::event[12609]: S20mysql-dump-tables=action|Event|pre-backup|Action|S20mysql-dump-tables|Start|1325638804 898116|End|1325638805 996999|Elapsed|1.098883
Jan  4 02:00:05 sassone01 esmith::event[12609]: Running event handler: /etc/e-smith/events/pre-backup/S50rewind-tape
Jan  4 02:00:06 sassone01 esmith::event[12609]: S50rewind-tape=action|Event|pre-backup|Action|S50rewind-tape|Start|1325638805 997598|End|1325638806 275641|Elapsed|0.278043
Jan  4 02:00:07 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: OLD 1325638803=backup_record|BackupType|workstation|StartEpochTime|1325638803
Jan  4 02:00:07 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: NEW 1325638803=backup_record|BackupType|workstation|EndEpochTime|1325638807|StartEpochTime|1325638803
Jan  4 02:00:07 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: OLD 1325638803=backup_record|BackupType|workstation|EndEpochTime|1325638807|StartEpochTime|1325638803
Jan  4 02:00:07 sassone01 /sbin/e-smith/do_backupwk[12608]: /home/e-smith/db/backups: NEW 1325638803=backup_record|BackupType|workstation|EndEpochTime|1325638807|Result|backup:7424|StartEpochTime|1325638803
Jan  4 02:47:47 sassone01 squid[5438]: sslReadServer: FD 18: read failure: (104) Connection reset by peer
Jan  4 02:53:13 sassone01 squid[5438]: sslReadServer: FD 17: read failure: (104) Connection reset by peer
Jan  4 02:54:28 sassone01 squid[5438]: sslReadServer: FD 17: read failure: (104) Connection reset by peer
Jan  4 02:57:30 sassone01 squid[5438]: sslReadServer: FD 18: read failure: (104) Connection reset by peer"

gli unici errori, che non so che significano sono nelle ultime 4 righe ma non credo che siano relative al backup visto l'orario

[Mat78]

Ciao, per risolvere il problema momentaneamente, senza intervenire sul sistema, potresti aggiungere il contribs "crontab-manager" (http://wiki.contribs.org/Crontab_Manager) ed aggiungere come operazione giornaliera il comando "umount /media/usbdisk" qualche minuto prima dell'inizio del backup.

[killrob]

ci posso anche provare ma il disco è già smontato prima che parta il backup di DAR, me ne sono assicurato

[ale1972]

Salve,
ho avuto sino a mezz'ora fa lo stesso identico problema, fortunatamente sono incappato in un post in cui si metteva in evidenza il fatto che settando sme tramite ultime versioni di browser (nel mio caso ff), la configurazione di db relativamente a bckupwrk veniva falsata dall'aggiunta di "^M" in corrispondenza di smbshare media/usbdisk. La soluzione è aggiornare e-smith-backup alla versione 2.0.0-36.el14.sme attivando i repository di test.

Rif: http://bugs.contribs.org/show_bug.cgi?id=6605   (commento 5)
e
http://bugs.contribs.org/show_bug.cgi?id=6512    (commento 50)

Saluti.

[killrob]

Ok forse ho risolto grazie alla segnalazione di ale1972, effettivamente c'era il carattere "^M" alla fine di /media/usbdisk. Senza fare upgrade di sorta, ho modificato il file configuration sotto /home/e-smith/db togliendogli quel doppio carattere e già le cose sono migliorate in quanto, facendo una prova di verifica backup workstation dal server manager, mi rispondeva sempre impossibile montare il disco /media/usbdisk, mentre adesso ha montato il disco e mi ha fatto la verifica. Domani vedo come è andato il backup, nel frattempo grazie a tutti.

[ale1972]

Ipotesi:
temo sia, la tua, Killrob, però, una soluzione temporanea in quanto la prossima volta che rimodificherai le impostazioni di backup, per qualche motivo, utilizzando il server-manager invaliderai nuovamente il file db.

Saluti

[killrob]

si ale lo so che è una soluzione di "ripego" ma non credo di modificare ulteriormente il backup, una volta funzionante.
Comunque penso di fare le modifiche direttamente sui files e non utilizzando il server manager, adesso che so quali sono il files di configurazione.

Ha funzionato adesso mi serve solo una procedura automatica che smonti il disco usb al termine dal backup di DAR, che parte alle 2:00 di notte, perchè altrimenti il backup di DAR2, che parte alle 5:00 di notte, non va perchè trova il disco usb già montato e lo smonta senza fare il backup.

[killrob]

a che ora girano gli script in cron.daily? non sono riuscito a trovare info da nessuna parte...

se ho capito giusto andando a vedere nel crontab in /etc il cron.daily viene eseguito tutti i giorni alle 4:02 di notte... me lo confermate?

02 4 * * * root run-parts /etc/cron.daily

[killrob]

Ok, adesso funzionano entrambi i backup. Grazie a tutti per le dritte ed i consigli.

p.s.: per chi non lo sapesse... non andate a modificare l'orario del .daily in crontab perchè il crontab viene rigenerato automaticamente, modificate il valore che vi interessa direttamente in /etc/e-smith/templates/etc/crontab.
e chiedo scusa a chi già lo sapeva

[Stefano]

biiip!

risposta errata

se modifichi un file in /templates/ potrebbe essere sovrascritto in un aggiornamento.

devi lavorare in /templates-custom/

per maggiori dettagli cerca qui nel forum nei miei post

[killrob]

ma di fare la modifica in templates l'ho letto sul wiki
http://wiki.contribs.org/SME_Server:Documentation:Developers_Manual alla voce Exercise 1: changing a configuration template

cercalo anche tu e dimmi se ho sbagliato a seguire la documentazione

e comunque sono andato a vedere nella /template-custom/etc/ c'è solo una directory che si chiama yum.conf  che ha al suo interno una file chiamato 15main_exclude_hal, mentre nella /templates-custom non c'è niente.

Ok ho letto meglio la doc ed ho capito, dovrei creare nella /templates-custom/etc/ una directory crontab copiarci dentro il file 10runparts e fare li dentro la modifica dell'esecuzione del cron.daily e dare il comando expand-template /etc/crontab, giusto?

[Stefano]

il principio base è il seguente:
tutto quello che è in templates in caso di backup e restore viene perso

se devi aggiungere o personalizzare una entry devi lavorare in templates-custom

quindi, nel tuo caso, devi
1) creare la directory  /etc/e-smith/templates-custom/etc/cron.daily
2) copiare il fragment di tuo interesse li dentro
3) modificare quel fragment come ti serve

in questo modo sei certo non solo che le tue modifiche sopravviveranno ad un upgrade del pacchetto, ma che le stesse verranno copiate nel backup E saranno presenti in un eventuale restore dello stesso

[killrob]

ok questo per aggiungere il fragment da far eseguire giornalmente, ma per modificare l'orario di esecuzione del cron.daily, per portarlo dalle 4:02 alle 5:02, devo fare la modifica come ho detto nel mio precedente post giusto?

[Fumetto]

...devo fare la modifica come ho detto nel mio precedente post giusto?

No...

...nel tuo caso, devi
1) creare la directory  /etc/e-smith/templates-custom/etc/...
2) copiare il fragment di tuo interesse li dentro
3) modificare quel fragment come ti serve

[killrob]

allora non credo di aver capito.....

creo la directory cron.daily in /etc/e-smith/templates-custom/etc/ e ci metto dentro il fragment da far eseguire giornalmente, e fin qui ci siamo, ma se voglio modificare l'ora di esecuzione del cron.daily, che adesso è alle 4:02 del mattino, non devo modificare il crontab creando la directory crontab in /etc/e-smith/templates-custom/etc/ e mettendo li dentro il file con il comando per cambiare l'ora di esecuzione? io avevo capito in questo modo...

[Fumetto]

Ho dato un'occhiata ma io non ho la config che hai tu quindi vado "a naso"...
Se tu riesci a ottenere quello che vuoi modificando il file /etc/e-smith/templates/etc/crontab/10runparts puoi semplicemente copiare lo stesso file in /etc/e-smith/templates-custom/etc/crontab/10runparts e modificarlo in base alle necessità; tale sistema ti permetterà, come già detto dal Luminare, di "backuppare" la modifica e renderla resistente agli upgrade.

Tutto quanto scritto sopra con riserva di rettifica... non ho testato

PS: RTFM!!! Almeno due volte... 

(senza offesa eh)

[Stefano]

scusa Fumetto ma.. luminare a chi?

[killrob]

... lo stesso file in /etc/e-smith/templates-custom/etc/crontab/10runparts e modificarlo in base alle necessità; tale sistema ti permetterà, come già detto dal Luminare, di "backuppare" la modifica e renderla resistente agli upgrade.

è esattamente quello che ho fatto... e funziona.
Se "l'offesa" era rivolta a me... non è stata raccolta sto quasi imparando il FM a memoria

[Stefano]

Se "l'offesa" era rivolta a me... non è stata raccolta sto quasi imparando il FM a memoria

no no, tranquillo.. era rivolta a me