Tape Backup... wie?

[holm]

Ich habe mich kürzlich mal wieder entschlossen meinen Computer für die tägliche Arbeit zu aktualisieren. Ich habe mir ein MSI "Gamer" Motherboard besorgt, ein B450A Pro Max mit einem Ryzen 5 3600 und 32GB Ram, ein Gamer hat da auf Kleinanzeigen ausrangiert :-)
Das Motherboard hat für heutige Verhältnisse verhältnismäßig viele PCI-E Slots, es war aber trotzdem notwendig von 2 Slotsteckern die frontseitige Begrenzung heraus zu fräsen, damit die Controller unter kommen. Die Graka und der SAS Controller stecken in einem 8x Slot, der Rest in 1x Slots.
Ich habe ein NVIDIA Quadro K500, eine 2x seriell Karte zusätzlich der auf dem Motherboard vorhandenen COM1 und LPT Ports (!), einen LSI SAS Controller an dem 4 900GB Toshiba Platten hängen, einen LSI Fiber Controller an dem ein Ultrium 5 klemmt sowie einen derzeit ungenutzten LSI SCSI 320 Controller im Rechner. Ich habe mal 3 Ultrium 5 Bandeinschübe aus einer verschrotteten Tivoli Libray von unserer Uni geerbt, die Dinger sind zwar nicht als Standalone Gerät gedacht, arbeiten aber wider Erwarten recht problemlos mit den üblichen Tools zusammen. Nach dem ersten Test mit camcontrol tur x:y:z commt zwar ein "not ready" zurück, aber nach dem 2. Mal ist das Ding ready und arbeitet problemlos mit mt und tar, sehr gut.

Die 4 Toshiba Platten bilden ein raidz1 mit geli auf dem Alles drauf ist:
root@trollo:/home/holm # zpool status
pool: zrpool
state: ONLINE
config:

NAME STATE READ WRITE CKSUM
zrpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
da0p3.eli ONLINE 0 0 0
da1p3.eli ONLINE 0 0 0
da2p3.eli ONLINE 0 0 0
da3p3.eli ONLINE 0 0 0

errors: No known data errors
root@trollo:/home/holm # zfs list
NAME USED AVAIL REFER MOUNTPOINT
zrpool 192G 2.11T 140K /zrpool
zrpool/ROOT 25.8G 2.11T 140K none
zrpool/ROOT/default 25.8G 2.11T 24.5G /
zrpool/tmp 1.03M 2.11T 1.03M /tmp
zrpool/usr 166G 2.11T 140K /usr
zrpool/usr/home 130G 2.11T 130G /usr/home
zrpool/usr/ports 33.4G 2.11T 33.4G /usr/ports
zrpool/usr/src 2.29G 2.11T 2.29G /usr/src
zrpool/var 1.61M 2.11T 140K /var
zrpool/var/audit 140K 2.11T 140K /var/audit
zrpool/var/crash 140K 2.11T 140K /var/crash
zrpool/var/log 761K 2.11T 761K /var/log
zrpool/var/mail 262K 2.11T 262K /var/mail
zrpool/var/tmp 203K 2.11T 203K /var/tmp
root@trollo:/home/holm #

Zusätzlich gibt es noch 2 1TB SATA Platten als "Müllhalde" die aber derzeit noch nicht eingebaut sind,
und eine 128GB SSD kullert hier auch noch herum wenn sich dafür eine sinnvolle Anwendung findet (backup Cache?).

Meine Frage ist nun was Ihr für eine sinnvolle Backup Strategie empfehlen könnt, ich wollte mir eigentlich Monster wie bacula zu diesem Zweck eher kneifen. Dump des Zpools mit ZFS send, oder lieber tar? Wie ist das mit Fortsetzungstapes? Das letzte Mal als ich Sowas brauchte spuckte mir der hald in die Suppe weil er ungefragt auf dem Bandgerät herumdallte..biss ich ihm das untersagt hatte. Mit FreeBSD 13 ist der ja nun wieder von uns gegangen..

Gruß,
Holm

 

[CommanderZed]

Ob ZFS mit Tapes funktioniert und wenn ja wie müsste hier einer der ZFS experten vermutlich genauer beschreiben

Ich nutze, auch beruflich, ganz klassisch tar mit verschiedenen Betriebsystemen und fand das immer eigentlich sehr angenehm.

Der allergrößte Vorteil ist imho das mans überall wieder auslesen kann, keine bestimmte Version von irgend nem Backuptool etc braucht - bakula oder gar kaufsoftware ist imho für "simples backup" viel zu komplex und bietet zu viele möglichkeiten der Fehlbedienung, ohne für "ich möchte nur nen paar Dateien von einem gemounteten Dateisystem aufs Band schreiben" nennenswerte vorteile zu bieten.

 

[crotchmaster]

Lang,lang ist es her, dass ich mit Bändern rumgemacht habe. Ich habe dafür immer dump/restore verwendet, da ich die dump level sehr praktisch fand. Das war noch zu UFS-Zeiten. Heute mit ZFS? Keine Ahnung.

 

[holm]

zfs send und receive soll wohl zum Backup geeignet sein, es läßt sich wohl auch der Änderungsstand zwischen 2 Snapshoots sichern..aber ich habe das auch noch nie gemacht. Ich habe aber letztens gelesen das das nicht unbedingt praktikabel wäre..dump/restore vermisse ich auch. Sehr oft habe ich nur mit restore -i eine einzelne Datei wiederholen müssen. Ich liebe nach Erfahrungen mit allem Anderen Tapes. "Festplatte kaputt"? ..der Händler kichert..."hoffentlich auf Band gesichert..." 1,5TB unkomprimiert auf einem Tape ist schon mal ne Ansage...

Die Medien gibts zwar nicht für lau, aber es gab auch Zeiten da habe ich 1400 DM in einen Tandberg Viertelzoll Streamer investiert...für den Homecomputer.
Da war Linux aber noch nicht Mode, da lief Sowas wie Esix SVR3, Eurix SVR3 oder später Onsite Unix SVR4.2. Solche Teile habe ich immer noch, weil die auch an PDP-11 und ollen VAXen funktionieren. Mit einem 8GB Streamer an einer VAX kommt man mindestens 1x um die ganze Welt...

Gruß,
Holm

 

[pit234a]

Mit einem 8GB Streamer an einer VAX kommt man mindestens 1x um die ganze Welt...

aber nicht in 80 Tagen...

tut mir leid und das meine ich ganz ehrlich, aber Bänder sind deshalb heute out, weil sie eben sehr langsam sind.
Eine ähnliche Diskussion hatte ich eben erst mit einem Nostalgiker, der an seinen optischen Laufwerken hängt.
Deshalb meine ich, dass du aus praktischen Gesichtspunkten da gar keine Mühe investieren solltest und die Bandlaufwerke ins Museum geben oder so was.

Anders gesagt, wenn du das aus nostalgischen Gründen trotzdem haben möchtest, dann aber schon ganz nostalgisch und mit tar. Was denn sonst!

 

[CommanderZed]

aber nicht in 80 Tagen...

tut mir leid und das meine ich ganz ehrlich, aber Bänder sind deshalb heute out, weil sie eben sehr langsam sind.
Eine ähnliche Diskussion hatte ich eben erst mit einem Nostalgiker, der an seinen optischen Laufwerken hängt.
Deshalb meine ich, dass du aus praktischen Gesichtspunkten da gar keine Mühe investieren solltest und die Bandlaufwerke ins Museum geben oder so was.

Anders gesagt, wenn du das aus nostalgischen Gründen trotzdem haben möchtest, dann aber schon ganz nostalgisch und mit tar. Was denn sonst!

Da möchte ich ein bisschen wiedersprechen, mein Band-Modell auf der arbeit ist zb deutlich schneller als die Spindel-Rost-SAS-Platten auf der die Daten liegen.

 

[pit234a]

Da möchte ich ein bisschen wiedersprechen, mein Band-Modell auf der arbeit ist zb deutlich schneller als die Spindel-Rost-SAS-Platten auf der die Daten liegen.

meine Erlebnisse mit Bändern sind ja schon etwas älter und damit magst du durchaus richtig liegen, vorstellen kann ich mir das aber nicht. Alleine das Spulen und vor und zurück dauert doch gefühlte Ewigkeiten.
Besonders bei inkrementellen Backups stelle ich mir das sehr langsam vor.

Ich gebe zu, dass ich auch mit ZFS meine Backups nicht angepasst habe und noch immer rsync nutze, halt auf ZFS. Das ist womöglich auch nicht so schnell, aber das syncen meiner vollen 100G aus ./~ braucht bei mir keine 10min, wenn ich richtig hingesehen habe:

sent 108.74G bytes  received 606.83K bytes  70.68M bytes/sec
total size is 143.42G  speedup is 1.32
42.172u 490.877s 25:57.50 34.2%    409+217k 2352260+856131io 2pf+0w

und da sind viele kleine Dateien enthalten.

Davon abgesehen habe ich für mich im Heimbereich SAS abgeschworen und einige Controller und wenigstens zwei Tandberg vor nicht allzu langer Zeit entsorgt. In Zeiten von SSD fallen für einen Desktop-User SATA-Geräte wohl kaum noch schwächer, aber deutlich billiger aus. Im Profi Bereich mag das noch anders sein.

 

[holm]

@Pit..es muss Dir nicht leid tun..Du bist halt nur voellig schief gewickelt. (Sorry, gerade qwerty keyboard). Baender sind nicht langsam, was denkst Du wohl warum meine LTO-5 ein Fiber Interface haben, weil es eine RS232 auch tut??
Das Raidz1 auf meinen 4 10k SAS Platten mit einem Ryzen 5 3600 und 32Gb RAM schaffen es nicht mal ansatzweise das Teil am streamen zu halten, was Du Dir dazu vorstellen kannst ist dabei eher irrelevant und mit Verlaub, es geht auch am Thema voellig vorbei. Schon im Zeitalter der etwas besseren 1/4" Streamer habe ich z.B. "/usr/ports/misc/team" benutzt um im RAM einen Umlaufpuffer aufzubauen der moeglichst das Band am streamen halten sollte, weil die Platten nicht die erforderliche Datenrate brachten. Freilich, Tapes haben keinen wahlfreien sondern sequentiellen Zugriff und sie wollen mit Daten beliefert und beim Lesen auch das die Daten abgeholt werden, aber langsam sind sie nicht. Das merkt man deutlich wenn man eine grosse Datei aufs Band schafft, ploetzlich laeuft das Ding durch, weil keine Zeit im Dateisystem vertroedelt wird, sondern weil die Daten kommen...
Ein LTO-5 benoetigt ohne Kompression 140MB/s, 280MB/s wenn sich der Kram gut komprimieren laesst, schaffe das erst mal ran..oder weg wenn Du schreibst und das nicht nur als Burst. Gigabit Ethernet ist da etwas knapp...

SSD? Mal vom booten und langen Compilerlaeufen abgesehen, was beschleunigen die Dinger an Deiner taeglichen Arbeit? Wohl eher Nichts. Ich habe geschrieben das hier eine 128GB SSD rumliegt die ich bereit bin als Tape-Cache zu nutzen wenn es die Moeglichkeit gibt, wie schnell die Schuessel bootet interessiert mich dagegen eher gar nicht. Ich boote den Rechner ueblicherweise nicht, sondern der laeuft.

Auch ich fuehre die Diskussion nicht zum ersten Mal aber auch nicht zum erstem Mal erfolgreich aus meiner Sicht, Du liegst einfach daneben.

Alte Streamer entsorgt man nicht! ..wenn dann auf Ebay..oder Kleinanzeigen.
Es ging mal durchs Netz das die Helden der Nasa es geschafft hatten die
Daten von irgend einer hornalten Sonde in klimatiserten Raeumen auf Baendern ueber Jahrzehnte zu lagern um dann feststellen zu muessen das am die Hardware um diese Baender zu lesen bereits vor langer Zeit entsorgt hatte... Die haben dann in der Community gebettelt das Ihnen Jemand die alten Baender liest. Ich habe dann von einer Restauration IMHO eines alten Ampex Laufwerkes zu diesem Zweck in einem Artikel gelesen.
Betreffs "in 80 Tagen um die Welt.." Du hast offensichtlich keine Idee von der ueblichen Groesse von Filesystemen auf einer VAX oder gar PDP11. Wahrscheinlich wuerdest Du nach hinten umklappen wenn Du es wuestest.


Gruss,
Holm

 

[bsd4me]

Hallo @holm, so ähnlich wie Du denke ich auch. Ich habe ein wenig Erfahrungen mit Tapes gemacht. Klaro sind sie nicht für "laufende" Systeme als Produktivspeicher gemacht, aber in einem Rechenzentrum der Uni sagte man vor ein paar Jahren, dass der Backup mit Tapes weniger Strom frisst als mit Platten. Ist doch ein positiver Punkt :-) Und was SSD's angeht, da stimme ich auch zu, denn, wenn ich nicht 100 mal am Tag boote, ist es mir relativ egal, ob ich 10 oder 3 Sekunden warte, bis der Rechner oben ist. Aber natürlich gibt es auch Punkte, an denen Bänder schlecht abschneiden und SSD Sinn machen. Die Frage ist eigentlich: brauchen wir immer schneller Hardware wirklich? Hand in Hand geht damit auch, dass die Software immer mehr aufgebläht wird. Ich erinnere mich an alte MS-DOS Zeiten (war noch geil!! :-)) und Word Perfekt. Alles wie im Terminal, aber man konnte tasächlich die "Tags" sehen wie "[Bold]Wichtig[/Bold]" und man konnte gezielt das "Bold" dann herausnehmen. Mach das mal in Word o.ä. - ich habe schon erlebt, dass bei einer solchen Aktion fast die komplette Formatierung in den "Arsch" ging... Mein Fazit ist - und ich denke @pit234a kann auch zustimmen :-) Lieber weniger machen, dafür aber sinnvoll und sauber. Dann muss man das Rad nicht immer wieder neu erfindnen ;-) Und lieber man in den Wald ohne Handy gehen, einfach echt da sein :-) Viele Grüße an Euch!! Norbert

 

[pit234a]

ich möchte nicht jeden Satz kopieren, zu dem ich etwas sagen möchte.
Bitte um Nachsicht: es ist nicht zum ersten Mal, dass ich mich irre. Aber, wer nicht fragt bleibt dumm und ich lerne gerne hinzu, auch, wenn dieses manchmal weh tut.

Was ich oben mal Ansatzweise zeigte war eine Sicherung, also ein Backup mit einem rsync von einem SATA Z-Mirror auf SSDs zu einem anderen SATA Z-Mirror auf SSDs. Ein inkrementelles zfs send wäre womöglich nochmal schneller gewesen.

Und das geht auf Bänder wirklich schneller?
Ich meine, meine SATA-LW sollten ja theoretisch bis 600.000MB/s liefern können. Reden wir nicht so über diese Theorie, denn viele kleine Dateien machen dem jedenfalls einen Strick durch die Rechnung, was aber immer gilt, auch für die Bänder. Wenn also mit vielen kleinen Dateien rsync von SATA zu SATA mir ca 70 Mbytes/sec meldet, halte ich das durchaus für gut, wobei auch das Schreiben sicher langsamer macht, als das Lesen.
Ob diese Werte mit HDs auf SATA oder SAS-Basis erreicht werden können?
Meine letzten SAS-HDs waren einen Faktor zehn langsamer, aber das ist ja auch schon einige Jahre her.
Und Bänder sind dann womöglich schneller im Schreiben, vielleicht sogar schneller als SSDs, aber wie du ja schon sagst: die Daten müssen ja auch erst irgendwo her kommen und ich sehe da SATA-SSD klar im Vorteil (und möchte nicht über SAS-SSD reden, weil die ohne entsprechenden Kontroller natürlich auch nicht liefern können und das wird dann gleich viel teurer).

Damit kurz zum Nutzen der SSDs: Bootzeiten habe ich keine (also nur bei den Laptops), mein FreeBSD-PC läuft immer und wie schnell der bootet ist mir egal.
Aber die SSDs sind leise und brauchen keine weitere Kühlung. Mit Schrecken denke ich an das Geratter der SAS-HDs und mit nicht weniger Entsetzen an die Geräusche der Band-LW.
Einen ganz anderen Nutzen haben diese SSDs (gegenüber langsameren HDs) tatsächlich bei Download-Geschwindigkeiten in schnellen Netzwerken. In etlichen Tests zeigte sich das bei mir, seit ich ein schnelles Internet habe. Nun gut, das ist natürlich ein Vorteil, der praktisch unwichtig ist. Wenn ich einen 4G-Film in 40 Sekunden downloade, ist das beeindruckend (für mich), aber ich brauche dann ja doch 90 Minuten, um den anzusehen. So what?
Es ist nur eben tatsächlich so, dass langsamere Medien auch bei diversen anderen Aufgaben als dem Booten durchaus verlangsamend wirken können und hier sehe ich eben gerade die tägliche Datensicherung im Umfang eines Desktop-Users und wenn ich sage, dass ich mir das kaum vorstellen kann, dass Bänder da schneller sind als SSDs, dann mag man mir mein mangelhaftes Vorstellungsvermögen verzeihen. Es rührt halt aus meiner Erfahrung, die einige Jahre her ist.

Da waren die Bänder nicht etliche TB groß und alleine die Vorbereitung zur Speicherung dauerte auf den damaligen PCs eine Weile (nämlich eine einzige Datei als tar-Archiv anlegen, die dann in einem Rutsch geschrieben werden konnte). Dann sollte das jede Nacht laufen und ich kann gar nicht sagen, wie oft das nicht gelaufen war, weil die Geräte aktiviert wurden und Sicherung und Arbeiten nun mal nicht zusammen gingen (keine IT-Rechner, also nicht in einem Rechenzentrum). Nach einigen erfolglosen Tagen waren die Bänder dann so oft hin und her gespult, dass sie nicht mehr funktionierten und dann gab es oft über Wochen und Monate keinen Backup, weil sich niemand um die Fehlermeldungen am nächsten Morgen kümmerte. Das Gerät funktionierte ja schließlich ohne Probleme.

Nun mag ich nicht den Eindruck erwecken, als sei ich nur modern und nur für SSDs und gegen HDs und Bänder. Ganz im Gegenteil. Dann hätte ich diese Dinge ja nicht selbst so lange gesammelt und immer wieder damit geliebäugelt.
Gesammelt habe ich die aus Rechnern, die verschrottet werden sollten und davon abgesehen, dass ich selbst keinen Ebay-Account habe, ist damit auch kein finanzielles Interesse verbunden, ja, im Gegenteil, ich musste die Verschrottung zusichern, wenn ich nicht selbst die Geräte für mich benutze. Gelegentlich gab es dann schon mal einen Bedarf im Freundeskreis und ich verschenkte dann solche Dinger, den Eigenbedarf stressfrei erweiternd.
Und so ist das dann nun mal, wenn meine bessere Hälfte mir den zugewiesenen Platz "für meinen Schrott" deutlich macht (und ich habe mehr, als nur IT-Schrott) und nicht gerade ein Bedarf vorliegt, dann muss ich halt verschrotten und von den Tandbergs habe ich mich recht leichten Herzens getrennt, weil ich eh einen leichten Horror vor deren Einsatz hatte.
Nicht, weil sie so langsam sind (also so langsam, wie ich mich zu erinnern glaube), sondern auch, weil sie umständlicher zu handhaben sind, als ein Backup direkt auf interne SATA-SSDs oder ins Netz. Der ist nämlich einfach da, direkt und vollständig. Und der läuft auch genauso direkt und ohne Spulen und Vorbereitung.

Und ja, weil ich so altmodisch und bequem bin, nutze ich noch meine alten Sicherungs-Routinen aus UFS-Zeiten und die funktionierten ja auch mit ZFS genauso. Aber ich sehe schon, dass ich endlich den Arsch hoch kriegen und voll auf zfs setzen sollte. Auch das war ein langsames Lernen, bis ich überhaupt so weit war, ZFS auf meinen PCs haben zu wollen.

Vielleicht überzeugt ihr mich nun für Bänder und ich telefoniere alle Kollegen ab, um mir noch welche zu sichern. Aber ich glaube nicht ernsthaft daran.

 

[CommanderZed]

Also privat sicher ich (inzwischen) einfach auf externe USB 3 Rost-Platten.

Beruflich sehe ich als den Kernvorteil für uns darin, das Bänder in einem Wechsler doch sehr gut vor überspannung, unterspannung etc zb geschützt sind, ganz anders als gerade aktiv laufende Platten. (+ Noch nen paar weitere Punkte aus dem Themengebiet)

Klar kann man auch mehrere Platten oder SSDs im wechsel nehmen, aber einen automatischen wechsler für platten kenn ich so ad-hoc jetzt nicht, also müsste man wieder zb jeden Tag drann denken vorbei zu latschen ... in ein anderes gebäude am anderen Ende des Geländes, da ist man schon mehr als 5 Minuten unterwegs, es soll ja möglichst außerhalb des gleichen Gebäudes sein wo die Hauptserver stehen

Die geschwindigkeit ist dann auch nicht sooo das große Thema: Nachts sichern sich alle Server per rsync die Daten auf die Rost-Platten des Backup-Server an den der Robby angeschlossen ist. Tagsüber schiebt der dann die Sicherung per tar von der Nacht auf das Band, fertig.

 

[Crest]

LTO8 schreibt min. 360MB/s und bei gut komprimierbaren Daten geht es auf fast 1000MB/s. Um das "langsame" Laufwerk beschäftigt zu halten brauchst du also entweder nen paar Platten im RAID oder eine gute NVMe SSDs als Spool.

 

[Azazyel]

Meine Frage ist nun was Ihr für eine sinnvolle Backup Strategie empfehlen könnt, ich wollte mir eigentlich Monster wie bacula zu diesem Zweck eher kneifen. Dump des Zpools mit ZFS send, oder lieber tar?

Kommt darauf an, ob du eine Komplettkopie des Dateisystems wirklich brauchst. Ich würde a priori tar bevorzugen, sichere selber aber auch nicht auf Band.

SSD? Mal vom booten und langen Compilerlaeufen abgesehen, was beschleunigen die Dinger an Deiner taeglichen Arbeit? Wohl eher Nichts.

Sobald der eigene PC mehr als nur ein glorifiziertes serielles Terminal ist, merkt man die Geschwindigkeitsvorteile einer SSD. Jeder Dateizugriff (inkl. Programmstarts) wird deutlich schneller.

Die Frage ist eigentlich: brauchen wir immer schneller Hardware wirklich?

Solange schnellere Hardware uns produktiver macht, brauchen wir sie. Wenn ich meine Software auf einer SSD in 1 statt auf einer HDD in 10 Minuten kompilieren und testen kann, gewinne ich enorm viel.

Hand in Hand geht damit auch, dass die Software immer mehr aufgebläht wird.

Hand in Hand geht damit auch, dass unsere Software mit gleichem Entwicklungsaufwand immer mehr kann und uns immer mehr Möglichkeiten bringt.

Alles wie im Terminal, aber man konnte tasächlich die "Tags" sehen wie "[Bold]Wichtig[/Bold]" und man konnte gezielt das "Bold" dann herausnehmen.

Geht das heute mit HTML, Markdown, AsciiDoc & Co. etwa nicht?

 

[holm]

@pit:
Die Bandgeräte sind ganz einfach nicht der limitierende Faktor. Du machst ein remote Backup von Deiner Maschine auf einen "Server", das würde ganz einfach nicht langsamer werden weil der Flschenhals hier das Filesystem und das Netzwerk sind, egal ob Du nun schreibst oder liest, Du hast also deswegen keinerlei Vorteile. Ich habe in der Vergangenheit Sowas auch schon mal gebastelt und zwar mit einer ausrangierten Tape Library die auf Videobänder (30min Tapes, viel dicker als die üblichen) sicherte, Laufwerke waren da Professionelle SCSI-II Tapes von Panasonic, halt mit helical Scan Verfahren..und bei diesem Verfahren gehören Fehler zum System, automatisches Read after write hat Dir bekannt gegeben ob Du den Block noch einmal schreiben solltest..
Die Sciherung wurde von den Clienten in 64kbyte Blöcken auf eine Spool Disk geschrieben und von dort auf die Bände. Ich habe momentan vergessen wie das damalige Backup System das ich mir gegriffen hatte hieß..
Irgendwo treibt sich auch noch eine alte Library herum mit einem DLT-IV LW drin, in die Ecke gestellt weil die Kapazitäten hinten und vorne nicht mehr reichten, ich denke aber nicht das ich das LW ersetzen kann. Die LTO Laufwerke zeigen Dir auf dem Bus auch ein Changer Device und sind in ihrer Kassette außer mit Fiber auch noch mit mehreren kleinen Kabeln mit einer Steuerelektronik verbunden die da im Falle Changer irgendwelche Aktionen auslöst..ich bekomme keine Unterlagen zu den LTO-5 von IBM die das irgendwie dokumentieren..

Eine Festplatte, die wie von Dir beschrieben "einfach da ist", will inder Zeit auch mit Strom versorgt werden und altert entsprechend, Ein Band das nach der Aufzeichnung aus dem Speicher entfernt wird, hat diesen Nachteil nicht und man bekommt davon auch etliche im Ernstfall in ein Bankschließfach.
Die Windowsfraktion ist ja auch immer ganz stolz das sie irgend einen Kryptovirus nicht nur auf der Rechnerplatte haben, sondern auch übers Netzwerk auch gleich mit auf den sichernden Servern..feine Sache das.

SSDs oder spinning rust? Ich bin Elektroniker und ich weiß wie ein Eprom funktioniert, schon dessen Funktion ist mehr oder weniger "Haarsträubend". Das die Dinger mittlerweile recht lange Daten halten ist ne feine Sache. Flash Disks sind im Prinzip das Selbe nur wird da in einer Zelle nicht nur ein Bit gespeichert, sondern wohl bis 16 unterschiedliche Spannungslevel die dann den Bits zugeordnet werden. Mir stehen da wirklich die Haare zu Berge wenn ich darüber nachdenke "Wie sicher" das eigentlich ist (Ladungsverlust, alpha Teilchen). Ich glaube in der Anzahl der defekten Platten und irgendwie gearteten Flashdisks die "kaputt" gegangen und mir über den Weg gelaufen sind unterscheiden sich die Technologieen nicht, wobei es den rotierrenden Rost deutlich länger gibt. Ok, mann kann ja Raid Arrays bauen, dann bleibts eine Frage von Bang for the Buck. Da möge Jeder nach seiner Fasson glücklich werden. Es ist ja auch nicht wirklich so das man Bandgeräte entsprechender Kapazität und Qualität auf dem Consumer Markt nachgeworfen bekommen würde, das Zeug kostet deutlich mehr Geld als eine Platte, die kann aber auch nur Ihre einfache Kapazität sichern, ein Bandgerät ein Vielfaches, nur der Zugriff ist halt nicht wahlfrei.

@Commander Zed:

Ich bin hier nicht nur Hobby, ich bin eine Einmannfirma so das die Wahrheit bei mir irgendwo "dazwischen" liegt. Zur Sicherungszeit..wir haben ein erwachsenes Multitaskingsystem als OS, man kann also im Zweifelsfalle problemlos arbeiten. Das der Kram möglichst Nachts aufs Band geschafft wird, versteht sich wohl meist von selbst. Die benötigte Zeit ist hier nicht wirklich ein Faktor.

@ Azazyel:
Natürlich hätte ich schon gerne periodische Komplettabzüge und alle paar Tage differentielle Backups dazu. Gerade dabei war die Funktionalität von dump/restore eine feine Sache, eben wegen der Level und der damit ausgeklügelt verfügbaren Strategieen. ZFS send kann Full Backup und differentielle Backups zwischen den Snapshots, nicht ganz das Gelbe vom Ei aber immerhin. Tar ist wie der Name schon sagt ein "Tape Archiver", aber der schafft Dir prinzipbedingt keine differentiellen Backups aufs Band.

Glorifiziertes serielles Terminal? Da ist bei mir teilweise tatsächlich so, da ich X11 sehr oft als Terminalmultiplexer benutze wenn ich z.B. Programmentwicklung für Mikrocontroller betreibe. Alernativ kann man die Maus totrödeln in irgendwelchen fettgefressenen Entwicklungsumgebungen, effizienter wird man damit allerdings nicht. Ich komme mit Vi, Make und Konsorten relativ gut klar und muß auch keine anders bunte Variante verwenden wenn ich mit einem ARM, einem MSP430 oder einem RISC IV zu tun habe. Your maileage may vary.

Performance: "Solange schnellere Hardware uns produktiver macht, brauchen wir sie. Wenn ich meine Software auf einer SSD in 1 statt auf einer HDD in 10 Minuten kompilieren und testen kann, gewinne ich enorm viel."
Ja, wenn Du das kannst mag das sein, der Faktor 10 wird da aber nie erreicht. Ich habe auch nicht 1 SSD und 1 HDD sondern 4+2 HDDs.
Möglicherweise ist mein "neuer " Rechner um den Faktor 10 schneller als der alte, (Core2QUAD mit 2,2Ghz und 8GB vs. Ryzen 5 mit 3,6GHz und 32GB RAM)
beide benutzen aber HDDs. Da ist also offensichtlich nicht der limitierende Faktor und das ist es seit ufs mit Softupdates nicht mehr. (Danke Marshall Kirk McKusick)

Einen Brief an die Oma kann man übrigens mit Wordstar 3 genauso effizeint schreiben wie mit Office365...

Gruß,
Holm

 

[holm]

Ok, keine Edit mehr...ich habe mal gegoogelt, das System das ich Anfang der 2000er benutzt habe hieß Amanda "AMANDA is an acronym for Advanced Maryland Automatic Network Disk Archiver."

Gruß,
Holm

 

[pit234a]

Lasst mich mal OT anfangen, wie man das von mir kennt, aber die Nostalgie hat mich irgendwo ins Herz getroffen:
auch ich bin von Haus aus Elektroniker und habe mal gelernt, oder zumindest gehört, wie ein E-Prom funktioniert und dann E²-Prom und so weiter und ich erinnere mich noch gut an die ersten Flash-Proms und mit welcher Angst ich denen gegenüber stand und immer versuchte, einen Ersatz dabei zu haben, wenn ich die bei Kunden neu flashen musste. Oh mein Gott, wie waren die Dinger so wackelig!
Aus dieser nostalgischen Erfahrung leite ich aber nicht ab, dass ich sämtliche Entwicklungen bis heute ähnlich betrachten sollte.
Logischerweise ist man mit einem solchen Hintergrund etwas, lasst es mich mal RETRO nennen.
Es gibt kaum eine Neuerung, die ich vorbehaltlos bejubele und auch sofort für mich haben möchte. Da bin ich eher abwartend und vorsichtig und sage mir selbst immer: brauche ich doch nicht, bei mir geht ja auch alles noch ohne dieses NEUE.

Aber SSD's haben mich praktisch überzeugt, wie SATA eben auch.
Ich möchte nicht SSDs in meinem Fileserver haben, aber das ist auch alleine schon eine Frage des Preises.
Ich mochte nie IDE und natürlich auch nicht SATA und hielt lange Zeit an meinen SCSI und SAS HDs fest. Aber irgendwann wurde mir der Spaß deutlich zu teuer und schließlich verdiene ich nicht meinen Lebensunterhalt mit IT und so wagte ich mich Schritt für Schritt an SATA und SSD und zwar auch, nachdem ich zuvor schon zögerlich den Schritt nach ZFS vollzogen hatte. Das ist nun meine unmaßgebliche, persönliche Erfahrung, aber ZFS on SSD scheint mir eine wirklich gute Nummer.
So richtig nachdenklich wurde ich aber, als in den Produkten meiner Firma, die sehr auf Qualität bedacht ist, immer mehr die HDs durch SSDs verdrängt wurden. Ja, SAS-SSDs, die ich sonst nirgendwo bisher im Einsatz gesehen habe.
Ohne Erlaubnis hatte ich bei zwei Problem-PCs eigenmächtig die zu kleinen SAS-HDs gegen größere SSDs ausgetauscht und schon beim Überspielen des Systems (ich machte das auch nicht nach Vorschrift, sondern bootete ein Knoppix, ein GNU/Linux-Live-System) war ich sehr angenehm überrascht, wie schnell das von Statten ging. Die Kundenresonanz anschließend war großartig und das hielt auch mehrere Jahre, bis die PCs dann eben abgebaut wurden.
Ich denke, dass dies mein erster Schritt in Richtung SSD war und das begab sich bereits zu einer Zeit, als ich gerade mit einem kleinen Asus EEE PC spielte und dann darin meine erste SSD einbaute. Hatte die 32GB? Vielleicht.
Genau das war eigentlich meine erste Intention: auf unwichtigen Laptopts Strom sparen und HDs durch SSDs ersetzen. Dass diese Dinger dann auch noch deutlich schneller waren, nur ein kleiner Nebeneffekt.
Jedenfalls hatte ich in all den Jahren noch nie ein Problem mit einer SSD, aber sehr viele Probleme mit HDs (von denen ich natürlich auch sehr viel mehr im Einsatz hatte). Die neueren HDs, die ich heute benutze, scheinen auch unvergleichbar robust und gut gegenüber früher. Aber meine anfänglichen Bedenken gegenüber SSDs haben sich vollkommen verloren. Und zwar, mal realistisch betrachtet: wenn man einen Desktop benutzt, werden alle benutzten Anwendungen immer größer. Ich denke, dass der PC an dem ich nun arbeite von mehreren SAS-HDs mit 136GB(?) auf SATA-SSDs mit 64GB und dann 128GB, 256GB, 512GB und heute benutze ich 1TB SSDs aufgerüstet wurde. Irgendwann wurde auch mal das Mainboard erneuert usw. (Das erinnert mich gerade an Len Fisher und "Reise zum Mittelpunkt des Frühstückseis", das ich neulich erst gelesen habe. Er erzählt von seinem Vater, einem Zimmermann, der in seinem ganzen Leben nur einen Hammer benutzt hatte. Lediglich der Stil wurde mehrfach und der Kopf dann auch einige Male ersetzt).
Jedenfalls müssen doch heute unsere PCs mit wachsen (wenn man nicht gerade in ganz speziellen Bereichen unter Wegs ist und ein Nischendasein fristen kann) und dann ist doch ein sukzessiver Austausch der HW eh notwendig und hier allen voran die Speichermedien. Ich erwarte nicht von meinen SSDs, dass die in zehn Jahren noch immer in meinem PC stecken.
Aber, oder vielleicht gerade deshalb, gebe ich nicht mehr das Geld für SAS-HW aus und nehme die billigere SATA-HW, die sich mir in der Praxis aber als schnell und zuverlässig genug bewiesen hat.

wie auch immer: vielen Dank an @holm für die gute Erklärung, die mich mal wieder nachdenklich macht. Für das gelegentliche, zusätzliche Backup könnten solche Bänder auch für mich einen gewissen Reiz haben, unabhängig von Geschwindigkeiten und so.
Vielleicht nur zum Abrunden:
Wenn du eine Strategie für dich gefunden hast, könntest du dann vielleicht mal echte Geschwindigkeiten hier einstellen?
Wie gesagt, mit theoretischen Werten habe ich es nicht so, aber ganz praktisch mal sehen, wie lange ein Backup dauert, bzw wie groß der Aufwand insgesamt ist, würde mich schon interessieren.

 

[Azazyel]

Tar ist wie der Name schon sagt ein "Tape Archiver", aber der schafft Dir prinzipbedingt keine differentiellen Backups aufs Band.

Ich hatte es tatsächlich falsch in Erinnerung, im Gegensatz zu GNU tar kann BSD tar nur komplette Backups.

Alternativ kann man die Maus totrödeln in irgendwelchen fettgefressenen Entwicklungsumgebungen, effizienter wird man damit allerdings nicht. Ich komme mit Vi, Make und Konsorten relativ gut klar und muß auch keine anders bunte Variante verwenden wenn ich mit einem ARM, einem MSP430 oder einem RISC IV zu tun habe. Your mileage may vary.

Seit wann brauchst du bei einer modernen IDE eine Maus?

Wie hast du bei dir im vi die fortlaufende statische Code-Analyse eingebunden, die schon beim Tippen deinen Code auf vermeidbare Fehler überprüft und dich unmittelbar darauf hinweist?

Ja, wenn Du das kannst mag das sein, der Faktor 10 wird da aber nie erreicht. Ich habe auch nicht 1 SSD und 1 HDD sondern 4+2 HDDs.

Mehr als 100.000 IOPS gegen weniger als 1.000 IOPS. Ich habe es gerade mal mit einem Kundenprojekt getestet, SSD 2m19s vs. 4 HDDs im RAID10 17m43s (d.h. nur Faktor 7-8).

Warum sollte ich pro Build eine Viertelstunde länger auf die lahmen HDDs warten, wenn sich die SSD an einem Vormittag amortisiert?

 

[holm]

Wie hast du bei dir im vi die fortlaufende statische Code-Analyse eingebunden, die schon beim Tippen deinen Code auf vermeidbare Fehler überprüft und dich unmittelbar darauf hinweist?

Gar nicht, der Syntaxcheck im vim reicht mir.

Mehr als 100.000 IOPS gegen weniger als 1.000 IOPS. Ich habe es gerade mal mit einem Kundenprojekt getestet, SSD 2m19s vs. 4 HDDs im RAID10 17m43s (d.h. nur Faktor 7-8).

Warum sollte ich pro Build eine Viertelstunde länger auf die lahmen HDDs warten, wenn sich die SSD an einem Vormittag amortisiert?

Ich mache Software für Mikrocontroller in irgendwelchen kleinen "Kästchen", irgendwelche Steuerungen die ein Kunde halt gerne hätte.
Die Compilerläufe dafür liegen in der Größenordnung weniger Sekunden, da ist eher meine Rübe der limitierende Faktor, das Problem ist also mehr oder weniger gar nicht existent. Wenn was lange dauert ist das der Bau irgenwelchen Krams auf dem BSD selber, aber selbst da ist man ja in der Zwischenzeit so weit das man nicht vor der Kiste warten muß, sondern sich zwischenzeitlich um Kaffeenachschub kümmert..mal ganz davon abgesehen das SSD vs HDD an meinem eigentlichen Problem absolut gar Nichts ändert.

Gruß,
Holm

 

[Yamagi]

Wenn was lange dauert ist das der Bau irgenwelchen Krams auf dem BSD selber, aber selbst da ist man ja in der Zwischenzeit so weit das man nicht vor der Kiste warten muß, sondern sich zwischenzeitlich um Kaffeenachschub kümmert..mal ganz davon abgesehen das SSD vs HDD an meinem eigentlichen Problem absolut gar Nichts ändert.

Und das wir hier weit im Offtopic-Land sind. Um nochmal zur ursprünglichen Frage zurückzukommen: Die per zfs send erzeugten Streams sind linear. Sie lassen sich über eine Pipe auf Tapes schreiben. Es ist schon etwas her, dass ich das machen musste, aber das Prinzip ist ein einfaches zfs send | tar. Eventuell noch mit einer Kompression wie zstd dazwischen, wenn man die nicht an LTO auslagern will. Zurück geht es dann umgekehrt mit tar | zfs receive.

Etwas problematisch sind Deltas. Zwar sind auch inkrementelle Streams, die per zfs send -i erzeugt werden, linear und lassen sich auf Tape schreiben. Zum Wiederherstellen muss man sie dann in der richtigen Reihenfolge per tar | zfs receive zurückspielen. Allerdings geht ZFS irgendwo davon aus, dass inkrementelle Streams sofort eingespielt haben. Daher ist dort kein Raum für Fehler. Wenn nur ein einziges Bit in einem Stream gekippt ist, lassen sich alle nachfolgenden Daten nicht mehr einspielen.

Um nochmal einen anderen Denkansatz geben, wäre es vielleicht zu überlegen auf Tape zu verzichten und stattdessen ein inkrementelles Backupprogramm wie Restic oder Borg (ich tendiere nach wie vor dazu, dass Borg reifer ist, aber das mag man anders sehen) mit einem Online-Storageservice zu kombinieren. Gehen wir mal davon aus, dass du knapp 200 GB Daten hast. Mit Deltas über ein Jahr 400 GB. Wären bei Backblaze Pi mal Daumen $40 pro Jahr. Damit ist dann auch gleich das Thema Offsite-Backup erschagen. Ist nur die Frage, ob der Internetanschluss tief in Merkels Gigabitrepublik es hergibt.

 

[Azazyel]

Gar nicht, der Syntaxcheck im vim reicht mir.

Jedem das Seine. Ich nehme die höheren Hardware-Anforderungen einer "fetten" Entwicklungsumgebung samt zugehöriger Tools zugunster höherer Softwarequalität gerne in Kauf.

Die Compilerläufe dafür liegen in der Größenordnung weniger Sekunden, da ist eher meine Rübe der limitierende Faktor, das Problem ist also mehr oder weniger gar nicht existent.

Bei trivialen Anforderungen fallen die Vorteile einer SSD natürlich nicht wesentlich ins Gewicht.

Mal ganz davon abgesehen das SSD vs HDD an meinem eigentlichen Problem absolut gar Nichts ändert.

Eine Möglichkeit unter Berücksichtigung der 3-2-1-Regel wäre disk to disk, disk to tape.

Das erste Backup geht auf HDD. Persönlich kann ich restic dafür wärmstens empfehlen.

Von dort aus kannst du problemlos auf Tape sichern. Damit umgehst du auch das Problem, dass HDDs gerade unter Last bei vielen kleinen Dateien nicht schnell genug Daten liefern können, um das Tape kontinuierlich zu beschreiben. Die Tapes kannst du dann regelmäßig als Offsite-Backup verstauen.

Bei den angesprochenen Datenmengen würde ich als dritten Speicherort auf einen entfernten S3-Storage übers Internet sichern (z.B. auch wieder via restic), als Ein-Mann-Firma sind die Kosten völlig vernachlässigbar.

 

[Yamagi]

Das erste Backup geht auf HDD. Persönlich kann ich restic dafür wärmstens empfehlen.

Wenn es eine SMR HDD ist, sollte man Restic tunlichst mit https://github.com/restic/restic/pull/2750 patchen und eine --min-packsize von mindestens 128, besser gleich 256 Megabyte setzen. Das führt zu etwas mehr Overhead, aber der Geschwindigkeitsgewinn gegenüber der Standardpacksize von nur 4 Megabyte beträgt schnell mal Faktor 10. Bei PMR HDDs und SSDs sowieso ist das nicht notwendig, da sie keine (so gravierende) Write Amplification auf oft 128 MB Spuren haben.

 

[holm]

Und das wir hier weit im Offtopic-Land sind. Um nochmal zur ursprünglichen Frage zurückzukommen: Die per zfs send erzeugten Streams sind linear. Sie lassen sich über eine Pipe auf Tapes schreiben. Es ist schon etwas her, dass ich das machen musste, aber das Prinzip ist ein einfaches zfs send | tar. Eventuell noch mit einer Kompression wie zstd dazwischen, wenn man die nicht an LTO auslagern will. Zurück geht es dann umgekehrt mit tar | zfs receive.

..und welche Funktion erfüllt hier eigentlich tar außer das die Daten zusätzlich in ein tar Archiv gekapselt werden? Das währe bei linearen Daten etwa genauso sinnvol wie ein UFS Dump mit nachfolgendem Tar...

Etwas problematisch sind Deltas. Zwar sind auch inkrementelle Streams, die per zfs send -i erzeugt werden, linear und lassen sich auf Tape schreiben. Zum Wiederherstellen muss man sie dann in der richtigen Reihenfolge per tar | zfs receive zurückspielen. Allerdings geht ZFS irgendwo davon aus, dass inkrementelle Streams sofort eingespielt haben. Daher ist dort kein Raum für Fehler. Wenn nur ein einziges Bit in einem Stream gekippt ist, lassen sich alle nachfolgenden Daten nicht mehr einspielen.

Ich habe ja nicht umsonst nach einer Strategie gefragt, also auch nach einem benuztzbaren Backup System für diesen Zweck das mich evtl. der Buchführung darüber welches Tape und welche Datei jetzt zurückzuspielen wäre enthebt.
Sind bei Dir Tape Laufwerke dafür bekannt Bits kippen zu lassen? Bei mir nicht, SSDs aber schon.

Mit "Allerdings geht ZFS irgendwo davon aus, dass inkrementelle Streams sofort eingespielt haben." kann ich irnkwie semantisch nix anfangen.

Um nochmal einen anderen Denkansatz geben, wäre es vielleicht zu überlegen auf Tape zu verzichten und stattdessen ein inkrementelles Backupprogramm wie Restic oder Borg (ich tendiere nach wie vor dazu, dass Borg reifer ist, aber das mag man anders sehen) mit einem Online-Storageservice zu kombinieren. Gehen wir mal davon aus, dass du knapp 200 GB Daten hast. Mit Deltas über ein Jahr 400 GB. Wären bei Backblaze Pi mal Daumen $40 pro Jahr. Damit ist dann auch gleich das Thema Offsite-Backup erschagen. Ist nur die Frage, ob der Internetanschluss tief in Merkels Gigabitrepublik es hergibt.

FTTH gibts ab ca. März nächsten Jahres (leerrohr liegt im Keller), bis dahin müssen es 30Mbits/s DSL tun, die Uploadgeschwindigkeit hab ich vergessen, wird aber nicht gerade eine Wurschtpelle vom Teller ziehen.
Auf Remotebackup würde ich gerne verzichten, nicht wegen der Kosten, aber es sind auch schon ganze Rechenzentren abgebrannt. Ich habe 2 Rootserver bei Hetzner, Platz wäre nicht das Problem und Kosten auch nicht.

Gruß,
Holm

 

[medV2]

Da gibts noch viel billigere Onlinespeicher wie Amazon Glacier. Da bist bei 0.5 USD für 500GB im Monat. Dazu kommt noch etwas für Traffic (vernachlässigbar beim Upload) und etwas fürs abrufen (das kostet ca. 1-2 Monatsgebühren). Aber das Backup muss man ja im Idealfall eh nicht abrufen. Sowas wie Borg funktioniert da leider nicht, da man Zugriff nur über eine API hat. Aber sowas wie zpaq klappt sehr gut. Aber man kann natürlich auch die zfs streams hochladen. Überprüfen lässt sich der Upload per Checksum.

 

[Yamagi]

..und welche Funktion erfüllt hier eigentlich tar außer das die Daten zusätzlich in ein tar Archiv gekapselt werden

Das Tape zu schreiben. Ich weiß, man kann bei vielen Bandlaufwerken auch per dd oder noch schlimmer cat gleich auf das rohe Device jagen. Aber mit tar ist immerhin etwas Logik dazwischen. Ein schöner Header, die Möglichkeit zu sehen was auf dem Tape gespeichert wurde, automatisches Padding auf den nächsten vollen Block und solche Sachen.

Sind bei Dir Tape Laufwerke dafür bekannt Bits kippen zu lassen? Bei mir nicht, SSDs aber schon.

Nein, das nicht. Vernünftige, aktuelle SSDs aber auch nicht mehr. Nur muss man halt immer davon ausgehen, dass doch irgendwann mal das Unwahrscheinliche passiert. Wenn man etliche inkrementelle Backups hat und schon das zweite Tape hat einen Lesefehler, ist halt kacke.

FTTH gibts ab ca. März nächsten Jahres (leerrohr liegt im Keller), bis dahin müssen es 30Mbits/s DSL tun, die Uploadgeschwindigkeit hab ich vergessen, wird aber nicht gerade eine Wurschtpelle vom Teller ziehen.

Ich bin neidisch auf meine Eltern. Wirklich absolut ländlich und dank staatlich gefördertem Ausbau seit einigen Monaten dank FTTH mehr Upstream als ich mitten in Hamburg an Downstream habe.

 

[holm]

Das Tape zu schreiben. Ich weiß, man kann bei vielen Bandlaufwerken auch per dd oder noch schlimmer cat gleich auf das rohe Device jagen. Aber mit tar ist immerhin etwas Logik dazwischen. Ein schöner Header, die Möglichkeit zu sehen was auf dem Tape gespeichert wurde, automatisches Padding auf den nächsten vollen Block und solche Sachen.

Das bedeutet das Du Dich fuer den Inhalt eines ZFS send Datenstromes interessierst, das ist mir zumindest bei dump bisher nicht passiert. Was da wirklich bei zfs send kommt muss ich mir mal ansehen, bis jetzt haette ich bezweifelt das das was fuer Menschenaugen sinnvoll Erfassbares ist.

Nein, das nicht. Vernünftige, aktuelle SSDs aber auch nicht mehr. Nur muss man halt immer davon ausgehen, dass doch irgendwann mal das Unwahrscheinliche passiert. Wenn man etliche inkrementelle Backups hat und schon das zweite Tape hat einen Lesefehler, ist halt kacke.

Naja..Du setzt hier fuer SSDs einen Grad an "Erwachsenheit" vorraus, den Du gleichzeitig den Ultrium Drives absprichst.
Wenn meine Erfahrungen nicht exakt gegensaetzlicher Natur waehren, wuerde ich das evtl. kaufen.

Ich bin neidisch auf meine Eltern. Wirklich absolut ländlich und dank staatlich gefördertem Ausbau seit einigen Monaten dank FTTH mehr Upstream als ich mitten in Hamburg an Downstream habe.

Das ist hier ein Erzgebirgsnest "Oederan" zwischen Chemnitz und meiner Heimatstadt Freiberg (gegenwaertig die tollsten Sachsen die es gibt! Die paar Hanseln kommen noch vor den 10000 Hamburgern (die ich ausdruecklich lieb gruesse)) mit 8000 Einwohnern.
Hier hat die Stadt die Initiative ergriffen und macht den Ausbau, Telekom,Vodafone etc. duerfen sich dann einmieten..

BTW: Es gibt Dinge die sind deutlich wichtiger als die Dicke des Netzwerkkabels, das bekommst Du spaeter sicher noch raus wenn Du mal erwachsen bist :-) (nicht persoenlich nehmen)

Gruss,

Holm