# tar.gz per FTP automatisch kopieren



## hahni (27. Feb. 2011)

Hallo zusammen,

ich möchte eine tar.gz-Datei nach der Erstellung via Cronjob automatisch auf ein FTP-Laufwerk übertragen.

Dieses ist mit einer Kennung geschützt und nur von intern erreichbar. Wie könnte ich dies bewerkstelligen, so daß dies täglich automatisiert erfolgen kann (vorzugsweise verschlüsselt via SFTP etc.)?

Viele Grüße

Hahni


----------



## Moestchen (27. Feb. 2011)

Auch per Cronjob!?

Deiner Beschreibung nach klingt es nach dem Hetzner-Backupspace?
Egal ob du jetzt tartarus, duplicity o.ä. nutzen würdest - für lediglich eine Datei sollte es doch auch Shell-Einzeiler tun, oder?


----------



## hahni (28. Feb. 2011)

Nein, das ist nicht Hetzner. Ich möchte dies selbst über einen internen FTP-Server lösen. Am besten aber mit Boardmitteln, was die jeweiligen Server betrifft. Hast du da eine konkrete Idee?


----------



## Till (28. Feb. 2011)

Ich würde zum hochladen das Programm wput verwenden. Funktioniert wie wget, nur umgekehrt.

Du legst Dir also ein neues shell script an, das erst die Befehle zum erstellen des tar.gz enthält und denn den Aufruf von wput zum hochladen des tar.gz auf den FTP-Server.


----------



## fuxifux (28. Feb. 2011)

Also ich hab ein bash-skript laufen, das per cron täglich(nächtlich) ein ganzes Verzeichnis "/backup" (in dem aber immer nur ein snapshot einer vm liegt) auf einen backup-ftp-server kopiert(dort ins rootverzeichnis).


```
#!/bin/bash
ncftpput -R -u *hostname-server* -p *passwort* *username* / /backup
```
Es wird zwar nicht verschlüsselt übertragen, aber der backup-space ist nur von der server-ip erreichbar.

Weiters hab ich auch ein zweites skript, dass dann die überflüssigen Dateien(älter als 9 Tage) am ftp-server löscht:
	
	



```
#!/bin/sh
HOST='*host*'
USER='*username*'
PASSWD='*passwort*'
RM_DATE=`date +%Y_%m_%d -d '10 days ago'`

ftp -n $HOST <<END_SCRIPT
quote USER $USER
quote PASS $PASSWD
cd backup
prompt off
mdelete *${RM_DATE}*
quit
END_SCRIPT
exit 0
```
Wichtig ist, dass die Dateien im Namen das aktuelle Datum in de Form von z.B.: "2011_02_28" enthalten, damit sie gelöscht werden können.

EDIT:
Für das erste skript musst du vermutlich das Paket "ncftp" installieren...


----------



## hahni (4. März 2011)

Eigentlich sah wput easy aus, doch ich bekomme nur Fehlermeldungen:

root@demo:~# wput --reupload --binary /root/server-backup_demo.tar.gz ftp://benutzer:kennwort@backup-space.hahnefeld.de/
Error: File `/root/server-backup_demo.tar.gz' does not exist. Don't know what to do about this URL.
Nothing done. Try `wput --help'.


----------



## fuxifux (4. März 2011)

Ist denn die Datei am Server auch schon vorhanden?
Sonst funktioniert das mit --reupload glaube ich nicht...


----------



## hahni (4. März 2011)

Habe ich auch schon ohne den Parameter probiert. Geht leider trotzdem nicht. Aber ich kann es gerne noch einmal probieren


----------



## fuxifux (4. März 2011)

Ansonsten fällt mir nur mehr zu prüfen, ob die Datei auch genau gleich heisst, bzw. ob die Rechte zum Zugriff auf /root ausreichen.

Ich persönlich verwende statt wput ncftpput und habe keinerlei Probleme...


----------



## hahni (4. März 2011)

wput erscheint eigentlich einfach in der Bedienung. Umso unerklärlicher ist deshalb die Fehlermeldung. Till wird sich bei der Empfehlung schon etwas gedacht haben. Wenn er sich jetzt noch melden würde deswegen, dann wärs super...


----------



## hahni (4. März 2011)

Achja: das Skript führe ich übrigens als "root" aus. Also daher scheidet dieses Problem auch aus...


----------



## fuxifux (4. März 2011)

Ich habs jetzt selbst grad probiert. Bei mir kommt dieser Error nur, wenn es die angegebene Datei nicht gibt.

Was gibt dir denn:

```
ls -l /root/server*
```
aus?


----------



## hahni (4. März 2011)

Lieb, dass du dich der Sache annimmst. Die Ausgabe sieht wie folgt aus:

--
-rw-r--r-- 1 root root 2813672698 2011-03-04 04:36 /root/server-backup_demo.tar.gz
--

Der Dateiname ist - normalerweise nutze ich "vdir" - rot hinterlegt.


----------



## fuxifux (4. März 2011)

Das hab ich als Hinweis auf die Farbe rot gefunden:

rot = symbolischer link auf ein nichtexistentes ziel

Edit:
Danke für den Hinweis auf die Farben, das ist hilfreich! -> wird bei mir ab sofort auch so gemacht...


----------



## hahni (5. März 2011)

Das mit der fehlenden Datei stimmt ja leider nicht. Folglich kann es nur noch sein, dass sich wput daran stört, dass die Datei im root-Verzeichnis liegt. Doch da ich als root eingeloggt bin, sollte dies an und für sich auch kein Problem darstellen...


----------



## hahni (5. März 2011)

Wenn ich es richtig sehe, liegt es scheinbar an der Dateigröße:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511554

Wie kann ich wput nun wieder sauber/restlos deinstallieren bei Ubuntu, ohne dass die Konfigdateien etc. gespeichert bleiben? Normalerweise müsste doch "apt-get remove ––purge wput" ausreichen, oder?


----------



## hahni (5. März 2011)

Zitat von Till:


> Ich würde zum hochladen das Programm wput verwenden. Funktioniert wie wget, nur umgekehrt.
> 
> Du legst Dir also ein neues shell script an, das erst die Befehle zum erstellen des tar.gz enthält und denn den Aufruf von wput zum hochladen des tar.gz auf den FTP-Server.


Wie ich schon am Ende des Threads gepostet habe, scheint wput einen Bug zu haben, wenn es um große Dateien geht. Das ist in einem Debian-Forum diskutiert worden. Das würde auch erklären, warum ich mit der Syntax nicht "klargekommen" bin. Dateien größer als 2 GB sind daher problematisch.


----------



## fuxifux (5. März 2011)

wenn die Datei von vdir rot angezeigt wird, ist sie anscheinend keine Datei, sondern ein symlink, dessen Ziel nicht mehr existiert.

Kannst du die Datei im /root entpacken?
wenn das geht scheint es tatsächlich an wput zu liegen, ansonsten stimmt mit der Datei oder dem symlink etwas nicht.


----------



## hahni (5. März 2011)

Fakt ist: mit ncftpput geht es. Also liegt es - wie schon von mir vermutet - definitiv nicht an der Datei. Es ist vielmehr so, dass wput einen Bug hat und mit Dateien größer als 2 GB nicht klar kommt. Dann kommt es - fälschlicherweise - genau zu dem Fehler, den ich gepostet habe. Diese Nacht lief schon auf dem ersten Server der Cron-Job mit ncftpput ! Besten Dank daher für deinen Tipp 

Allerdings bin ich auf dem nächsten Server leider schon an meine Grenzen gestoßen. Bei ncftpput kommt permanent "Lost data connection to remote host: Broken pipe.". Bei einer 1,6 GB-Datei hat dies noch gut geklappt. Jetzt aber wird permanent nach 1 Minute und 40 Sekunden oder eben 3 GB abgebrochen. Einen "keep-alive"-Parameter habe ich leider nicht gefunden bei ncftpput.


----------



## fuxifux (6. März 2011)

Meine snapshots sind leider nur 1,6GB groß.

Ev. hilft der -E Parameter, der den PASV-Mode unterdrückt.


----------



## hahni (6. März 2011)

Auf meinem Backup-Space lagen bereits Daten. Das hatte ich vergessen und folglich war es blinder Alarm .

Jetzt funktioniert es wunderbar und es gibt auch keine Timeouts. Es ist lediglich die Meldung von "ncftpput" nicht glücklich gewählt.


----------

