Gunther: Backup-Strategie

Hallo werte Selfgemeinde!

Gerne würde ich zum einen eure Meinung, bzw. anderslautende Vorschläge, zu meiner Backup-Strategie hören, und zum anderen wäre ich für entsprechende Hilfe bei den/ dem benötigten Batch-Skripten sehr dankbar.

Ich habe 3 verschiedene "Bereiche", die ich jeweils gerne per rdiff-backup sichern möchte:
1. alle vorhandenen MySQL DBs
2. alle Web-Ordner (liegen alle in Unterordnern in einem bestimmten Verzeichnis)
3. alle Mail-Ordner (liegen alle in Unterordnern in einem bestimmten Verzeichnis)

Das Ganze soll täglich per Cronjob ablaufen.

Für 1. muss ich ja vorher, bspw. per mysqldump, einen Dump der jeweiligen Datenbank erzeugen (ich möchte nicht alle in einer Datei haben).

Kann ich (oder besser gesagt "man") alle Abläufe in ein Batch-Skript packen, um so u.a. sicherzustellen, dass die einzelnen Schritte auf jeden Fall nacheinander abgearbeitet werden?

Ist es (aus Sicherheitsgründen) ratsam, für die MySQL Dumps einen eigenen Benutzer anzulgen, um diese nicht als root ausführen zu müssen (da ja das Passwort im Klartext in das Batch-File rein muss)?

Und kann mir jemand sagen, ob rdiff-backup auch mit geapckten (tar.gz oder gzip) Dateien "klarkommt", oder ob es in diesem Fall "besser" ist, unkomprimierte Dumps zu erzeugen?
Wie sieht es "schätzungsweise" mit dem Platzbedarf aus, wenn ich z.B. die unterschiedlichen Versionen von einer Woche (7 Tage) aufheben möchte?

Das Ganze soll übrigens auf einem Server mit Debian Squeeze laufen.

Für eure freundliche Unterstützung & Hilfe wie immer meinen besten Dank im Voraus!

Frohe Ostern!

Gruß Gunther

  1. Hi,

    Ich habe 3 verschiedene "Bereiche", die ich jeweils gerne per rdiff-backup sichern möchte:

    1. alle vorhandenen MySQL DBs
    2. alle Web-Ordner (liegen alle in Unterordnern in einem bestimmten Verzeichnis)
    3. alle Mail-Ordner (liegen alle in Unterordnern in einem bestimmten Verzeichnis)

    Das Ganze soll täglich per Cronjob ablaufen.

    Klingt doch schonmal ganz sinnvoll. Aber was ist z.B. mit den Systemdateien? - Die würde ich auch von Zeit zu zeit mal backuppen, für den Fall der Fälle...

    Für 1. muss ich ja vorher, bspw. per mysqldump, einen Dump der jeweiligen Datenbank erzeugen (ich möchte nicht alle in einer Datei haben).

    Kann ich (oder besser gesagt "man") alle Abläufe in ein Batch-Skript packen, um so u.a. sicherzustellen, dass die einzelnen Schritte auf jeden Fall nacheinander abgearbeitet werden?

    Klar. Du könntest verschiedene "Bereiche" in der Batch-Datei/Shell-Datei erstellen. Als erstes wird z.B. der mysqldump ausgeführt, als nächstes dann die Web-Dateien gesichert und als letztes die Mail-Verzeichnisse.

    Da das als Job ausgeführt werden soll, würde ich noch ein paar Meldungen als Mail an mich schicken. Z.b. Backup von XYZ erfolgreich ausgeführt.

    Ist es (aus Sicherheitsgründen) ratsam, für die MySQL Dumps einen eigenen Benutzer anzulgen, um diese nicht als root ausführen zu müssen (da ja das Passwort im Klartext in das Batch-File rein muss)?

    Ja. Benutzer "root" sollte nur für administrative Aufgaben benutzt werden. Für alles andere sollten man sich einzelne Benutzer, die wiederrum nur die wirklich benötigten Rechte erhalten, erstellen.

    Und kann mir jemand sagen, ob rdiff-backup auch mit geapckten (tar.gz oder gzip) Dateien "klarkommt", oder ob es in diesem Fall "besser" ist, unkomprimierte Dumps zu erzeugen?

    Das Programm/Tool kenne ich nicht. Ich würde Backups allerdings immer komprimieren, denn es sind nur Backups die man nicht täglich aufrufen muss und die eigentlich so wenig Speicher wie möglich verbrauchen sollten.

    Gruß

    1. Hi,

      vielen Dank für deine Antwort - gibt mir ein wenig mehr Vertrauen in meine "Strategie"! ;-)

      Klingt doch schonmal ganz sinnvoll. Aber was ist z.B. mit den Systemdateien? - Die würde ich auch von Zeit zu zeit mal backuppen, für den Fall der Fälle...

      Ja, durchaus. Wobei das für mich wieder ein extra Kapitel ist.
      Wie mache ich denn am besten eine (möglichst) komplette System-Sicherung unter Linux?
      Falls es hilft - es handelt sich dabei um einen vServer mit KVM. Leider bietet der Hoster nur die Möglichkeit inkrementelle Snapshots (die zwar im laufenden Betrieb) zu erstellen, an die man aber nicht herankommt, also nicht separat sichern kann.

      Klar. Du könntest verschiedene "Bereiche" in der Batch-Datei/Shell-Datei erstellen. Als erstes wird z.B. der mysqldump ausgeführt, als nächstes dann die Web-Dateien gesichert und als letztes die Mail-Verzeichnisse.

      Da das als Job ausgeführt werden soll, würde ich noch ein paar Meldungen als Mail an mich schicken. Z.b. Backup von XYZ erfolgreich ausgeführt.

      Da ich bis jetzt selber noch nie etwas mit Batch-Skripten zu tun hatte, das also völliges Neuland für mich ist, hier mal ein Skript, welches ich gefunden habe -> Shell Script To Backup MySql Database Server
      Wäre das als Ausgangspunkt brauchbar?

      Und kann mir jemand sagen, ob rdiff-backup auch mit geapckten (tar.gz oder gzip) Dateien "klarkommt", oder ob es in diesem Fall "besser" ist, unkomprimierte Dumps zu erzeugen?
      Das Programm/Tool kenne ich nicht.

      Kein Problem -> rdiff-backup

      Ich würde Backups allerdings immer komprimieren, denn es sind nur Backups die man nicht täglich aufrufen muss und die eigentlich so wenig Speicher wie möglich verbrauchen sollten.

      Das ist aber genau bei der Verwendung von rdiff-backup die Frage, denn ich habe im Netz gelesen, dass das Programm mit gepackten Dateien "nicht so gut" zurechtkommt.

      Gruß Gunther

      1. Tach!

        Wie mache ich denn am besten eine (möglichst) komplette System-Sicherung unter Linux?

        Platte kopieren, oder cp -a auf Dateiebene.

        Falls es hilft - es handelt sich dabei um einen vServer mit KVM.

        Dann ist die Frage, wie du nach einem Defekt wieder zu einem zugreifbaren System kommst. Du wirst da wohl den Hostermechanismus nehmen müssen, der einen neuen Server mit irgendeiner Grundkonfiguration aufsetzt. Das heißt, dass dir eine System-Kopie nichts nützt, weil du kein Rescue-System zum Beispiel von USB starten kannst, um die Platten im Ruhezustand zu beschreiben.

        Jede Eigensicherung kann sich dann nur auf die Teile konzentrieren, die du im laufenden Betrieb einer Grundkonfiguration hinzufügen/ändern kannst, also alles das, was du nach der Übergabe an dich an Änderungen vorgenommen hast.

        Da ich bis jetzt selber noch nie etwas mit Batch-Skripten zu tun hatte, das also völliges Neuland für mich ist, hier mal ein Skript, welches ich gefunden habe -> Shell Script To Backup MySql Database Server
        Wäre das als Ausgangspunkt brauchbar?

        Sieht erstmal brauchbar aus, aber diese whois-Anweisungen sehen sinnlos aus:
        MYSQL="$(which mysql)"
        Wenn which den Pfad zur ausführbaren Datei findet, wozu es üblicherweise den PATH abklappert, dann findet ein einfacher Aufruf von mysql dieselbe Datei, weil dabei ebenfalls der PATH abgesucht wird. Das Problem ist jedoch, dass beim Starten von Cronjobs oftmals nicht der übliche PATH gesetzt ist, wie man ihn in einer normalen Anmelde-Shell vorfindet, weswegen ein einfaches mysql nicht zu /usr/bin/mysql aufgelöst werden kann. Und which kann das dann auch nicht. Zumal auch noch zuerst which aufgelöst werden muss.

        Wenn du Scripts maßgeschneidert und ohne großartige Rücksicht auf Wiederverwendbarkeit anderswo schreiben willst, dann schreib lieber gleich den richtigen Pfad MYSQL=/usr/bin/mysql. Um den vollständigen Dateinamen zu ermitteln kannst du ja which zu Fuß am Prompt aufrufen. (Für Kompatibilität gäbe es zum Beispiel das oftmals in Shebang-Zeilen genutzte /usr/bin/env.)

        dedlfix.

        1. Tach!

          Wie mache ich denn am besten eine (möglichst) komplette System-Sicherung unter Linux?

          Platte kopieren, oder cp -a auf Dateiebene.

          Falls es hilft - es handelt sich dabei um einen vServer mit KVM.

          Dann ist die Frage, wie du nach einem Defekt wieder zu einem zugreifbaren System kommst. Du wirst da wohl den Hostermechanismus nehmen müssen, der einen neuen Server mit irgendeiner Grundkonfiguration aufsetzt. Das heißt, dass dir eine System-Kopie nichts nützt, weil du kein Rescue-System zum Beispiel von USB starten kannst, um die Platten im Ruhezustand zu beschreiben.

          Jede Eigensicherung kann sich dann nur auf die Teile konzentrieren, die du im laufenden Betrieb einer Grundkonfiguration hinzufügen/ändern kannst, also alles das, was du nach der Übergabe an dich an Änderungen vorgenommen hast.

          Ja, das leuchtet mir soweit ein. Ich kann, im Falle eines Falles wahlweise ein sog. "Rettungssystem" booten oder auch wieder das Image installieren, mit welchem ich begonnen habe.

          Neben etlichen neuen Paketen, die ich installiert habe, und den diversen Konfigurationsdateien, die entsprechend angepasst wurden, besteht meine Serververwaltung noch aus einer MySQL DB, die ich aber ja sowieso schon zusammen mit den anderen sichere/ gesichert habe.

          Um Platz zu sparen würde ich ebenfalls rdiff-backup verwenden und die Verzeichnisse mit den Webs und Mails ausnehmen.

          Funktioniert das dann, wenn ich nach einem Crash erst das Ursprungs-Image wieder installiere und anschließend mein(e) Backup(s) restore? Oder "fehlen" dann ggf. doch noch irgendwelche Sachen/ Dateien?

          Da ich bis jetzt selber noch nie etwas mit Batch-Skripten zu tun hatte, das also völliges Neuland für mich ist, hier mal ein Skript, welches ich gefunden habe -> Shell Script To Backup MySql Database Server
          Wäre das als Ausgangspunkt brauchbar?

          Sieht erstmal brauchbar aus, aber diese whois-Anweisungen sehen sinnlos aus:
          MYSQL="$(which mysql)"
          Wenn which den Pfad zur ausführbaren Datei findet, wozu es üblicherweise den PATH abklappert, dann findet ein einfacher Aufruf von mysql dieselbe Datei, weil dabei ebenfalls der PATH abgesucht wird. Das Problem ist jedoch, dass beim Starten von Cronjobs oftmals nicht der übliche PATH gesetzt ist, wie man ihn in einer normalen Anmelde-Shell vorfindet, weswegen ein einfaches mysql nicht zu /usr/bin/mysql aufgelöst werden kann. Und which kann das dann auch nicht. Zumal auch noch zuerst which aufgelöst werden muss.

          Wenn du Scripts maßgeschneidert und ohne großartige Rücksicht auf Wiederverwendbarkeit anderswo schreiben willst, dann schreib lieber gleich den richtigen Pfad MYSQL=/usr/bin/mysql. Um den vollständigen Dateinamen zu ermitteln kannst du ja which zu Fuß am Prompt aufrufen. (Für Kompatibilität gäbe es zum Beispiel das oftmals in Shebang-Zeilen genutzte /usr/bin/env.)

          OK! Und ja, liegt in /usr/bin/mysql.

          Gruß Gunther

          1. Tach!

            Ich kann, im Falle eines Falles wahlweise ein sog. "Rettungssystem" booten oder auch wieder das Image installieren, mit welchem ich begonnen habe.

            Ah, mit "Rettungssystem", das ist ja schon mehr Komfort, als ich erwartet hatte. Dann ist vermutlich doch die Variante mit der Gesamtsytemkopie eine Option. Zumindest solange das Rettungssystem unabhängig vom eigentlichen läuft und die Partitionen sich beliebig an- und abmounten lassen.

            Um Platz zu sparen würde ich ebenfalls rdiff-backup verwenden und die Verzeichnisse mit den Webs und Mails ausnehmen.
            Funktioniert das dann, wenn ich nach einem Crash erst das Ursprungs-Image wieder installiere und anschließend mein(e) Backup(s) restore? Oder "fehlen" dann ggf. doch noch irgendwelche Sachen/ Dateien?

            Tut mir leid, zu rdiff-backup kann ich nichts sagen. Es ist aber eine gute Idee, solch ein Backup- und Restore-Szenario mal durchzuspielen, am besten in einer virtuellen oder echten Testmaschine mit demselben System wie der vServer.

            dedlfix.

            1. Tach!

              Ah, mit "Rettungssystem", das ist ja schon mehr Komfort, als ich erwartet hatte. Dann ist vermutlich doch die Variante mit der Gesamtsytemkopie eine Option. Zumindest solange das Rettungssystem unabhängig vom eigentlichen läuft und die Partitionen sich beliebig an- und abmounten lassen.

              Werde mal versuchen, das bei meinem Hoster in Erfahrung zu bringen. ;-)

              Um Platz zu sparen würde ich ebenfalls rdiff-backup verwenden und die Verzeichnisse mit den Webs und Mails ausnehmen.
              Funktioniert das dann, wenn ich nach einem Crash erst das Ursprungs-Image wieder installiere und anschließend mein(e) Backup(s) restore? Oder "fehlen" dann ggf. doch noch irgendwelche Sachen/ Dateien?

              Tut mir leid, zu rdiff-backup kann ich nichts sagen.

              Und wie sieht es mit rsync aus? ;-)
              Kann ich denn prinzipiell unter Linux "im laufenden Betrieb" ein hinterher auch brauchbares Backup von der ganzen Platte ziehen?
              Sorry, bin halt in der Windows-Welt groß geworden ..., aber ich bemühe mich ja zu lernen.

              Das Filesystem meines vServers sieht übrigens so aus:

              Filesystem            Size  Used Avail Use% Mounted on
              /dev/mapper/volume-root
                                    115G   18G   92G  16% /
              tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
              udev                  2.0G  116K  2.0G   1% /dev
              tmpfs                 2.0G     0  2.0G   0% /dev/shm
              /dev/vda1             248M   26M  210M  11% /boot

              Es ist aber eine gute Idee, solch ein Backup- und Restore-Szenario mal durchzuspielen, am besten in einer virtuellen oder echten Testmaschine mit demselben System wie der vServer.

              Ich denke auch, dass man erst auf diese Art & Weise halbwegs sicher sein kann. Ich muss mal aus den ganzen "alten" Teilen, die hier so rumliegen, einen Rechner zusammenbauen auf dem ich dann meinen vServer möglichst 1:1 nachbauen kann.

              Ich darf mich aber schon mal recht herzlich für deine Hilfe & Tipps bedanken!

              Gruß Gunther

              1. Tach!

                Und wie sieht es mit rsync aus? ;-)
                Kann ich denn prinzipiell unter Linux "im laufenden Betrieb" ein hinterher auch brauchbares Backup von der ganzen Platte ziehen?

                Prinzipiell wie bei jedem System auch, wenn Dateien offen und nicht zugreifbar sind oder sie inkonsistent auf Festplatte liegen, gibts hinterher Probleme. Das ist aber alles nicht pauschal beantwortbar. Zum Beispiel dürften beim MySQL MyISAM-Tabellen ein Umkopieren relativ schadlos überstehen, InnoDB eher nicht. Nicht umsonst gibt es ein Tool namens mysqlhotcopy, das mit InnoDB nicht funktioniert.

                Das Filesystem meines vServers sieht übrigens so aus:
                Filesystem            Size  Used Avail Use% Mounted on
                /dev/mapper/volume-root
                                      115G   18G   92G  16% /
                tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
                udev                  2.0G  116K  2.0G   1% /dev
                tmpfs                 2.0G     0  2.0G   0% /dev/shm
                /dev/vda1             248M   26M  210M  11% /boot

                Davon sind nur / und /boot interessant, der Rest wird sowieso on-the-fly angelegt und übersteht ein Systemabschalten/-sturz sowieso nicht. Das heißt, beim Kopieren von / sollten diese Bereiche exkludiert werden. (proc und sys vermisse ich (ah, die zeigt das df nicht an, aber mount tut es), die sind ebenfalls nicht backup-geeignet.)

                dedlfix.

                1. Tach!

                  Das Filesystem meines vServers sieht übrigens so aus:
                  Filesystem            Size  Used Avail Use% Mounted on
                  /dev/mapper/volume-root
                                        115G   18G   92G  16% /
                  tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
                  udev                  2.0G  116K  2.0G   1% /dev
                  tmpfs                 2.0G     0  2.0G   0% /dev/shm
                  /dev/vda1             248M   26M  210M  11% /boot

                  Davon sind nur / und /boot interessant, der Rest wird sowieso on-the-fly angelegt und übersteht ein Systemabschalten/-sturz sowieso nicht. Das heißt, beim Kopieren von / sollten diese Bereiche exkludiert werden. (proc und sys vermisse ich (ah, die zeigt das df nicht an, aber mount tut es), die sind ebenfalls nicht backup-geeignet.)

                  Der Vollständigkeit halber hier noch die Ausgabe von mount:
                  /dev/mapper/volume-root on / type ext4 (rw,relatime,errors=remount-ro,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
                  tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
                  proc on /proc type proc (rw,noexec,nosuid,nodev)
                  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
                  udev on /dev type tmpfs (rw,mode=0755)
                  tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
                  devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
                  /dev/vda1 on /boot type ext3 (rw)

                  Auf dem Filesystem läuft ja auch LVM2.
                  Vorweg mal als Frage: Soweit ich das bis jetzt recherchiert habe, bietet LVM doch die Möglichkeit Snapshot Backups zu erstellen - richtig?

                  Allerdings kapiere ich (noch) nicht so ganz, wie das Ganze dann funktioniert. Wenn ich es einigermaßen richtig verstanden habe, dann muss man für den Snapshot quasi ein Laufwerk erstellen und mounten. Von diesem dann das Backup erstellen und anschließend wieder unmounten - so oder so ähnlich jedenfalls. ;-)

                  Wäre sehr nett, wenn ihr mir da mal ein "wenig unter die Arme" greifen könntet, damit ich das noch vor Weihnachten kapiert habe - danke! :-)

                  Gruß Gunther

                  1. Tach,

                    Auf dem Filesystem läuft ja auch LVM2.

                    nein, das Filesystem befindet sich auf einem Block-Device, das von LVM zur Verfügung gestellt wird.

                    Vorweg mal als Frage: Soweit ich das bis jetzt recherchiert habe, bietet LVM doch die Möglichkeit Snapshot Backups zu erstellen - richtig?

                    Ja.

                    Allerdings kapiere ich (noch) nicht so ganz, wie das Ganze dann funktioniert. Wenn ich es einigermaßen richtig verstanden habe, dann muss man für den Snapshot quasi ein Laufwerk erstellen und mounten. Von diesem dann das Backup erstellen und anschließend wieder unmounten - so oder so ähnlich jedenfalls. ;-)

                    Wenn es darum geht mithilfe von Snapshots ein Backup zu machen, erzeugt man ein Snapshot Device, macht ein Backup von diesem Snapshot und löscht das Device wieder (aktive Snapshot-Devices verlangsamen die Festplatte, weil alle Änderungen mehrfach geschrieben werden müssen), damit kann man z.B. eine Datenbank sichern ohne dafür darin Sperren zu brauchen: http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

                    mfg
                    Woodfighter

                    1. Tach!

                      Auf dem Filesystem läuft ja auch LVM2.

                      nein, das Filesystem befindet sich auf einem Block-Device, das von LVM zur Verfügung gestellt wird.

                      OK, wieder etwas dazugelernt ...!

                      Vorweg mal als Frage: Soweit ich das bis jetzt recherchiert habe, bietet LVM doch die Möglichkeit Snapshot Backups zu erstellen - richtig?

                      Ja.

                      Allerdings kapiere ich (noch) nicht so ganz, wie das Ganze dann funktioniert. Wenn ich es einigermaßen richtig verstanden habe, dann muss man für den Snapshot quasi ein Laufwerk erstellen und mounten. Von diesem dann das Backup erstellen und anschließend wieder unmounten - so oder so ähnlich jedenfalls. ;-)

                      Wenn es darum geht mithilfe von Snapshots ein Backup zu machen, erzeugt man ein Snapshot Device, macht ein Backup von diesem Snapshot und löscht das Device wieder (aktive Snapshot-Devices verlangsamen die Festplatte, weil alle Änderungen mehrfach geschrieben werden müssen), damit kann man z.B. eine Datenbank sichern ohne dafür darin Sperren zu brauchen: http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

                      Erstmal danke für den Link.
                      Allerdings hapert es bei mir in erster Linie schon beim ersten Schritt, nämlich bei der Erstellung des Snapshot Volumes.

                      Meine Volume Group sieht so aus:

                      --- Volume group ---
                        VG Name               volume
                        System ID
                        Format                lvm2
                        Metadata Areas        1
                        Metadata Sequence No  5
                        VG Access             read/write
                        VG Status             resizable
                        MAX LV                0
                        Cur LV                2
                        Open LV               2
                        Max PV                0
                        Cur PV                1
                        Act PV                1
                        VG Size               116.75 GiB
                        PE Size               4.00 MiB
                        Total PE              29887
                        Alloc PE / Size       29887 / 116.75 GiB
                        Free  PE / Size       0 / 0
                        VG UUID               T3d2em-9Vqb-c39u-qB0f-AbIE-dNft-xmvzzq

                      Wie und wo erstelle ich denn da jetzt das Snapshot Volume (ohne dass ich dabei alle Daten lösche)?

                      Gibt es irgendwo einen "verständlichen" Artikel über das Dateisystem in Linux?
                      Die ganze Mounterei gibt's unter Windows ja nicht - primäre Partition, erweiterte Partition, logisches Laufwerk und Schluss! ;-)

                      Gruß Gunther

                      1. Tach,

                        Free  PE / Size       0 / 0

                        Wie und wo erstelle ich denn da jetzt das Snapshot Volume (ohne dass ich dabei alle Daten lösche)?

                        dafür hast du keinen freien Platz gelassen. Du könntest jetzt das Dateisystem und dann das Volume verkleinern, habe ich aber keine Erfahrung mit und würde es auch eher nicht empfehlen.

                        Gibt es irgendwo einen "verständlichen" Artikel über das Dateisystem in Linux?

                        Ich vermute mal du meinst nicht das Dateisystem, sondern den gesamten Umgang mit Festplatten und allem was da dran hängt? Ich würde einfach irgendwo in der Wikipedia (z.B. bei LVM) anfangen und mich durchklicken und mir die externen Sachen mit ansehen.

                        Die ganze Mounterei gibt's unter Windows ja nicht - primäre Partition, erweiterte Partition, logisches Laufwerk und Schluss! ;-)

                        Windows kann schon seit Jahren ähnliche Dinge (logische Volumes, Software-RAID, mounten, Schattenkopien), sie werden nur seltener genutzt.

                        mfg
                        Woodfighter

                        1. Tach!

                          Free  PE / Size       0 / 0

                          Wie und wo erstelle ich denn da jetzt das Snapshot Volume (ohne dass ich dabei alle Daten lösche)?

                          dafür hast du keinen freien Platz gelassen. Du könntest jetzt das Dateisystem und dann das Volume verkleinern, habe ich aber keine Erfahrung mit und würde es auch eher nicht empfehlen.

                          Ja, dasss da aktuell kein Platz mehr vorhanden ist, habe ich mir auch schon gedacht.
                          Allerdings ist ja erst relativ wenig Platz tatsächlich belegt. Insofern war ich davon ausgegangen, dass ich noch "Platz schaffen" könnte ...!

                          Gibt es irgendwo einen "verständlichen" Artikel über das Dateisystem in Linux?

                          Ich vermute mal du meinst nicht das Dateisystem, sondern den gesamten Umgang mit Festplatten und allem was da dran hängt? Ich würde einfach irgendwo in der Wikipedia (z.B. bei LVM) anfangen und mich durchklicken und mir die externen Sachen mit ansehen.

                          Das ist nebenbei bemerkt IMHO einer der etwas "unschöneren" Aspekte an Linux. Es gibt zwar haufenweise irgendwelche Tutorials, aber entweder sind sie veraltet, oder gelten nur für bestimmte Distributionen, oder bestimmte Versionen oder oder oder ...

                          Die ganze Mounterei gibt's unter Windows ja nicht - primäre Partition, erweiterte Partition, logisches Laufwerk und Schluss! ;-)

                          Windows kann schon seit Jahren ähnliche Dinge (logische Volumes, Software-RAID, mounten, Schattenkopien), sie werden nur seltener genutzt.

                          Stimmt! Ich wollte damit eigentlich auch eher zum Ausdruck bringen, dass Otto normal Anwender mit solchen Dingen i.d.R. nichts zu tun hat, bzw. wenn, dann meist mit Hilfe irgendwelcher Tools/ GUIs, die die ganze Sache wesentlich intuitiver gestalten.

                          Gruß Gunther

                          1. Tach,

                            Ja, dasss da aktuell kein Platz mehr vorhanden ist, habe ich mir auch schon gedacht.
                            Allerdings ist ja erst relativ wenig Platz tatsächlich belegt. Insofern war ich davon ausgegangen, dass ich noch "Platz schaffen" könnte ...!

                            das geht ja auch, aber ich kenne mich damit nicht aus, resize2fs und lvresize können das.

                            Das ist nebenbei bemerkt IMHO einer der etwas "unschöneren" Aspekte an Linux. Es gibt zwar haufenweise irgendwelche Tutorials, aber entweder sind sie veraltet, oder gelten nur für bestimmte Distributionen, oder bestimmte Versionen oder oder oder ...

                            Mit etwas Erfahrung kann man diese dann allerdings meist trotzdem nutzen und passend substituieren und üblicherweise liegt die gesamte Doku, die man braucht, schon in /usr/share/doc oder als man/textinfo vor.

                            Stimmt! Ich wollte damit eigentlich auch eher zum Ausdruck bringen, dass Otto normal Anwender mit solchen Dingen i.d.R. nichts zu tun hat, bzw. wenn, dann meist mit Hilfe irgendwelcher Tools/ GUIs, die die ganze Sache wesentlich intuitiver gestalten.

                            Auch für LVM gibt es GUIs, z.B. system-config-lvm; der Vorteil ist, man muss sie nicht benutzen.

                            mfg
                            Woodfighter

        2. Tach!

          Hallo.

          Wie mache ich denn am besten eine (möglichst) komplette System-Sicherung unter Linux?

          Platte kopieren, oder cp -a auf Dateiebene.

          Warum sollte man sowas tun? Ich habe sowohl auf meinen workstations als auch auf meinen servern /home auf einer seperaten partition. Wenn notwendig wird diese gesichert. Ansonsten brauche ich nur /etc, auf einigen systemen vllt. noch /opt und /var. Kommt ganz drauf an wie die anderen backup strategien sind (meine datenbank backups der anwendungungen beispielsweise, werden von den anwendungen erstellt und verteilt).

          Auf meinem home liegt auch /u, eventuell die webroots, ftp.. alles was "daten" sind. Ich versuche den rest von meinem / austauschbar zu halten, und bin bis jetzt immer relativ gut damit gefahren. Wenn irgendwas passiert, wird die kiste via console resettet, einen neues mininmal system drauf gebügelt und die backups eingespielt.

          Leider bin ich noch nicht soweit die komplette installation des basissystems von Chef oÄ. automatisiert aufzusetzen, aber in naher zukunft werde ich daran arbeiten.

          Mfg entropie

          --
          Whenever people agree with me I always feel I must be wrong.
            -- Oscar Wilde
          1. Tach!

            Wie mache ich denn am besten eine (möglichst) komplette System-Sicherung unter Linux?
            Platte kopieren, oder cp -a auf Dateiebene.
            Warum sollte man sowas tun?

            Das ist die Frage, die ich mir auch stelle. Einerseits hat man damit sehr schnell und mit wenigen Handgriffen wieder einen lauffähigen Stand (vorausgesetzt, das Backup hat alles erwischt und keine Problemfälle mit offenen und nur halb geschriebenen Dateien gesichert). Andererseits hat man damit jede Menge Zeug gesichert, das bei einer Systeminstallation (plus Updates) auch wieder da ist. Hier hat Linux den Vorteil, dass das Updaten einer CD/DVD-Neuinstallation üblicherweise deutlich schneller geht als ein Windows auf den aktuellen Stand zu patchen, besonders wenn es eine alte Version ist und tausendundein Patch mit mehrfachem Booten zwischendrin nachzupflegen ist.

            Ich bin ja auch eher dafür, System und Programme neu zu installieren und nur die Daten zu sichern. Für so einen Server hat es sich für mich bewährt, alle Konfigurationsschritte zu protokollieren, so dass ich im Falle eines Falles einen roten Faden habe und nichts vergesse.

            Leider bin ich noch nicht soweit die komplette installation des basissystems von Chef oÄ. automatisiert aufzusetzen, aber in naher zukunft werde ich daran arbeiten.

            Puppet for the win. Das verwenden wir für die neuen SELFHTML-VMs, nicht weil es so/zu viele sind, sondern eher aus Dokumentations- und Nachvollziehbarkeitsgründen (in Testmaschinen). Da steht alles drin, was zu tun ist, und automatisch geht's obendrein auch noch.

            dedlfix.

            1. Tach!

              Hi.

              Leider bin ich noch nicht soweit die komplette installation des basissystems von Chef oÄ. automatisiert aufzusetzen, aber in naher zukunft werde ich daran arbeiten.

              Puppet for the win. Das verwenden wir für die neuen SELFHTML-VMs, nicht weil es so/zu viele sind, sondern eher aus Dokumentations- und Nachvollziehbarkeitsgründen (in Testmaschinen). Da steht alles drin, was zu tun ist, und automatisch geht's obendrein auch noch.

              Ich benutz seit einiger zeit Capistrano zum deployen von ruby anwendungen (nicht rails), und ich war sehr begeistert. Ich werde das defintiv noch ausweiten auf die installationsoutinen des systems. Aber ist erstmal einiges an aufwand bevor man wirklich automatisiert installieren/deployen kann. Morgen, ™.

              Mfg entropie

              --
              Whenever people agree with me I always feel I must be wrong.
                -- Oscar Wilde