tar gz mit Rechtesicherung, usw.

[Tom]

Hello,

ich muss kurzfristig über Netz einen Linux-Server sichern und zwar so, dass man die geicherten Verzeichnisse nachher wieder herstellen kann inclusive User, Gruppe und Rechten.

Was muss ich beachten?

Das System verwendet Confixx

Wir haben die "WebX"-Directories, da sehe ich noch wenig Probleme
Dann haben wir die Server-Konfigurationen für Apache, PHP, MySQL Mailserver, usw. (???)

Und wie kriege ich die User und ihre Rechte?
Wer hat sowas schon mal auf "Alarm" gemacht und kann mir helfen?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

ich muss kurzfristig über Netz einen Linux-Server sichern und zwar so, dass man die geicherten Verzeichnisse nachher wieder herstellen kann inclusive User, Gruppe und Rechten.

Was muss ich beachten?

Zuerst einmal ist es ideal, alle Dienste, die man gerade NICHT benötigt, zu beenden. Im Idealfall läuft gar nichts bis auf die Shell, auf der man das Backup macht - allerdings kann man wenn man Remote arbeitet auf den SSHD z.B. nicht verzichten.

tar bietet eine Option 'p' an, die für 'preserve' steht, d.h. "Rechte erhalten". Ferner ist 'tar' als 'root' auszuführen, damit es mit Zugriffsrechten keine Probleme gibt.

Ferner ist die Option --one-file-system hilfreich: Es ist besser, alle Partitionen separat zu Backupen und nicht in gemountete Verzeichnisse hineinzuwechseln (sonst sammelt man sich Probleme wie /proc, /sys etc. an).

Zudem mounten einige Distributionen gerade in Verzeichnisse wie /dev andere Filesysteme und "überschreiben" so die Dateien, die standardmäßig in /dev vorhanden sind. Daher ist es sinnvoll, vorher ein Bind-Mount der Partition in ein anderes Verzeichnis zu machen und das Verzeichnis dann zu backupen.

Sprich: Wenn man folgende Konfiguration hat:

/dev/hda1      /boot
/dev/hda5      /
/dev/hda6      /home

Und das Backup-Medium auf dem Server (externe Festplatte oder Netzwerkdateisystem wie z.B. NFS oder CIFS oder SMB) nach /mnt/backup gemountet hat.

Dann würde man am besten folgendes machen:

1. Alle Dateisysteme per bind-mount an eine bestimmte Stelle mounten:

mkdir /mnt/system
mkdir /mnt/boot
mkdir /mnt/home

mount --bind / /mnt/system
mount --bind /boot /mnt/system
mount --bind /home /mnt/system

2. Backups anlegen
   [Optionen: -c == create, -v == verbose, -p == preserve, -z == compress,
              -C == in das Verzeichnis wechseln]
   [Den "." am Ende nicht vergessen!]

tar --one-file-system -cvpzf /mnt/backup/root.tar.gz -C /mnt/system .
tar --one-file-system -cvpzf /mnt/backup/boot.tar.gz -C /mnt/boot .
tar --one-file-system -cvpzf /mnt/backup/home.tar.gz -C /mnt/home .

3. Die bind-mounts wieder entfernen:

umount /mnt/home
umount /mnt/boot
umount /mnt/system

---- das war's für's backup ---

Wenn dann der Server wiederhergestellt werden soll, dann müssen alle Partitionen bereits korrekt eingerichtet sein das Dateisystem schon angelegt sein (sollte das gleiche Dateisystem wie vorher sein, wenn nicht, geht das auch, man muss dann aber die /etc/fstab anpassen!).

Man sollte dann von einem Rettungssystem aus den Rechner gebootet haben. Dann kann man die Partitionen an die entsprechende Stelle mounten, wenn man dem bisherigen Beispiel folgt:

[auf dem Rettungssystem (!):]
mkdir /mnt/system

mount /dev/hda5 /mnt/system

tar -xvpzf /mnt/backup/root.tar.gz -C /mnt/system

mount /dev/hda1 /mnt/system/boot

tar -xvpzf /mnt/backup/boot.tar.gz -C /mnt/system/boot

mount /dev/hda6 /mnt/system/home

tar -xvpzf /mnt/backup/home.tar.gz -C /mnt/system/home

[WICHTIG IST, DASS HIER DIE PARTITIONEN AN DIE RICHTIGE STELLE UNTERHALB VON /mnt/system gemountet werden!]

Dann sind die Backups wiederhergestellt, dann wäre es noch sinnvoll, den Bootloader wieder zu installieren. Dazu ist es am sinnvollsten, in das System reinzu-chroot-en und dort das Bootloaderprogramm auszuführen.

Um aber erfolgreich rein-zu-chrooten musst Du erst dafür sorgen, dass /proc etc. verfügbar ist:

mount --bind /proc /mnt/system/proc
mount --bind /dev /mnt/system/dev
mount --bind /sys /mnt/system/sys

Dann reinwechseln:

chroot /mnt/system /bin/bash
source /etc/profile

Dann den Bootloader neu installieren, bei LILO:

lilo

Bei Grub ist es am einfachsten, eine Grub-Shell zu laden:

grub

Und dann dort Befehle einzugeben:

root (hd0,0)
setup (hd0)
quit

Wobei (hdX) == X+1te Festplatte ist (d.h. setup (hd0) schreibt das in den MBR der ersten Platte, bei IDE-Systemen hda) und (hdX,Y) ist die Y+1te Partition der X+1ten Platte, dort muss /boot liegen, d.h. (hd0,0) wäre hda1  bei einem IDE-System.

Danach rauswechseln aus dem chroot:

exit

Und danach alles unmounten:

Bind-Mounts für's chroot

umount /mnt/system/dev
umount /mnt/system/sys
umount /mnt/system/proc

Zusätzliche Partitionen wie home und root

umount /mnt/system/home
umount /mnt/system/boot

Das eigentliche System

umount /mnt/system

Und dann sollte das System wieder problemlos booten - und wäre faktisch identisch zum vorigen System.

Wenn Du nicht das GESAMTE System backupen willst, dann müsstest Du mal genauer erklären, was Du überhaupt anstellen willst.

Das System verwendet Confixx

Das kenne ich nicht wirklich, ich kenne aber genug Leute, die und deren Meinung ich sehr schätze, die das Ding meiden wie der Teufel das Weihwasser.

Viele Grüße,
Christian

[Tom]

Hello Christian,

Das System verwendet Confixx

Das kenne ich nicht wirklich, ich kenne aber genug Leute, die und deren Meinung ich sehr schätze, die das Ding meiden wie der Teufel das Weihwasser.

Erstmal vielen Dank für Deine wirklich ausführliche Hilfestellung.
Ich hätte wohl einiges vergessen.

Das System läuft als Root-Server bei Strato und muss neu aufgesetzt werden.
Nach Möglichkeit soll bei der Gelegenheit auch gleich ein Versions-Upgrade durchgeführt werden
Bisher bekanntes Problem der verwendeten Suse ist z.B. eine Macke bei der Auslieferung von PDFs an den Internet-Explorer.

Es beherbergt vier "web"s mit zusammen ca. 5GBytes an Scripten und Daten
Diese benutzen bisher PHP4 und MySQL 4.x

Es dient außerdem für ca. 10 Leute als Mailserver. Mails werden dort noch 30 Tage gespeichert, auch wenn man sich eine  Kopie abgeholt hat.

Unabhängig davon, dass evtl. das Upgrade schon in etlichen Scripten Probleme mitbringen kann, will ich natürlich vermeiden, dass durch fehlende Daten/Links und/oder Rechte noch mehr Verdruss entsteht.

Alle von Dir bedachten Punkte muss ich deshalb hoffentlich nicht nachvollziehen, aber besser vorher drüber nachdenken, als hinterher jammern.

Fragen wären daher noch:

• Kann MySQL 5.2 ff mit den Datenstrukturen von MySQL 4.? umgehen?
    also einfach Files sichern und wiedereinspielen?

• Kann man die POP3 und IMAP-Verzeichnisse einfach wieder einspielen,
    ohne tiefer eindringen zu müssen?

• Werden Symbolic Links durch tar gz mit gesichert und wiederhergestellt?

Und das mit dem Confixx-Hasser passt auch auf mich. Ich rege mich jedes Mal darüber auf, aber das nützt nichts. Ich bin nur Gast auf dem Server. Da steckt wahrscheinlich noch eine Falle drin, denn wenn die Virt-Hosts mit ihren inzwischen diversen Sonderregeln (Mod_Rewrite und Force_Type usw) nicht wiederhergestellt werden können, läuft erstmal gar nichts.

Mit Confixx und seinen Datenstrukturen muss ich mich leider noch auseinadersetzen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Alle von Dir bedachten Punkte muss ich deshalb hoffentlich nicht nachvollziehen, aber besser vorher drüber nachdenken, als hinterher jammern.

In Deinem beschriebenen Szenario reicht es aus, die Datenverzeichnisse zu sichern, den Server komplett plattzumachen und dann die Datenverzeichnisse wieder einzuspielen.

Beachte bitte, dass Du Dir auch ein Backup von /etc anlegst, damit die Konfiguration gesichert ist. Beachte aber auch, dass Du, wenn Du Versionsupdates machst, das nicht einfach wieder einspielen darfst, sondern es Dir höchstens als "Erinnerungshilfe" zur erneuten Konfiguration verwenden darfst.

Beachte ferner, dass Datenverzeichnisse an teilweise obskuren Orten liegen können, bei Mails z.B. auch in /var.

Es wäre daher evtl. nicht verkehrt, zumindest das Backup selbst in der Gesamt-Fassung, wie ich es beschrieb, durchzuführen, das ganze dann aber nur in ein Unterverzeichnis wieder zu entpacken sobald der Server plattgemacht wurde, dann selektiv die nötigen Daten aus dem Unterverzeichnis rauskopieren. Dann kann nichts verloren gehen.

• Kann MySQL 5.2 ff mit den Datenstrukturen von MySQL 4.? umgehen?
    also einfach Files sichern und wiedereinspielen?

Nein. Zum einen: 5.2 gibt es nicht, 5.1 ist Entwicklungsversion und 6.0 ist Alpha-Entwicklungsversion. Ich würde empfehlen, bei 5.0 zu bleiben, außer, Du brauchst unbedingt Features aus 5.1 (6.0 würde ich DEFINITIV noch nicht produktiv einsetzen wollen).

Du kannst mittels mysqldump ein Komplettbackup aller Datenbanken anlegen, wie Du das genau machst, steht im Handbuch (Stichwort habe ich ja jetzt genannt). Das Backup legst Du an, solange die alte 4.1er noch läuft.

Beachte auch, dass sich zwischen 4.0 und 4.1 (oder war's 4.1 und 5.0 - weiß nicht mehr) wegen Zeichensätzen EINIGES getan hat und Umstellungen deswegen nicht immer ganz schmerzfrei sind. Im Archiv gibt's einige Threads zu dem Thema.

• Kann man die POP3 und IMAP-Verzeichnisse einfach wieder einspielen,
    ohne tiefer eindringen zu müssen?

Wenn die im mbox- oder Maildir-Format gespeichert werden: Ja.

mbox == 1 Große Textdatei, die alle Mails inklusive Header enthält.
MailDir == Verzeichnis, das 3 weitere Unterverzeichnisse 'cur' 'new' und 'tmp' enthält.

• Werden Symbolic Links durch tar gz mit gesichert und wiederhergestellt?

Mit -p: Ja.

Viele Grüße,
Christian

[Tom]

Hello,

• Kann MySQL 5.2 ff mit den Datenstrukturen von MySQL 4.? umgehen?
    also einfach Files sichern und wiedereinspielen?

Nein. Zum einen: 5.2 gibt es nicht, 5.1 ist Entwicklungsversion und 6.0 ist Alpha-Entwicklungsversion. Ich würde empfehlen, bei 5.0 zu bleiben, außer, Du brauchst unbedingt Features aus 5.1 (6.0 würde ich DEFINITIV noch nicht produktiv einsetzen wollen).

Ja, ist auch 5.0. Ich habe nur nicht nachschauen können (meine Testinstallation hat ja gerade jetzt die Füße gestreckt...) und die Versionsnummer mit PHP verwechselt.

Du kannst mittels mysqldump ein Komplettbackup aller Datenbanken anlegen, wie Du das genau machst, steht im Handbuch (Stichwort habe ich ja jetzt genannt). Das Backup legst Du an, solange die alte 4.1er noch läuft.

Gerade _das_ hätte ich gerne vermieden. Ist es verbrieft, dass MySQL 5.0 mit den Dateien von 4.1 nichts anfangen kann?

Beachte auch, dass sich zwischen 4.0 und 4.1 (oder war's 4.1 und 5.0 - weiß nicht mehr) wegen Zeichensätzen EINIGES getan hat und Umstellungen deswegen nicht immer ganz schmerzfrei sind. Im Archiv gibt's einige Threads zu dem Thema.

Jau. Muss ich mich nochmal orientieren, ist aber schon im Hinterkopf.

• Kann man die POP3 und IMAP-Verzeichnisse einfach wieder einspielen,
    ohne tiefer eindringen zu müssen?

Wenn die im mbox- oder Maildir-Format gespeichert werden: Ja.

mbox == 1 Große Textdatei, die alle Mails inklusive Header enthält.
MailDir == Verzeichnis, das 3 weitere Unterverzeichnisse 'cur' 'new' und 'tmp' enthält.

Zweiteres ist es.

• Werden Symbolic Links durch tar gz mit gesichert und wiederhergestellt?

Mit -p: Ja.

Scheint ja doch eine größere Aktion zu werden, zumal das Hauptproblem "Wie erreiche ich die kürzest mögliche Down-Time" auch noch geknackt werden muss.

Ich weiß bisher überhaupt nicht, ob im Servercluster von Strato ein Transfer von targz-Balls so einfach möglich ist (von einem Root-Server zum anderen). Denn mit 1Mbit/s (Upload) will ich gewiss nicht 5Gbyte (ungepackt) wieder uploaden. Und der Download wird bei 16MBit/s auch noch nicht so richtig Spaß machen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Du kannst mittels mysqldump ein Komplettbackup aller Datenbanken anlegen, wie Du das genau machst, steht im Handbuch (Stichwort habe ich ja jetzt genannt). Das Backup legst Du an, solange die alte 4.1er noch läuft.

Gerade _das_ hätte ich gerne vermieden. Ist es verbrieft, dass MySQL 5.0 mit den Dateien von 4.1 nichts anfangen kann?

Hmm, das scheint doch zu funktionieren, siehe http://dev.mysql.com/doc/refman/5.0/en/upgrade.html und http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html. War aber mal nicht so.

Dennoch ist ein Dump als Backup SEHR hilfreich.

[Maildir]
Zweiteres ist es.

Gut, dann kannst Du einfach rumkopieren.

Viele Grüße,
Christian

[Christian Seiler]

Dennoch ist ein Dump als Backup SEHR hilfreich.

.... um im Fehlerfalle wenigstens noch die Daten zu haben.

[Tom]

Hello,

Dennoch ist ein Dump als Backup SEHR hilfreich.

.... um im Fehlerfalle wenigstens noch die Daten zu haben.

Das ist auch kein Problem, einen anzulegen. Aber die Zeit ist das Problem, insbesondere beim Wiedereinstellen der Daten.

Für eine versionsinterne Lösung haben wir mal ein Tool entwickelt. Das tut auch. Ein Copy und targz der Dateien hat nur ca. 3 Min Offtime verursacht, ein Dump über zwei Stunden. Beim Wiedereinstellen der Daten sieht die Bilanz für den Dump noch schlechter aus.

Wir haben auch schon darüber nachgedacht, einen zusätzlichen Root-Server für die Umstellung zu nehmen, aber für vier Wochen machen die das nicht, sondern eben nur für ein Jahr Mindestlaufzeit.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Dennis]

Hi Christian,

Hmm, das scheint doch zu funktionieren, siehe http://dev.mysql.com/doc/refman/5.0/en/upgrade.html und http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html. War aber mal nicht so.

Also ich entsinne mich noch, dass ich unter Debian über APT von MySQL 4.1 auf MySQL 5.0 aktualisiert habe - das hat problemlos geklappt und APT hat alles für mich gemacht. Vielleicht wäre das für Tom auch eine Möglichkeit, erst wieder 4.1 zu installieren und dann über die Packetverwaltung zu aktualisieren? Oder muss es ein selbst kompiliertes MySQL sein?

Dennoch ist ein Dump als Backup SEHR hilfreich.

Dem kann ich mich nur anschließen, ich ziehe auch vor größeren Datenbankoperationen grundsätzlich ein Backup mit mysqldump ;-)

[Maildir]
Zweiteres ist es.

Es kann dort aber neben cur, new und tmp noch andere Ordner geben, oder? Bei mir sieht es zum Beispiel so aus:

drwx------ 2 mesc driehle 16384 2007-10-25 16:35 courierimapkeywords
-rw-r--r-- 1 mesc driehle    12 2006-09-12 06:13 courierimapsubscribed
-rw-r--r-- 1 mesc driehle    17 2007-10-25 16:35 courierimapuiddb
-rw-r--r-- 1 mesc driehle   160 2006-09-12 06:12 courierpop3dsizelist
drwx------ 2 mesc driehle 16384 2007-10-25 15:39 cur
drwx------ 2 mesc driehle 12288 2007-11-14 03:20 new
drwx------ 6 mesc driehle  4096 2006-11-29 22:46 .sent-mail
drwx------ 2 mesc driehle  4096 2007-11-14 03:20 tmp
drwx------ 6 mesc driehle  4096 2006-09-12 06:13 .Trash

Es handelt sich dabei um das E-Mail Konto eines virtuellen Postfix-Users (mich *g*).

Viele Grüße,
  ~ Dennis.

[Christian Seiler]

Hallo Dennis,

[Maildir]
Zweiteres ist es.

Es kann dort aber neben cur, new und tmp noch andere Ordner geben, oder? Bei mir sieht es zum Beispiel so aus:

drwx------ 2 mesc driehle 16384 2007-10-25 16:35 courierimapkeywords
-rw-r--r-- 1 mesc driehle    12 2006-09-12 06:13 courierimapsubscribed
-rw-r--r-- 1 mesc driehle    17 2007-10-25 16:35 courierimapuiddb
-rw-r--r-- 1 mesc driehle   160 2006-09-12 06:12 courierpop3dsizelist
drwx------ 2 mesc driehle 16384 2007-10-25 15:39 cur
drwx------ 2 mesc driehle 12288 2007-11-14 03:20 new
drwx------ 6 mesc driehle  4096 2006-11-29 22:46 .sent-mail
drwx------ 2 mesc driehle  4096 2007-11-14 03:20 tmp
drwx------ 6 mesc driehle  4096 2006-09-12 06:13 .Trash

Es handelt sich dabei um das E-Mail Konto eines virtuellen Postfix-Users (mich *g*).

Ja, das ist OK so. Die Verzeichnisse, die mit . anfangen (.sent-mail, .Trash) sind Unterordner, wo es wieder »cur«, »new« und »tmp« gibt. Ferner sieht der Maildir-Standard zwar nur »cur«, »new« und »tmp» vor, allerdings erlaubt er Programmen durchaus zusätzliche Informationen in separaten Dateien dort abzuspeichern (solange diese keine Konflikte verursachen) - und die Courier-Server speichern zusätzliche Informationen eben so ab.

Backup funktioniert trotzdem weiterhin über einfaches Kopieren / taren - man sollte halt die Rechte erhalten.

Viele Grüße,
Christian

[Dennis]

Hi Christian,

Ja, das ist OK so.

Danke, ich war nur etwas stutzig, ob mein Server da vielleicht aufgrund einer Fehlkonfiguration noch andere Ordner hat, oder ob es in der Tat OK so ist ;-)

Backup funktioniert trotzdem weiterhin über einfaches Kopieren / taren - man sollte halt die Rechte erhalten.

Davon war ich ausgegangen :-)

Viele Grüße,
  ~ Dennis.

[Tom]

Hello Dennis, halle Christian,

Also ich entsinne mich noch, dass ich unter Debian über APT von MySQL 4.1 auf MySQL 5.0 aktualisiert habe

Welche Debian-Version war das?

Oder muss es ein selbst kompiliertes MySQL sein?

Nein, muss es nicht. Ich hatte ja auf meinem Testserver auch alles hinbekommen.
Hier auf dem betreffenden ist zwar noch eine Suse mit Confixx drauf, aber man könnte mal überlegen, ob wir die nicht bei der Gelegenheit auch gelich platt machen. Aber ich gleube, bei Strato kann man Confixx nicht einfach so beseitigen, weil sich die "Root-Server" damit ins übergeordnete System in der Verwaltung einbinden.

Aber für mich selber im Moment viel wichtiger:

Was mache ich mit meiner Testserver-Möhre?
Da muss ich mit Debian eine Nummer zurückschrauben.
Ist zwar im anderen Thread weil anderes Thema, aber falls hier noch einer guckt.

bitte nochmal gucken gehen. https://forum.selfhtml.org/?t=162019&m=1053903

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Dennis]

Hi Tom,

Welche Debian-Version war das?

Müsste Debian Sarge auf Debian Etch gewesen sein, also das letzte Dist-Upgrade.

Aber ich gleube, bei Strato kann man Confixx nicht einfach so beseitigen, weil sich die "Root-Server" damit ins übergeordnete System in der Verwaltung einbinden.

Meinst du? Glaube ich eigentlich nicht. Wenn du einen eigenen Root-Server hast kannst du damit eigentlich auch wirklich machen was du willst ;-) Könnte allerdings sein, dass Strato gewisse Interfaces von Confixx nutzt und nach dem Entfernen von Confixx machen Funktionen aus dem Strato Kundenmenü nicht mehr funktionieren. Aber das müsste sich ja recherchieren lassen.

Was mache ich mit meiner Testserver-Möhre?

Wenn es von jetzt auf sofort einen Kernel Panic gibt *ohne*, dass du irgendetwas am PC gemacht hast, klingt das für mich doch irgendwie nach einen Hardware Defekt (Festplatte?). Ich hab den anderen Thread jetzt nicht mitverfolgt, aber hast du schon von einem Rettungssystem gebooted und alle Hardware Komponenten geprüft?

Viele Grüße,
  ~ Dennis.

[Tom]

Hello,

Was mache ich mit meiner Testserver-Möhre?

Wenn es von jetzt auf sofort einen Kernel Panic gibt *ohne*, dass du irgendetwas am PC gemacht hast, klingt das für mich doch irgendwie nach einen Hardware Defekt (Festplatte?). Ich hab den anderen Thread jetzt nicht mitverfolgt, aber hast du schon von einem Rettungssystem gebooted und alle Hardware Komponenten geprüft?

Nee, nee. Ich hatte ein apt-get upgrade gemacht und er hat sich wohl eine neues Fertig-Kernel gezogen. So genau weiß ich leider nicht mehr, wann und wie das passiert ist. Jedenfalls hatte ich dann "plötzlich" Kernel 2.6.18-5-486 statt 2.6.18-4-486 drauf und dann ist er abgeschmiert.

Ich habe ihn heute Nacht neu aufgebaut. Die alte Platte kann ich inzwischen auch lesen. Die Daten sind also alle noch in sortierter Form da. (Auf CDs hätte ich sie auch noch aber leider immer nur einzelne Stände, nie ein Fullbackup.)

Einen abgebrochen habe ich mir mit dem Gateway und Route add default...
Er wollte und wollte sich den Gateway nicht merken. Nach dem Booten war er immer wieder weg.

Bis ich dann mal die glorreiche Idee hatte, /etc/init.de/networking restart zu benutzen und das hat mir dann eine aussagefähige Fehlermeldung produziert. Ich hatte bei der Netmask 255.155.155.0 getippt. Das habe ich trotz mehrfacher Kontroll nicht gesehen und habe mich gewundert, dass die Routingtabelle nicht permanent blieb. Beim Starten rauschen die Fehlermeldungen eben so schnell durch, dass man sie nicht sehen kann.

Ein Problem besteht noch: Die DB-Übernahme von MySQL klappt nicht so, wie ich es mir vorstelle. Jedenfalls bekomme ich die alte DB nicht einfach durch Kopieren der Dateien (MyISAM) in die Struktur der neuen Datenbank rein. Mit dem Konsolen-Tool (mysql) kann ich zwar alles ansprechen und auch damit arbeiten, aber im Frontend (SQL-Front) will sie einfach nicht auftauchen.

Bei MySQL 4.? ging das noch problemlos.

Ich schreibs jetzt nur hier, weil wir es in diesem Thread ja auch diskutiert hatten.

Insofern hat der Absturz meines Testservers auch seine guten Seiten. Ich musste jetzt alles nochmal durchspielen, ohne das wirklich Schaden entstehen kann (außer Zeit). Die Daten hätte ich zur Not ja alle noch gehabt. Wenn uns das aber bei dem Produktivserver passiert, kostet es richtig Geld.

Strato ist da auch nicht wirklich kooperativ. Wir können keine ca. 5 GB Daten über DSL 16.000/1.000 runter und wieder raufschieben. Das geht nur innerhalb des Strato-Clusters über Gigabit-Netz oder zumindest 100MBit in angemessener Zeit. Aber um die 5GB auf einen VHost zusätzlich zu bekommen, möchten sie einen Vertrag über 12 oder 24 Monate machen...

So lange sollte der Umbau eigentlich nicht dauern *g*

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Dennis]

Hi Tom,

Nee, nee. Ich hatte ein apt-get upgrade gemacht und er hat sich wohl eine neues Fertig-Kernel gezogen. So genau weiß ich leider nicht mehr, wann und wie das passiert ist. Jedenfalls hatte ich dann "plötzlich" Kernel 2.6.18-5-486 statt 2.6.18-4-486 drauf und dann ist er abgeschmiert.

Das ist mir (dummerweise bei einem Produktiv-Server) auch schon mal passiert. Über ein Update wollte ich einen neuen Kernel installieren und habe mal drauf gehofft, dass das System intelligent genug ist, dies selbständig zu erledigen. Leider ist (bzw. war damals) in dem Standard-Kernel nur ein Treiber für IDE-Festplatten drin. Doof, wenn der eigene Server dann zwei SATA-Platten hat ;-)

Bei mir ist es dann darauf hinausgelaufen, dass ich mir selber einen Kernel mit SATA-Support kompiliert habe, diesen mit ein paar Tools zu einem Debian-Package gebastelt und dann über dpkg installiert habe. Für im Archiv lesende sei noch der Tipp gegeben, nicht auf den alten SATA-Support im Linux-Kernel hineinzufallen - damals hatte ich zwei Optionen in meiner Kernel-Config zur Verfügung, eine tat es schlichtweg gar nicht ;-)

Strato ist da auch nicht wirklich kooperativ. Wir können keine ca. 5 GB Daten über DSL 16.000/1.000 runter und wieder raufschieben. Das geht nur innerhalb des Strato-Clusters über Gigabit-Netz oder zumindest 100MBit in angemessener Zeit. Aber um die 5GB auf einen VHost zusätzlich zu bekommen, möchten sie einen Vertrag über 12 oder 24 Monate machen...

Offensichtlich hast du dir den falschen Provider gewählt. Bei Hetzner gibt es für jeden Root-Server kostenfrei 50 GB Speicherplatz auf einem von Hetzner betriebenen Backup-Server, auf welchen du Netz-intern und ohne Traffic-Kosten per FTP zugreifen kannst.

Viele Grüße,
  ~ Dennis.

[Tom]

Hello,

Offensichtlich hast du dir den falschen Provider gewählt. Bei Hetzner gibt es für jeden Root-Server kostenfrei 50 GB Speicherplatz auf einem von Hetzner betriebenen Backup-Server, auf welchen du Netz-intern und ohne Traffic-Kosten per FTP zugreifen kannst.

Ist ja nicht mein Provider, obwohl ich da auch als "Untermieter" einen Zugang habe.
Aber den Tipp mit Hetzner gebe ich weiter.

Ich bevorzuge sonst die kleineren Provider, die man auch noch persönlich im Büro treffen kann, wenn man will. Die haben dann vielleicht allgemein nicht die Verfügbarkeit von 99,9% sondern nur 99%, aber wenn es mal brennt, sind sie innerhalb von Minuten erreichbar. Das kann wichtiger sein.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

• Kann MySQL 5.2 ff mit den Datenstrukturen von MySQL 4.? umgehen?
    also einfach Files sichern und wiedereinspielen?

Zumindest mit MyISAM-Dateien gibt es von Version 4.1 nach 5.0 keine mir bekannten Probleme. Von Version 4.0 nach 4.1 ist die Zeichenkodierungsproblematik zu beachten. (Von 4.0 nach 5.0 hab ich nie probiert.) Wenn du 4.0er MyISAM-Dateien in Version 4.1 verwenden willst, musst du die Server-Default-Kodierung des 4.1er Servers auf Latin1 stellen, da die 4.0 generell in dieser Kodierung speichert. Dann musst du jedem Feld einzeln zumindest mal die Kollation ändern (z.B. von german1 nach german2, ist aber im Prinzip egal, von wo nach wo du das machst, Hauptsache das latin1 bleibt bestehen), damit dabei die Kodierungs-/Kollationsinformation in der Tabellendatei abgelegt wird. Danach das gleiche noch bei den Tabellen und am Ende bei der Datenbank durchführen. Somit wären dann alle Kodierungs-/Kollationsinformationen explizit in den Dateien eingetragen. Jetzt kann man auch gefahrlos die Server-Default-Kodierung z.B. auf UTF-8 ändern. Da die Felder durch den vorhergehenden Schritt ihre Kodierungsinformation bekommen haben, kann MySQL nun diese verwenden. Ohne den Schritt findet MySQL keine Kodierungsinformation und geht von der Server-Default-Kodierung aus, was dann im Falle von UTF-8 in die Hosen ginge. Man darf sich auch nicht von der Kodierungs-/Kollationsanzeige des phpMyAdmin irritieren lassen. Wenn diese Information nicht explizit in den Feldern eingetragen wurde, wird da nur der Server-Default-Wert angezeigt. Daran kann man nicht erkennen, welche Felder nun ihre kodierungsinformation haben, und welche noch nicht. Hier muss man schon selbst und auf anderem Wege die Übersicht über die bereits behandelten Felder bewahren.

echo "$verabschiedung $name";