staging.inyokaproject.org

Tach.

In dem Artikel steht, dass Quell- und Zieldateisystem sich nicht unterscheiden duerfen. Ich nutze das Skript momentan, unter unionfs (eigentlich vzfs). Ist es nicht so, dass das Dateisystem nur korrekt hardlinks unterstuetzen muss, damit der --link-dest parameter funktioniert?

Ich will mit rsync von einem virtualisierten Server ein Backup auf einen Rechner in der Firma machen. Auf dem Server wird vzfs genutzt (ein erweitertes unionfs). Auf dem lokal Rechner in der Firma wird ext3 genutzt. Ist das mit dem Skript so moeglich? Wenn es nur an der Unterstuetzung fuer hardlinks liegt, sollte es ja gehen.

Vielleicht weiss ja jemand Rat, sonst muss ich einfach mal testen. Waere nur uebel, wenn es erst funktioniert und dann irgendwann mal versagt.

Gruss Matthias

Da das Script ja eigentlich nur aus einem rsync-Befehl besteht

Beispiel für /etc:

/usr/bin/rsync -auv --delete --link-dest=/media/backup/081007/etc/ /etc/ /media/backup/081007/etc/

musst du nur feststellen, ob rsync entsprechend korrekt arbeitet. Die Hardlinks sind natürlich immer nur im bezug auf das Ziel (hier /media/backup) zu betrachten. Aber es kann natürlich sein, dass "rsync" bei dem Kopieren von einem EXT3-Filesystem zu einem anderen Dateisystem irgendwelche Probleme macht. Das wäre zu klären.

Jup. Das ist mir soweit klar. Das war ja auch meine Frage. Der Autor des Artikels (zum Skript) schreibt, dass man es nicht machen soll. Ich glaube aber, dass er es nur geschrieben hat, weil backups auf NTFS eben nicht moeglich sind mit diesem Skript (wg fehlendem Hardlink-Support).

Die Information suche ich halt.. ist unionfs → ext3 okay?

Falls jmd. Info hat.. bitte melden. Inzwischen teste ich weiter und suche im Netz. Falls der Autor das liest, kann er sich ja auch mal aeussern, wie er zu der Annahme gelangt ist, dass rsync nur zwischen identischen Dateisystemen funktioniert.

Ich denke, der Autor meint damit, dass man kein FAT- oder NTFS-Dateisystem als Backupmedium verwenden soll, weil dort neben Hardlinks auch die Unix-Dateirechte nicht funktionieren würden. Zwischen verschiedenen Unix-Dateisystemen sollte es aber keine Probleme geben.

Ok, der der Autor des Artikels war ich und vor allem meinte ich damit FAT und NTFS, da es damit auf keinen Fall funktioniert. Den Rest habe ich noch nicht probiert.

Ich hab jetzt vzfs → ext3 probiert und das arbeitet einwandfrei. Sollte also alles okay sein. Vielleicht sollte man in dem Artikel mal den Hinweis aendern, dass rsync nur funktioniert, wenn Quell- und Zieldateisystem identisch sind. Das scheint ja so nicht korrekt zu sein. Stattdessen dann lieber einen ausfuehrlicheren Hinweis auf die Probleme mit FAT/NTFS, oder?

ist es möglich das Skript so zu erweitern, dass die Backups automatisch mit tar komprimiert werden? Das wäre genial, weil man dann auch Onlinespeicher wie wuala als Zielordner nutzen könnte.

Dann wuerde das Skript keinen Sinn ergeben, weil es nicht mehr inkrementell arbeiten koennte. Fuer das, was du moechtest brauchst du kein rsync. Dazu reicht

DATE=`/bin/date +%y%m%d`
tar czf backup$DATE.tar.gz /folder1 /folder2
scp backup$DATE.tar.gz user@host:/backup/folder/

Das ist jetzt natuerlich nur ein schlechtes Beispiel.

Speicher ist auch eigentlich nicht wirklich ein Problem. Wenn das Zieldateisystem hardlinks unterstuetzt, dann werden die Dateien ja nicht doppelt angelegt. D.h. wenn du zwei backups mit 30gb bzw. 31gb hast, dann werden auf dem Ziel 31gb belegt (30gb die alten files plus 1gb differenz).

Matthias

mal eine kleine Frage ..

Ich verwende die im Artikel beschriebene Backupmethode jetzt seit einem halben Jahr, um mein /home und ein paar wichtige config-dateien auf eine externe 160GB-Platte (ext3) zu sichern .. Das läuft soweit ja auch alles prima! unglaublich, wie viele Versionen man mit diesen hardlinks auf eine platte bekommt 😉

ABER: der Platz auf der ext. Platte wird knapp! ich würde mir jetzt gerne eine neue, größere anschaffen (750GB oder so), auf der ich die bisherige inkrementell Sicherungsgeschichte fortführen möchte. Dazu müsste ich jetzt ja alle der aktuell vorhandenen Daten auf die neue Platte schieben .. ABER: Wie bekomm ich die hardlinks mit auf die neue Platte? cp müsste ja für jeden gefundenen hardlink auf der alten platte die gesamte Datei neu kopieren? oder versteh' ich das falsch?

Was ich also jetzt brauche, ist eine Möglichkeit, die vorhandenen Backup-Versionen auf die neue Platte zu übertragen, wobei die vorhandene Struktur mit den Hardlinks übernommen wird (sonst bräuchte ich ja allein für die bisherigen Backups ca. 400GB !)

Wie stelle ich das am besten an?

vielen Dank im Voraus Kristian

Faktotum schrieb:

Was ich also jetzt brauche, ist eine Möglichkeit, die vorhandenen Backup-Versionen auf die neue Platte zu übertragen, wobei die vorhandene Struktur mit den Hardlinks übernommen wird (sonst bräuchte ich ja allein für die bisherigen Backups ca. 400GB !)

Wie stelle ich das am besten an?

Ich würde einfach mit dd das komplette Dateisystem kopieren und dann mit resize2fs (oder dem vergleichbaren anderen Tool für dein Dateisystem, falls du nicht ext3 benutzt) an die Größe der Platte/Partition anpassen.

ok .. dankeschön .. das werd' ich dann mal versuchen.

Ich wollte mal eben mitteilen, dass ich mein Script aus:

Skripte/Backup mit RSYNC

ein wenig erneuert habe. Im Wiki habe ich es aber noch nicht geändert.

Über den Paramter "EXPIREDAYS" kann man angeben, nach wie vielen Tagen ein inkrementelles Backup als veraltet gilt. Alle älteren Versionen werden dann gelöscht. Natürlich fragt das Programm nicht vorher nach, da es ja automatisch läuft.

Bitte vorsichtig ausprobieren. Backup vorher anfertigen 😉

#!/bin/bash
# Simple backup with rsync

# SOURCES and TARGET must end with slash

SOURCES="/root/ /etc/ /home/ /boot/"
TARGET="/usr/local/backup/"
LOGFILE="/root/backup.log"
EXPIREDAYS=100
RSYNC="--delete"

#SSHUSER="user"
#SSHHOST="hostname"

### do not edit ###

`/bin/date > $LOGFILE`

if [ -e $TARGET ]; then
 LASTBACKUP=`/bin/ls -d $TARGET[[:digit:]]* 2>> $LOGFILE | /usr/bin/sort -r | /usr/bin/head -1  ` 
fi

TODAY=$(/bin/date +%y%m%d)

EXPIRED=`/usr/bin/find $TARGET[[:digit:]]* -maxdepth 0 -ctime +$EXPIREDAYS  2>> $LOGFILE`
for EX in `/bin/echo $EXPIRED`
do
  /bin/echo  "rm -rf $EX " >> $LOGFILE
  `/bin/rm -rf $EX`
done

for SOURCE in `/bin/echo $SOURCES`
do
  if [ "$LASTBACKUP" ]; then
    INC="--link-dest=$LASTBACKUP$SOURCE"
  fi
  if [ "$SSHUSER" ] && [ "$SSHHOST" ]; then
    SOURCEDIR="$SSHUSER@$SSHHOST:$SOURCE"
  else
    SOURCEDIR=$SOURCE
  fi
  `/bin/mkdir -p $TARGET$TODAY$SOURCE` >> $LOGFILE
  echo "/usr/bin/rsync -av $RSYNC $INC $SOURCEDIR $TARGET$TODAY$SOURCE"  >> $LOGFILE
  `/usr/bin/rsync -av $RSYNC $INC $SOURCEDIR $TARGET$TODAY$SOURCE >> $LOGFILE 2>> $LOGFILE`
done

Ich würde dieses Script gern verwenden, allerdings ist es notwendig, dass ich bestimmte Ordner (mit NFS in /home/user/ eingebunden) von dem Backup ausschließe. Ich kann Ordner allerdings vor dem Backup auch nicht aushängen, weil ich einen dieser Ordner als Ziel verwenden will. Gibt es eine Möglichkeit dem Script bestimmte Ordner zu sagen, die es nicht beachten soll?

Gibt es eine Möglichkeit dem Script bestimmte Ordner zu sagen, die es nicht beachten soll?

Ja. Du musst nur entsprechend die rsync-Parameter in der Variablen "RSYNC" setzen. Da du wohl "/home/" als Quelle angibst wirst du wohl folgendes nutzen müssen:

RSYNC="--delete --exclude=nfsmountpointname"
RSYNC="--delete --exclude=user/nfsmountpointname"

Leider funktioniert das wohl nicht mit absoluten Pfaden. Somit sollte der Pfad nur dort auftauchen. Alternativ kannst du vielleicht

--exclude-from=FILE     read exclude patterns from FILE

nutzen. Lese entsprechend das Manual von "rsync" durch.

Hallo!

Ich habe das Script (ähnlich) wie beschrieben unter dem Namen /root/backup_ext3.sh angelegt und chmod 755 ausgeführt.

gerald@CentrinoDuo1800:/root$ ls -al
insgesamt 160
drwxr-xr-x 28 root root 4096 2009-05-01 10:31 .
drwxr-xr-x 22 root root 4096 2009-05-01 10:01 ..
drwxr-xr-x  4 root root 4096 2008-10-19 21:39 .adobe
drwx------  2 root root 4096 2009-04-27 20:38 .aptitude
-rwxr-xr-x  1 root root 8456 2009-05-01 10:30 backup_ext3.sh

Allerdings kann ich die Datei nicht ausführen: command not found

gerald@CentrinoDuo1800:/root$ sudo backup_ext3.sh
sudo: backup_ext3.sh: command not found
gerald@CentrinoDuo1800:/root$ backup_ext3.sh
bash: backup_ext3.sh: command not found

Woran liegt das?

Grüße, Gerald