Bevor es hier richtig losgeht, noch eine Ergänzung zu den eingesetzten Tools: Windows selbst ist nicht in der Lage, für eine FTP-Verbindung einen Laufwerksbuchstaben zu vergeben, dafür werden zusätzliche Tools benötigt. Der Caschy hat gleich zwei gefunden: NetDrive und FTPDrive.
Systemvorraussetzungen:
NetDrive:[...]Windows 2000, Windows XP, Windows Vista[...]
FTPDrive:[...]Windows 2000/XP/2003/Vista[...]
Damit sind die Grundbedingungen für eine Sicherung via FTP geschaffen.
Bedenkt aber: FTP ist als potentiell unsicher einzustufen, das es völlig unverschlüsselt ist, also nicht nur den Datenstrom, sondern auch Benutzername|Passwort im Klartext überträgt. Wirklich sensible Daten sollte man also nicht einfach per FTP irgendwohin sichern.
Weiterhin sollte klar sein, das bei ADSL-Nutzern eine FTP-Verbindung um den Faktor x langsamer ist als die Sicherung auf ein lokales Laufwerk (oder ein per LAN|WLAN verbundenes Netzlaufwerk), da selbst bei einer 16.000er-Leitung max. 1Mbit/s. an Upload zur Verfügung steht. Sehr grosse Backups können da schonmal wg. der Zwangstrennung nach 24h schiefgehen.
Ein Backup per FTP kann aber auch im eigenen LAN durchaus Sinn machen, z.B. wenn man seine Daten auf ein NAS-System schiebt. Gerade wer ein NAS mit Gigabit-Netzwerkkarte sein Eigen nennt, wird zwischen der SMB- und der FTP-Verbindung meist einen deutlichen Geschwindigkeitsunterschied zugunsten der FTP-Verbindung bemerken (was der meist veralteten Samba-Version auf den NAS-Systemen geschuldet ist; NFS lasse ich hier aussen vor, da dieses Protokoll eher zu den Exoten zählt).
So, nun mal “Butter bei die Fisch”. Ich erstelle mir für solche Projekte gern eine Ordnerstruktur, die in etwa so aussieht:
<LW:>\Batchfiles\<projektname>\
Hier landen dann alle Batchfiles und sonstige Dateien, wie die Backup-Definitionen für ntbackup oder ini-Dateien für die Steuerung der Skripte.
Um aus den Skripten -egal, von wo aus diese ausgeführt werden- Zugriff auf robocopy und blat (und evtl. andere Tools) zu bekommen, müssen deren Installationspfade in der Systemvariable %path% eingetragen sein oder im selben Verzeichnis abgelegt werden, aus dem heraus das Skript ausgeführt wird. Das erspart eine Menge Schreibarbeit und hält die Skripte übersichtlich (natürlich könnte man die Pfade auch in einer eigenen Variable innerhalb der Skripte speichern, aber das wäre “von hinten durch die Brust ins Auge”).
robocopy ist Bestandteil des Windows Ressource Kits, habt ihr dieses vollständig installiert, wird %path% automatisch angepasst. blat hingegen besitzt kein Setup, hier genügt es, die blat.exe nach %windir%\system32\ zu kopieren. Wer das Ressource Kit nicht installiert hat, kopiert die robocopy.exe bestenfalls auch nach %windir%\system32\. Ob die Tools dann tatsächlich zur Verfügung stehen, lässt sich ganz einfach kontrollieren: Einfach in der Eingabeaufforderung den Namen der jeweiligen exe-Datei eingeben und Enter drücken.
Im Falle von robocopy und blat sollte das dann so aussehen:
Aufruf robocopy
Aufruf blat
Damit sind die Vorbereitung (fürs erste) abgeschlossen. Im nächsten Teil folgt dann das erste Backup-Skript, das mittels robocopy ein Verzeichnis synchronisiert und per blat eine entsprechende Mailbenachrichtigung versendet.
Die Idee ist ja an sich nicht schlecht. Allerdings würde ich es vermeiden die Dateien unverschlüsselt auf einem öffentlichen FTP Server abzulegen.
Ich würde hier eher auf die Freeware Personal Backup zurückgreifen (http://personal-backup.rathlev-home.de), die im Vergleich zu hausgemachten Skriptlösungen mehrere Vorteile hat:
- verschlüsselte Archive
- Inkrementelle und differenzielle Backups einfach zu konfigurieren (für den End-Benutzer)
- Sicherung bei Abmeldung des Benutzers
Daneben bietet es auch eine Benachrichtigung per E-Mail an. Ich hatte es eine Zeitlang im praktischen Einsatz und konnte keine Probleme feststellen. Inzwischen wurde es bei mir von Bacula (www.bacula.org) abgelöst.
Ich hatte auch mal Areca (http://areca.sourceforge.net) getestet, welches das besonderes Feature hat, das es nur die Differenzen von verschiedenen Dateiversionen sichert. Aber es konnte mich nicht ganz überzeugen.
Da Personal Backup auch per Skript ansprechbar ist, wäre es vielleicht eine Alternative zu robocopy in Komination mit NetDrive/FTPDrive.
Ich will aber eben grad _keine_ Software installieren, die nicht unbedingt sein muss.
Das mag für den Heimanwender schwer zu verstehen sein, aber im Business-Bereich installiere ich nur äusserst ungern ein Stück Software auf nem Server, wenns nicht _unbedingt_ sein muss.
Und letztenendes soll diese Artikelserie ja gerade aufzeigen, das man vernünftige Backups auch so hinbekommt.
Bacula hatte ich auch mal Einsatz, hat mich nicht vom Hocker gehauen. Davon abgesehen laufen meine Skripte auch noch, wenn die Backupsoftware seit Jahren nicht mehr gepflegt wird…
wenn es nicht unbedingt ftp sein muss, und eh schon ein apache/httpd laeuft, ist sicher webdav noch ein gedanke.
und webdav kann windows (ab xp(?)) einfach als laufwerk einbinden. das geht dann natuerlich auch ueber tls/ssl gesichert.
Nunja, eigentlich sollte sich die Artikelserie nur mit lokalen Sicherung beschäftigen, ich hatte NetDrive und FTPDrive nur “eingeschoben”, weil ich es bei Caschy grad gelesen hatte…
Mal schauen, vielleicht baue ich die WebDAV-Geschichte noch mit ein. Danke jedenfalls für den Hinweis!
Hallo,
sehr schönes Blog, Kompliment.
Die Idee mit einem Backup-Script auf Basis von Robocopy hatte ich auch mal. Emails habe ich mit Hilfe von bmail gesendet und auch die Möglichkeit einen ausgeschalteten Rechner mit einem WOL Paket ist bereits integriert.
Das Script kann hier eingesehen werden:
Vielleicht ist das ja für euch interessant.
Vielen Dank – ich werde das Skript mal unter die Lupe nehmen; melde mich ggf. bei dir.
Hallo Jörg,
wollte mal Nachfragen ob deine Reihe noch fortgesetzt wird?
Ich finde irgendwie nichts hier.
Das Thema interessiert mich sehr. Und ich würde mich über eine Fortsetzung freuen.
Grüße
Ronald
@Ronald:
Ja, die Reihe wird fortgesetzt – das ganze Thema war ziemlich eingeschlafen, weil wir aus Zeitgründen erstmal “fertige” Lösungen einsetzen mussten.
Da die aber nicht so ganz das sind, was wir wollen, werde ich wieder in die Skriptwelt abtauchen und das Thema auf Vista|Sieben|2008 ausdehnen. Stay tuned!