Discussion:
rsync von NAS auf Server dauert sehr lange
Steffen Auer
2012-05-27 09:19:18 UTC
Permalink
Hallo,

ich erstelle meine Proxmox-Snapshots automatisiert auf ein per NFS
eingebundenes NAS. Bis auf einen Ausrutscher dauert das bislang bei ca.
100 GB großem Snapshot (also noch größerer Nutzdatenmenge) ca. 2 1/4 bis
2 3/4 Stunden.

Anschließend synce ich das Snapshotverzeichnis mit rsync als zusätzliche
Datensicherung zurück auf den Server.

Das sind 30 Snapshots mit je ca. 100GB, wobei sich pro Nacht natürlich
immer nur 2 ändern: Der Älteste wird rotierend gelöscht, ein neuer kommt
hinzu.

Dennoch ist, wie ich gerade bemerkt habe, der rsync Vorgang nach über 6
Stunden noch immer nicht abgeschlossen.
Kann das sein oder läuft da was nicht optimal?

Die Befehlszeile lautet
---
rsync -r --delete /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
---

Top verrät, dass rsync ganz schön Systemressourcen verbrät, per ssh
erfolgt z.B. der Aufruf von mc recht zeitverzögert.

Viele Grüße
Steffen
--
System:
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Tobias Küchel
2012-05-27 11:07:33 UTC
Permalink
Hallo Steffen,
Post by Steffen Auer
Hallo,
ich erstelle meine Proxmox-Snapshots automatisiert auf ein per NFS
eingebundenes NAS. Bis auf einen Ausrutscher dauert das bislang bei ca.
100 GB großem Snapshot (also noch größerer Nutzdatenmenge) ca. 2 1/4 bis
2 3/4 Stunden.
Anschließend synce ich das Snapshotverzeichnis mit rsync als zusätzliche
Datensicherung zurück auf den Server.
Das sind 30 Snapshots mit je ca. 100GB, wobei sich pro Nacht natürlich
immer nur 2 ändern: Der Älteste wird rotierend gelöscht, ein neuer kommt
hinzu.
Dennoch ist, wie ich gerade bemerkt habe, der rsync Vorgang nach über 6
Stunden noch immer nicht abgeschlossen.
Kann das sein oder läuft da was nicht optimal?
Die Befehlszeile lautet
---
rsync -r --delete /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
---
Top verrät, dass rsync ganz schön Systemressourcen verbrät, per ssh
erfolgt z.B. der Aufruf von mc recht zeitverzögert.
Das ist kein Wunder, rsync (bevor es kopiert), erstellt eine Liste aller
zu kopierenden Daten, und zwar aus dem Timestamp. Wenn du also zillionen
Dateien hast dauert das und verbrät ressourcen. Wenn ich richtig
verstehe, hast du unter /mnt/pve/Backup-NAS/dump/ ein Verzeichnisbaum
pro Snapshot? und ebenso unter /var/lib/vz/dump/ dann?


Willst du denn einfach nur kopieren, oder wirklich syncronisieren?
Eigentlich willst du doch nur das neueste Snapshot verzeichnis kopieren,
oder?
Kopieren sollte deutlich schneller gehn.

Wenn jedes deiner Snapshots eine container-datei ist, versteh ich nicht,
warum er so lange braucht.

grüße, Tobias.


_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
henrik hansen
2012-05-27 15:46:03 UTC
Permalink
wenn du die vzdump bzw. kvm snapshoot funktion nutzt ist es statk
netzwerk abhängig.

kopiere doch mal mit scp vom selben server aufs selbe ziel. und guck
dir den geschwindigkeitsresult an.

daraus lasst sich schließen ob bei euch was nixht stimmt.

Von meinem Atari gesendet
Post by Tobias Küchel
Hallo Steffen,
Post by Steffen Auer
Hallo,
ich erstelle meine Proxmox-Snapshots automatisiert auf ein per NFS
eingebundenes NAS. Bis auf einen Ausrutscher dauert das bislang bei ca.
100 GB großem Snapshot (also noch größerer Nutzdatenmenge) ca. 2 1/4 bis
2 3/4 Stunden.
Anschließend synce ich das Snapshotverzeichnis mit rsync als zusätzliche
Datensicherung zurück auf den Server.
Das sind 30 Snapshots mit je ca. 100GB, wobei sich pro Nacht natürlich
immer nur 2 ändern: Der Älteste wird rotierend gelöscht, ein neuer kommt
hinzu.
Dennoch ist, wie ich gerade bemerkt habe, der rsync Vorgang nach über 6
Stunden noch immer nicht abgeschlossen.
Kann das sein oder läuft da was nicht optimal?
Die Befehlszeile lautet
---
rsync -r --delete /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
---
Top verrät, dass rsync ganz schön Systemressourcen verbrät, per ssh
erfolgt z.B. der Aufruf von mc recht zeitverzögert.
Das ist kein Wunder, rsync (bevor es kopiert), erstellt eine Liste aller zu kopierenden Daten, und zwar aus dem Timestamp. Wenn du also zillionen Dateien hast dauert das und verbrät ressourcen. Wenn ich richtig verstehe, hast du unter /mnt/pve/Backup-NAS/dump/ ein Verzeichnisbaum pro Snapshot? und ebenso unter /var/lib/vz/dump/ dann?
Willst du denn einfach nur kopieren, oder wirklich syncronisieren?
Eigentlich willst du doch nur das neueste Snapshot verzeichnis kopieren, oder?
Kopieren sollte deutlich schneller gehn.
Wenn jedes deiner Snapshots eine container-datei ist, versteh ich nicht, warum er so lange braucht.
grüße, Tobias.
_______________________________________________
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
_______________________________________________
linuxmuster mailing list
http://mail.schule-bw.de/cgi-bin/mailman/listinfo/linuxmuster
linuxmuster-archive: http://mailman.schule-bw.de/pipermail/linuxmuster/
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Steffen Auer
2012-05-27 18:14:07 UTC
Permalink
Hallo Henrik,
Post by henrik hansen
wenn du die vzdump bzw. kvm snapshoot funktion nutzt ist es statk
netzwerk abhängig.
das Erstellen des Snapshots dauert unter 3 Stunden. Das finde ich, wenn
eine 100 GB große Datei dabei raus kommt ok.

Was unerträglich lange dauert, ist das anschließende synchronisieren des
Snapshotverzeichnisses auf dem NAS mit dem Server.
Post by henrik hansen
kopiere doch mal mit scp vom selben server aufs selbe ziel. und guck
dir den geschwindigkeitsresult an.
Kopieren ist vom Speed ok, schwankt zwar ziemlich, aber es sind bis zu
100 MB/s
Post by henrik hansen
daraus lasst sich schließen ob bei euch was nixht stimmt.
grundsätzlich glaube ich nicht, aber rsync ist sau lahm.

Gibt's da eine Alternative zum synchronisieren unter Linux?
Oder kann ich andere Parameter verwenden, die das schneller machen?

Wie gesagt, es sollen 2 Verzeichnisse synchron gehalten werden. Das
Sourceverzeichnis beinhaltet 30 Snapshots á ca. 100 GB und 30 Snapshots
á ca. 2 GB.
Jede Nacht wird je ein Snapshot mit 2 GB und 100 GB gelöscht und ein
neuer erstellt.
Im Zielverzeichnis soll anschließend genau dasselbe passieren.

Also wenn rsync dazu wirklich > 7 Stunden braucht, dann wäre es deutlich
kürzer, die VMs jede Nacht 2x zu snapshoten, einmal auf's NAS und einmal
auf den Server. Da ich das aber im Suspend Mode machen lasse, ist die
pädML dann länger nicht erreichbar, was auch doof ist.

Viele Grüße
Steffen
--
System:
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
jonny
2012-05-27 18:33:04 UTC
Permalink
hi,
Post by Steffen Auer
grundsätzlich glaube ich nicht, aber rsync ist sau lahm.
welche mount optionen haben rsync quelle und ziel denn?

jonny

_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Steffen Auer
2012-05-27 18:48:37 UTC
Permalink
Hallo Jonny,
Post by jonny
hi,
Post by Steffen Auer
grundsätzlich glaube ich nicht, aber rsync ist sau lahm.
welche mount optionen haben rsync quelle und ziel denn?
Die Partition auf dem Server (Ziel):
---
/dev/pve/data /var/lib/vz ext3 defaults 0 1
---

Das NAS (Quelle) ist per NFS eingebunden.

Viele Grüße
Steffen
--
System:
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
jonny
2012-05-27 19:47:23 UTC
Permalink
hallo steffen,
Post by Steffen Auer
Post by jonny
Post by Steffen Auer
grundsätzlich glaube ich nicht, aber rsync ist sau lahm.
welche mount optionen haben rsync quelle und ziel denn?
---
/dev/pve/data /var/lib/vz ext3 defaults 0 1
zitat aus der manpage:
Es empfiehlt sich, auf der Quell- und Zielseite die mount-Optionen "noatime"
+ "nodiratime" oder "relatime" zu setzen, um beim Aufbau beider
Dateilisten
(Lesen von Verzeichnissen und Inodes) keine Schreiboperationen
auszulösen.
das kann einiges ausmachen.

ansonsten zeigt dir das hinzufügen der option --stats und/oder
--progress vielleicht etwas aufschlussreiches.

jonny

_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Steffen Auer
2012-05-27 19:52:57 UTC
Permalink
Hallo Jonny,
Post by jonny
hallo steffen,
Post by Steffen Auer
Post by jonny
Post by Steffen Auer
grundsätzlich glaube ich nicht, aber rsync ist sau lahm.
welche mount optionen haben rsync quelle und ziel denn?
---
/dev/pve/data /var/lib/vz ext3 defaults 0 1
Es empfiehlt sich, auf der Quell- und Zielseite die mount-Optionen "noatime"
+ "nodiratime" oder "relatime" zu setzen, um beim Aufbau beider Dateilisten
(Lesen von Verzeichnissen und Inodes) keine Schreiboperationen auszulösen.
das kann einiges ausmachen.
hm, das ist auf dem Server die Partition, auf der auch die laufenden VMs
selber liegen. Ich weiß nicht, ob ich da an den Mountoptionen rumspielen
sollte...
Post by jonny
ansonsten zeigt dir das hinzufügen der option --stats und/oder
--progress vielleicht etwas aufschlussreiches.
muss ich mal ausprobieren.

Viele Grüße
Steffen
--
System:
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
jonny
2012-05-27 20:58:40 UTC
Permalink
hallo steffen,
Post by Steffen Auer
Post by jonny
Post by Steffen Auer
/dev/pve/data /var/lib/vz ext3 defaults 0 1
Es empfiehlt sich, auf der Quell- und Zielseite die mount-Optionen "noatime"
+ "nodiratime" oder "relatime" zu setzen, um beim Aufbau beider Dateilisten
(Lesen von Verzeichnissen und Inodes) keine Schreiboperationen auszulösen.
das kann einiges ausmachen.
hm, das ist auf dem Server die Partition, auf der auch die laufenden VMs
selber liegen. Ich weiß nicht, ob ich da an den Mountoptionen rumspielen
sollte...
im allgemeinen erhöhen diese optionen sogar die performance eines
systems :) ich habe diese bei meinen servern überall gesetzt (auch ohne
rsync). ich benutze allerdings virtualbox auf debian als
virtualisierungssystem. m.e. könnten diese sich maximal auf das
snapshotverhalten des virtualisierers auswirken (auch wenn ich auch
dieses für unwahrscheinlich halte).

nochwas: gehn die uhren auf beiden systemen exakt gleich?
falls nicht, könnte es sein, daß du mit modify-window spielen musst.

wenn es noch nicht klar wurde: es wäre möglich, daß der erste rsync test
nach dateiname, größe und modifikationsdatum fehlschlägt und rsync
deshalb alle dateien jedesmal neu indiziert, statt sie zu überspringen.

das solltest du aber mit den optionen stat oder progress rauskriegen
können...

jonny
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.

Steffen Auer
2012-05-27 20:25:08 UTC
Permalink
Hallo Jonny,
Post by jonny
ansonsten zeigt dir das hinzufügen der option --stats und/oder
--progress vielleicht etwas aufschlussreiches.
das zeigt mir, dass jede einzelne Datei überprüft wird, dabei steigt die
Geschwindigkeit auf bis zu 111 MB/s an, d.h. die
Übertragungsgeschwindigkeit ist sehr gut.
Allerdings dauert das Prüfen wohl so lang wie das kopieren. Bei den
Snapshots des IPCops mit ihren 2,2 GB 20-30 Sekunden je Snapshot.

Das Kopieren geht auch nicht länger, denn ich hatte testweise vorher im
Ziel einen Snapshot des IPCops gelöscht.

Oder wird hier munter jedesmal einfach alles kopiert?

Nochmal meine Befehlszeile:
---
rsync -r --delete /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
---

Als rsync die Snapshots des pädML Servers angefangen hat zu prüfen, habe
ich abgebrochen, aber vom IPCop Snapshot hochgerechnet dauert das pro
Snapshot 20 Minuten, macht bei 30 Snapshots von IPCop und Server
insgesamt ganz grob 600 min = 10 Std.

Ich habe keine passende Option gefunden, aber gibt es keine Möglichkeit,
dass nur das Vorhandensein des Dateinamens überprüft wird? Das würde für
meine Zwecke völlig ausreichen.

Dateiname in der Quelle nicht vorhanden (weil von Proxmox rotierend beim
Backup gelöscht), aber im Ziel vorhanden --> Datei im Ziel löschen
Dateiname in der Quelle vorhanden, im Ziel nicht --> Datei ins Ziel
kopieren.

So was muss doch möglich sein.

Ah, Option -u (skip files that are newer on the receiver) scheint meine
Zwecke zu erfüllen. Jedenfalls erhalte ich, wenn ich wieder einen
Snapshot samt Log im Ziel lösche, und diese Option -u verwende :

---
rsync -r -u --delete --stats --progress /mnt/pve/Backup-NAS/dump/
/var/lib/vz/dump/
sending incremental file list
vzdump-qemu-100-2012_05_27-00_00_02.log
838 100% 0.00kB/s 0:00:00 (xfer#1, to-check=50/97)
vzdump-qemu-100-2012_05_27-00_00_02.tar.lzo
2379382943 100% 91.72MB/s 0:00:24 (xfer#2, to-check=49/97)

Number of files: 97
Number of files transferred: 2
Total file size: 2177239014530 bytes
Total transferred file size: 2379383781 bytes
Literal data: 2379383781 bytes
Matched data: 0 bytes
File list size: 3250
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2379677578
Total bytes received: 50

sent 2379677578 bytes received 50 bytes 93320691.29 bytes/sec
total size is 2177239014530 speedup is 914.93
---

Viele Grüße
Steffen
--
System:
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
henrik hansen
2012-05-27 20:30:55 UTC
Permalink
rsync ist stark drauf fixiert auf änderungen in den datein zu finden.

da sich on deinen alten backups nichts ändert würde ich sagen bist du
mit den optionen so gut geholfen.

ich würde mal versuchen nachzuprüfen wie rsync die datein prüft.

bin leider gerade auf nen schützenfest daher :)

Von meinem Atari gesendet
Post by Steffen Auer
Hallo Jonny,
Post by jonny
ansonsten zeigt dir das hinzufügen der option --stats und/oder
--progress vielleicht etwas aufschlussreiches.
das zeigt mir, dass jede einzelne Datei überprüft wird, dabei steigt die Geschwindigkeit auf bis zu 111 MB/s an, d.h. die Übertragungsgeschwindigkeit ist sehr gut.
Allerdings dauert das Prüfen wohl so lang wie das kopieren. Bei den Snapshots des IPCops mit ihren 2,2 GB 20-30 Sekunden je Snapshot.
Das Kopieren geht auch nicht länger, denn ich hatte testweise vorher im Ziel einen Snapshot des IPCops gelöscht.
Oder wird hier munter jedesmal einfach alles kopiert?
---
rsync -r --delete /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
---
Als rsync die Snapshots des pädML Servers angefangen hat zu prüfen, habe ich abgebrochen, aber vom IPCop Snapshot hochgerechnet dauert das pro Snapshot 20 Minuten, macht bei 30 Snapshots von IPCop und Server insgesamt ganz grob 600 min = 10 Std.
Ich habe keine passende Option gefunden, aber gibt es keine Möglichkeit, dass nur das Vorhandensein des Dateinamens überprüft wird? Das würde für meine Zwecke völlig ausreichen.
Dateiname in der Quelle nicht vorhanden (weil von Proxmox rotierend beim Backup gelöscht), aber im Ziel vorhanden --> Datei im Ziel löschen
Dateiname in der Quelle vorhanden, im Ziel nicht --> Datei ins Ziel kopieren.
So was muss doch möglich sein.
---
rsync -r -u --delete --stats --progress /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
sending incremental file list
vzdump-qemu-100-2012_05_27-00_00_02.log
838 100% 0.00kB/s 0:00:00 (xfer#1, to-check=50/97)
vzdump-qemu-100-2012_05_27-00_00_02.tar.lzo
2379382943 100% 91.72MB/s 0:00:24 (xfer#2, to-check=49/97)
Number of files: 97
Number of files transferred: 2
Total file size: 2177239014530 bytes
Total transferred file size: 2379383781 bytes
Literal data: 2379383781 bytes
Matched data: 0 bytes
File list size: 3250
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2379677578
Total bytes received: 50
sent 2379677578 bytes received 50 bytes 93320691.29 bytes/sec
total size is 2177239014530 speedup is 914.93
---
Viele Grüße
Steffen
--
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
_______________________________________________
linuxmuster mailing list
http://mail.schule-bw.de/cgi-bin/mailman/listinfo/linuxmuster
linuxmuster-archive: http://mailman.schule-bw.de/pipermail/linuxmuster/
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Tobias Küchel
2012-05-27 20:55:28 UTC
Permalink
Hallo Steffen,
Post by Steffen Auer
Dateiname in der Quelle nicht vorhanden (weil von Proxmox rotierend beim
Backup gelöscht), aber im Ziel vorhanden --> Datei im Ziel löschen
Dateiname in der Quelle vorhanden, im Ziel nicht --> Datei ins Ziel
kopieren.
So was muss doch möglich sein.
Ah, Option -u (skip files that are newer on the receiver) scheint meine
Zwecke zu erfüllen. Jedenfalls erhalte ich, wenn ich wieder einen
war leider nicht am Rechner, das wäre mein nächster Vorschlag gewesen.

Noch ein Tipp für die Zukunft:

manuell ausführen mit -P und dann siehst du direkt: 1. wie lange er am
Anfang für das listenerstellen braucht - da kommt keine Ausgabe und dann
wie lange er pro Datei kopiert (sehe grade hast du unten schon benutzt).
Ich vermute stark er hat jedesmal alle Dateien kopiert.

nochwas:

--size-only skip files that match in size

und

-c, --checksum skip based on checksum, not mod-time & size

letzteres dauert länger ist aber das ultimo an sicherheit...

grüße und schöne Ferien.

Tobias.
Post by Steffen Auer
---
rsync -r -u --delete --stats --progress /mnt/pve/Backup-NAS/dump/
/var/lib/vz/dump/
sending incremental file list
vzdump-qemu-100-2012_05_27-00_00_02.log
838 100% 0.00kB/s 0:00:00 (xfer#1, to-check=50/97)
vzdump-qemu-100-2012_05_27-00_00_02.tar.lzo
2379382943 100% 91.72MB/s 0:00:24 (xfer#2, to-check=49/97)
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Steffen Auer
2012-05-27 18:05:12 UTC
Permalink
Hallo Tobias,
Post by Tobias Küchel
Post by Steffen Auer
Die Befehlszeile lautet
---
rsync -r --delete /mnt/pve/Backup-NAS/dump/ /var/lib/vz/dump/
---
Top verrät, dass rsync ganz schön Systemressourcen verbrät, per ssh
erfolgt z.B. der Aufruf von mc recht zeitverzögert.
Das ist kein Wunder, rsync (bevor es kopiert), erstellt eine Liste aller
zu kopierenden Daten, und zwar aus dem Timestamp. Wenn du also zillionen
Dateien hast dauert das und verbrät ressourcen.
nun ja, es sind 60 Dateien (30x Snapshot IPCop und 30x Snapshot
pädML-Server)
Post by Tobias Küchel
Wenn ich richtig
verstehe, hast du unter /mnt/pve/Backup-NAS/dump/ ein Verzeichnisbaum
pro Snapshot? und ebenso unter /var/lib/vz/dump/ dann?
nein, alle Snapshots liegen in /mnt/pve/Backup-NAS/dump/.
Und dieses eine Verzeichnis will ich vom NAS auf den Server spiegeln
(also in /var/lib/vz/dump/ soll immer derselbe Datenbestand an Snapshots
sein)
Post by Tobias Küchel
Willst du denn einfach nur kopieren, oder wirklich syncronisieren?
synchronisieren.
Denn es wird ja jede Nacht der älteste Snapshot gelöscht und dann ein
neuer erstellt. Somit sind immer 30 Snapshots vorhanden.

Wenn ich nur kopiere, dann läuft mir die Server-HD ja voll, weil in
/var/lib/vz/dump/ dann nichts gelöscht sondern nur dazu kopiert wird.
Post by Tobias Küchel
Eigentlich willst du doch nur das neueste Snapshot verzeichnis kopieren,
oder?
ja, das Snapshotverzeichnis mit allen Snapshots, aber eben die beiden
Verzeichnisse synchron halten.
Post by Tobias Küchel
Kopieren sollte deutlich schneller gehn.
Wenn jedes deiner Snapshots eine container-datei ist, versteh ich nicht,
warum er so lange braucht.
ja, der Snapshot des pädML Servers ist eine Datei mit knapp 100 GB.

Ich verstehe auch nicht, warum das so lange geht, denn das Erstellen des
Snapshots auf das NAS ist ja in unter 3 Stunden abgeschlossen, und da
muss ja das ganze Dateisystem in die Snapshotdatei gepackt werden.

Viele Grüße
Steffen
--
System:
- virtualisiert mit Proxmox 2.1
- pädML 5.1.0
- dedizierter IPCop
- Linbo 2.0.9-0
- Erweiterungen: Pykota, Copspot, MRBS und OpenSchulportfolio
- Moodle extern (Belwue) per ldaps angebunden
_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Lesen Sie weiter auf narkive:
Loading...