-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
| Schon mal ein paar tests mit ner *.tar, *.tar.gz und *.tar.bz von
| 8 GByte größe gemacht ? Eine reine tar auf dem band ist ein
| paarmal schneller als mit gnuzip oder bzip2 compremierte tar
| archive.
Hallo,
in welcher
Michelle Konzack wrote:
Hab ich schon getestet. bzip2 scheint im Schnitt leistungsfähiger zu sein.
Dauer aber wesentlich länger und bringen
an Kompression tuts nicht mehr als 5%.
Zeit spielt bein einem Laufwerk das nur mit 1MB/s schreibt keine wesentliche
Rolle. Platz hingegen schon wenn man
Hi,
this is an automatic reply. Your message to this list
HAS NOT BEEN DELIVERED,
because it was empty after being processed to strip (any) non textual part.
Most often, this may be due to the following conditions:
* You really sent an empty message: you may not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
| Deswegen würde ich hier apio empfehlen, das macht dasselbe wie
| cpio, kann aber jede Datei einzeln komprimieren.
Glaub das Programm hieß afio :-)
| Also erst kompremieren und dann tar ? Das kannste dann auch mit
| gnuzip oder
Hi,
this is an automatic reply. Your message to this list
HAS NOT BEEN DELIVERED,
because it was empty after being processed to strip (any) non textual part.
Most often, this may be due to the following conditions:
* You really sent an empty message: you may not
Am 2004-09-05 10:41:38, schrieb Jan Kesten:
Hallo,
in welcher Hinsicht ist ein unkomprimiertes tar schneller als ein
komprimiertes? Klar, beim Sichern brauchst Du viel CPU Zeit um die
ganzen Daten zu komprimieren und das kostet natürlich seine Zeit.
Bei bzip2 noch mehr als bei gzip.
Wenn
Am 2004-09-05 11:03:13, schrieb Jan Kesten:
Naja, der Unterschied ist natürlich, dass wenn Du dein tar Archiv
hast und das mit gzip komprimiert ist, hast Du ein Problem, sobald
ein einzelnes Bit kippt: Mit etwas Glück ist dann das Archiv unlesbar.
Das meinte ich...
Und umgedreht, wenn Du die
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
| Platz spielt eigentlich keine Rolle... Verwende TDK Bänder die
| sogar deutlich mehr als 8 GByte (kompremiert) schaffen, - im
| idealfall 16 GByte aber über 12 bin ich nicht hinausgekommen
Eben, genau da muss man abwägen was
Michelle Konzack schrieb am 04.09.2004 um 18:06:50 +0200:
Hallo Michelle,
Am 2004-09-04 17:00:59, schrieb Björn Schmidt:
Michelle Konzack wrote:
Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
gnuzip hat keine Fehlerkorrektur.
Da muss ich wohl zu bzip2 wechseln.
Am 2004-09-05 11:52:37, schrieb Jan Kesten:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
| Platz spielt eigentlich keine Rolle... Verwende TDK Bänder die
| sogar deutlich mehr als 8 GByte (kompremiert) schaffen, - im
| idealfall 16 GByte aber über 12 bin ich
Hi,
Michelle Konzack am Sonntag, 5. September 2004 11:11:
Am 2004-09-05 11:52:37, schrieb Jan Kesten:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
| Platz spielt eigentlich keine Rolle... Verwende TDK Bänder die
| sogar deutlich mehr als 8 GByte
Am 2004-09-05 11:43:38, schrieb Dieter Franzke:
Hi,
ich möchte hier noch mal ganz bescheiden darauf hinweisen, dass
Backups mittels DDS definitiv für den professionellen Einsatz nicht
geeignet sind.
Erst recht nicht mit Hardwarekomprimierung.
Die Bänder lassen sich meistens nur mit dem
Hi Michelle,
Michelle Konzack am Sonntag, 5. September 2004 12:17:
...
So wie mein DLT in Paris ? - Wo ich meinen Arbeitgeber
anhauchen mußte mir die 4600 Euro zu stellen ?
ich sprach ausdrücklich von professionellem Einsatz...
Lieber 4600 Euronen fürs Backup, als ne Firma ohne Daten.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Franzke wrote:
| ich sprach ausdrücklich von professionellem Einsatz... Lieber
| 4600 Euronen fürs Backup, als ne Firma ohne Daten. Unsere könnte
| dichtmachen bei Datentotalverlust.
Hallo, Dieter!
Ich hab mal eine Studie gelesen, dass 80% aller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Franzke wrote:
| Ich kenne auch viele, die zwar Backups machen, sich aber noch nie
| Gedanken um das Rückspielen machen.
| Genauso schlimm.
Ne, schlimmer! Die wiegen sich in Sicherheit. Die ohne reguläres Backup
machen wenn Sie nicht ganz matt
Philipp Meier wrote:
Ne, schlimmer! Die wiegen sich in Sicherheit. Die ohne reguläres Backup
machen wenn Sie nicht ganz matt sind hin und wieder wenigstens mal
Gummibackups auf CD oder so.
Lol, was sind denn gummibackups?
--
Bye,
Patrick Cornelissen
http://www.p-c-software.de
ICQ:15885533
--
Michelle Konzack [EMAIL PROTECTED] schrieb:
Hatte auch schon daran gedacht, einen Multi-CD-Brenner zu besorgen,
die können im Magazin 12 CD's aufnehmen und kosten 2500 Euro :-)
Währen dann unkompremiert 7800 MBytes an Kapazität
Wow, so viel Geld für 7800 MB! Was spricht gegen z. B.
Am 2004-09-05 16:02:33, schrieb Malte Spiess:
Michelle Konzack [EMAIL PROTECTED] schrieb:
Hatte auch schon daran gedacht, einen Multi-CD-Brenner zu besorgen,
die können im Magazin 12 CD's aufnehmen und kosten 2500 Euro :-)
Währen dann unkompremiert 7800 MBytes an Kapazität
Wow, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patrick Cornelißen wrote:
| Philipp Meier wrote:
|
| Ne, schlimmer! Die wiegen sich in Sicherheit. Die ohne reguläres Backup
| machen wenn Sie nicht ganz matt sind hin und wieder wenigstens mal
| Gummibackups auf CD oder so.
|
| Lol, was sind denn
Michelle Konzack [EMAIL PROTECTED] schrieb:
Am 2004-09-05 16:02:33, schrieb Malte Spiess:
Michelle Konzack [EMAIL PROTECTED] schrieb:
Hatte auch schon daran gedacht, einen Multi-CD-Brenner zu besorgen,
die können im Magazin 12 CD's aufnehmen und kosten 2500 Euro :-)
Währen
Am 2004-09-05 20:57:57, schrieb Malte Spiess:
Ach, so ist das also...
Und was ist mit externen Festplatten? Die müssten doch auch recht lange
überleben.
Ich habe einen BackupServer mit 4 x 300 GBytes im Raid-5
Aber der ist nervig...
Ich kenne keinen einzigen Hersteller, der über 1 Jahr
On Friday 03 September 2004 22:46, Robert Rakowicz wrote:
2$errorlog $log
gibt:
debian:/# tar -cv -b 64 -f /dev/tape /home/user |2$errorlog$log
bash: 2: ambiguous redirect
Ich habe etwas anderes gefunden:
debian:/# tar -cv -b 64 -f /dev/tape /home/user /home/user/tar.txt
Und später: tail
Klaus Becker wrote:
On Friday 03 September 2004 22:46, Robert Rakowicz wrote:
2$errorlog $log
gibt:
debian:/# tar -cv -b 64 -f /dev/tape /home/user |2$errorlog$log
Das gehört da nicht hin --^^
Und da fehlt ein blank davor
Am 2004-09-03 23:06:58, schrieb Björn Schmidt:
Ich habe ein Netzlaufwerk via smbfs gemountet. Darin liegt dann eine 14GB
große tar.gz die ich per DragDrop in das Laufwerk kopiere.
Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
gnuzip hat keine Fehlerkorrektur.
Greetings
Am 2004-09-04 10:02:33, schrieb Klaus Becker:
On Friday 03 September 2004 22:46, Robert Rakowicz wrote:
2$errorlog $log
gibt:
debian:/# tar -cv -b 64 -f /dev/tape /home/user |2$errorlog$log
^ ^ ^
Michelle Konzack wrote:
Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
gnuzip hat keine Fehlerkorrektur.
Da muss ich wohl zu bzip2 wechseln. Irgendwelche Einwände?
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
Am 2004-09-04 10:02:33, schrieb Klaus Becker:
debian:/# tar -cv -b 64 -f /dev/tape /home/user |2$errorlog$log
^ ^ ^
| | |
Am 2004-09-04 17:00:59, schrieb Björn Schmidt:
Michelle Konzack wrote:
Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
gnuzip hat keine Fehlerkorrektur.
Da muss ich wohl zu bzip2 wechseln. Irgendwelche Einwände?
Ja, Du kannst keine einzelnen Dateien herausholen :-)
Am 2004-09-04 17:12:41, schrieb Thomas Kosch:
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
tar -cv -b 64 -f /dev/tape /home/user 2$errorlog 1$log
funktioniert einwandfrei.
Und überschreibt ihm bei jedem Lauf das Log, was er ja vielleicht nicht
will. Die Pipe allerdings sollte
Hi;
[On Sat Sep 4 18:06:50 2004 +0200, Michelle Konzack wrote:]
Am 2004-09-04 17:00:59, schrieb Björn Schmidt:
Michelle Konzack wrote:
Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
gnuzip hat keine Fehlerkorrektur.
Da muss ich wohl zu bzip2 wechseln.
Michelle Konzack wrote:
Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
gnuzip hat keine Fehlerkorrektur.
Da muss ich wohl zu bzip2 wechseln. Irgendwelche Einwände?
Ja, Du kannst keine einzelnen Dateien herausholen :-)
Ich meinte berechtigte Einwände...
Eine einfache *.tar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
| Am 2004-09-03 23:06:58, schrieb Björn Schmidt:
|
|
|Ich habe ein Netzlaufwerk via smbfs gemountet. Darin liegt dann eine 14GB
|große tar.gz die ich per DragDrop in das Laufwerk kopiere.
|
|
| Und lass da mal ein Bit in der
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
Am 2004-09-04 17:00:59, schrieb Björn Schmidt:
Da muss ich wohl zu bzip2 wechseln. Irgendwelche Einwände?
Ja, Du kannst keine einzelnen Dateien herausholen :-)
Man kann ja einem komprimierten Tarball viele Nachteile nachsagen. Aber
das
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
Am 2004-09-04 17:12:41, schrieb Thomas Kosch:
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
tar -cv -b 64 -f /dev/tape /home/user 2$errorlog 1$log
funktioniert einwandfrei.
Und überschreibt ihm bei jedem Lauf das Log, was
Am 2004-09-04 18:38:14, schrieb Martin Wanke:
Hi;
Und nun?
Dauert gut 4 mal länger als ein tar vom Laufwerk kompremiert.
Gruß
Mawan
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
Am 2004-09-04 19:12:34, schrieb Björn Schmidt:
Ich meinte berechtigte Einwände...
Beim OP war von *.tar.gz die rede !
Hab ich schon getestet. bzip2 scheint im Schnitt leistungsfähiger zu sein.
Dauer aber wesentlich länger und bringen
an Kompression tuts nicht mehr als 5%.
Mit freundlichen
Am 2004-09-04 20:20:35, schrieb Thomas Kosch:
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
Am 2004-09-04 17:00:59, schrieb Björn Schmidt:
Da muss ich wohl zu bzip2 wechseln. Irgendwelche Einwände?
Ja, Du kannst keine einzelnen Dateien herausholen :-)
Man kann ja einem
Am 2004-09-04 19:35:17, schrieb Philipp Meier:
| Und lass da mal ein Bit in der *.tar.gz kippen und Du hast Schrott...
| gnuzip hat keine Fehlerkorrektur.
Deswegen würde ich hier apio empfehlen, das macht dasselbe wie cpio,
kann aber jede Datei einzeln komprimieren.
Also erst kompremieren
Am 2004-09-04 20:25:13, schrieb Thomas Kosch:
On Day 29 of Bureaucracy 3170, Michelle Konzack wrote:
Am 2004-09-04 17:12:41, schrieb Thomas Kosch:
Und überschreibt ihm bei jedem Lauf das Log, was er ja vielleicht nicht
will. Die Pipe allerdings sollte überflüssig sein.
DAT=`date
n'Abend,
ich sichere meine Daten auf ein Onstream Bandlaufwerk mit folgendem Befehl:
tar -cv -b 64 -f /dev/tape /home/user
Soweit, so gut. Nun möchte ich aber überwachen, ob auch alles korrekt
gesichert worden ist, und das ist bei knapp 15 GO nicht so einfach.
Ich habe tar die ganze Nacht
Klaus Becker wrote:
ich sichere meine Daten auf ein Onstream Bandlaufwerk mit folgendem Befehl:
tar -cv -b 64 -f /dev/tape /home/user
Kombinier das mit Buffer, dann ist das Backup in ~3 Stunden fertig.
Soweit, so gut. Nun möchte ich aber überwachen, ob auch alles korrekt
gesichert worden ist,
Hallo Björn,
On Friday 03 September 2004 22:06, Björn Schmidt wrote:
Klaus Becker wrote:
ich sichere meine Daten auf ein Onstream Bandlaufwerk mit folgendem
Befehl:
tar -cv -b 64 -f /dev/tape /home/user
Kombinier das mit Buffer, dann ist das Backup in ~3 Stunden fertig.
kannst du mir
Klaus Becker wrote:
ich sichere meine Daten auf ein Onstream Bandlaufwerk mit folgendem
Befehl:
tar -cv -b 64 -f /dev/tape /home/user
Kombinier das mit Buffer, dann ist das Backup in ~3 Stunden fertig.
kannst du mir das erklären?
Könnte ich, mache ich aber nicht. Es gibt hier
Hi,
wie wäre es mit
,
| 2$errorlog $log
`
Pozdrawiam/Gruß/Regards
Robert Rakowicz
--
Robert Rakowicz
URL: www.rjap.de
E-Mail: [EMAIL PROTECTED]
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail
44 matches
Mail list logo
