Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Hi...
ich überlege gerade wie ich mein NAS (TS-453mini) ersetzen kann. Gibt es hier vielleicht jemanden der von einem QNAP Nas zu einem TrueNas/Freenas oder ähnlichem gewechselt ist. Ist das zu empfehlen? Vermisst ihr was? Welches Gehäuse könnt Ihr empfehlen für bis zu 4 oder 5 drives? Bin noch ziemlich unentschlossen.
Bin für Tipps oder Hinweise dankbar. Ich weiß ist etwas unspezifisch...danke!
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"Etwas unspezifisch" ist hier wohl die Untertreibung des Jahrhunderts - wir wissen weder dein Anwendungsgebiet noch deine Anforderungen an die Größe des Gehäuses, wir wissen noch nicht mal, wieso Du dein NAS ersetzen willst, deswegen wäre jeder wie auch immer geartete Vorschlag ein Blick in die Kristallkugel...
Ich bin von einem QNAP zu Unraid gewechselt und bereue nichts. Im Gegenteil, bisher nur Vorteile. Aber auch hier ist eher die Frage, was du von einem NAS erwartest und für was genau du es später verwenden möchtest. TrueNAS/Unraid können so viel mehr sein als ein Datengrab.
Frage ist, was du für ein Gehäuse suchst. Soll es wieder etwas kompaktes sein wie ein QNAP NAS oder willst du was größeres?
Stimmt! Sorry Also danke erstmal das ihr was geschrieben habt. Verwendung hätte ich ja echt mal sagen können.
Ähnlich wie das erwähnt TS453 mini würde ich es zum einen als Datengrab verwenden. Die Idee war, wenn ich sowas wie Unraid nehme, das ich dann zwei große 16TB Festplatten einbaue und diese in meinem alten NAS spiegele. Dann hab ich zwar kein Raid aber mir ist das backup im zweiten NAS wichtiger. Wenn dann mal eine Platte ausfällt kann ich sie einfach ersetzen und vom backup wieder rüberkopieren, ohne eine RAID wiederherstellen zu müssen. Kann mir nicht vorstellen,dass das so gut laufen würde bei den PLattengrößen.
Anwendung ist neben dem Datengrab die Zuspielung zu einem kleinen A300 auf dem mein Plex und Roon läuft. Im Idealfall könnte man, wenn die Hardware des "NAS" perfomant genug wäre dieses System ü berflüssig machen. Aber da kenn ich mich zu wenig aus. Es würde wohl auch die Verwendung als reiner Speicher ausreichen. Das Ganze steht in meinem Büro und kann vielleicht irgendwann mal in den Keller wandern, wenn der Traum vom Hausbau noch umsetzbar ist. Aber das kann noch Jahre dauern.
Wenn du mit deinem Qnap nicht klar gekommen bist, vielleicht ein Synology Nas mit BTRFS und SHR Raid ?
UnRaid hat halt auch Nachteile: Keine Bitroterkennung, langsam unter XFS. Voteil: Festplatten können gemischt werden. Wenn dich langsam nicht stört, kannst du auch direkt Windows nutzen und DrivePool mit Snapraid wie ich es verwende. Da hast jedenfalls Bitroterkennung und Prüfsummen + Reparatur, und kannst im Fall eines Crash noch direkt auf die Daten der anderen Platten zugreifen ohne ein Live Linux aufsetzen zu müssen.
Sonst halt TrueNas mit ZFS. Auch hier müssen alle Datenträger gleich groß sein. ZFS Raid können nicht ohne weiteres erweitert werden. Vorteil: Bitroterkennung mit Prüfsummen + automatische Reparatur.
Danke! Ich bin schon ganz gut damit klargekommen, aber ich würde gerne auf ein Raid verzichten und lieber den Platz der Platten ganz ausnutzen. Das Risiko sollte da ja nicht höher sein, weil ich ja ein wöchentliches Backup fahre. Ich würde also im worst case nur Daten der Woche verlieren und das ist bei mir nicht relevant. Wichtig ist mir noch, dass ich auch einige Folder zusätzlich in die Cloud syncen kann. Das sind meine wirklich wichtigen Dokumente usw. was dann im Augemblick noch im onedrive landet. Wie "groß" ist das BitrotThema? ist das eine reele Bedrohung? Tritt das bei vielen Schreib/lesezyklen auf? Die QNAP und Synology Cases sind halt auch recht teuer, gerade wenn es in die performantere Richtung gehen soll (Plex mit transkodieren, Roon). Finde das Angebot da auch etwas unübersichtlich. Aber klar, wenn es preislich in ähnliche Regionen wie eine Selbstbaulösung geht, bin ich auch weiterhin dafür offen.
Bitrot ist immer so eine Sache, wichtig gegen Bitrot ist immer ECC Ram. im Zweiten schritt ein Dateisystem mit Prüfsummen. Sprich BTRFS oder ZFS oder Snapraid obwohl Snapraid kein Dateisystem ist.
Sonst, Bitrot hatte ich eigentlich immer ohne ECC Ram, mit ECC Ram war das Risiko schon echt gering. Wenn du eh nur Festplatten bündeln magst und kein Raid mehr fahren möchtest, kannst du echt UnRaid oder DrivePool mit Windows OS nutzen. DrivePool hat auch eine Cloudfunktion und es gibt auch ein Cloud Tool womit du Cloudanbieter als Festplatte einbinden kannst. Verschieben/Sync könntest du über Freefilesync. Für UnRaid gibt es auch Lösungen, bin aber früher von UnRaid recht schnell wieder auf Windows gewechselt. Wie geschrieben hatte ich kein bock auf Live Linux wenn doch mal crashen sollte, sprich das ich alle anderen Daten einfach über Windows zugreifen kann. Und wichtiger warn mir Prüfsummen und Reparatur. Prüfsummen und Reparatur fällt ja bei dir weg.
Und auf was für einer Hardware läuft das bei dir? 24/7? Bei windows hätte ich wahrscheinlich auch ein Problem wenn ich die kiste nachts für ein paar Stunden runterfahren will oder? Ist also im Prinzip eine win Applikation die interne Festplatten verwaltet. Sollte dann ja bei entsprechender hardware auch mit roon und plex parallel auf der gleichen kiste laufen oder? Muss mir das mal genauer ansehen. Was sind deine Anwendungen?
Danke! Gibts in Win einen Energiezeitplan bei dem sich der Rechner aus selbst aus dem Schlaf wecken kann? Hast du, oder gerne auch jemand anderes hier einen guten Vorschlag für die hardware? Sollte ja relativ compact machbar sein oder? Ich denke mehr Platz als für zwei oder drei drives werde ich nicht brauchen. Dann ne SSD fürs OS. RAM und ne CPU mit interner GPU und genug power fürs transkoden. Wird wahrscheinlich schwierig da die balance zwischen power und Stromverbrauch zu finden
Danke! Gibts in Win einen Energiezeitplan bei dem sich der Rechner aus selbst aus dem Schlaf wecken kann? Hast du, oder gerne auch jemand anderes hier einen guten Vorschlag für die hardware? Sollte ja relativ compact machbar sein oder? Ich denke mehr Platz als für zwei oder drei drives werde ich nicht brauchen. Dann ne SSD fürs OS. RAM und ne CPU mit interner GPU und genug power fürs transkoden. Wird wahrscheinlich schwierig da die balance zwischen power und Stromverbrauch zu finden
PC AutoTimer is an easy-to-use application allows computer resume from sleep state to perform scheduled tasks and customize hotkeys to launch these repetitive actions.
Im Unraid Forum gibt es einen guten Threads was Hardware betrifft. Schade ist, dass vieles davon schon was älter ist kaum noch zu bekommen. Lohnt dennoch Mal reinzuschauen.
Ich habe mich dennoch für ein amd System entschieden und fahre auch damit sparsam.
Ein B550 Board empfiehlt sich weil effizienter als X570. Zuerst war ein 3700x drinnen. Mittlerweile bin ich bei einer 4350G. Hängt alles davon ab, was du auf der Kiste laufen lassen willst.
Wie gesagt, geh Mal ins unraid Forum. Dort gibt es ein deutsches Unterforum, wo regelmäßig jemand nach Hardwareempfehlungen fragt. Ich habe auch zwei Wochen hin und her überlegt. Ist halt leider ein Prozess, der sich aber auch lohnt mit recherchieren.
Bitrot ist immer so eine Sache, wichtig gegen Bitrot ist immer ECC Ram. im Zweiten schritt ein Dateisystem mit Prüfsummen. Sprich BTRFS oder ZFS oder Snapraid obwohl Snapraid kein Dateisystem ist.
Sonst, Bitrot hatte ich eigentlich immer ohne ECC Ram, mit ECC Ram war das Risiko schon echt gering.
Bit rot gibt es sowohl im RAM als auch im Storage (letzteres meint man aber in aller Regel, wenn man von bit rot spricht).
ECC kann bei bit rot im RAM helfen, da sich dort selbst umwandelnde Bits korrigiert werden können. Das passiert bei Datenbanken oder anderen Sachen die eben über einen längeren Zeitraum Daten im RAM speichern.
Wobei RAM auch selber nen internen refresh hat, auch ohne ECC, nur wirkt der eben nicht zu 100% und kann somit nicht sicherstellen, dass Zellen nicht kippen, es wird eben nur statistisch besser.
Mit DRAM ohne den Refresh kommt richtig Spaß auf, btw...
ECC RAM kann aber bei Storage bit rot rein garnichts machen, wie sollte es auch? Denn die Daten, die z.B. auf einer HDD liegen, werden mit der Zeit der Lagerung (oder beim Verarbeiten in der Platte) eben auf dem Datenträger selber schlecht, sie verrotten.
Da kannst du auch Quadrupel super duper magic ECC RAM in dein System bauen, es wird der HDD nicht helfen diesen bit rot zu unterbinden.
(falls du da, @Ceiber3, anderer Meinung bist, dann bitte den Weg beschreiben, wie eine HDD mittels CPU ECC RAM verhindert, dass sich bit rot bildet)
Um diesen bit rot entgegenzuwirken, muss man Redundanzen erzeugen, wie beispielsweise RAID, das dann, am besten, eine 2 aus 3 Entscheidung macht, damit das gekippte Bit korrigiert werden kann.
Dazu müssen diese Bits aber regelmäßig auf rot untersucht werden.
Dazu braucht es aber auch kein ECC, weder bei einem RAID noch bei ZFS, weil ECC an diesem Prozess nichts am bit rot selber ändern kann.
Es werden einfach Operationen ausgeführt, die + * - / rechnen und dabei rausbekommen, ob das Bit nun OK ist (also nicht gerottet) oder eben nicht OK (also gerottet) ist. Wird ein bit rot erkannt, wirds durch den ECC RAM nicht plötzlich negiert, sondern durch die Rechenoperation und die Reaktion des Systems auf die Erkennung. (es korrigiert also das defekte Bit)
ECC kommt dann zum Einsatz, wenn die CPU irgendwie an Storageprozessen beteiligt ist, das trifft als auf SoftwareRAID als auch ZFS und ähnliches zu. Aber auch hier gilt wieder, dass ECC nichts mit dem bit rot zu hat.
ECC verhindert in einem solchen Szenario nur, dass die CPU, bedingt durch Speicherfehler, Berechnungen falsch anstellt und damit entweder Bit falsch schreibt oder aber eigentlich korrekte Bits vermeintlich "korrigiert" und sie somit erst defekt macht. Das hat also nichts mit bit rot zu tun, da in dem Fall entweder korrekte Daten auf die HDD geschrieben wurden und damit korrekt da sind oder aber gerottete Daten von der HDD gelesen werden und dann, im Nachgang, durch das System korrigiert werden müssen. In letzterem Fall ist das Kind also schon in den Brunnen gefallen, da kann der ECC nichts mehr tun.
Mir scheint, da hat einer das System ZFS und Co. nicht ganz verstanden und für welchen konkreten Sachverhalt die Systeme den ECC eigentlich brauchen.
Wie eigentlich jedes andere System auch, wenn es um ECC geht. ECC verhindert am Ende nur, dass Daten, die im RAM sind, zu falschen Ergebnissen einer Rechnung führen.
Wenn man dann noch einen Schritt weitergehen will, führt man dann die Rechnungen noch auf unterschiedlichen Wegen und Systemen durch. Da sind wir dann aber auf einer ganz anderen Baustellen unterwegs.
(Denn wer sagt einem, dass die CPU überhaupt richtig rechnet oder die Rechnung selber korrekt ist? ...)
EDIT:
ZFS (und co.) setzt natürlich noch woanders an, das gehört aber nicht zum Thema.
Bit rot ist, wie so vieles in der IT, ein statistisches Problem.
Jemand mit 1000Bilder oder 100h Videomaterial hat eben andere Vorrausetzungen von Fehler getroffen zu werden, als jemand mit 1000mrd Bilder und 10Jahren Videomaterial.
Nur weil User 1 das Problem nicht hat, kann man daraus nicht schließen, dass User 2 das Problem nicht auch hat.
Willkommen in der Welt der Stochastik.
2ndEDIT:
Es ist bei weitem nicht so, dass ECC beim Durchlaufen eines Bits einen bit rot erkennt und beseitigt.
Nehmen wir an, dass eine 1 auf "die" HDD geschrieben wurde. Die hat nach einem Jahr plötzlich den Wert 0 (bit rot). Jetzt wird das Bit gelesen, dann wir eben eine 0 gelesen und keine 1. Und diese 0 steht dann im RAM, ja, auch im ECC RAM.
Und da wird auch erstmal nichts passieren, weil die 0 ja erstmal gelesen wurde und formal erstmal korrekt ist und somit auch korrekt im ECC RAM ist.
Erst jetzt kommt z.B. ZFS um die Ecke und fragt, ob denn die 0 überhaupt korrekt ist und kuckt ins schwarze Büchlein und da steht drin, dass diese 0 früher mal eine 1 gewesen ist. Das wird dann korrigiert, aber nicht durch den ECC RAM, sondern durch die Logik.
Sowohl die 0 als auch die dann folgende 1 sind, aus Sicht des RAMs jeweils korrekte Werde, an denen es nichts zu korrigieren gibt. Und dieser Mechanismus greift auch bei nonECC RAM, siehe oben.
ECC Ram wegen lesen und schreiben, einfach jede Datei geht durch den Ram. Dateisystem mit Prüfsummen gegen Bitrot beim Langzeitspeicher.
Hast du kein ECC Ram kann es halt auch passieren das beim lesen oder schreiben ein Bit im Ram kippt und die Datei beschädigen kann. Die Chance ist zwar gering, besteht aber.
Beim normalen Ram bekommst du das ja garnicht mit und beim ECC Ram wird das auch nicht immer Protokolliert aber gefixt.
Joah, das war etwas unpräzise vom Ceiber3. Hätte besser lauten sollen:
"Wichtig für korrekte Daten und Datenverarbeitung ist immer (auch) ECC RAM, gepaart mit einem Dateisystem mit Prüfsummen, Parität/Redundanz und idealerweise automatischer Fehlerkorrektur,"
ECC betrifft halt (nur) Bits im RAM, das ist aber leider nur ein sehr enger Ausschnitt in der Gesamtschau auf "Herkunft", "Transport", "Verarbeitung" und "dauerhaften Speicherung" - und das jeweils ohne ungewollte Veränderungen. Wirklich Einfluss haben wir Normalsterbliche ohne extreme Klimmzüge ja eh nur auf die Komponenten RAM, Datenspeicher und Filesystem.
Es gibt noch mehr Sicherungskomponenten/Funktionen außer ECC.
Und nein, das ist kein Sci-Fi, sowas gibt es seit der Entstehung der IT.
Es hat schon einen Grund, warum ECC(RAM) Systeme statistisch robuster sind als nonECC. (und nein, statistisch robuster heißt nicht 101% Verfügbarkeit)
Das führt jetzt aber zu weit.
PS: Falls du dich mal etwas belesen möchtest, schau dir doch mal an, was so nen CPU Cache heute an Funktionen mitbringt. (mal ganz abseits von irgendwelchen Marketingfolio wieviel GB man heute hat)
Ich denke, da wirst du Bauklötze staunen.
@pumuckel Auch bei deinen Clients ist's am Ende auch nur die Frage ECC ja/nein und ggf. Filesystem/Setup des lokalen Storage.
Ich fühl' mich jedenfalls mit ECC allein nicht sicher - zumindest nicht auf'm Storage-Server, da will ich ein ordentliches Filesystem und wenn ich nur "entweder, oder" kann, nehm' ich das Filesystem/saubere Storage-Konzept anstatt ECC.
Worum's mir ging war die manuelle Härtung der Transportwege und Verarbeitung in Netz, CPU & Co. z.B. durch Setzen individueller Einstellungen oder Einsatz zusätzlicher Spezialhardware usw. über die 08/15-Standards hinaus. Ich hab mir jedenfalls noch keine Gedanken dazu gemacht, ob ich mein OS dazu bringen kann, "sicherer" zu arbeiten als out-of-the-box (z.B. wirklich ALLES doppelt durchzuführen?) oder 'ne Extrawurst im Netzwerk-Traffic brauch'. Ich alos eher nicht. Ist aber eh nur Homeuse und Spaß anner Freud. Professionell bzw. für den produktiven Einsatz dürfen sich da andere drum kümmern - auch für mich.
Im DC macht das auch keiner. Da ist es auch nicht ganz so wichtig.
Es gibt aber Bereiche, wo es schon relevant ist. So nen A380 fliegt nicht mehr mit Seilzugsteuerung, soviel ist sicher und es geht auch keiner hinter und dreht am Ruder.
So nen Desaster Recovery sieht bei einem A380 daher anders aus, als bei einem DC. Bei letzterem ist es Backupprozess und ähnliches, bei ersterem auch, nur dass dann keiner im Flieger nen USB-Stick mit Acronis bekäme, sondern nen Fallschirm. (und dann have fun mit 800 ppl sky dive)
Ergo, man will garkein Desaster haben, hat daher auch keinen Desaster Recovery Prozess.
Joah, die Sicherheit im Flugbetrieb ist eine Wissenschaft für sich. Ich hab da von Berufswegen mal gewisse Einblicke bekommen, das ist einfach der Hammer und mit nichts auch nur ansatzweise zu vergleichen, was mir ansonsten je untergekommen ist. Da ist ja quasi für jede Schraube sowohl die Relevanz im Gesamtkunstwerk einschließlich Notfallplan für den Versagensfall definiert. Und trotzdem geht jeden Tag unglaublich viel in der Luft schief, von dem wir nur einfach nichts mitbekommen (weil die ganzen Mechanismen eben verdammt gut funktionieren).
Um nochmal auf das Ursprungsthema zurückzukommen: Wie groß seht ihr die Gefahr des bit rot in meinem angepeilten Maßstab. Welches System wäre da dann sinnvoll?
Bit rot ist immer ein Thema, bei so und so viel mrd. Bits ist immer einer dabei, der aus der Reihe tanzt. -> Statistik regelt
Die Frage ist jetzt also, wieviele Versuche, sprich Bits, hast du. Je mehr, desto ofter/wahrscheinlicher wirst du davon getroffen.
4x 1TB Drives sind was anderes als 4x 20TB Drive. Die Drives selber haben schon von Haus eine Fehlerrate und die besagt, dass bei großen Platten, statistisch, min. 1 Bit dabei ist, was schon perse falsch gelesen wird.
(das ist die Nette Fehlerratenangabe im Datenblatt, kannste ja mal in TB umrechnen)
Persönlich würde ich gar nicht nachdenken, wenn man es sich leisten kann.
Minimum ist erstmal das Stroragesystem an sich, sprich RAID oder ähnliches, was gegen bit rot hilft.
Weiter geht es dann mit einem Filesystem was andere Problemfälle abfängt, also ZFS, ReFS usw.
Und dann geht es nochmal weiter, dass man dem Filesystem nach Möglichkeit die bestmögliche Arbeitsumgebung zur Verfügung stellt und das ist dann ECC.
Viel mehr ist es dann auch nicht.
Jetzt kann man noch 3 trillionen Mal NAS, ZFS, Unraid und sonst noch für ein Gelumpe miteinander vergleichen, die Entscheidung wird nicht einfacher, solange man sich nicht tief einarbeitet.
Alles hat seine Vorteile und Nachteile.
Ich habe eine Lösung mit QNAP NASes an verteilten Standorten mit Sync, und Explorereinbettung für Clientsync.
Geplant ist jetzt zusätzlich eine Backupstrategie mit ZFSbased Systemen für eben diese NASen.
Und solange man nur einfaches Storage macht, nehmen sich die Systeme eigentlich nichts. Spannend wirds bei den Zusatzfeatures wie Apps, Container, VMs und co.
VMs aufm NAS habe ich mir angeschaut und, bedingt durch ne ESX-Infrastruktur, nach 4 Wochen mit einer Saturn V aufn Mond geschossen. Soviel kann man gar nicht saufen, als das was werden würde.
(mag bei nem Highcore System anders sein, aber allein VM-Backupstrategie, alter Schwede...)
Für mich hat NAS den Vorteil, das Zeug ist so schlecht, aus Sicht des Spielfaktors, das man es eigentlich nur als Storage benutzt und damit in der Regel nicht kaputtgespielt werden kann, also allways on.
Das Storage ist also immer verfügbar, so gibt es auch keinen Stress mit inhouse-Kunden.
An andere Systemen spielt man ggf. zu oft rum, so dass unter Umständen das SLA im Schlafzimmer nicht mehr passt.
Das ist nur eine Variante, neben den anderen 3 Mios von anderen Leuten.
EDIT:
Auch Cases kann nur schwer empfehlen.
Allein an der Frage hot swap oder nicht, scheiden sich schon die Geister. Ich bin nen hotswap Freund, da gäbe es nen ITX von Chenbro mit 4 Slots, oder auch von anderen.
5er Systeme gibt es sicherlich auch.
Silverstone hat nen 8er im Angebot und wer das eskalieren will, der nimmt z.B. nen SC836 aus der Bucht. (am Besten im Bad hinstellen, erleichtert das Haare Föhnen)
Also danke erstmal das ihr was geschrieben habt. Verwendung hätte ich ja echt mal sagen können.
