Speichermedium: ich bin es endgültig Leid....

picknicker1971 schrieb:
Nein, iCloud,.
Und ich schlafe trotzdem ruhig.
Z.B. die Rechnung meiner KFZ Versicherung oder Vertragsunterlagen würde ich auch auf Bitten der NSA, Mossad oder sonst wem zur Verfügung stellen.
Möchtest Du eine Kopie?
Zum Vergrößern anklicken....

Ach na dann.. :hamma:
 
Witzige Geschichte: gerade ist meine Seagate über den Jordan gegangen - und die war wirklich nicht alt. Zudem wurde sie nur als Sicherungskopie für RAW Files hin und wieder angeworfen...
 
DrHook schrieb:
Witzige Geschichte: gerade ist meine Seagate über den Jordan gegangen - und die war wirklich nicht alt. Zudem wurde sie nur als Sicherungskopie für RAW Files hin und wieder angeworfen...
Zum Vergrößern anklicken....
Festplatten gehen eher anfangs kaputt oder nach einigen Jahren. Deine hat vielleicht einen anfänglichen Defekt gehabt, der sich wegen der geringen Betriebsdauer erst später gezeigt hat. HDDs sind filigran und tw. habe ich die auch schon so schlecht verpackt zugeschickt bekommen, dass ein anfänglicher Defekt garantiert war. Über defekte Platten sollte man sich daher nicht wundern, die Frage ist nicht ob es passiert, sondern wann.

Eine brandneue SSD wurde mir auch innerhalb von sechs Monaten zu Schweizer Käse, du konntest am Ende über die ganze SSD eine handvoll Sektoren mit ddrescue lesen - trotz Markenware mit 5 Jahren Garantie.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ja, die poltern vom Amazon Zentrallager bis zur Haustür in zu großen Kartons schon ziemlich hin und her. Ich gehe mehr und mehr dazu über, Computerteile bei anderen Händlern (Alternate, Mindfactory etc.) zu bestellen. Ich meine, die verpacken sorgfältiger.
 
DrHook schrieb:
die poltern vom Amazon Zentrallager bis zur Haustür in zu großen Kartons schon ziemlich hin und her.
Zum Vergrößern anklicken....
Von denen musst gar nicht anfangen - die haben mir eine Bestellung von 16x14TB in einem 10KG schweren Paket komplett ohne Polsterung geschickt. Der Karton hatte schon Risse, weil die schweren Platten herumgestürzt sind im Karton. Warenwert von mehreren tausenden Euros komplett zerstört. Hat ein Monat gedauert bis ich das Geld wieder hatte, da ging es mit der Erstattung nicht so schnell wie gewöhnlich. Allein schon 10+ Platten in den gleichen Karton zu packen ist grob fahrlässig. Mehr als 6-8 Platten pro Versandkarton geht eigentlich nicht - sorgsam verpackt ist der schon riesig.
 
Ein Hinweis für die 2,5“ Platten, die über USB mit Strom versorgt werden: hier reicht ein passiver Hub nicht immer aus. Die Platten werden Teil unwillkürlich nach einer Weile ausgeworfen, oder sie beginnen ganz leise zu klackern, was verdächtig nach Headcrash klingt. Ich hatte es auch schon, dass mit dem Beginn des Klackens die Lese- oder Schreibaktivitäten eingestellt werden, was dann noch mehr auf Headcrash hinweist. An einem aktiven Hub, also mit eigener Stromversorgung, laufen sie dann wieder wie gewohnt.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich sichere meine Daten auf einem ZFS-Storage mit zfs-auto-snapshot. Das ist nicht einfach einzurichten, aber genial.
 
DrHook schrieb:
was dann noch mehr auf Headcrash hinweist.
Zum Vergrößern anklicken....
Den hast aber nur einmal, dann ist die Platte Toast. Das Klacken bedeutet, dass der Arm in die Sicherungsposition zurückschnalzt, eben wenn der Strom weg ist machen HDDs das automatisch (damit der Arm nicht auf die Platter knallt...).

Birma schrieb:
Ich sichere meine Daten auf einem ZFS-Storage mit zfs-auto-snapshot. Das ist nicht einfach einzurichten, aber genial.
Zum Vergrößern anklicken....
So mache ich es auch - dafür brauchst halt einen x86-Server, in anderen Worten, ein kleiner Raspberry Pie im Wohnwagen reicht nicht aus. Das resumable zfs send sorgt dann für die verschlüsselte offsite-Verteilung an einen zentralen Server im RZ, der mit Gbit-Leitung an zwei weitere Standorte verteilt, bei denen ich Hardware angemietet habe. Wobei am Ende leider das Risiko bleibt, dass ein Fehler in ZFS selbst für Datenverlust sorgt. Soviel Kohle hab ich nicht um hier nochmal alles alternativ zu sichern, das sind wegen 4K-Videos einfach zuviele Daten.
 
OmarDLittle schrieb:
So mache ich es auch - dafür brauchst halt einen x86-Server, in anderen Worten, ein kleiner Raspberry Pie im Wohnwagen reicht nicht aus. Das resumable zfs send sorgt dann für die verschlüsselte offsite-Verteilung an einen zentralen Server im RZ, der mit Gbit-Leitung an zwei weitere Standorte verteilt, bei denen ich Hardware angemietet habe. Wobei am Ende leider das Risiko bleibt, dass ein Fehler in ZFS selbst für Datenverlust sorgt. Soviel Kohle hab ich nicht um hier nochmal alles alternativ zu sichern, das sind wegen 4K-Videos einfach zuviele Daten.
Zum Vergrößern anklicken....
Ein Raspi 4 reicht. Schau mal hier:
 
...alles schön und gut mit dem Raspi - aber am Ende des Tages bin ich doch wieder beim Bewährten gelandet. Gefühlt habe ich in den letzten Monaten meine Serverhardware öfter gewechselt als als die Unterwäsche: :hehehe:

Standard-PC -> Synology 1 -> ZFS-Server 1 -> Synology 2 -> ZFS-Server 2 -> Raspi 4 -> Mini-ITX Standard-PC

Das Ziel bei all' diesen Versuchen war, die Kiste so leise und so sparsam wie möglich zu halten, denn die meiste Zeit des Tages tut so ein Server bei mir üblicherweise nichts: Er holt sich nachts die Backups von externen Servern, dient als persönlicher Fileserver, als Pi-Hole und als Plex-Server und das wars. Dafür reicht auch ein Raspi mit nur einer Platte dran - das geht prima, ich habs probiert.

Aber:

Sorry, ich will meine Platten am Raspi nicht dauerhaft über USB betreiben. Was hilft mir das sicherste Dateisystem, wenn alle Daten über einen zusätzlichen, prinzipiell überflüssigen (!), mit wackligen USB-Kableln an Festplatten-Dockingstationen zweifelhafter Qualität im Dauerbetrieb angeschlossen sind? Alles Mist, obwohl das sonst eigentlich die perfekte Plattform wäre...

Dann die ZFS-Server: Alles schön und gut, resilient ohne Ende, aber - wenn man es richtig machen will - enorm hardwarehungrig: ECC-Speicher sollte es schon sein und davon nicht zu knapp. Viel schlimmer: ZFS ist unter Linux lizenzbedingt nur ein 'angeflanschtes' Dateisystem, will man es "vollintegriert" braucht man einen BSD-Unterbau, z.B. mit FreeNAS. Das wiederum ist im Grunde eine eigene Distribution, die sich nur mit Risiken selbst anpassen lässt. Ebenfalls unangenehm: Backups auf USB-Platten sind nicht vorgesehen und Recovery von Backupmedien läuft nur über das Klonen von Snapshots.

Nach dieser ganzen Odysee bin ich (wieder) bei der Brot-und-Butter-Lösung gelandet: Ein grundsolides Debian auf einfacher, standardisierter und sparsamer PC-Hardware. Da dran hängen zwei grosse, sparsam langsam drehende Seagate Ironwolfs im Raid1-Verbund, den ich per LVM beliebig in logische Volumes unterteilen und erweitern kann. Dort ein ext4-Dateisystem drauf, fertig. Backups dann wie gewohnt per versionierendem rsync-Skript, simple as that.
Ich brauch' keine fertig-NAS oder NAS-Distributionen mit ihren jeweiligen Ideosynkrasien und überteuerter Hardware, die paar Dienste die ich brauche lassen sich auf jedem Linux einfach aufsetzen, gute Doku findet sich massenhaft im Netz. Was als Dienst nicht direkt im Serverbetriebssystem laufen soll läuft in Docker, so ließ sich z.B. auch Plex und Pi-Hole in kürzester Zeit zwischen den unterschiedlichen Plattformen migrieren und direkt weiterbetreiben.

Man kann die Vorteile von Standardkomponenten mit OpenSource-Standardsoftware und massig verfügbarer Dokumention gar nicht unterschätzen. Das am Anfang höhere Einarbeitungsaufwand lohnt sich später um so mehr. Interessant, wie sich Kreise irgendwann wieder schliessen... :teeth:
 
Zuletzt bearbeitet:
bowman schrieb:
wenn man es richtig machen will - enorm hardwarehungrig: ECC-Speicher sollte es schon sein und davon nicht zu knapp. Viel schlimmer: ZFS ist unter Linux lizenzbedingt nur ein 'angeflanschtes' Dateisystem, will man es "vollintegriert" braucht man einen BSD-Unterbau, z.B. mit FreeNAS. Das wiederum ist im Grunde eine eigene Distribution, die sich nur mit Risiken selbst anpassen lässt. Ebenfalls unangenehm: Backups auf USB-Platten sind nicht vorgesehen und Recovery von Backupmedien läuft nur über das Klonen von Snapshots.
Zum Vergrößern anklicken....
Dass ZFS soviel RAM bräuchte wird oft behauptet, tatsächlich bist du mit 8GiB bis 16GiB schon gut dabei. ECC-RAM ist kaum teurer als normaler, zumindest wenn man ältere gebrauchte Xeons mit DDR3 nimmt. zfsonlinux funktioniert bei mir einwandfrei, da ist nichts schlimm daran, die Installation erfolgt normal über den Paketmanager. Klar, wenn du so irre bist und das Zeug selbst kompilierst, hast du nach jedem Update das Spiel von vorne. Backups auf USB-Platten kannst du auch machen, entweder dort auch ZFS nutzen, oder einen zfs-send-Stream in eine Datei packen, oder eben mit rsync sichern. Warum soll die Platte über USB großartig anders funktionieren als intern? Dokumentation gibt es bei ZFS auch zur Genüge, vor allem gut formulierte.

Den Raspberry Pie habe ich deswegen im Zusammenhang mit zfs so abwertend erwähnt, weil der auf ARM basiert und das nicht (gut) getestet ist. Das ist bzgl. Datenverlust etwas riskant. Ganz abgesehen davon dass die meisten Geräte nur 4GiB RAM haben und sowieso Portknappheit. Auf 4GiB kannst du zfs nutzen, aber je nach Volumengröße und anderen laufenden Diensten kann der Speicher ausgehen.
 
  • Gefällt mir
Reaktionen: Birma
OmarDLittle schrieb:
Dass ZFS soviel RAM bräuchte wird oft behauptet, tatsächlich bist du mit 8GiB bis 16GiB schon gut dabei. ECC-RAM ist kaum teurer als normaler, zumindest wenn man ältere gebrauchte Xeons mit DDR3 nimmt.
Zum Vergrößern anklicken....
...das kann man machen (den Quatsch hab' ich auch hinter mir), allerdings läuft das zumindest bei mir auf "mit Kanonen nach Spatzen schiessen" hinaus: Dafür, daß so eine Kiste den grössten Teil des Tages im Privathaushalt nichts tut, verursacht ein Serverboard mit ECC-RAM und Xeons ganz ordentlich Lärm und Stromverbrauch. Selbst kleine, spezialisierte Boards wie mein letztes

https://www.supermicro.com/products/motherboard/atom/A2SDi-8C_-HLN4F.cfm

haben trotz Denverton-Atom aufgrund des IPMI-Zugangs und der vier Netzwerkschnittstellen einen immensen, kaum reduzierbaren Grundverbrauch. Ganz zu schweigen von den Kosten bei der Anschaffung und ggf. Reparatur. Tolle Sache insgesamt, aber das ist wie Brötchenholen mit dem LKW...

OmarDLittle schrieb:
zfsonlinux funktioniert bei mir einwandfrei, da ist nichts schlimm daran, die Installation erfolgt normal über den Paketmanager. Klar, wenn du so irre bist und das Zeug selbst kompilierst, hast du nach jedem Update das Spiel von vorne. Backups auf USB-Platten kannst du auch machen, entweder dort auch ZFS nutzen, oder einen zfs-send-Stream in eine Datei packen, oder eben mit rsync sichern. Warum soll die Platte über USB großartig anders funktionieren als intern? Dokumentation gibt es bei ZFS auch zur Genüge, vor allem gut formulierte.
Zum Vergrößern anklicken....
...all nice and well, aber wozu? Ich brauch' keine Hochverfügbarkeit und Bitrot war noch nie ein Problem. Snapshots habe ich nur gebraucht als ich unter Proxmox ganze VMs mit Mail- und Webservern als Fullbackups gesichert habe, aber das waren nicht nur die berüchtigten Kanonen auf Spatzen, sondern ein komplettes Artillerieregiment. Und was die Backups betrifft: Die mach ich dann doch lieber gleich auf Dateiebene mit einem versionierendem rsync-Skript oder meinetwegen dirvish innerhalb von ein paar Minuten oder Sekunden, was helfen mir da snapshots (ich hab' ja keine ungedumpten Datenbanken laufen)...? Selbst wenn ich welche wollte, könnte ich die auch mit dem aus Flexibilitätsgründen ohnehin installierten LVM machen...

OmarDLittle schrieb:
Den Raspberry Pie habe ich deswegen im Zusammenhang mit zfs so abwertend erwähnt, weil der auf ARM basiert und das nicht (gut) getestet ist. Das ist bzgl. Datenverlust etwas riskant. Ganz abgesehen davon dass die meisten Geräte nur 4GiB RAM haben und sowieso Portknappheit. Auf 4GiB kannst du zfs nutzen, aber je nach Volumengröße und anderen laufenden Diensten kann der Speicher ausgehen.
Zum Vergrößern anklicken....
Eigentlich ist der Raspi genau das Teil daß ich brauche - ZFS halte ich für meine Zwecke aber für absolut verzichtbar. Der Hauptvorteil vom Raspi ist seine Standardisierung, sein Preis und generell gute Verfügbarkeit. Gewichtige Nachteile sind jedoch die Krämpfe die man treiben muß um ihn ohne SD-Karte booten zu lassen und eben die fehlenden SATA-Schnittstellen (ja, ich hätte schon gerne mindestens zwei für ein Software Raid1). Mit Banana-Pi etc. bin ich dann wieder auf noch kleinere System- & Treiber-Ökosysteme eingeschränkt - nö danke. Da klatsch' ich mir lieber ein amd64-Debian ootb auf ein kleines PC-Board, fahr' das Ding mit einem sparsamen 54,- €-Zen-Athlon und finde Ersatzteile an jeder Straßenecke...
 
Zuletzt bearbeitet:
Mit zwei Platten käme ich nicht weit, für meine 4K-Aufnahmen hab ich aktuell 24 Platten im Hauptserver, der frisst dann schon 200W - die Hälfte davon kommt von den Platten. Mit nur zwei davon wäre ich wohl eher bei 100W idle. Das ist weit weg von einem Raspberry Pi, der genügt den Anforderungen halt einfach nicht, hab auch Goodies wie 10Gbit-Netzwerk. Die Features von ZFS sind eigentlich kein Overkill, für Offsite-Backups über langsamere/instabile Leitungen beispielsweise ist ein resumable zfs send Gold wert. Hatte früher 4Mbit/s Upload und immer wieder Ausfälle, ein rsync mit tausenden von Files ist nie komplett durchgelaufen. Auch jetzt weiß ich es zu schätzen, dass zfs ohne Overhead sofort weiß welche Blöcke zu senden sind und das komprimiert auf Blockebene erledigt. Aktuell sende ich jede Woche 500GB-1TB auf den Offsiteserver, das wäre mit rsync in der gleichen Zeit nicht möglich.

Aber dafür dass ich Dual-Xeons hab, find ich die 100W im Idle ohne Platten nicht so schlimm. Ein sparsameres Board mit nur einer CPU ohne zusätzliche Erweiterungskarten läge wohl darunter. Und der Verbrauch stört mich nicht, dafür hab ich die Beleuchtung auf LED umgestellt.
 
  • Gefällt mir
Reaktionen: Birma
24 Platten? *wow*
Filme oder aus beruflichen Gründen @4K?

So reine Neugier...
 
Da der TE im WoMo unterwegs ist halte ich den Raspberry PI 4 mit USB3 für absolut ausreichend. Und ZFS als "Kanone" zu bezeichnen ist witzig. Es ist ein Dateisystem das viel mehr kann als LVM o.ä. und kostet etwas Speed in der Datenübertragung. Aber gegen ZFS send kommt nichts in der Preisklasse an.

Und hier mit 2 SSDs oder Platten:
https://www.amazon.de/stores/page/87D62A42-64E2-4EC6-909E-FB4B9E44BD1D
 
  • Gefällt mir
Reaktionen: kenduo
Okay. Danke :)
 
Birma schrieb:
Da der TE im WoMo unterwegs ist halte ich den Raspberry PI 4 mit USB3 für absolut ausreichend. Und ZFS als "Kanone" zu bezeichnen ist witzig. Es ist ein Dateisystem das viel mehr kann als LVM o.ä. und kostet etwas Speed in der Datenübertragung. Aber gegen ZFS send kommt nichts in der Preisklasse an.

Und hier mit 2 SSDs oder Platten:
https://www.amazon.de/stores/page/87D62A42-64E2-4EC6-909E-FB4B9E44BD1D
Zum Vergrößern anklicken....

Hmm, jetzt überlege ich wieder, ob ich nein altes NAS nicht einfach durch zwei solche Systeme ersetze (eines externe dann).
Mit einem Sync (ZFS send klingt sehr nieal, muss mich mal einlesen) hätte man ein gutes Backup. Dazu TimeMaschine und es passt.
 
Ich sehe damit mehrere Probleme - nur 2,5"-Platten, die sind eher fehleranfällig, vor allem wenn es größere mit mehreren TB Speicherplatz sind, das sind lahme SMR-Krücken mit nicht allzu glänzenden Reviews. Wenn du aber SSDs reinsteckst wird das schon wieder teurer und du bist auch auf 2TB nutzbarer Kapazität im RAID1 (also 2x2TB SSDs) limitiert bevor es richtig teuer wird.

Über USB Platten anzustecken geht locker auch mit zfs, mir wäre es für ein dauerhaftes NAS nicht sicher genug. Aber wenn man da nicht an den Kabeln ankommt geht das vermutlich, gut. Bin einfach nur SAS/SATA-Einschübe gewohnt, da kann man an keinem Kabel wackeln und einen Disconnect verursachen.

Und dann ist da eben die Tatsache, dass zfs(onlinux) auf der ARM-Architektur nicht breitflächig verwendet wird, d.h. es hat das Potential fehleranfälliger zu sein. zfsonlinux auf X86 hingegen wird so vielfach eingesetzt, es werden laufend Bugs gefunden und behoben. Da weiß ich, die Chancen stehen gut einen Bugfix zu erhalten bevor ich selbst in das Problem laufe und möglicherweise Datenverlust erleide. Diese Bugfixes kommen auch zu ARM rüber, aber ARM kann wieder seine eigenen Bugs haben und dann bin ich der erste der in das Fettnäpchen tappt...

Fürs Backup ist es schon nett mit zfs send zu synchronisieren. Allerdings Vorsicht, wenn du eben wirklich zwei idente zfs-Server aufbaust und dann hast du einen Bug mit Datenverlust in zfs selbst, kann es beide Server treffen und im schlimmsten Fall sind alle Daten von beiden Servern weg. Eine Lösung dafür ist, nicht ausschließlich auf ZFS zu vertrauen und ein weiteres Backup auf XFS/EXT4 oder so vorzuhalten.
 
  • Gefällt mir
Reaktionen: Birma
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten