Backup problem

[John]

hallo,

ich erhalte immer wenn ich die Backup.pl ausführe folgende fehlermeldung:

<Rechner>:/usr/share/otrs/scripts# ./backup.pl -d backup/
tar: backup//2007-08-24_16-58/SymLinks.tar.gz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
xargs: tar: terminated by signal 13
failed
Backup backup//2007-08-24_16-58/Config.tar.gz ... tar: backup//2007-08-24_16-58/Config.tar.gz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
failed
Backup backup//2007-08-24_16-58/Application.tar.gz ... tar: backup//2007-08-24_16-58/Application.tar.gz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
failed
Dump MySQL rdbms ... done
Compress SQL-file... done

ich denke ich mache alles wie in der doku auf otrs.org beschrieben. Ich habe im Verzeichnis /usr/share/otrs/scripts zuvor den ordner backup angelegt. muß dieser evtl an eine andere Stelle? aber bitte sagt mir dann wohin.

Danke

[larf]

ich denke ich mache alles wie in der doku auf otrs.org beschrieben. Ich habe im Verzeichnis /usr/share/otrs/scripts zuvor den ordner backup angelegt. muß dieser evtl an eine andere Stelle? aber bitte sagt mir dann wohin.

Versuchs mal mit einer vollständigen Pfadangabe, also in deinem Fall:

Code: Select all

 /backup.pl -d /usr/share/otrs/scripts/backup

Ansonsten ist es so aus rein administrativen Gründen nicht unbedingt der beste Ort, im Script-Ordner die Backups anzulegen.

[jojo]

Hallo,

ich würde mal auf mangelnde Schreibrechte tippen.

Probier mal als Zielverzeichnis /tmp (nautürlich nur zum testen)

[John]

Es ist sowieso nur ein testsystem, aber dennoch soll es später online gehen.
ich habe jetzt mal den gesamten pfad angegeben und das verzeichnis gewechselt. Jetzt erhalte ich folgende fehlermeldung, die ich mir gar nicht erklären kann:

<Rechner>:/usr/share/otrs/scripts# ./backup.pl -d /usr/share/otrs/backup
done
Backup /usr/share/otrs/backup/2007-08-27_10-36/Config.tar.gz ... done
Backup /usr/share/otrs/backup/2007-08-27_10-36/Application.tar.gz ... tar: ./backup/2007-08-27_10-36/Application.tar.gz: file changed as we read it
failed
Dump MySQL rdbms ... done
Compress SQL-file... done
snoopy:/usr/share/otrs/scripts#

Er legt die dateien aber an, wie folgendes beweist:

-rw-r--r-- 1 root root 6205519 2007-08-27 10:36 Application.tar.gz
-rw-r--r-- 1 root root 15239 2007-08-27 10:36 Config.tar.gz
-rw-r--r-- 1 root root 49242 2007-08-27 10:36 DatabaseBackup.sql.gz
-rw-r--r-- 1 root root 226 2007-08-27 10:36 SymLinks.tar.gz

was soll dann die fehlermeldung zu application.tar.gz? kann es sein, dass noch agents verbunden waren? sollte eigentlich aber auch nicht sein!
Danke schon mal im voraus für die hilfe

[jojo]

Hallo,

die Application.tar.gz behinhaltet den Inhalt des gesamten OTRS Verzeichnisses, also auch Dein Backup Verzeichnis und sich selber, das kann also gar nicht wirklich funktionieren. Nimm als Zielverzeichnis ein Verzeichnis außerhalb des OTRS Basisverzeichnisses!

BTW: Eigentlich hat Deine Frage relativ wenig mit OTRS zu tun, sondern mit *NIX Wissen...

[larf]

Es ist sowieso nur ein testsystem, aber dennoch soll es später online gehen.

Wenn es jetzt auch als Testsystem genutzt wird, würde ich für das Produktivsystem nochmal ein ganz "sauberes" System installieren und nicht das eventuell unbemerkt verbastelte Testsystem. Aber das wieder nur am Rande.

was soll dann die fehlermeldung zu application.tar.gz? kann es sein, dass noch agents verbunden waren? sollte eigentlich aber auch nicht sein!
Danke schon mal im voraus für die hilfe

Für eine solche Fehlermeldung reicht es schon, dass das Log geändert wird (so es denn auch dort irgendwo lieg) und da auf deinem System auch diverse Cron-Jobs laufen, ist es nicht unwahrscheinlich, dass grade zu dem Zeitpunkt des Backups etwas geändert wurde. Du kannst ja einfach das Backup testen und hast damit die Bestätigung, dass alles funktioniert hat.

Und nochmal zum Backup im OTRS-Ordner: falls du das Backup über Cron-Jobs laufen lässt, ist das eine tödliche Idee. Durch das rekursive Backup ist die Platte irgendwann voll und dein System down. Das macht keinen Spaß (ich spreche da aus Erfahrung und änder seitdem 2 Sekunden vor Feierabend keine Cronjobs mehr ).

[John]

wenn ich zum befehl backup.pl aber noch das kürzel -r 30 setze, sollten die backups doch nur 30 tage gültig sein und anschließend verschwinden. leider bin ich noch nicht so weit dies zu sehen. geschieht das auch so, oder verbleiben die backups auf dem laufwerk?

[larf]

wenn ich zum befehl backup.pl aber noch das kürzel -r 30 setze, sollten die backups doch nur 30 tage gültig sein und anschließend verschwinden. leider bin ich noch nicht so weit dies zu sehen. geschieht das auch so, oder verbleiben die backups auf dem laufwerk?

Nein, da hat einfach so jemand nen Parameter hingeschrieben... das ist nur ein Scherz.

Sorry, aber natürlich funktioniert das so.
30 Tage halte ich allerdings für eine recht weite Zeitspanne - meine Vollbackups gehen so langsam auf die 500 MB (pro Backup). Ob du das 30 mal auf der Platte haben willst?

[John]

natürlich möchte ich die nicht 30 mal auf der platte haben. war ja nur mal ne zahl in den raum geschmissen.

außerdem gehe ich davon aus, dass der Backup-cronjob nicht täglich ausgeführt wird, sonsern 1-mal wöchentlich. ich denke das reicht für mich als vollbackup. dass wären dann maximal 4 Vollbackups innerhalb eines Monats (in deinem Fall 2 GB); da der festplattenspeicher derzeit recht günstig ist, wird meinem System halt eine größere Platte spendiert. außerdem rechne ich nicht damit, dass ich täglich 10 000de tickets bearbeiten muß.

DANKE trotzdem für den Hinweis.

[Andre Bauer]

meine Vollbackups gehen so langsam auf die 500 MB (pro Backup)

Ich bin bei 60 GB