Remote FTP & SQL Backup

[Nimox]

Hi @ all

hier mein Problem ...

Wir haben einen Server im RZ auf dem unser gesamtes CMS läuft.
Es sind nen paar einzel HP'S ca 4 Datenbanken und ne menge an Daten ...
um genauer zu sein es sind Video Daten.

Auf dieser lustigen Kiste läuft "Plesk" und macht eigentlich so nen ganz vernünftigen eindruck.

Leider funzt die Plesk Backup Funktion "FTP Repository" nicht richtig.
Er bricht ab oder führt garnicht erst aus.

Nach vergeblichen Telefonaten mit Provider usw. gehe ich nun der Weg anders herum an.

Ich suche eine Möglichkeit unseren MacServer (local) mit dem FTP zu connecten.
Danach ein SYNC alle angegebenen Daten zu machen am besten gleich /httpdocs/

Das ganze dann für alle Domains ...(sind ja unterschiedliche Logins)
Die DB's würde ich mit dem MySQL Dumper angehen.
Dieses soll in periodischen Abständen immer wieder ausgeführt werden.

Hab Ihr ne Idee wie mann das realisiern kann?

 

[oneOeight]

kannst du mit rsync machen oder einem unix script, wo du einfach die dateien hochlädst (am besten vorher packen)...

 

[Nimox]

Vielen Dank schonmal für die AW

Kannst du mir bei rsyc behilflich sein ?

Sofern du da erfahrung hast würde ich mich über nen Link zu BSP freuen ...

Oder vieleicht kennst du ne Page mit nem guten HowTo.

Packen würde ich das gerne aber ohne shell zugriff auf dem Root is das leider nicht drinn den es is ein managed root....

LEIDER

THX

 

[oneOeight]

ich hab gerade gelesen, dass rsync bei so was nur vernünftig bei os x auf os x funktioniert.

ein paar ftp clients haben auch eine abgleich funktion.

 

[Nimox]

Es muss ja nichtmal eine Abgleich f(x) sein ein reguläres Backup reicht mir

Ich will nur nicht dumm da stehen wenn am RZ Server mal was is ich hätte eben gerne nen Full Backup local liegen.

Mit nem Clienten is mir das noch nicht gelungen ... Filezilla hat das nicht glaub ich ...

Und wenn dann müsste der Client sich echt automatisieren lassen.
Als BSP

Domain 1 Backup Montag 2200
Domain 1 DB Backup 0000

Domain 2 Backup Dienstag 2200
Domain 2 DB Backup 0000

und so weiter.

Kann denn nen client so ohne weiters automatisch connecten und files ziehen

Wenn ja und das geht dann echt so easy dann müsste ich nur noch wissen welcher Client sowas kann

 

[Zapfenzieher]

Du kannst dein eigenes rsync Script schreiben und dazu die passenden SQL-Scripts und Loggingfunktionen. Oder du codes selber kurz in Assembler deine eigene Backupsoftware. Natürlich könntest du die Daten auch mit Papier und Bleistift abschreiben.

Wenn du eine seriöse Antwort willst brauche ich folgende Daten:

1. Name der CMS
2. Eingesetzte Datenbank
3. Datenmenge die übertragen wird
4. Lokale Bandbreite
5. Betriebssystem des Servers im RZ und Lokal

Danach kann man sich nach einer vernünftigen Backupsoftware umschauen und muss nicht eine selbstgefrickeltes Script verwenden.

 

[Nimox]

1. Name der CMS
--------------------
Kein name sonder Self Coding bessergesagt Auftrags Entwicklung kein CMS von der Stange.
--------------------
2. Eingesetzte Datenbank
-----------------------------
SQL Datenbank
-----------------------------
3. Datenmenge die übertragen wird
----------------------------------------
Insgesamt werden bei Full Backup aller Domains ca 15 GB übertragen
----------------------------------------
4. Lokale Bandbreite
-----------------------
2 MBit fixed IP Tange cxk 15 tkps
-----------------------
5. Betriebssystem des Servers im RZ und Lokal
----------------------------------------------------
Betriebssystem des Servers im RZ ist Open SUSE incl Plesk Administrations Interface .

Betriebssystem des Servers local ist MAC OS 10.5.X
----------------------------------------------------

So da hoff ich erstmal alle rellevanten Daten zusammengefasst zu haben.

Sollte noch was fehlen immer her mit den Fragen.

Vielen Dank für deine Mühe

 

[Zapfenzieher]

Zuerst muss mit dem Programmierer der CMS abgeklaert werden, wie die CMS-Daten genau zu sichern sind.


Für OS X ist die Auswahl der Backupsoftware leider extrem beschränkt.

tolisgroup.com/products/bruserver/macosx/highlights.html

Diese Software ist die einzige die mir bekannt ist. Ob sie etwas taugt kann ich dir nicht sagen.

Die sauberste Loesung waere sicher das Systen über zmanda auf einen Linux-Server zu sichern.

 

[2nd]

Die CMS-Dateien werden sicherlich auf Verzeichnis-Ebene gesichert.

Ich lasse meine Root-Servern durch Cronjobs per ftplicity/duplicity verschlüsselte inkrementelle Backups in zwei andere RZ sichern (2x täglich, per FTP). Die MySQL DB werden durch den mysqldumper bzw. dessen Perl-Skript kurz vor den Backups aus dem Filesystem rausgedumpt.

Ansonsten kannst Du noch eine PKI-Authentifizierung einrichten (Linux Server -> OS X Server) und die Daten per Cronjob getriggert via SCP verschicken (vorher packen!). Das funktioniert auch gut.

Das mit FTP und verschiedenen Logins halte ich für keine gute Idee: nackiges FTP ist unverschlüsselt und für jeden vHost ein Login/Backup-Skript Task ist zu aufwendig.

Die Backupinitiative sollte vom Linux-Server ausgehen und ein wartendes System übernimmt nur die Daten.

 

[Zapfenzieher]

Die CMS-Dateien werden sicherlich auf Verzeichnis-Ebene gesichert.

Das ist nicht klar. Und es macht dann keinen Spass, wenn man ein korruptes Backup hat.

Ich lasse meine Root-Servern durch Cronjobs per ftplicity/duplicity verschlüsselte inkrementelle Backups in zwei andere RZ sichern (2x täglich, per FTP). Die MySQL DB werden durch den mysqldumper bzw. dessen Perl-Skript kurz vor den Backups aus dem Filesystem rausgedumpt.

Ansonsten kannst Du noch eine PKI-Authentifizierung einrichten (Linux Server -> OS X Server) und die Daten per Cronjob getriggert via SCP verschicken (vorher packen!). Das funktioniert auch gut.

Das ist sicher eine Loesung wenn man ein paar private Dateien zu sichern hat. Aber fuer Firmen ist dieser Ansatz viel zu fehleranfaellig und unsicher.

Die Backupinitiative sollte vom Linux-Server ausgehen und ein wartendes System übernimmt nur die Daten.

Das Backup muss immer von einem externen System gestartet werden. Externe Systeme duerfen nie Zugriff auf den Backupspeicher haben. Ansonsten ist man nicht gegen Benutzerfehler und Programmfehlfunktionen geschuezt. Das ist das zentrale Prinzip einer Backuploesung.

 

[2nd]

Das ist sicher eine Loesung wenn man ein paar private Dateien zu sichern hat. Aber fuer Firmen ist dieser Ansatz viel zu fehleranfaellig und unsicher.

Das waren 2 Ansätze. Was meinst Du mit fehleranfällig und unsicher?

 

[Zapfenzieher]

Gehen wir mal davon aus, dass keine Offsitebackups existiert. Dann muss ein dedizierter Backupserver existieren welcher ausschliesslich Zugriff auf den Backupspeicher hat. Der Backupserver darf genau nur einen Administratorzugang per SSH/RDP und gesondertem Passwort haben. Dieser Backupserver holt dann per Client die Dateien ab.

Alle Backupskonzepte die dieses Grundprinzip nicht befolgen kann man sofort in die Tonne treten. Wenn ein anderer Server oder Dienst auf die Backupdaten zugreifen kann, kann dieser auch die Backups zerstoeren. Am schlimmsten sind die, welche gnadenlos das Backupvolumen auf allen zu sichernden Servern fix mounten, oder einfach so das Backupvolumen per FTP oder SCP dem ganzen Intranet mit einem Standardpasswort oder schlimmer mit PKI zur
Verfuegung stellen.

Ein Backup muss bestmoeglich geschirmt gegen alle Aussenzugriffe sein. Alles andere schuetzt vielleicht gerade gegen Hardwareausfall.

In diesem speziellen Fall hier, will der TS ja den internen Server als Backupserver zur Verfuegung stellen. Da ist ein offener SSH oder FTP-Port noch doofer.

 

[Nimox]

Ich möchte euch ja ehrlich nicht zu nahe treten aber Ihr schiesst da etwas über das Ziel hinaus.

Nochmal ich suche eine ganz " stink normale " Backuplösung für einen im RZ gehosteten Root Server.

Es ist doch völlig egal auf wieviel Folder ebenen die Daten verteilt sind !!!
Ich muss auch nicht vorher packen es is mir auch recht wenn der File für file einzel zieht...

Das ganze muss auch nicht Sicherheitsrelevant abgesegnet werden.

Es soll nur ein FTP to FTP transfer stattfinden.

Wir haben schon backups in diese RZ auch ein Sync läuft schon.

Es soll nur eine Wöchentliche Versionskopie in underem localen NW bestehen.

DANKE

 

[Nimox]

Die CMS-Dateien werden sicherlich auf Verzeichnis-Ebene gesichert.

Ich lasse meine Root-Servern durch Cronjobs per ftplicity/duplicity verschlüsselte inkrementelle Backups in zwei andere RZ sichern (2x täglich, per FTP). Die MySQL DB werden durch den mysqldumper bzw. dessen Perl-Skript kurz vor den Backups aus dem Filesystem rausgedumpt.

Ansonsten kannst Du noch eine PKI-Authentifizierung einrichten (Linux Server -> OS X Server) und die Daten per Cronjob getriggert via SCP verschicken (vorher packen!). Das funktioniert auch gut.

Das mit FTP und verschiedenen Logins halte ich für keine gute Idee: nackiges FTP ist unverschlüsselt und für jeden vHost ein Login/Backup-Skript Task ist zu aufwendig.

Die Backupinitiative sollte vom Linux-Server ausgehen und ein wartendes System übernimmt nur die Daten.

Das würd ich auch gerne machn nur leider is es ein managed root sys und ich habe keinen zugang zu shell

Deswegen such ich ja die Abhollösung.

 

[Zapfenzieher]

Warum machst du dann nicht einfach eine FTP-Freigabe auf den nicht-root-Server und lädst die Dateien herunter?

 

[Nimox]

Warum machst du dann nicht einfach eine FTP-Freigabe auf den nicht-root-Server und lädst die Dateien herunter?

Kannst du mir das bitte genauer erläutern wie du das meinst ?

Ich hab auf dem OSX Server nen FTP Server am laufen (RUMPUS) kann aber auch noch den Server eigenen FTP Dienst zur Verfügung stellen.

Ich möchte das ja automatisch haben in einem periodischen Intervall...

Das nächste Problem ... leider Hackt Plesk die Daten auseinander je nach Domain eigener FTP acc und sql

 

[Zapfenzieher]

Ich kenne auch keine fertige Lösung für OS X. Vielleicht läuft duplicity unter OS X. Ansonsten musst du halt mit cron und einem Konsolen-FTP-Programm alles selber scripten.

 

[ratti]

ich hab gerade gelesen, dass rsync bei so was nur vernünftig bei os x auf os x funktioniert.

Ich verwende rsync von Linux-Clients nach OS X Server.

Das ganze hakt ganz furchtbar bei Dateinamen, die „Sonderzeichen“ enthalten, wobei der Begriff hier deutlich überstrapaziert ist: Als problematisch Sonderzeichen scheint so ziemlich alles in Frage zu kommen, was kein Buchstabe oder Zahl ist, sondern auch eigentlich ganz harmlose Zeichen. wie Minus oder so.

Da es aber hier um eine Webroot geht, und „man“ da normalerweise sowieso recht päpstlich mit den Dateinamen ist, ist das durchaus praktikabel.

Ein Fallstrick ist da noch: rsync OS X ist tastächlich reichlich broken, so ist es selbst auf einem Case-Sensitiv formatierten HFS+ nicht in der Lage, Dateien zu unterscheiden, und so wird z.B. /usr/lib/perl bei jedem Durchlauf überschrieben von /usr/lib/PERL. Ich weiss ja auch nicht, welcher Holzkopf auf diese Namen gekommen ist, aber jedenfalls ist rsync für OS X tatsächlich ein Software-Totalschaden (über das übliche Probleme hinaus, zwischen unterschiedlichen Betriebssystemen einfach keine Charset-Conversion durchzuführen…)

Was die MySQL-Daten angeht: Wir lassen ein Cron-Script laufen, welches alle Datenbanken dumpt - dann hat man schon mal Dateien. Die Dateien werden per MD5 mit dem bereits vorhandenen Backup verglichen, und wenn die gleich sind, dann weg damit. So halten wir das Backup klein.

Gruß,
Jörg