KeyHelp Community

Hallo zusammen,

ich überlege, ob wir zusätzlich das in keyhelp integrierte Backupsystem nutzen. Kann mir einer sagen, wie lange ein Backup eines ordentlich gefüllten Servers auf z.B. eine keydisc benötigt?

Ist die genaue Vorgehensweise irgendwo dokumentiert?

PS: http://serverfault.com/questions/769357 ... om-a-rm-rf

Hallo,

habe über den Vormittag ein Backup via KeyHelp auf einem gefüllten System durchgeführt.

Art des Backups: Vollständiges Server Backup
Benutzer: 100
Verwendete Daten (bunt gemischt, typische webhostdaten, Datenbanken, E-Mails): 50 GB
Speicherort: Lokal

Gestartet: 09:32:42
Beendet: 13:14:34

Am Längsten dauerte das Komprimieren des Finalen Archivs: 2:50 h

Sofern Bedarf besteht, werde ich dem Administrator noch Einflussmöglichkeiten auf die Kompressionsstufe geben, um die Zeit zu verkürzen.

Ist die genaue Vorgehensweise irgendwo dokumentiert?

Welche Vorgehensweise meinen Sie, das Einrichten von Backups?

Hallo Alexander,

vielen Dank für die Antwort.

Alexander wrote:

Ist die genaue Vorgehensweise irgendwo dokumentiert?

Welche Vorgehensweise meinen Sie, das Einrichten von Backups?

Ich meinte, welche Daten gesichert werden, und wie.

Also z.B.
- /home/users/ wird kopiert
- /etc/ wird kopiert
- alle Datenbanken werden exportiert mit: mysqldump --routines --quick

Hintergrund meiner Frage:

Ich habe z.B. bei anderen Providern die Erfahrung machen dürfen, dass Datenbanken ohne --routines exportiert werden. Bei einem restore fehlen dann die views.

Vielleicht ist es für manche Anwender wichtig, die installierten Pakete für einen Restore zu kennen ...

Wenn man die genaue Vorgehensweise kennt, kann man als Keyhelp Anwender besser abschätzen, was man zusätzlich vor dem Backup an die richtige Stelle kopieren/schreiben muss.

Hallo,

Der Parameter "--routines" ist tatsächlich noch nicht Teil des Datenbank-Dumps.
Ich werde Ihn aber im kommenden Update [ 14.6.3 / 14.7.0 ] ergänzen, Danke für den Hinweis!

Ordnerstruktur der 7zip

Dateiname: ART_DES_BACKUPS - SERVERNAME - ERSTELLUNGSZEIT .7z

Inhalt Server-Backup:

/database/
- direkt in diesem Verzeichnis befinden sich alle Datenbanken, die keinem KeyHelp Benutzer gehören, bzw. die Unabhängig von KeyHelp-Benutzern angelegt wurden, z.B. die KeyHelp eigene Datenbank, Roundcube, phpMyAdmin, usw...
- Weiterhin befindet sich hier die Datei "all-databases.sql" mit dem Inhalt aller Datenbanken [erstellt mit --add-drop-table], dies dient als eine Art Desaster Recovery
- Datenbanken der Kunden befinden sich in Unterordnern, mit dem Namen des KeyHelp-Benutzers: <KeyHelp-Benutzername>/<Datenbankname>.sql
- Datenbank Backups werden bislang ohne spezielle Parameter, die Einfluss auf den Output hätten erstellt [ab kommender Version dann mit "--routines"]

/mail/
- hier befinden sich alle E-Mails der KeyHelp Benutzer, gepackt als .tar
- für jeden Benutzer existiert eine Datei: <KeyHelp-Benutzername>.tar
- der Inhalt der .tar entspricht dem Inhalt des Verzeichnisses /var/mail/vhosts/<Domainname>/
- in dieser .tar befinden sich alle E-Mail-Postfach-Ordner eines Benutzers

/home/
- hier befinden sich die Homeverzeichnisse der Benutzer, gepackt als .tar
- für jeden Benutzer existiert eine Datei: <KeyHelp-Benutzername>.tar
- der Inhalt der .tar entspricht dem Inhalt des Verzeichnis /home/users/<KeyHelp-Benutzername>/

/config/
- hier befinden sich 4 .tar Archive:
- root.tar (= Inhalt der /root/ Verzeichnis)
- etc.tar (= Inhalt des /etc/ Verzeichnis)
- cron.tar (= Inhalt des /var/spool/cron/ Verzeichnis)
- keyhelp.tar (= Inhalt des /home/keyhelp/ Verzeichnis)


Ein Benutzerbackup hat die selbe Struktur, die ein Server Backup:

/database/
- mit dem Unterordner <KeyHelp-Benutzername>/<Datenbankname>.sql

/mail/
- mit dem Inhalt <KeyHelp-Benutzername>.tar

/home/
- mit dem Inhalt <KeyHelp-Benutzername>.tar


Wird das Einspielen eines Backups notwendig, so muss der Inhalt der einsprechende Inhalt der Ordner/Archive an die oben genannte Stelle kopiert werden. KeyHelp wird eine automatisierte Einspiel-Funktion für Backups nachreichen.


Ergänzende Hinweise:
Zu Beginn des Backup Prozesses wird in etwa doppelt soviel Speicherplatz alloziert, wie gesichert werden soll. Laufen nun auf einem mit vielen Benutzern belegten Server alle Backups zur gleichen Zeit, kann es vorkommen, das für später gestartete Backups kein Platz im aktuellen Durchlauf mehr vorhanden ist. Es würde in dem Fall eine Fehler-E-Mail an die im Backup-System hinterlegte E-Mail gesendet werden.
Sollte also Speicherplatz-Knappheit bestehen, ist es ratsam den Backup-Zeitpunkt auf unterschiedliche Uhrzeiten zu verteilen.

Vielen Dank für die sehr ausführliche Beschreibung.

Alexander wrote: Am Längsten dauerte das Komprimieren des Finalen Archivs: 2:50 h

Sofern Bedarf besteht, werde ich dem Administrator noch Einflussmöglichkeiten auf die Kompressionsstufe geben, um die Zeit zu verkürzen.

Ich melde hier Bedarf an. Ab ca. 500 GB kann man nicht mehr täglich mit dieser Methode sichern.

Vielleicht könnte man für den tar Befehl auch exclude Parameter hinterlegen? Das würde bei uns die Datenmenge ein wenig reduzieren.

select name from me; wrote:Vielleicht könnte man für den tar Befehl auch exclude Parameter hinterlegen? Das würde bei uns die Datenmenge ein wenig reduzieren.

Weiterhin wäre auch die Implementierung von differentiellen/inkrementellen Backups eine Möglichkeit, Zeit und zu sichernde Datenmenge zu reduzieren.

Bisher haben wir die Daten differentiell gesichert. Erst mit rsync, rsnapshot, dann mit rdiff-backup. In Verbindung mit der Keydisc gibt es aber einige Hindernisse.

Der Vorteil der Keyhelp Lösung ist natürlich, dass man sich um Anpassungen nicht kümmern muss.

Hast Du positive Erfahrungen mit anderen Systemen in diesem Bereich?

select name from me; wrote:Hast Du positive Erfahrungen mit anderen Systemen in diesem Bereich?

Die Krux bei Backups ist ja, daß es kaum allgemeingültige Richtlinien für DAS perfekte Backup gibt. Jedes Projekt hat andere Anforderungen an die Datensicherung bezüglich des Umfangs und der Art der zu sichernden Daten und auch der nötigen bzw. sinnvollen Backupintervalle.
Und da es nach meinem Kenntnisstand (noch) nicht DAS universelle Backuptool gibt, läuft es letztlich immer auf die Entwicklung einer ganz individuellen Backupstrategie heraus, die genau die Ansprüche des jeweiligen Projekts erfüllt.
Für reine DB-Sicherungen nutze ich je nach Einsatzzweck z.B. mysqldump (wenn man Zugriff auf das CLI hat), MySQLDumper (ideal, wenn kein CLI-Zugriff verfügbar) oder bei großen Sachen auch schon mal Percona XtraBackup.
Für komplette (und inkrementelle/differentielle) Backups kommt neben rsync/rsnapshot u.a. Tartarus oder Bacula zum Einsatz.
Tartarus ist meist meine erste Empfehlung, da hiermit viele Eventualitäten abgedeckt werden können, von einfachen Sicherungen über LVM-Snapshots bis hin zu inkrementellen Sicherungen ist einiges realisierbar. Auch verschlüsselte Backups sind hier kein Problem. Außerdem ist Tartarus in der Lage, den Backupspeicher aufzuräumen und so eine einfache Backup-Versionierung zu etablieren. Es ist auch ziemlich simpel zu konfigurieren und setzt ausnahmslos auf bereits vorhandene Systemtools auf.

P.S. Die MySQLDumper-Seite ist im Moment scheinbar offline

Danke für die Infos. Ich fürchte sogar, es gibt nicht mal pro Projekt DAS perfekte Backup.

Bacula haben wir früher auch mal verwendet. Tartarus schaue ich mir an.

select name from me; wrote:Ich fürchte sogar, es gibt nicht mal pro Projekt DAS perfekte Backup.

Jupp, liegt aber auch in der Natur der Sache...Genauso wie sich ein Projekt (meist) ständig weiterentwickelt, muß auch die Backupstrategie immer mal wieder an die aktuellen Gegebenheiten angepaßt werden.

select name from me; wrote:Tartarus schaue ich mir an.

Dazu hier noch eine ziemlich gute Zusammenfassung als zusätzlicher Lesestoff.

Super, vielen Dank!

Macht es nicht Sinn, die Datei all-databases.sql wegzulassen?
Wir haben zumindest ziemlich umfangreiche Datenbanken und dadurch die doppelte Datenmenge.

Ein Restore wäre ja auch anhand der Dateinamen möglich.

Hallo,

die all-databases wird angelegt um im Falle eines "Desasters" in einem Wisch die Datenbanken importieren zu können.
Die einzelnen Dumps können Spezifisch bei Bedarf für nur die jeweilige DB für den Restore genutzt werden.

Hallo Daniel,

verstehe. Ich finde es jedoch unnötig. Mit einer kurzen Schleife könnte man die Datenbanken anlegen und die einzelnen SQL Dateien importieren.

Das würde eine Menge sparen, wenn man, wie wir, nicht nur ein paar Wordpress Blogs in der Datenbank hat.

Ein entsprechendes Skript könnte man zur Not sogar mit in das Backup einfügen.