Datenbanken haben i.d.R. ihren eigenen Sicherungsmechanismus - den sollte man auch für die Datenbank benutzen.
Wenn die DB nicht durchläuft, dann sollte aber auch ein

/etc/init.d/mysql stop

o.ä. vor der Sicherung funktionieren.

Hallo,

bin noch relativ neu im Linux, habe aber schon ein halbes Jahr Erfahrung. Ich hätte da als Nichtprofi noch ein paar Anregungen für die Wiki

Du schreibst, dass man die Datei Backup im Ordner bin anlegen soll. Im Verzeichnis /bin habe ich aber keine Zugriffrechte. Oder meinst du im Ordenr Home/bin? Falls ja, warum dahin, weil es den ja noch nicht gibt. So gesehen ist das doch egal, wo es liegt oder?
Jedenfalls habe ich es auf dem Desktop angelegt und bin per Terminal in das Verzeichnis gewechselt. Dort habe ich den chmod-Befehl gemacht und danach habe ich einfach „backup“ eingegeben wie du geschrieben hast. Leider hat er wohl irgendeinen Systembefehl oder so ausgeführt, jedenfalls wollte er OpenAFS installieren. Hab ich gemacht und die Fragen die ich nicht verstanden habe einfach abgenickt. Danach ging es aber auch nicht. Also OpenAFS wieder deinstalliert. Dann habe ich die backup in backup.sh umbenannt, chmod gemacht und nochmals ausgeführt. Dann ging es!

Also vielleicht noch die zwei Änderungen in die Wiki und dann luppt das

Ich danke dir auf jeden Fall für deine Mühe. Ich habe schon vor ein paar Monaten nach einem einfachen Skript gesucht mit dem ich meine Dateien verschlüsselt auf einen externen Datenträger mit NTFS spielen konnte. Ich brauche dort NTFS, weil es gleichzeitig meine Windows-Backupplatte ist. Und dank deinem Skript habe ich nun ein Backup-Programm für meinen TrueCrypt-Container-Inhalt.

Das Skript lässt sich jetzt mit folgendem Befehl starten:

backup  

stimmt einfach nicht, weder aus $HOME/bin heraus, dann wärs

./backup  

noch von überall anders, dann wärs

$HOME/bin/backup  

so hab ich es jetzt auch geändert. Ich sehe den Sinn von $HOME/bin ohnehin nicht ganz, sollte sowas nicht eigentlich z.B. in /usr/local/bin stehen? Dann könnte man es tatsächlich mit

backup  

starten.

Gruß,

mesrumma

mesrumma schrieb:

Das Skript lässt sich jetzt mit folgendem Befehl starten:

> backup 
>  

stimmt einfach nicht, weder aus $HOME/bin heraus, dann wärs

./backup  

./backup funktioniert in dem Verzeichnis, in dem das Skript liegt, denn ./ bezeichnet das aktuelle Verzeichnis, unabhängig davon, wie das aktuelle Verzeichnis heißt.

noch von überall anders, dann wärs

Doch, wenn $HOME/bin im Pfad ist, das ist bestimmt auf diesen 6 Seiten, die 1,5 Jahre alt sind, irgendwo gesagt.

Ich sehe den Sinn von $HOME/bin ohnehin nicht ganz, sollte sowas nicht eigentlich z.B. in /usr/local/bin stehen? Dann könnte man es tatsächlich mit

backup  

starten.

Das hängt nur davon ab, ob das Verzeichnis im Pfad ist, nicht, wie das Verzeichnis heißt.

Der Sinn eines Verzeichnisses für selbstgebaute Scripte in ~/bin ist, daß man dort auch nur selbstgebaute Sachen ablegt, und mit einer Kopie des Verzeichnisses auf einen USB-Stick z.B. dann alle Eigenbauten dabei hat.

Außerdem packen sich manche Leute ihr home-Verzeichnis auf eine eigene Partition. Wenn man dann eine neue Version parallel installiert, die auf eine neue Partition kommt, und wenn alles klappt löscht man die alte Systempartition, dann muß man auf /usr/local nicht besonders achten.

Aber das ist auch Gewohnheit. Wenn sich mehrere Leute einen Rechner teilen, dann ist /usr/local besser, damit alle das nutzen können - oder man linkt von da aus nach ~/bin, und hat das beste aus 2 Welten.

Doch, wenn $HOME/bin im Pfad ist, das ist bestimmt auf diesen 6 Seiten, die 1,5 Jahre alt sind, irgendwo gesagt.

Dann sollte man das ins Wiki schreiben. Hab mir gestern den Artikel durchgelesen und gedacht, dass das vermutlich nicht funktioniert, wenn man den Artikel, so wie er ist, durcharbeitet und $HOME/bin nicht im Path hat, wie es ja nun standardmäßig erstmal ist. Ich habs dann getestet und es hat tatsächlich nicht funktioniert. Ich habe dann Seite 1 und 6 von der Diskussion gelesen und der letze Post vor mir hatte auch erstmal Probleme damit. Man kann eigentlich nicht erwarten, dass jemand 6 Seiten Diskussion zum Artikel liest, bis es funktioniert.

Gruß,

mesrumma

Hier war bereits die Rede von den bin-Verzeichnissen: http://forum.ubuntuusers.de/post/1074053/

mesrumma schrieb:

Dann sollte man das ins Wiki schreiben.

Deswegen hast Du da Schreibrechte. Laß Dich nicht aufhalten!

Deswegen hast Du da Schreibrechte. Laß Dich nicht aufhalten!

Es geht ja nicht nur um Berechtigung, sondern auch um Kompetenz...

@e1bart0: Hast recht, nach dem öffnen einer neuen Shell war die PATH-Variable gesetzt

schon wieder was gelernt. Hab ich jetzt in den Artikel eingearbeitet.

Gruß,

mesrumma

Jetzt hab ich noch mehr Anregungen/Fragen:

1. Sollte man auf "getestet mit Karmic" setzen oder einfach "Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig."?

2. Es wäre schön, wenn wie bei Skripte/inkrementelles Backup ein paar Worte zum Rücksichern drinstehen. Weil das Editieren im echten Artikel immer eine Operation am offenen Herzen ist, wollte ich lieber vorher fragen, ob das soweit ok ist:

"

ROOTDIR=/
sudo tar -xjf backupdatei.tar.bz2 -C $ROOTDIR 

Als ROOTDIR ist das Verzeichnis anzugeben, von dem aus das Backup angelegt wurde, backupdatei ist durch den tatsächlichen Dateinamen des Backups zu ersetzen, bspw. backup-2007-11-24-170024.tar.bz2 "

Hintergrund ROOTDIR: Vielleicht möchte jemand das Backup von einer LiveCD aus zurückspielen, da ist die Option

-C /  

aus Skripte/inkrementelles Backup natürlich irreführend.

Frage 1: sudo ja, nein, vielleicht? Frage 2: Warnung, dass vorhandene Daten evtl. überschrieben werden?

3. Optik/Gliederung: Muss

tar: Entferne führende „/“ von Elementnamen

eine Überschrift sein?

Gruß,

mesrumma

Noch eine kleine Frage: Habe ein altes / gesichert mit dem Befehl und einen Haufen derartige Meldungen erhalten:

tar: /Pfad_zum_root/var/spool/postfix/public/cleanup: Socket ignoriert

Fehlt da jetzt was Wichtiges, wenn ichs zurückschreibe?

Gruß,

mesrumma

Hallo, ich hänge mal mein Problem hier an, auch wenn es nicht direkt um den Artikel geht, sondern um meine Probleme mit dem Skript. (Hoffe, das ist ok?)

Ich erhalte nach einer Weile folgende Fehlermeldung: gzip: stdout: file too large Die .tgz - Datei auf meiner externen Festplatte hat dann genau 4 Gb erreicht. Mein Homeverzeichnis ist über 10 Gb groß (selbst gemachte Videos etc., die ich auch sichern möchte). Ich vermute mal, es liegt am Dateisystem oder an gzip? Warum tritt das Problem nur(?) bei mir auf?

Leider weiß ich auch nicht, um welches Dateisystem es sich handelt und wie ich das rausfinden kann. Nur so viel: Es ist nicht NFTS Unter Eigenschaften steht: Dateisystemtyp: msdos. Ist das überhaupt ein Dateisystem?

konnischubert schrieb:

Ich erhalte nach einer Weile folgende Fehlermeldung: gzip: stdout: file too large Die .tgz - Datei auf meiner externen Festplatte hat dann genau 4 Gb erreicht. Mein Homeverzeichnis ist über 10 Gb groß (selbst gemachte Videos etc., die ich auch sichern möchte). Ich vermute mal, es liegt am Dateisystem oder an gzip? Unter Eigenschaften steht: Dateisystemtyp: msdos. Ist das überhaupt ein Dateisystem?

Beio dem Dateisystem handelt es sich vermutlich um FAT32, und das hat eine maximale Dateigröße von 4 GB. Ich würde die externe Platte als ext4 oder NTFS formatieren, da sind dann auch größere Dateien möglich.

Ich habe die Platte soweit ich mich erinnere aber mit Ubuntu formatiert. Glaube deshalb nicht, dass es sich um FAT handelt. Könnte es nicht auch am Packprogramm liegen? Ansonsten probiere ich es natürlich ext4 aus, es ist nur recht viel Arbeit und ich glaube nicht so recht daran.

Naja, wenns so angezeigt wird, wird es schon ein msdos-Dateisystem sein. Du kannst das ganze ja noch mit dem Befehl

mount

überprüfen. Das Packprogramm tar hat aber definitiv keine Probleme mit 4 GB großen Archiven.

ok, ich glaubs

Hi!

Mal was ganz anderes: Das sollte doch wohl besser unter Skripte eingebunden werden, oder? Da habe ich es jetzt hingeschoben.

so long
hank