Backup mittels tar und split

Hallo,

gestern haben wir über die 2G Grenze beim Erstellen einer Backupdatei
gesprochen. Habe mich ein wenig umgeschaut und bin auf eine Mail
gestoßen in der die Schuld der glibc zugeschoben wird. Scheinbar ist es
  nicht ein Problem vom Filesystem. Siehe:
http://radawana.cg.tuwien.ac.at/mail-archives/lll/200006/msg00125.html

Daraus schließe ich, dass das Problem noch länger existieren wird und
wir lernen sollten, einfach damit zurechtzukommen.

Also bin ich gerade dabei einen Testlauf des beschriebenen Kommandos auf
meinen Schläppi durchzuführen.

Ich habe es ein wenig verändert:
[inspiron]pazzo$ tar -czvp --one-file-system --exclude RH_72 -f - . |
split -b 1000m - `hostname -s`_`whoami`_`date +"%Y-%m-%d"`.tar.gz.

Die Option one-file-system benutze ich in der Hoffnung, dass evtl.
gemountete Verzecihnisse nicht mitgesichert werden. Ich habe nämlich in
meiner home mehrere Verzeichnisse mit Samba mounts.

Weiters habe ich auch die ISOs der RedHat unter dem Verzeichnis RH_72
kopiert, sodass ich die CDs nicht andauernd mitschleppen und wechseln
muss. Mittels der Option --exclude RH_72 befehle ich dem tar-Tool das
Verzeichnis zu überspringen.

-f - sagt dem tar-Tool, dass das Ergebnis auf den "standard output"
Kanal geschrieben werden soll, sodass es mittels Pipe '|' dem split-Tool
übergeben werden kann.

Mittels split wird dann das Archiv in meherere 1G Teile aufgesplittet.
Als Eingang für split wird wieder - angegeben, sodass split die Daten
vom "standard input" einliest und als letzter Parameter gebe ich das
Filenamenprefix an, welches ich dynamisch zusammenstelle:

`hostname -s`_`whoami`_`date +"%Y-%m-%d"`.tar.gz.

das wird dann in meinen Fall

inspiron_pazzo_2002_05_24.tar.gz.

Und die Dateien werden dann von split folgendermaßen benannt:

inspiron_pazzo_2002_05_24.tar.gz.aa
inspiron_pazzo_2002_05_24.tar.gz.ab
...

Kleiner Tipp, mittels folgendem Kommando kann man sehr einfach die
tar-Dateien im aktuellen Verzeichnis in einem 3-Sekunden-Rhythmus
überwachen:

[inspiron]pazzo$ while true; do clear ; ls -ld *tar* ; sleep 3 ; done

Hehe es scheint zu funktionieren:
-rw-rw-r-- 1 pazzo pazzo 1000M Mai 24 15:23
inspiron_pazzo_2002-05-24.tar.gz.aa
-rw-rw-r-- 1 pazzo pazzo 230M Mai 24 15:24
inspiron_pazzo_2002-05-24.tar.gz.ab

mfg.
Patrick

Hi,

ich kommentiere nur einen kleinen Teil der mail.

Kleiner Tipp, mittels folgendem Kommando kann man sehr einfach die
tar-Dateien im aktuellen Verzeichnis in einem 3-Sekunden-Rhythmus
überwachen:

[inspiron]pazzo$ while true; do clear ; ls -ld *tar* ; sleep 3 ; done

Hierfuer gibt es auch den Befehl "watch", den viele nicht kennen
und den ich deswegen erwaehnen moechte.

  watch "du -k *tar*"

wuerde in etwa dasselbe erledingen. Siehe man watch.

Bye, Chris.

gestern haben wir über die 2G Grenze beim Erstellen einer Backupdatei
gesprochen. Habe mich ein wenig umgeschaut und bin auf eine Mail
gestoßen in der die Schuld der glibc zugeschoben wird. Scheinbar ist es
  nicht ein Problem vom Filesystem. Siehe:
http://radawana.cg.tuwien.ac.at/mail-archives/lll/200006/msg00125.html

Daraus schließe ich, dass das Problem noch länger existieren wird und
wir lernen sollten, einfach damit zurechtzukommen.

Stimmt nicht.

Ich habe ein System mit einem Vanilla 2.4.5 Kernel (+ 1 Reiser FS patch) -
also nicht gerade der allerletzte Schrei - auf dem ich mit Reiserfs
problemlos dies machen kann:

  chris(a)linuxbox:~$ dd if=/dev/zero of=bigfile bs=1024 count=2300000
  2300000+0 records in
  2300000+0 records out
  chris(a)linuxbox:~$ ls -la bigfile
  -rw-r--r-- 1 chris users 2355200000 May 24 21:57 bigfile

Ich meine, dass Linux seid 2.4.0 64 bit filepointer verwenden kann.
Von der glibc und von gcc sollte es auch keine Probleme geben, der
Typ "long" ist da ja schon seit jeher 64 bit.

Ich wuerde mal sagen, seid 1.5 Jahren oder so liegt der schwarze
Peter wirklich nur mehr bei ext2fs.

* chrism(a)desk.nl (chrism(a)desk.nl) wrote:

Ich meine, dass Linux seid 2.4.0 64 bit filepointer verwenden kann.
Von der glibc und von gcc sollte es auch keine Probleme geben, der
Typ "long" ist da ja schon seit jeher 64 bit.

Ich wuerde mal sagen, seid 1.5 Jahren oder so liegt der schwarze
Peter wirklich nur mehr bei ext2fs.

erm...

http://www.suse.de/~aj/linux_lfs.html

Leider wegen ein paar signed/unsigned probleme in manche low-level
storage treiber ist der limit auf diese geraete noch 1Tb und nich 2Tb
wie man sich erwartet.

Ja kannst du dies auch mit tar machen? Denn wenn tar auf die glibc
aufbaut und nicht die erweiterten API calls verwendet, sollte das
Problem auch auf Reiser FS weiterhin bestehen. Ich kann dies hier nicht
testen, leider nur ext2 :slight_smile:

mfg.
Patrick

chrism(a)desk.nl wrote:

erm...

http://www.suse.de/~aj/linux_lfs.html

Ok, ok. Es sind also noch nicht alle Felle im Trockenen bezueglich
grosser Files. Das wusste ich nicht.

Trotzdem: mit ReiserFS unter meinem 2.4.5er vanilla kernel (+1
ReiserFS patch) von vor beinahe einem Jahr scheine ich keine Probleme mit
Files groesser als 2GB zu haben. Auch nicht mit tar:

$ dd if=/dev/zero of=bigfile1 bs=1024
count=1500000
1500000+0 records in
1500000+0 records out

$ dd if=/dev/zero of=bigfile2 bs=1024
count=800000
800000+0 records in
800000+0 records out

$ tar cf ~/big.tar bigfile1 bigfile2

$ ls -la ~/big.tar
-rw-r--r-- 1 chris users 2355210240 May 25 18:45
/home/chris/big.tar

$ od --skip-bytes=2355210000 ~/big.tar
21430323420 000000 000000 000000 000000 000000 000000 000000 000000

Hi.

Ja kannst du dies auch mit tar machen? Denn wenn tar auf die glibc
aufbaut und nicht die erweiterten API calls verwendet, sollte das
Problem auch auf Reiser FS weiterhin bestehen. Ich kann dies hier nicht
testen, leider nur ext2 :slight_smile:

Ja (siehe Antwort auf Micheles Mail).

bye, Chris.

Geht also auch mit ext2fs!?

Yepp.

Des Raetsels Loesung fand ich dann im Changelog meiner Linux Distribution:
Slackware unterstuetzt Files groesser als 2 GB schon seit einem Jahr und
zwar mit ReiserFS _und_ ext2fs.

Ob sich da Red Hat was abschauen koennte :wink:

Funkt seit RH7.1 ganz ohne Probleme [mach mir 4Gb ISO images
seit APR 2001 mindestens]

Ciao,
Michele

> Ob sich da Red Hat was abschauen koennte :wink:

Funkt seit RH7.1 ganz ohne Probleme [mach mir 4Gb ISO images
seit APR 2001 mindestens]

Hmmm... Ok.

Aber warum hatte Patrick dann die Probleme?
Verwendet er eine aeltere Version oder hat er uns den tar/split Trick nur
zum Spass verraten?
Patrick: RFC!

Bye, Chris.

http://www.freego.it/news.php?show=411

Ich habe die Probleme ja gar nicht gehabt, Raphael hatte sie. Und da ich
immer alles glaube, dachte ich es wäre unter ext2 nicht möglich Dateien
dieser Größe anzulegen. Muss in Zukunft weniger auf euch losen, speziell
wenns Donnerstag Abend gegen Ende vom Treffen ist :wink:

Wenn ich mich richtig erinnere, hat Raphael das Problem auf einem Samba
Mount gehabt, also war es eine Windows-Partition. Es wäre ganz
interessant herauszufinden ob diese Einschränkung nur bei FAT oder auch
bei NTFS gelten.

Ich hoffe der Tipp ist trotzdem nützlich, man kann damit ja auch einfach
Dateien auf die Größe von "Removable medias" (CD-Roms, Disketten, ...)
aufsplitten und dann wieder zusammenfügen.

mfg.
Patrick

chrism(a)desk.nl wrote:

Ich habe die Probleme ja gar nicht gehabt, Raphael hatte sie. Und da ich
immer alles glaube, dachte ich es wäre unter ext2 nicht möglich Dateien
dieser Größe anzulegen. Muss in Zukunft weniger auf euch losen, speziell
wenns Donnerstag Abend gegen Ende vom Treffen ist :wink:

Mir ging's genau gleich!
Wir haben also ein Problem geloest, das wir gar nicht haben :wink:

Ich hoffe der Tipp ist trotzdem nützlich, man kann damit ja auch einfach
Dateien auf die Größe von "Removable medias" (CD-Roms, Disketten, ...)
aufsplitten und dann wieder zusammenfügen.

Stimmt!

Bye, Chris.

Karl qualche settimana fa ha portato il modulo alla riunione, dando così
la possibilità ai presenti di firmare.

Non so se è già stato spedito, magari potremmo portarlo anche questo
giovedì.

byez
Patrick

weiss(a)ndreas.it wrote:

Patrick Ohnewein wrote:

Karl qualche settimana fa ha portato il modulo alla riunione, dando così
la possibilità ai presenti di firmare.

Non so se è già stato spedito, magari potremmo portarlo anche questo
giovedì.

Non ho ancora spedito niente e posso portare i module

Ciao
Karl

Ich habe die Probleme ja gar nicht gehabt, Raphael hatte sie. Und da

ich

immer alles glaube, dachte ich es wäre unter ext2 nicht möglich

Dateien

dieser Größe anzulegen. Muss in Zukunft weniger auf euch losen,

speziell

wenns Donnerstag Abend gegen Ende vom Treffen ist :wink:

Ich weiß nicht wie wir auf ext2 gekommen sind. Ich glaube ich habe immer
von dem gemountetem SMB share gesprochen.

Wenn ich mich richtig erinnere, hat Raphael das Problem auf einem Samba
Mount gehabt, also war es eine Windows-Partition. Es wäre ganz
interessant herauszufinden ob diese Einschränkung nur bei FAT oder auch
bei NTFS gelten.

Ja, stimmt. Ich glaube es ist ein Windows 2000 server von dem ich einen
share mounte. Bei 2GB geht gzip (von "tar czf ...") auf 100% CPU und der
Prozess wird nicht mehr beendet.

Ich hoffe der Tipp ist trotzdem nützlich, man kann damit ja auch einfach
Dateien auf die Größe von "Removable medias" (CD-Roms, Disketten, ...)
aufsplitten und dann wieder zusammenfügen.

Ja, war nützlich, nun funktioniert alles paletti :slight_smile:

bye, raf

hallo,

nachdem lugbz PHP-Nuke auf seiner homepage laufen hat, kann mir
vielleicht jemand helfen. ich habe interessehalber PHP-Nuke auf meinem
pc installiert, die installation wird einem ja wirklich leicht gemacht.
es läuft soweit auch gut, nur gibt es ein problem beim user-login. user
werden nicht gefunden, es gibt immer die meldung "incorrect login". als
administrator kann ich mich aber ohne probleme einloggen.
woran kann das liegen?
verwende:
- mandrake 8.2
- php-nuke 5.3
- mysql 3.23
- php-mysql 4.1.2

danke für eventuelle hilfe!
lg, andreas

Hi,

da wird Dir Raphael vermutlich helfen koennen.

Ich geb' Dir inzwischen den Rat, PHP-Nuke *nicht* auf
einem oeffentlich zugaengliche Webserver zu legen.
Das System ist naemlich loechrig wie ein Sieb und wird
gern von Script kiddies auseinandergenommen (wie wir
leider auf der Lugbz Seite gesehen haben :frowning:

Bye, Chris.

chrism(a)desk.nl wrote:

Hi,

da wird Dir Raphael vermutlich helfen koennen.

Ich geb' Dir inzwischen den Rat, PHP-Nuke *nicht* auf
einem oeffentlich zugaengliche Webserver zu legen.
Das System ist naemlich loechrig wie ein Sieb und wird
gern von Script kiddies auseinandergenommen (wie wir
leider auf der Lugbz Seite gesehen haben :frowning:

Bye, Chris

danke für den hinweis! werde den webserver inzwischen 'mal schnellstens
öffentlich unzugänglich machen ...
was ist daran eigentlich so löcherig?
lg, andreas

danke für den hinweis! werde den webserver inzwischen 'mal schnellstens
öffentlich unzugänglich machen ...
was ist daran eigentlich so löcherig?

Zumindest bei unserer Version, 5.3.1, gibt es zahlreiche
Sicherheitsloecher. ich sah, dass Du 5.3 benutzt, also
sind die bei Deiner Version vermutlich auch noch drinnen.

So z.B. eine Stelle im code, wo externe Files ueber eine
Variable $file ge-include-iert werden, die nicht weiter
ueberprueft wird. Wenn das nicht gepatcht ist, kann ein request wie
index.php?file=/some/interesting/file/on/server interessante
Einsichten liefern...

Der eingebaute Filemanager hat auch Probleme: es ist relativ
leicht die Sicherung zu umgehen, die ihn nur fuer Admins
zugaenglich macht (ich sag' jetzt mal nicht wie, aber die
Interessierten koennen leicht selbst draufkommen :slight_smile:

Bye, Chris.

PS: Raphael sei Dank sind diese Loecher in unserer Version jetzt
gepatcht!