Meine Linksammlung bei del.icio.us: 
FTP-Sync ist ja eigentlich das Tool meiner Wahl, um FTP-Server abzuziehen. Das Dumme an FTP-Sync ist leider, dass es zwar auf dem FTP-Server gelöschte Dateien auch auf dem Ziel löscht, aber die Verzeichnisse bleiben stehen (das Verhalten hat Lars hier festgestellt; ich konnte es unter Windows und unter Linux reproduzieren. Ein Berechtigungsproblem auf der Zielplatte liegt definitiv nicht vor).
Also habe ich mich wieder auf die Suche nach einer Software für Windows (Martin hat was für den Mac in petto, aber ich habe als Wartungsrechner immer noch den Windoof-Kasten)… wo war ich? Achso: auf die Suche nach einer Software gemacht, die einen FTP-Server nicht nur 1:1 abziehen kann sondern auch die Änderungen an der FTP-Quelle mit dem Ziel synchronisiert ohne gleich alles komplett herunterzuladen.
Gestossen bin ich auf Allway Sync, das bis 20.000 Dateien/Monat Freeware ist; die Pro-Version kostet vertretbare 19,95 $ => rd. 15 €.
Die Oberfläche ist zwar sehr gewöhnungsbedürftig und unvollständig eingedeutscht, aber das Programm synchronisiert alles mit jedem: FTP zu Platte, S3 zu Platte, Platte zu S3, FTP zu S3 usw… s. links.
Zu allem Überfluss kann man Allway Sync auch noch per Kommandozeile oder Taskplaner anstossen – genau das Richtige für Vaters Sohn 
Zuerst jedoch muss man sich je Sync-Vorhaben ein Projekt anlegen, das dann als Reiter im Programmfenster erscheint. Das Projekt dann später über die Kommandozeile als Parameter mitgegeben werden.
Damit später der automatische Sync reibungslos funktioniert sollte man nach einem ersten Analyselauf die Warnmeldungen ausschalten, sonst holpert die automatische Synchronisierung natürlich. Dazu öffnet man die Eigenschaften des Projektes und schaltet bei “Fehlerbehandlung” Alle Warnungstypen auf “Ignorieren”.
Ein Blick in die Filter lohnt auch, ich habe dort die Cacheverzeichnissse in den Ausschlussfilter eingetragen. Da sind unendlich viele winzige Dateien drin, die eine Sicherung nur unnötig verlangsamen.
Der Kommandozeilenaufruf geschieht dann folgendermaßen:
C:\Program Files (x86)\Allway Sync\Bin\syncappw” -s “Projektname”-es
“Projektname” ist der Name des erstellten Sync-Projektesund muss in Anführungszeichen stehen.
“-es” veranlasst das Programm sich nach fehlerfreier (!) Abarbeitung des Auftrages zu beenden.
Man kann mehrere Projektnamen hintereinander schreiben, die dann alle automatisch abgearbeitet werden. Mit dem Parameter “-s” ohne Projektname grast Allway Sync alle vorhandenen Projekte ab.
Den Pfad zum Programm muss man natürlich entsprechend der eigenen Machine anpassen; oben steht das Beispiel für Windows 7 64 bit. Es gibt übrigens auch eine portable Version von Allway Sync.
Ich bin wirklich angetan und sollte das Programm doch an die Freeware-Grenze stossen, dann sind die paar Euronen gut investiert
Jetzt überlege ich noch, ob meine Robocopy-Scripte dieser Software weichen müssen… aber ich denke nicht. We´ll see….
Meine Linksammlung bei del.icio.us:
Meine Linksammlung bei del.icio.us:
Meine Linksammlung bei del.icio.us:
Ich hatte ja hier schonmal beschrieben, wie ich unter Windows mit ncpget und 7zip meinen Webspace abziehe. Caschy hat sich des Themas dankenswerterweise angenommen und den Post aufgegriffen.
Das Problem an dieser Lösung war immer, dass der ganze Webspace heruntergeladen wird, was natürlich dauert und für einen gewissen Zeitraum den Webspace auch etwas verlangsamt. Mir schwebte immer eine Lösung vor, die nur die Änderungen synchronisiert – quasi rsync via ftp.
Da rsync über ftp aber nicht tut (zumindest habe ich mir einen Wolf gesucht), ist mir eine andere Lösung aufgefallen: ftpsync. Dabei handelt es sich um ein Perl-Script, was somit die ganze Sache plattformunabhängig macht, denn Perl gibts für jedes Betriebssystem. Linuxer und Mac-User haben es an Bord, Windowsuser bekommen Perl hier.
Grundsätzlich funktioniert ftpsync sehr simpel, man muss nur “perl ftpsync.pl [Optionen]” auf der Kommandozeile des jeweiligen Betriebssystems aufrufen. Natürlich sollten die Pfade passen, aber wem sag ich das
Für einen Webserverbackup reicht als Option ein “-g Ziel Quelle”, was ftpsync auf das “get”, also den Download von Dateien, beschränkt. Beispiel:
perl ftpsync.pl -gv .\Sicherung ftp://Username:Passwort@Servername/Verzeichnis
Die komplette Syntax sieht so aus:
FTPSync.pl 1.3.03 (2009-07-03)
ftpsync [ options ] [ localdir remoteURL ]
ftpsync [ options ] [ remoteURL localdir ]
options = [-dfgpqv] [ cfg|ftpuser|ftppasswd|ftpserver|ftpdir=value ... ]
localdir local directory, defaults to “.”.
ftpURL full FTP URL, scheme
ftp://[ftpuser[:ftppasswd]@]ftpserver/ftpdir
ftpdir is relative, so double / for absolute paths as well as /
-c | -C like -i, but then prompts whether to actually do work
-d | -D turns debug output (including verbose output) on
-f | -F flat operation, no subdir recursion
-g | -G forces sync direction to GET (remote to local)
-h | -H prints out this help text
-i | -I forces info mode, only telling what would be done
-n | -N no deletion of obsolete files or directories
-l | -L follow local symbolic links as if they were directories
-p | -P forces sync direction to PUT (local to remote)
-q | -Q turns quiet operation on
-s | -S turns usage timestamps comparison (only checks for changes in size)
-t | -T turns timestamp setting for local files off
-v | -V turnes verbose output on
Die Optionen zeigen, dass ftpsync auch auf den Webserver schreibend zugreifen kann – vielleicht interessant, wenn man Webdevelopment betreibt und lokal die neueren Daten hat.
Im Gegensatz zu meiner alten Lösung, bei der ich den ganzen Download anschliessend in eine Zip-Datei geschoben habe, muss hier der Download stehenbleiben, damit beim nächsten Lauf ftpsync auch brav vergleichen kann. Da ftpsync auf dem Quellsystem gelöschte Dateien auch tapfer auf dem Zielmedium löscht (ein echter Sync eben), sollte man sich zu Archivierungszwecken vor (!) dem Sync eine Zipdatei in einem Archivverzeichnis erstellen, die dann im Fall der Fälle als Sicherung von der Sicherung dienen kann. Beispiel für Windows:
@echo off & setlocal
for /f “delims=. tokens=1,2,3″ %%a in (‘echo %date%’) do set datum=%%c.%%b.%%a
c:\Programme\7-Zip\7z a -tzip archiv\%datum%.zip Sicherung\*
Damit wird das Verzeichnis “Sicherung” in eine Zipdatei im Verzeichnis “Archiv” gepackt. Die Zipdatei heisst dann “Jahr.Monat.Tag.zip”.
Packt man das in eine Batchdatei oder ein Script, dann hat man eine recht saubere und schnelle Backuplösung mit Archivierungsfunktion.
Meine Linksammlung bei del.icio.us:
Ein recht häufig gelesener Artikel hier (nicht zuletzt dank Caschy) ist eine Anleitung, wie man seinen Webspace per FTP automatisiert herunterlädt und in ein Zip-Archiv schiebt.
Tom hat seine Domain umgezogen und dabei stellte sich folgende Frage:
Was passiert mit den Datenbanken?
Klar, für Wordpress gibts z.B. den WP-DBManager, die meisten Provider bringen PHPmyAdmin mit, mit dem man Datenbanken dumpen kann oder man nimmt den MySQLDumper, der das gleiche komfortabler kann.
Aber wenn man mehrere Datenbanken hat (z.B. in meinem Fall für Sitebar, Fever und eine Foto-Galerie, ggfs. noch einen Webmailer und ein Zweitblog), dann stossen PHPmyAdmin und MySQLDumper schnell an ihre Grenzen, weil man dort immer nur eine Datenbank verarbeiten kann.
Freundlicherweise bietet der Support bei meinem Provider all-inkl für fast alles eine Lösung: auf den Supportseiten findet sich folgendes nette PHP-Script:
<?php
######## einstellungen #############################################
$db_name = “LOGINNAME”;
$db_passwd = “PASSWORT”;$sql_file = “dump_” . $db_name . “_” . date(‘Ymd_Hi’) . “.sql”;
####################################################################
exec(“mysqldump -u $db_name -p’$db_passwd’ –allow-keywords –add-drop-table –complete-insert –quote-names $db_name > $sql_file”);
exec(“gzip $sql_file”);$datei = $sql_file . “.gz”;
$link = ‘http://’.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'];
$link = str_replace(basename(__FILE__),$datei,$link);
echo “Downloadlink: <a href=’” . $link . “‘>” . $datei . “</a>”;?>
Das Ding habe ich mir locker flockig sechs mal nacheinander in eine Datei kopiert und die Zugangsdaten jeder von mir verwendeten Datenbank dort eingetragen. Vor den Dateinamen habe ich ein “dumps” gesetzt” und das entsprechende Verzeichnis per FTP angelegt. So läuft das Skript einfach als bessere Batch-Datei (ja, ich hab keinen blassen Schimmer von PHP!). Bei neuen Datenbanken muss man das natürlich anpassen.
Das PHP-Skript selbst habe ich als “backup.phpx” gespeichert und lasse es über einen Cron-Job von all-inkl einmal die Woche laufen (meine WP-Datenbank sichere ich natürlich intern täglich). Wer noch mehr Cron-Jobs benötigt: http://www.cron-job.org
Natürlich würde jetzt irgendwann der Webspace vollaufen, weil ja die Dumps mit jedem Lauf einen anderen Dateinamen (das Datum, “. date(‘Ymd_Hi’) .”) bekommen.
Da ich wöchentlich mit meinem FTP-Backup den Server abziehe, kann ich hervorragend damit leben, wenn einmal im Monat alle Dumps rausgeworfen werden. Ich habe ja noch die Historie auf meinen lokalen Platten. Das Löschen habe ich mit folgenden PHP-Skrip erledigt:
<?php
foreach (glob(“dumps/*.*”) as $filename) {
echo “$filename size ” . filesize($filename) . “\n”;
unlink($filename);
}?>
Auch das abgespeichert (del.phpx), als Cron-Job eingetragen und man muss sich keine Sorgen mehr machen
Meine Linksammlung bei del.icio.us:
Meine Linksammlung bei del.icio.us:
Letzte Kommentare