[ERLEDIGT]ispCP System Backup: HowTo

[menki]

also ich bin gerade dabei einen zweiten sicherungsjob anzulegen der mir /etc samt unterverzeichnisse sichert. im ersten backup werden die /var/www/virtual/ verzeichnisse komplett gesichert. am ende der sicherung bekomme ich eine komplette auflisttung was gesichert wurde, wieviel gesichert wurde mit welchem daten durchsatz gesichert wurde, und überhaupt was und wieviele files auf dem ftp server mehr bzw. weniger wurden. also sehr deutlich.

an alle die sich nicht direkt als root einloggen. die mail wird dem normalen user in sein /var/mail/der_user zugestellt. ich habe einfach in der /etc/aliases den zustellungsort bzw. die mail auf meine root mail angepasst. diese methode wird auf alle ovh server zutreffen den die erstellen in dem image einen OVH user. bei anderen providern kann dieses anders sein...

in die exlude datei müssen komplette verzecihniss-pfade hinein. wenn ich das verzeichniss /tmp im virtualhost testdomain.de in der sicherung ausschliessen möchte, dann füge ich diesen pfad in die /root/.ftplicity/mein_profil/exclude rein:

/var/www/virtual/testdomain.de/tmp

bei sehr viel daten ist es empfehlenswert die filegrösse auf dem ftp server in der conf datei auf 100 mb anzupassen.

bei zwei verschiednenen profilen sollten sich diese in der cron nicht in die quere kommen, also verschiedene zeiten eintragen. ersten backup über cron laufen lassen und dann die mail abwarten. die mail wird das start bzw. end datum beinhalten (bei mir war das wichtig da der server bei mehr last länger zum zum sichern benötigte). man kann schon mehrfache gleichzeitige backups laufen lassen aber die cpu wird sicherlich 100% nonstop betragen!

überetzung könnte ich auch machen, nur die woche komme ich sicherlich nicht dazu.

MENKI

---

wir können genau so einen verschlüsselten mySql dump durchführen und diesen in ein separates verzeichniss auf dem ftp server ablegen. die vorgehensweise ist so.

----> wir erstellen eine datei mit dem namen pre im verzeichniss: /root/.ftplicity/backup_profile/

# vim /root/.ftplicity/backup_profile/pre

---> wir fügen folgenden inhalt in die pre datei rein und ausserdem wollen wir die mySql sicherungen in ein separates verzeichniss auf dem ftp server haben:

Code:

/usr/bin/mysqldump –-all-databases -u root -pdeinrootpasswort > /mysqldump/db_backup.sql

---> /root/.ftplicity/backup_profile/pre MUSS ausführbar sein

# chmod 700 /root/.ftplicity/backup_profile/pre

nach erfolgreicher sicherung sendet das system so eine ausführliche mail:

Code:

--- Start running command BKP (18:40:02.213) ---
Running duplicity - OK
Output: NcFTP version is 3.2.0
Reading globbing filelist /root/.ftplicity/menki/exclude
Last full backup date: none
No signatures found, switching to full backup.
--------------[ Backup Statistics ]--------------
StartTime 1224434402.59 (Sun Oct 19 18:40:02 2008)
EndTime 1224438081.25 (Sun Oct 19 19:41:21 2008)
ElapsedTime 3678.66 (1 hour 1 minute 18.66 seconds)
SourceFiles 606559
SourceFileSize 16674708129 (15.5 GB)
NewFiles 606559
NewFileSize 16674708129 (15.5 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 606559
RawDeltaSize 3085844187 (2.87 GB)
TotalDestinationSizeChange 11559613834 (10.8 GB)
Errors 0
-------------------------------------------------
--- Finished (19:41:40.849) ---

--- Start running command POST (19:41:40.888) ---
Skipping n/a script '/root/.ftplicity/menki/post'.
--- Finished (19:41:40.902) ---

FULLSPEED !!

über ein feedback würde ich mich natürlich freuen:

---> ftplicity heise online artikel (bitte ftplicity von sourceforge laden!)
http://www.heise.de/security/artikel/78816/1

ausserdem beim gesamten system backup diese verzeichnisse unbedingt auch ausschliessen! (also in die exlude datei einfügen):

Code:

/boot
/dev
/initrd
/lib
/media
/mnt
/proc
/src
/sys
/tmp
/var/tmp
/var/run
/var/spool

MENKI

[Kaimane]

(10-20-2008 03:01 AM)menki Wrote:  

Code:

/usr/bin/mysqldump –-all-databases -u root -pdeinrootpasswort > /mysqldump/db_backup.sql

Menki, wäre es nicht sinnvoller vor dem mysqldump den MySQL-Daemon zu beenden? Oder macht mysqldump dies automatisch?
Habe in verschiedenen Threads gelesen, dass mysqldump einen fehlerhaften Dump erstellt, sobald wärend des Vorgangs ein Schreibbefehl an die DB gesendet wird.
Hast du da Informationen zu?

Vorab vielen Dank für dein Tutorial!

[menki]

der mysqldump sperrt kurzzeitig die zu sichernde datenbank wärend des sicherns, und gibt sie sofort wieder frei sobald die datenbank gesichert wurde. :-)

das stoppen des daemons ist absolut nicht erwünscht! wir wollen alle mysql datenbanken sichern und die benutzer sollen davon nichts mitbekommen. bei grösseren datenbanken kann der backupdump etwas länger dauern, und dann könnten die user etwas bemerken. bei 1-20 mb grossen datenbanken (innerhalb des rechenzentrums) wird die nichterreichbarkeit kaum spürbar sein. alles ist abhängig vom eigenen server und wie weit der ausgelastet ist , bzw. wie die backup server angebunden sind. es gibt da mehrere kriterien die eine rolle spielen. desto schneller die server, desto kürzer wird dumpmässig auf die datenbanken zugegriffen. also meine server sichern 20 mb databases in bruchteilen von sekunden. das fällt keinem auf. :-)

die beste methode wäre wäre den gesamten server zu replizieren/spiegeln und somit eine kopie des gesamten servers als sicherung zu haben. die software rsync in kooperation mit duplicity wäre dazu allzu perfekt! der nachteil wenn der server gehackt wurde wird der hack genauso auf die server kopie übertragen. :-)

der backupserver sollte immer in der nähe (gleiches netz/subnet) sein. server to server transfers innerhalb des rechenzentrums werden (im lan) 5 mal schneller transferiert!

grüße

MENKI

[ZooL]

der backupserver sollte immer in der nähe (gleiches netz/subnet) sein. server to server transfers innerhalb des rechenzentrums werden (im lan) 5 mal schneller transferiert!

und meistens nicht berechnet

mfg

[menki]

na ja viele grosse provider haben schon unlimiterten transfer. :-)

aber du hast schon recht, es wird mestens nicht berechnet.

MENKI

[Kaimane]

@Menki
Kurze Frage: Ist es möglich die zu sichernden Dateien sowohl auf dem externen FTP als auch lokal unter beispielsweise /home/backup abzulegen?

EDIT
-----
Bei der Konfiguration von ftplicity stellt sich mir eine weitere Frage:
Besteht die Möglichkeit in der Datei

Code:

/root/.ftplicity/profile/conf

mehrere zu sichernde Quellen anzugeben?
Bsp.:

Code:

SOURCE='/var/www','/var/mail/virtual','...'

Wenn dem nicht so ist, müsste ich wohl vor der eigentlichen Sicherung durch ftplicity erst mal alle zu sichernden Dateien in ein Verzeichnis kopieren, wodurch die Last des Servers erheblich in die Höhe schnellt und sich der Backupprozess deutlich verzögert.
Dies wäre sehr unvorteilhaft.

[menki]

du kannst mehrere verschiedene sicherungsprofile erstellen. diese könnten die verschiedenen gewünschten verzeichnisse sichern. cronmässig sollten sie sich nicht in die quere kommen.

wenn du lokal deine files verschlüsselt sichern möchtest dann füge in der config einfach: /tmp/backup_folder rein. das passwort sollte leer bleiben.

die files lokal zu speichern und dann irgendwo hianufzuladen ist sinnlos da das rücksichern so nicht funktionieren kann!

ganz wichtig!
bitte sichert eure duplicity/ftplicity konfiguration an einen sicheren ort ausserhalb des servers (vorallem den GPG-Key), da ansonsten eine rücksicherung nach einem systemausfall nicht mehr möglich wäre.

MENKI

[Kaimane]

(10-27-2008 01:21 AM)menki Wrote:  du kannst mehrere verschiedene sicherungsprofile erstellen. diese könnten die verschiedenen gewünschten verzeichnisse sichern. cronmässig sollten sie sich nicht in die quere kommen.

Dieser Weg sollte mir auch recht sein

(10-27-2008 01:21 AM)menki Wrote:  wenn du lokal deine files verschlüsselt sichern möchtest dann füge in der config einfach: /tmp/backup_folder rein. das passwort sollte leer bleiben.

Also würde das so aussehen:

Code:

TARGET='/tmp/backup_folder/'
TARGET_PW=''

(10-27-2008 01:21 AM)menki Wrote:  die files lokal zu speichern und dann irgendwo hianufzuladen ist sinnlos da das rücksichern so nicht funktionieren kann!

Das hab ich auch nicht vor, sollte nur zusätzlich dort gesichert werden.

Jetzt ist folgendes Problem beim Testlauf aufgetreten:

Code:

Start ftplicity v1.4.0b1, time is 10/26/08 16:45:47.
Using profile '/root/.ftplicity/webmailsql'.
Attention: Could not interpret your duplicity version string ((most
"/usr/bin/duplicity",
duplicity.backends
"/usr/lib/python2.4/site-packages/duplicity/backends/__init__.py",
duplicity.backends.botobackend
"/usr/lib/python2.4/site-packages/duplicity/backends/botobackend.py",
duplicity.backend
"/usr/lib/python2.4/site-packages/duplicity/backend.py",
duplicity.dup_temp
"/usr/lib/python2.4/site-packages/duplicity/dup_temp.py",
log,
"/usr/lib/python2.4/site-packages/duplicity/path.py",
duplicity
"/usr/lib/python2.4/site-packages/duplicity/gpg.py",
GnuPGInterface,
No).

--- Start running command PRE (16:45:47.16) ---
Running '/root/.ftplicity/webmailsql/pre' - OK
--- Finished (16:45:47.47) ---

--- Start running command BKP (16:45:47.48) ---
Running duplicity - FAILED (code 1)
Output: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 31, in ?
    import duplicity.backends
  File "/usr/lib/python2.4/site-packages/duplicity/backends/__init__.py", line 9, in ?
    import duplicity.backends.botobackend
  File "/usr/lib/python2.4/site-packages/duplicity/backends/botobackend.py", line 22, in ?
    import duplicity.backend
  File "/usr/lib/python2.4/site-packages/duplicity/backend.py", line 30, in ?
    import duplicity.dup_temp as dup_temp
  File "/usr/lib/python2.4/site-packages/duplicity/dup_temp.py", line 22, in ?
    import log, path, file_naming
  File "/usr/lib/python2.4/site-packages/duplicity/path.py", line 657, in ?
    from duplicity import gpg
  File "/usr/lib/python2.4/site-packages/duplicity/gpg.py", line 22, in ?
    import GnuPGInterface, misc, log
ImportError: No module named GnuPGInterface
--- Finished (16:45:47.58) ---

--- Start running command POST (16:45:47.59) ---
Skipping n/a script '/root/.ftplicity/webmailsql/post'.
--- Finished (16:45:47.60) ---

Womit kann dies zusammen hängen?

EDIT
-----
Nach vielem Lesen hat es dann nun doch geklappt! Keine Fehlermeldung mehr.
In Menki's HowTo wird unterstellt, dass soweit alles an benötigter Software installiert ist, um duplicity lauffähig zu machen (ausser python-dev sowie librsync-dev; diese Pakete werden ausdrücklich zum installieren angesprochen).
Duplicity gibt jedoch folgende Vorraussetzungen an:

Duplicity Requirements Wrote:* Python v2.3 or later (Python Home)
* librsync v0.9.6 or later (librsync Home)
* GnuPG for encryption (GnuPG Home)
* GnuPGInterface 0.3.2 or later (GnuPGInterface Home)
* NcFTP version 3.1.9 or later (NcFTP Home)
* Boto 0.9d or later (Boto Home)
* pexpect 2.1 or later (Pexpect Home)

Bei mir war es GnuPGInterface sowie pexpect, was nicht installiert war und somit zu den o. g. Fehlermeldungen führte.

@Menki
Vllt nimmst du dies noch in dein Howto auf ...

Viele Grüße

[menki]

freut mich das es funktioniert hat!

die progs sind seit der letzten version dazugekommen.

die howto werde ich natürlich dementsprechend anpassen.

sonst bist du step by step vorgegenagen und die einzigen troubles waren in den fehlenden programmen?

MENKI

[Kaimane]

(10-27-2008 03:47 AM)menki Wrote:  sonst bist du step by step vorgegenagen und die einzigen troubles waren in den fehlenden programmen?

Genau! Step by Step. Musste zwar ab und zu zwischen Post #1 und #11 switchen, da es nicht ganz zusammenhängend ist, aber ansonsten hab ich mich ans HowTo gehalten und es klappt wunderbar.
Habs gestern Abend manuell gestartet, mit Erfolg. Cronjob für 2am eingerichtet, jedoch keine Sicherung. Scheinbar hat sich nichts an den Dateien verändert (Server ist noch nicht produktiv), sodass auch nichts gesichert werden musste.
Ich denke, morgen früh werde ich wissen, ob alles funktioniert.

BTW: Kurze Frage: Wann läuft der Backup-Cron von ISPCP für die täglichen Backups an?
Bring ja nichts, wenn das ISPCP-Backup nach dem Ftplicity-Backup startet ...