rsync -a über curlftpfs

  • Thread starter Thread starter derOli
  • Start date Start date
D

derOli

Guest
Guten Abend.

Ich versuche mich gerade an automatisierten Backups für meinen Root-Server. Der Hoster bietet einen 50GB Backup-Space an, welcher per FTP bereit gestellt wird.

Habe mir nun ein kleines Shell-Skript geschrieben, welches mir für jeden Wochentag ein Backup erstellt und dieses in einem entsprechenden Verzeichnis (/backup/wochentag) abglegt. Hierzu verwende ich rsync.
Der Backup-Space ist per curlftpfs eingebunden.

Die Daten werden auch kopiert, allerdings schlägt das Beibehalten der Besitz- und Gruppenrechte fehl.
Habe nun an mehreren Stellen im Internet gelesen, dass dies ein generelles Problem bei FTP-Freigaben in Verbindung mit rsync und dem Parameter -a ist.

Code: 
rsync: chown "/backup/Tuesday/opt/somefile1" failed: Operation not permitted (1)
rsync: chown "/backup/Tuesday/opt/somefile2" failed: Operation not permitted (1)
rsync: chown "/backup/Tuesday/opt/somefile3" failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]

Gibt es eine Möglichkeit dieses Problem zu lösen oder ist rsync in diesem Fall der falsche Ansatz?
 
Alle Dateien auf dem FTP Account müssen dem gleichen Benutzer gehören (mit dem man sich am FTP-Server anmeldet.
Wäre das ändern des Dateieigentümers möglich, könntest du ja das Quota eines anderen Kunden belasten. Somit wird dir das keiner erlauben. ;)

Für FTP Backup ist es sicherer Backup-Archive zu packen. Darin können auch Rechte und Eigentümerzuordnungen archiviert werden.
Und um diese auf den FTP Server hochzuladen, brauchts auch kein rsync.
Alternativ rsync nicht die Eigentümer und Gruppen mitsyncen lassen. Das könnte allerdings beim Restore der Daten zu ziemlichem Chaos und vieler manueller Arbeit führen.
 
Keine Ahnung ob das Abhilfe schafft, kannst das mal versuchen:
Code: 
For example: if you want to use -a (--archive) but don't want
    -o (--owner), instead of converting -a into -rlptgD, you could specify -a --no-o (or -a --no-owner).
 
Vielen Dank für die schnellen Antworten

Firewire2002 said:
Alle Dateien auf dem FTP Account müssen dem gleichen Benutzer gehören (mit dem man sich am FTP-Server anmeldet.
Wäre das ändern des Dateieigentümers möglich, könntest du ja das Quota eines anderen Kunden belasten. Somit wird dir das keiner erlauben. ;)
Click to expand...
Klingt irgendwie logisch und macht Sinn... :)

DeaD_EyE said:
Keine Ahnung ob das Abhilfe schafft, kannst das mal versuchen:
Code: 
For example: if you want to use -a (--archive) but don't want
    -o (--owner), instead of converting -a into -rlptgD, you could specify -a --no-o (or -a --no-owner).
Click to expand...

In der Dokumentation zu rsync hatte ich bereits gelesen dass -a nichts anderes als -rlptgD ist. Allerdings würde ein Verwerfen der Benutzer- und Gruppenberechtigungen im Falle eines Restores wirklich ein totales Chaos verursachen.

Werde dann wohl doch nach einer Alternative zu rsync Ausschau halten müssen.
Hatte im Laufe es Tages bereits erste Anläufe mit rdiff-backup gestartet. Werde dann da noch mal einen genaueren Blick drauf werfen.
 
Hast Recht.
Das wäre bei einem Restore des kompletten Systems nicht gut. Ich dachte es ginge nur um ein Verzeichnis.

Was spricht gegen das Archivieren mit tar oder soll immer nur ein einziges Abbild vorhanden sein?

EDIT:
Ich denke mal, dass alles was auf viele Einzeldateien Basiert und keinem Archiv bzw. Abbild entspricht, wird nicht via FTP funktionieren.
z.B. kann man auch mit lftp einen Mirror machen, wobei aber auch da die Besitzer der Dateien und Verzeichnisse verloren gehen. Wie soll das auch funktionieren. Ich hab noch keinen FTP-Server gesehen, der das Ändern der UID/GID zulassen würde. Selbst wenn, wäre mir das zu unsicher. Dann lieber doch in ein Archiv sichern und dieses dann via Rsync, wput oder irgendwas anderes auf den FTP-Server hochladen.
 
Last edited by a moderator:
Also generell spricht nichts gegen tar. Wie oben geschrieben ist das der erste Versuch, sich an das Thema Datensicherung unter Linux heran zu wagen. Der Hauptgrund rsync und rdiff-backup in Betracht zu ziehen war primär, dass mir deise beiden Tools als recht einfach zu bedienen erschienen.
Dass die Benutzer- und Gruppenrechte auf dem FTP-Backup-Space nicht aufrecht erhalten werden konnten war mir leider nicht bewusst.

Mein Vorhaben ist es, pro Tag eine Sicherung zu erstellen, sodass ich in der Lage bin, den Stand von einer Wochen vorhalten zu können.
Werde dieses Vorhaben dann mit tar in die Tat umsetzen.

Vielen Dank für die Hilfe und die Tipps. :)
 
Ach, mit tar, date, rsync/wput/curl, mail kannst du dir schon was tolles basteln.
Es gibt auch fertige Backupscripts, die sogar Fehler abfangen und dementsprechend reagieren, wie z.B. eine Mail schicken. Zusätzlich können noch Backups gelöscht werden, die z.B. älter als einen Monat sind.

Du solltest mal genau beschreiben, was du haben willst.
 
Wer (z.B. aufgrund sehr großer Datenmengen) inkrementelle Backups braucht, ist meiner Erfahrung nach mit rsync und dessen Hardlinking-Option im Endeffekt immer am besten bedient. Weniger ist manchmal mehr, denn das Ergebnis kriege ich im Zweifelsfall überall mit Bordmitteln wieder eingespielt. :) Und: Es funktioniert einfach. Nie Probleme mit gehabt.

Guter Artikel (auch) dazu: http://blog.jonaspasche.com/2012/02/11/lob-des-backups/


Grüße
Tim
 
Grundlegend noch ein paar Informationen um das ganze Vorhaben ggf. etwas verständlicher zu machen:

Es geht mir bei der Datensicherung nicht darum, lebensnotwendige Daten zu sichern. Im Grunde handelt es sich bei der ganzen Sache um ein interessengetriebenes Freizeitprojekt, welches unter möglichst "realistischen" Bedingungen geführt werden soll. Auf dem Server wird künftig ein LAMP und ein Teamspeak-Server laufen. Das sind auch die wesentlichen Daten, die gesichert werden sollen.

Um ehrlich zu sein war ich mir selbst noch nicht so ganz grün, wie die Backups gehandelt werden sollen. Habe nun mit tar versucht ein inkrementelles Backup per Shell-Skript zu realisieren, welches Sicherungen für jeweils einen Monat vorhält.

Das Skript erstellt ein inkrementelles Backup in einem frei wählbaren Verzeichnis. Ebenfalls wird ein Log-File erstellt.
An jedem ersten des Monats wird der gesamte Ordner geleert und eine neue Komplettsicherung für den aktuellen Monat erstellt.

Code: 
#!/bin/bash
#
#
# Configuration
#
# Define where the backup should be stored.
BACKUP_DIR=/backup
# Define beckup log dir
BACKUP_LOG_DIR=/backup/log
# Define the name of the created backups.
BACKUP_NAME=backup
# Define backup date and time. Will be attached to BACKUP_NAME.
BACKUP_DATE=`date +%F_%H_%M_%S`
# Define which directories should be backed up.
SOURCE_DIR="/opt /home"


# Start of script

if [ ! -d $BACKUP_DIR  ]; then
   echo "Unable to find $BACKUP_DIR."
   echo "Please check 'BACKUP_DIR' in the configuration or create '$BACKUP_DIR'."
   exit 1
else
   if [ ! -d $BACKUP_LOG_DIR  ]; then
      echo "Unable to find '$BACKUP_LOG_DIR'."
      echo "Please check 'BACKUP_LOG_DIR' in the configuration or create '$BACKUP_LOG_DIR'."
      exit 1
   else
      if [ `date +%d` = "01"  ]; then
         rm $BACKUP_DIR/${BACKUP_NAME}*
         rm $BACKUP_LOG_DIR/${BACKUP_NAME}*
      fi
      tar -cvzf $BACKUP_DIR/${BACKUP_NAME}_${BACKUP_DATE}.tar.gz -g $BACKUP_DIR/$BACKUP_NAME.snar $SOURCE_DIR >\
      $BACKUP_LOG_DIR/${BACKUP_NAME}_${BACKUP_DATE}.log
   fi
fi
 
Last edited by a moderator:
s24! said:
ist meiner Erfahrung nach mit rsync und dessen Hardlinking-Option im Endeffekt immer am besten bedient
Click to expand...

Lies den Thread doch bitte noch mal von Beginn an und passe deine Antwort auf die hier gegebenen Fakten an.
Ja, rsync mit Hardlinks ist eine schöne Lösung. Passt aber mal so gar nicht zu dem Problem hier. :rolleyes:
 
Ja, rsync mit Hardlinks ist eine schöne Lösung. Passt aber mal so gar nicht zu dem Problem hier.
Click to expand...
Vllt doch? Zugegeben eine bastelei, aber es funktioniert.

FPT-Space mounten, darauf ein Image anlagen, Dateisystem erstellen und ueber Loopback mounten. Damit kann dann rsync mit all seinen Vorteilen genutzt werden ;)

Hatte sowas mal eine Zeitlang im Einsatz, sonderlich performant ist diese Loesung allerings nicht.
 
You must log in or register to reply here.
Back
Top