Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem mit rsync und Hardlinks (Diskspace explodiert)
49 views
Skip to first unread message
Michelle Konzack
Dec 16, 2011, 5:40:03 AM12/16/11
to
Hallo Leute,
ich weis nicht, was passiert ist, aber seitdem ich dem Backup-Server
32 neue 2 TByte Festplatten verpaßt habe und das DIst-Upgrade von Etch
(wollte mit Volumes von 32 TByte nicht arbeiten) auf Squeeze gemacht
habe, geht hier einiges schief.
Die Incremental-Backups explodieren, sprich, sie haben WESENTLICH mehr
Diskspace Verbrauch als sie sollten.
Die Backups werden folgendermaßen gemacht
1) Wenn der Tag ein Montag ist oder noch kein Full-Backup in
der Woche gemacht wurde, wird ein Full-Backup gemacht
2) Alle anderen Tage ein Incemental-Backup
Damit bei einem Full-Backup nicht jedesmal >1,2 TByte transferiert
werden müssen, kopiere ich das lezte Full-Backup mit
cp -a ${LAST_FULL}/* ${NEW_BACKUP}/
+
rsync -v -e ssh -a root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
damit werden auch Hardlinks de-refferenced. Für das Incremental-Backup
verwende ich immer das lezte Backup-Verzeichnis mit
cp -a -l ${LAST_BACK}/* ${NEW_BACKUP}/
+
rsync -v -e ssh -a --delete root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
Nun habe ich ein Problem mit meinem Sun Storage Server festgestellt, das
die 70 TByte verfügbarer Patz (2x 16 Platten mit 2 TByte ; 1x 16 Platten
mit 1 TByte ; Alles Raid-5 mit jeweils 16 PLatten) in 2 Monaten nahezu
aufgebraucht sind...
Nun habe ich "du" über ein paar Verzeichnisse laufen lassen und das
gefunden:
----[ command 'for NUM in 3 4 5 6 ; do du -smc RSYNC_*/2011-12-1${NUM}*/ ; echo ; done' ]--
364 RSYNC_dns1/2011-12-13_153502_full/
2621 RSYNC_intranet1_work1/2011-12-13_164623_full/
4064 RSYNC_mail/2011-12-13_154006_full/
825 RSYNC_vserver04/2011-12-13_163415_full/
7872 total
363 RSYNC_dns1/2011-12-14_040001_increment/
2622 RSYNC_intranet1_work1/2011-12-14_040826_increment/
4065 RSYNC_mail/2011-12-14_040026_increment/
411 RSYNC_tdcloud_storage000/2011-12-14_035609_full/
827 RSYNC_vserver04/2011-12-14_040727_increment/
8286 total
363 RSYNC_dns1/2011-12-15_091002_increment/
2622 RSYNC_intranet1_work1/2011-12-15_102320_increment/
4079 RSYNC_mail/2011-12-15_091501_increment/
416 RSYNC_tdcloud_storage000/2011-12-15_193114_increment/
832 RSYNC_vserver04/2011-12-15_100952_increment/
8309 total
2599 RSYNC_intranet1_work1/2011-12-16_040029_increment/
421 RSYNC_tdcloud_storage000/2011-12-16_040509_increment/
3020 total
--------------------------------------------------------------------------------
----[ command 'for NUM in 3 4 5 6 ; do du --apparent-size -smc RSYNC_*/2011-12-1${NUM}*/ ; echo ; done' ]--
345 RSYNC_dns1/2011-12-13_153502_full/
2475 RSYNC_intranet1_work1/2011-12-13_164623_full/
3829 RSYNC_mail/2011-12-13_154006_full/
728 RSYNC_vserver04/2011-12-13_163415_full/
7375 total
345 RSYNC_dns1/2011-12-14_040001_increment/
2476 RSYNC_intranet1_work1/2011-12-14_040826_increment/
3829 RSYNC_mail/2011-12-14_040026_increment/
398 RSYNC_tdcloud_storage000/2011-12-14_035609_full/
729 RSYNC_vserver04/2011-12-14_040727_increment/
7774 total
344 RSYNC_dns1/2011-12-15_091002_increment/
2476 RSYNC_intranet1_work1/2011-12-15_102320_increment/
3841 RSYNC_mail/2011-12-15_091501_increment/
403 RSYNC_tdcloud_storage000/2011-12-15_193114_increment/
734 RSYNC_vserver04/2011-12-15_100952_increment/
7795 total
2455 RSYNC_intranet1_work1/2011-12-16_040029_increment/
407 RSYNC_tdcloud_storage000/2011-12-16_040509_increment/
2862 total
--------------------------------------------------------------------------------
Normalerweise sollte lezterer Test die Hardlinks ausschließen und der effektiv
benötiget Platz nicht 25 GByte sondern so um die 10-12 GByte liegen oder besser
gesagt, ein Full-Backup und sechs Incremental-Backup sollten den benötigten
Backplatz gerade mal verdoppeln, wenn nichts nennenswertes neu installiert wurde
Irgend welche Ideen, was da schief läuft?
Was mich am meisten wurmt ist die "work1" aus meinem Intranet im Büro,
denn diese "Devel Workstation" wurde von mir leztes Wochenende komplett
neu auf einem neuen Rechner installiert und noch nicht benutzt, sprich,
Sie läuft derzeit einfach nur so mit.
Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>
itsystems@tdnet Jabber linux4m...@jabber.ccc.de
Owner Michelle Konzack
Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)
USt-ID: DE 278 049 239
Linux-User #280138 with the Linux Counter, http://counter.li.org/
ich weis nicht, was passiert ist, aber seitdem ich dem Backup-Server
32 neue 2 TByte Festplatten verpaßt habe und das DIst-Upgrade von Etch
(wollte mit Volumes von 32 TByte nicht arbeiten) auf Squeeze gemacht
habe, geht hier einiges schief.
Die Incremental-Backups explodieren, sprich, sie haben WESENTLICH mehr
Diskspace Verbrauch als sie sollten.
Die Backups werden folgendermaßen gemacht
1) Wenn der Tag ein Montag ist oder noch kein Full-Backup in
der Woche gemacht wurde, wird ein Full-Backup gemacht
2) Alle anderen Tage ein Incemental-Backup
Damit bei einem Full-Backup nicht jedesmal >1,2 TByte transferiert
werden müssen, kopiere ich das lezte Full-Backup mit
cp -a ${LAST_FULL}/* ${NEW_BACKUP}/
+
rsync -v -e ssh -a root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
damit werden auch Hardlinks de-refferenced. Für das Incremental-Backup
verwende ich immer das lezte Backup-Verzeichnis mit
cp -a -l ${LAST_BACK}/* ${NEW_BACKUP}/
+
rsync -v -e ssh -a --delete root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
Nun habe ich ein Problem mit meinem Sun Storage Server festgestellt, das
die 70 TByte verfügbarer Patz (2x 16 Platten mit 2 TByte ; 1x 16 Platten
mit 1 TByte ; Alles Raid-5 mit jeweils 16 PLatten) in 2 Monaten nahezu
aufgebraucht sind...
Nun habe ich "du" über ein paar Verzeichnisse laufen lassen und das
gefunden:
----[ command 'for NUM in 3 4 5 6 ; do du -smc RSYNC_*/2011-12-1${NUM}*/ ; echo ; done' ]--
364 RSYNC_dns1/2011-12-13_153502_full/
2621 RSYNC_intranet1_work1/2011-12-13_164623_full/
4064 RSYNC_mail/2011-12-13_154006_full/
825 RSYNC_vserver04/2011-12-13_163415_full/
7872 total
363 RSYNC_dns1/2011-12-14_040001_increment/
2622 RSYNC_intranet1_work1/2011-12-14_040826_increment/
4065 RSYNC_mail/2011-12-14_040026_increment/
411 RSYNC_tdcloud_storage000/2011-12-14_035609_full/
827 RSYNC_vserver04/2011-12-14_040727_increment/
8286 total
363 RSYNC_dns1/2011-12-15_091002_increment/
2622 RSYNC_intranet1_work1/2011-12-15_102320_increment/
4079 RSYNC_mail/2011-12-15_091501_increment/
416 RSYNC_tdcloud_storage000/2011-12-15_193114_increment/
832 RSYNC_vserver04/2011-12-15_100952_increment/
8309 total
2599 RSYNC_intranet1_work1/2011-12-16_040029_increment/
421 RSYNC_tdcloud_storage000/2011-12-16_040509_increment/
3020 total
--------------------------------------------------------------------------------
----[ command 'for NUM in 3 4 5 6 ; do du --apparent-size -smc RSYNC_*/2011-12-1${NUM}*/ ; echo ; done' ]--
345 RSYNC_dns1/2011-12-13_153502_full/
2475 RSYNC_intranet1_work1/2011-12-13_164623_full/
3829 RSYNC_mail/2011-12-13_154006_full/
728 RSYNC_vserver04/2011-12-13_163415_full/
7375 total
345 RSYNC_dns1/2011-12-14_040001_increment/
2476 RSYNC_intranet1_work1/2011-12-14_040826_increment/
3829 RSYNC_mail/2011-12-14_040026_increment/
398 RSYNC_tdcloud_storage000/2011-12-14_035609_full/
729 RSYNC_vserver04/2011-12-14_040727_increment/
7774 total
344 RSYNC_dns1/2011-12-15_091002_increment/
2476 RSYNC_intranet1_work1/2011-12-15_102320_increment/
3841 RSYNC_mail/2011-12-15_091501_increment/
403 RSYNC_tdcloud_storage000/2011-12-15_193114_increment/
734 RSYNC_vserver04/2011-12-15_100952_increment/
7795 total
2455 RSYNC_intranet1_work1/2011-12-16_040029_increment/
407 RSYNC_tdcloud_storage000/2011-12-16_040509_increment/
2862 total
--------------------------------------------------------------------------------
Normalerweise sollte lezterer Test die Hardlinks ausschließen und der effektiv
benötiget Platz nicht 25 GByte sondern so um die 10-12 GByte liegen oder besser
gesagt, ein Full-Backup und sechs Incremental-Backup sollten den benötigten
Backplatz gerade mal verdoppeln, wenn nichts nennenswertes neu installiert wurde
Irgend welche Ideen, was da schief läuft?
Was mich am meisten wurmt ist die "work1" aus meinem Intranet im Büro,
denn diese "Devel Workstation" wurde von mir leztes Wochenende komplett
neu auf einem neuen Rechner installiert und noch nicht benutzt, sprich,
Sie läuft derzeit einfach nur so mit.
Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>
itsystems@tdnet Jabber linux4m...@jabber.ccc.de
Owner Michelle Konzack
Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)
USt-ID: DE 278 049 239
Linux-User #280138 with the Linux Counter, http://counter.li.org/
David Raab
Dec 16, 2011, 8:50:02 AM12/16/11
to
Hmm, ich gehe mal davon aus das du beim Upgrade von Etch nach Squeeze
auch über Lenny gegangen bist und das eigentliche Upgraden an sich nicht
die Fehlerursache ist.
Das einzige was mir ansonsten gerade eben spontan einfällt. Gab es nicht
für jedes Dateisystem (unterschiedliche) Hardlink grenzen, bzw pro
Ordner im Dateisystem eine maximale Anzahl von Hardlinks? Eventuell bist
du an dieses Limit gestoßen und rsync erzeugt nun neue Dateien anstatt
Hardlinks?
Das ist nur eine vermutung von mir. Ob es soweit stimmt müsstest du
selber einmal nachschauen.
Ich finds aber sowieso ulkig wieso man anscheint so viele Server und
Daten hat, und dann selber ein Backup mit cp & rsync zusammmenbastelst.
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/4EEB4A97...@david-raab.de
auch über Lenny gegangen bist und das eigentliche Upgraden an sich nicht
die Fehlerursache ist.
Das einzige was mir ansonsten gerade eben spontan einfällt. Gab es nicht
für jedes Dateisystem (unterschiedliche) Hardlink grenzen, bzw pro
Ordner im Dateisystem eine maximale Anzahl von Hardlinks? Eventuell bist
du an dieses Limit gestoßen und rsync erzeugt nun neue Dateien anstatt
Hardlinks?
Das ist nur eine vermutung von mir. Ob es soweit stimmt müsstest du
selber einmal nachschauen.
Ich finds aber sowieso ulkig wieso man anscheint so viele Server und
Daten hat, und dann selber ein Backup mit cp & rsync zusammmenbastelst.
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/4EEB4A97...@david-raab.de
Harald Weidner
Dec 16, 2011, 10:40:01 AM12/16/11
to
Hallo,
Michelle Konzack <linux4m...@tamay-dogan.net>:
>Die Incremental-Backups explodieren, sprich, sie haben WESENTLICH mehr
>Diskspace Verbrauch als sie sollten.
1. ("Hard"-)Links, die innerhalb des zu sichernden Dateibestandes
existieren.
Um diese zu erhalten, gibt es bei rsync die Option -H . Beachte, dass -H
nicht in -a enthalten ist. Der Grund ist, dass ein rsync mit -H viel mehr
Speicherplatz braucht, weil es sich alle kopierten inodes merken muss.
2. Links, die zwischen den verschiedenen Versionen des Backups existieren
(von dir mit cp -l angelegt).
Hierzu bietet rsync die Option --link-dest=... . Für ein Beispiel siehe
die Folie 6 meines Vortrages über versioniertes Backup:
http://www.weidner.ch/pub/VersioniertesBackup_LinuxWSKoeln_2011.pdf
Das cp kannst du dir in beiden Fällen sparen. Beim Full Backup übernimmt
rsync --copy-dest die Rolle des cp.
Idealerweise verwendest du auch noch die Option rsync -S, um Sparse Files
zu erhalten. Also:
Full Backup:
rsync -v -e ssh -aHS --copy-dest=${LAST_FULL} root@${SERVER}:${SOURCE}/ ${NEW_BACKUP}/
Incremental Backup:
rsync -v -e ssh -aHS --delete --link-dest=${LAST_BACKUP} root@${SERVER}:${SOURCE}/ ${NEW_BACKUP}/
Gruß, Harald
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/jcfoih$qba$1...@ext01.hweidner.de
Michelle Konzack <linux4m...@tamay-dogan.net>:
>Die Incremental-Backups explodieren, sprich, sie haben WESENTLICH mehr
>Diskspace Verbrauch als sie sollten.
>Damit bei einem Full-Backup nicht jedesmal >1,2 TByte transferiert
>werden müssen, kopiere ich das lezte Full-Backup mit
>
> cp -a ${LAST_FULL}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
>
>damit werden auch Hardlinks de-refferenced. Für das Incremental-Backup
>verwende ich immer das lezte Backup-Verzeichnis mit
>
> cp -a -l ${LAST_BACK}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a --delete root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
>werden müssen, kopiere ich das lezte Full-Backup mit
>
> cp -a ${LAST_FULL}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
>
>damit werden auch Hardlinks de-refferenced. Für das Incremental-Backup
>verwende ich immer das lezte Backup-Verzeichnis mit
>
> cp -a -l ${LAST_BACK}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a --delete root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
>Normalerweise sollte lezterer Test die Hardlinks ausschließen und der effektiv
>benötiget Platz nicht 25 GByte sondern so um die 10-12 GByte liegen oder besser
>gesagt, ein Full-Backup und sechs Incremental-Backup sollten den benötigten
>Backplatz gerade mal verdoppeln, wenn nichts nennenswertes neu installiert wurde
Man muss hier unterscheiden zwischen
>benötiget Platz nicht 25 GByte sondern so um die 10-12 GByte liegen oder besser
>gesagt, ein Full-Backup und sechs Incremental-Backup sollten den benötigten
>Backplatz gerade mal verdoppeln, wenn nichts nennenswertes neu installiert wurde
1. ("Hard"-)Links, die innerhalb des zu sichernden Dateibestandes
existieren.
Um diese zu erhalten, gibt es bei rsync die Option -H . Beachte, dass -H
nicht in -a enthalten ist. Der Grund ist, dass ein rsync mit -H viel mehr
Speicherplatz braucht, weil es sich alle kopierten inodes merken muss.
2. Links, die zwischen den verschiedenen Versionen des Backups existieren
(von dir mit cp -l angelegt).
Hierzu bietet rsync die Option --link-dest=... . Für ein Beispiel siehe
die Folie 6 meines Vortrages über versioniertes Backup:
http://www.weidner.ch/pub/VersioniertesBackup_LinuxWSKoeln_2011.pdf
Das cp kannst du dir in beiden Fällen sparen. Beim Full Backup übernimmt
rsync --copy-dest die Rolle des cp.
Idealerweise verwendest du auch noch die Option rsync -S, um Sparse Files
zu erhalten. Also:
Full Backup:
rsync -v -e ssh -aHS --copy-dest=${LAST_FULL} root@${SERVER}:${SOURCE}/ ${NEW_BACKUP}/
Incremental Backup:
rsync -v -e ssh -aHS --delete --link-dest=${LAST_BACKUP} root@${SERVER}:${SOURCE}/ ${NEW_BACKUP}/
Gruß, Harald
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Martin Steigerwald
Dec 17, 2011, 4:40:02 AM12/17/11
to
Hallo,
Am Freitag, 16. Dezember 2011 schrieb Michelle Konzack:
> Damit bei einem Full-Backup nicht jedesmal >1,2
> TByte transferiert werden müssen, kopiere ich das lezte Full-Backup
> mit
>
> cp -a ${LAST_FULL}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
>
> damit werden auch Hardlinks de-refferenced. Für
> das Incremental-Backup verwende ich immer das lezte
> Backup-Verzeichnis mit
>
> cp -a -l ${LAST_BACK}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a --delete root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
Nur eine Idee, die nur dann Sinn macht, wenn Du da in der letzten Zeit
etwas geändert hast:
Enthält SOURCE einen abschließenden Slash?
Sonst kopiert rsync das neue Backup in ein Unterverzeichnis unterhalb
NEW_BACKUP. Der cp-Befehl legt jedoch nache, das das Backup direkt in
NEW_BACKUP ist.
Für solche Backup-Szenarios gibts rsnapshot, das auf rsync zurückgreift.
Das setzen wir mit --link-dest ein und das funktioniert auch mit Squeeze
einwandfrei. Einziges Thema ist, dass rsnapshot meines Wissens rsync-
Fehlermeldung immer noch nicht in die Protokoll-Datei durchschleifen kann.
Wenn also ein Fehler auftrat, darf man es in einer Shell nochmal manuell
laufen lassen, um die Fehlermeldungen zu sehen.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/201112171038...@lichtvoll.de
Am Freitag, 16. Dezember 2011 schrieb Michelle Konzack:
> Damit bei einem Full-Backup nicht jedesmal >1,2
> TByte transferiert werden müssen, kopiere ich das lezte Full-Backup
> mit
>
> cp -a ${LAST_FULL}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
>
> damit werden auch Hardlinks de-refferenced. Für
> das Incremental-Backup verwende ich immer das lezte
> Backup-Verzeichnis mit
>
> cp -a -l ${LAST_BACK}/* ${NEW_BACKUP}/
> +
> rsync -v -e ssh -a --delete root@${SERVER}:${SOURCE} ${NEW_BACKUP}/
etwas geändert hast:
Enthält SOURCE einen abschließenden Slash?
Sonst kopiert rsync das neue Backup in ein Unterverzeichnis unterhalb
NEW_BACKUP. Der cp-Befehl legt jedoch nache, das das Backup direkt in
NEW_BACKUP ist.
Für solche Backup-Szenarios gibts rsnapshot, das auf rsync zurückgreift.
Das setzen wir mit --link-dest ein und das funktioniert auch mit Squeeze
einwandfrei. Einziges Thema ist, dass rsnapshot meines Wissens rsync-
Fehlermeldung immer noch nicht in die Protokoll-Datei durchschleifen kann.
Wenn also ein Fehler auftrat, darf man es in einer Shell nochmal manuell
laufen lassen, um die Fehlermeldungen zu sehen.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Michelle Konzack
Dec 17, 2011, 5:30:02 AM12/17/11
to
Hello David Raab,
Am 2011-12-16 14:41:43, hacktest Du folgendes herunter:
noch alles funktioniert und bin dann ich diese Probleme geraten.
Ein weiterer Backupserver der direkt mit Squeeze installiert wurde,
zeigt aber die gleichen Symptome, deswegen rätzele ich herum, wo der
Fehler liegen könnte.
> Das einzige was mir ansonsten gerade eben spontan einfällt. Gab es nicht
> für jedes Dateisystem (unterschiedliche) Hardlink grenzen, bzw pro
> Ordner im Dateisystem eine maximale Anzahl von Hardlinks? Eventuell bist
> du an dieses Limit gestoßen und rsync erzeugt nun neue Dateien anstatt
> Hardlinks?
??? Also ich kann mir eigentlich nur vorstellen, das die Anzahl erhöht
ein könnte. Denn unter Etch (mit leztem selbstbau Kernel) hatte ich
bereits 16x 1 TByte = 13 TByte effectiv weil der Debian-Kernel das nicht
unterstützt hatte.
> Das ist nur eine vermutung von mir. Ob es soweit stimmt müsstest du
> selber einmal nachschauen.
>
> Ich finds aber sowieso ulkig wieso man anscheint so viele Server und
> Daten hat, und dann selber ein Backup mit cp & rsync zusammmenbastelst.
Ist einfacher zu warten. Vor allem habe ein paar Backup Programme über
die Zeit gewaltige veränderungen erfahren und waren mehrfach nicht mehr
kompatibel... Sowas nervt.
Dazu kommt noch hinzu, das die Backup-Programme nicht das gemacht haben
was ich wollte und es keine passenden Web-Frontends gab der mir erlaubte
von Australien aus einen Server in Marokko wieder herzustellen während
der Backupserver bei Hetzner in Nuürnberg sreht und der Administrations-
server in meinem Strasbourger Büro. :-D
Am 2011-12-16 14:41:43, hacktest Du folgendes herunter:
> Hmm, ich gehe mal davon aus das du beim Upgrade von Etch nach Squeeze
> auch über Lenny gegangen bist und das eigentliche Upgraden an sich nicht
> die Fehlerursache ist.
Nunja, ich habe nach jeden einzelnen Dist-Upgrade nicht getestet, ob
> auch über Lenny gegangen bist und das eigentliche Upgraden an sich nicht
> die Fehlerursache ist.
noch alles funktioniert und bin dann ich diese Probleme geraten.
Ein weiterer Backupserver der direkt mit Squeeze installiert wurde,
zeigt aber die gleichen Symptome, deswegen rätzele ich herum, wo der
Fehler liegen könnte.
> Das einzige was mir ansonsten gerade eben spontan einfällt. Gab es nicht
> für jedes Dateisystem (unterschiedliche) Hardlink grenzen, bzw pro
> Ordner im Dateisystem eine maximale Anzahl von Hardlinks? Eventuell bist
> du an dieses Limit gestoßen und rsync erzeugt nun neue Dateien anstatt
> Hardlinks?
ein könnte. Denn unter Etch (mit leztem selbstbau Kernel) hatte ich
bereits 16x 1 TByte = 13 TByte effectiv weil der Debian-Kernel das nicht
unterstützt hatte.
> Das ist nur eine vermutung von mir. Ob es soweit stimmt müsstest du
> selber einmal nachschauen.
>
> Ich finds aber sowieso ulkig wieso man anscheint so viele Server und
> Daten hat, und dann selber ein Backup mit cp & rsync zusammmenbastelst.
die Zeit gewaltige veränderungen erfahren und waren mehrfach nicht mehr
kompatibel... Sowas nervt.
Dazu kommt noch hinzu, das die Backup-Programme nicht das gemacht haben
was ich wollte und es keine passenden Web-Frontends gab der mir erlaubte
von Australien aus einen Server in Marokko wieder herzustellen während
der Backupserver bei Hetzner in Nuürnberg sreht und der Administrations-
server in meinem Strasbourger Büro. :-D
Michelle Konzack
Dec 21, 2011, 6:30:02 PM12/21/11
to
Hello Harald,
Am 2011-12-16 15:36:49, hacktest Du folgendes herunter:
noch eigenartig, denn:
----8<------------------------------------------------------------------
Wed, 21 Dec 2011 13:45:07 +0100
===============================
344 RSYNC_dns1/2011-12-19_040002_full/
2566 RSYNC_intranet1_work1/2011-12-19_051115_full/
3923 RSYNC_mail/2011-12-19_040459_full/
379 RSYNC_tdcloud_storage000/2011-12-19_051738_full/
731 RSYNC_vserver04/2011-12-19_045855_full/
7941 total
191 RSYNC_dns1/2011-12-20_040002_increment/
1883 RSYNC_intranet1_work1/2011-12-20_044400_increment/
2390 RSYNC_mail/2011-12-20_040250_increment/
240 RSYNC_tdcloud_storage000/2011-12-20_044825_increment/
371 RSYNC_vserver04/2011-12-20_043643_increment/
5073 total
192 RSYNC_dns1/2011-12-21_040002_increment/
1885 RSYNC_intranet1_work1/2011-12-21_044424_increment/
2400 RSYNC_mail/2011-12-21_040245_increment/
245 RSYNC_tdcloud_storage000/2011-12-21_044832_increment/
379 RSYNC_vserver04/2011-12-21_043705_increment/
5099 total
----8<------------------------------------------------------------------
Ich finde, das dies nicht besonderst lustig aussieht...
Die frage ist nämlich, was hat sich zwischen Lenny und Squeeze geändert,
das plötzlich alle Incrementalbackups so groß sind?
Es kann nicht sein, das ich jetzt jeden Tag 450 GByte Incrementalbackups
(~400 Server + ~80 Workstationen) machen muß, während es unter Lenny
gerade mal 80 GByte waren. Vor allem verwende ich mein Script nahezu
unverändert seit 8 Jahren
Auch wenn ich eine SEHR schnellen Internet-Zugang habe, mir reicht der
Festplattenplatz nicht
Wenn ich tägliche Vollbackups machen will, kann ich auf jedem einzelnen
Server TAR+BZIP2 laufen lassen und die kompremierte Datei auf den Server
schicken.
Am 2011-12-16 15:36:49, hacktest Du folgendes herunter:
> rsync -v -e ssh -aHS --copy-dest=${LAST_FULL} root@${SERVER}:${SOURCE}/ ${NEW_BACKUP}/
> rsync -v -e ssh -aHS --delete --link-dest=${LAST_BACKUP} root@${SERVER}:${SOURCE}/ ${NEW_BACKUP}/
Also die beiden Sachen habe ich jetzt laufen lassen und es ist immer
noch eigenartig, denn:
----8<------------------------------------------------------------------
Wed, 21 Dec 2011 13:45:07 +0100
===============================
344 RSYNC_dns1/2011-12-19_040002_full/
2566 RSYNC_intranet1_work1/2011-12-19_051115_full/
3923 RSYNC_mail/2011-12-19_040459_full/
379 RSYNC_tdcloud_storage000/2011-12-19_051738_full/
731 RSYNC_vserver04/2011-12-19_045855_full/
7941 total
191 RSYNC_dns1/2011-12-20_040002_increment/
1883 RSYNC_intranet1_work1/2011-12-20_044400_increment/
2390 RSYNC_mail/2011-12-20_040250_increment/
240 RSYNC_tdcloud_storage000/2011-12-20_044825_increment/
371 RSYNC_vserver04/2011-12-20_043643_increment/
5073 total
192 RSYNC_dns1/2011-12-21_040002_increment/
1885 RSYNC_intranet1_work1/2011-12-21_044424_increment/
2400 RSYNC_mail/2011-12-21_040245_increment/
245 RSYNC_tdcloud_storage000/2011-12-21_044832_increment/
379 RSYNC_vserver04/2011-12-21_043705_increment/
5099 total
----8<------------------------------------------------------------------
Ich finde, das dies nicht besonderst lustig aussieht...
Die frage ist nämlich, was hat sich zwischen Lenny und Squeeze geändert,
das plötzlich alle Incrementalbackups so groß sind?
Es kann nicht sein, das ich jetzt jeden Tag 450 GByte Incrementalbackups
(~400 Server + ~80 Workstationen) machen muß, während es unter Lenny
gerade mal 80 GByte waren. Vor allem verwende ich mein Script nahezu
unverändert seit 8 Jahren
Auch wenn ich eine SEHR schnellen Internet-Zugang habe, mir reicht der
Festplattenplatz nicht
Wenn ich tägliche Vollbackups machen will, kann ich auf jedem einzelnen
Server TAR+BZIP2 laufen lassen und die kompremierte Datei auf den Server
schicken.
Harald Weidner
Dec 22, 2011, 3:50:02 AM12/22/11
to
Hallo,
Michelle Konzack <linux4m...@tamay-dogan.net>:
>Also die beiden Sachen habe ich jetzt laufen lassen und es ist immer
>noch eigenartig, denn:
[...]
>Ich finde, das dies nicht besonderst lustig aussieht...
>Die frage ist nämlich, was hat sich zwischen Lenny und Squeeze geändert,
>das plötzlich alle Incrementalbackups so groß sind?
Aus den angegebenen Zahlen kann man nicht ablesen, wie groß das
Increment wirklich ist.
Da es bei Links (im Gegensatz zu symbolischen Links) keinen Unterschied
zwischen "Original" und "Kopie" gibt, misst jeder deiner du Kommandos den
Platzverbrauch einer Generation. Die Summe über verschiedene Generationen
kann wegen der Links deutlich kleiner sein. Das kann dein Skript aber
nicht anzeigen, da es die Generationen getrennt behandelt.
Probiere mal:
du -smc RSYNC_dns1/*
du -smc RSYNC_intranet1_work1/*
du -smc RSYNC_mail/*
usw.
Gruß, Harald
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/jcuqse$6o7$1...@ext01.hweidner.de
Michelle Konzack <linux4m...@tamay-dogan.net>:
>Also die beiden Sachen habe ich jetzt laufen lassen und es ist immer
>noch eigenartig, denn:
>Ich finde, das dies nicht besonderst lustig aussieht...
>Die frage ist nämlich, was hat sich zwischen Lenny und Squeeze geändert,
>das plötzlich alle Incrementalbackups so groß sind?
Increment wirklich ist.
Da es bei Links (im Gegensatz zu symbolischen Links) keinen Unterschied
zwischen "Original" und "Kopie" gibt, misst jeder deiner du Kommandos den
Platzverbrauch einer Generation. Die Summe über verschiedene Generationen
kann wegen der Links deutlich kleiner sein. Das kann dein Skript aber
nicht anzeigen, da es die Generationen getrennt behandelt.
Probiere mal:
du -smc RSYNC_dns1/*
du -smc RSYNC_intranet1_work1/*
du -smc RSYNC_mail/*
usw.
Gruß, Harald
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
0 new messages