BD Brennprogramm (Freeware?) mit vielen Brenn-Einstellmöglichkeiten? + Fragen zum Dateisystem

Maitry

Ensign
Registriert
Dez. 2016
Beiträge
182
Hallo!

Zur Langzeitarchivierung einiger wichtiger Daten suche ich ein gutes Freeware Programm. (Kann auch bisl was kosten) und mache mir Gedanken über ein geeignetes Dateisystem was auch in Zukunft noch auf möglichst vielen Maschinen gelesen werden kann (auch auf älteren Systemen) !
Wegen vieler langer Dateinamen und tiefer Verzeichnisebenen scheint UDF die geeignete Wahl zu sein.
Angeblich Dateinamen bis 255 Zeichen. Max Pfadlänge 1023 Zeichen. Damit kann ich gut leben!

CD Burner XP: getestet. Bietet mir UDF Versionen von 1.02 - 2.60.
Aber bei allen Versionen steht: "Datei oder Verzeichnisnamen können nicht aus mehr als 127 Zeichen bestehen" Wieso das??

Gibt es Alternativen mit der ich UDF voll ausschöpfen kann?

Ich möchte nicht erst nach dem Brennen einer Scheibe dann die Enttäuschung erleben das da irgendwas gekürzt wurde. Ebenso kann man wohl nicht bei allen Programmen 1x Geschwindigkeit einstellen (das hätt ich gern für gute Brennergebnisse).

-----------------------------------------------------------------
Hintergrund ist Langzeitarchivierung (über dieses Thema kann man mit mir in anderen Threads hier diskutieren) auf BD 25GB (Normale sowie auch die M-Disc Variante).
Und das mit möglichst geringer Rohdaten-Fehlerrate (leider nicht verifizierbar)
Daher werde ich 1x brennen und ansonsten drauf vertrauen das mein neues Pioneer BDR-X12EBK (extern) gute Brennergebnisse liefert.

Haben ansonsten Brennprogramme Einfluss auf die Brennqualität?

Ich weis das UDF für Langzeitarchivierung nicht gerade geeignet ist was die Kompatibilität betrifft. Ich wollte 2.50 nehmen, das kann man zur Not auch mal auf ner XP Maschine auslesen falls man garnix anderes mehr zur Hand hat. Aber tausende Verzeichnisse/Dateien kürzen um dann ISO9660 nehmen zu können, würde mich Tage lange Arbeit kosten.
 
Zuletzt bearbeitet:
Z.B. BurnAware, welches auch in einer kostenlosen Version verfügbar ist. Willst Du mehr, dann greife zu CyberLink Power2Go 13.
 
Mit Standard-Rohlingen bist da raus, da hält das Dateisystem länger als das Medium.

Langzeitarchivierung ist sicherlich eine Frage des Budgets. Schmales Budget: Festplatte(n). Größeres Budget: Bänder. Beide erfordern Pflege, dh. auch die Backups müssen ab und zu verifiziert werden (backup was nicht zurückgespielt werden kann ist kein Backup) und über die Medien verschoben werden.
 
Maitry schrieb:
CD Burner XP: getestet. Bietet mir UDF Versionen von 1.02 - 2.60.
Aber bei allen Versionen steht: "Datei oder Verzeichnisnamen können nicht aus mehr als 127 Zeichen bestehen" Wieso das??

Gibt es Alternativen mit der ich UDF voll ausschöpfen kann?
Offenbar ist die Unicode-Unterstützung nicht deaktivierbar und das Limit deshalb bei 127 Zeichen:
https://forum.cdburnerxp.se/topic/10107-how-to-allow-a-file-name-length-127-chars-for-udf-v260/

Maitry schrieb:
Ich möchte nicht erst nach dem Brennen einer Scheibe dann die Enttäuschung erleben das da irgendwas gekürzt wurde.
Du könntest zunächst ein Image erstellen, dieses prüfen und wenn alles ok ist, 1:1 brennen.

Maitry schrieb:
Ebenso kann man wohl nicht bei allen Programmen 1x Geschwindigkeit einstellen (das hätt ich gern für gute Brennergebnisse).
Weil die Ergebnisse nicht besser, sondern schlechter werden, bieten die meisten Brenner abhängig von Medien die niedrigsten Geschwindigkeiten nicht an. Prinzipiell ist es keine Einschränkung der Software. Selbst wenn man z.B. "1x" auswählen kann, wird u.U. trotzdem schneller gebrannt.
 
  • Gefällt mir
Reaktionen: Maitry
Zur Archivierung würde ich die Dateien auf jeden Fall packen (Archive) und dann brennen. So weißt du auch, ob sie okay sind, wenn du sie entpackst.
 
Eben einfach mit Unterverzeichnissen packen aufgeteilt auf z.B. 2 GByte Dateien so dass die auch bei 32 bit Systemen keine Probleme machen und dann die (z.B. zip) Dateien brennen.

Mit mkisofs kann man ISO9660 + UDF parallel "mastern" das wird dann sicher auch in CDBurnerXP gehen

Ich fülle dann den Rest der Disk noch zusätzlich mit PAR Dateien.
 
  • Gefällt mir
Reaktionen: Maitry
OK. Als geeignetes Programm - habe ich gerade entdeckt das mein altes Nero10 bereits BD brennen kann!
Das wusste ich nicht. Ansonsten CD Burrner XP ist völlig OK.
Ergänzung ()

Banned schrieb:
Zur Archivierung würde ich die Dateien auf jeden Fall packen (Archive) und dann brennen. So weißt du auch, ob sie okay sind, wenn du sie entpackst.
Ich bevorzuge seit jeher Daten direkt auf Scheiben zu brennen, ungepackt, unverschlüsselt. (Manchmal muss man hier Ordner teilen, oder ein bisl überlegen, planen um den Platz optimal auszunutzen, aber es geht)

Was ist wenn das Archiv von der Disk nicht mehr kopierbar ist weil Fehler sich an bestimmten Stellen eingeschlichen haben? Ist nicht dann das ganze Archiv futsch?
Wären die Daten ungepackt auf der Disk, wären vielleicht nur 2,3,4... Dateien defekt (an der Stelle wo eben der der Defekt oder die Korruption ist) und der Rest noch kopierbar.
Ist das richtig? Bitte korrigiert mich, das Thema interssiert mich brennend (wie passend:)-)

https://www.pcwelt.de/ratgeber/Datenarchivierung-Das-sind-die-besten-Methoden-9977044.html
Das ist ne Super Info wenn man Daten für ne längere Zeit bannen will (Langzeitarchivierung) um sie in einiger Zukunft noch lesen zu können.
Dort steht:
"Benutzen Sie nach Möglichkeit keine Datei-Container, die viele Backup-Programme anlegen oder eine Komprimierungs-Funktion. Benutzen Sie stattdessen ein Dateisystem oder Format, das sicherlich auch in einigen Jahren noch lesbar sein wird, wie FAT, NTFS, HFS, EXT, ISO9660 oder UDF. Wenn Sie auf Komprimierung nicht verzichten können, wählen Sie etwas Universelles wie ZIP."
 
Zuletzt bearbeitet:
Maitry schrieb:
Was ist wenn das Archiv von der Disk nicht mehr kopierbar ist weil Fehler sich an bestimmten Stellen eingeschlichen haben? Ist nicht dann das ganze Archiv futsch?
Ja, aber einige Archivformate - wie WinRAR - bieten mehr Schutz durch Redundanz:
https://netzmechanik.de/wasteland/wp/?p=1195

Das könnte man also nutzen, allerdings ist WinRAR proprietär und daher vielleicht auch nicht die erste Wahl.

Ähnliches kann auch Nero direkt beim Brennen, nennt sich SecurDisc:
https://de.wikipedia.org/wiki/SecurDisc

Auch SecurDisc ist aber proprietär und noch weniger verbreitet als WinRAR.
 
  • Gefällt mir
Reaktionen: Maitry
(Zitat aus anderem Thread)
gymfan schrieb:
Das Problem bei allen BDs (egal, welches Unterformat) ist, dass es für Privatleute keine Laufwerke gibt,, mit denen man die Rohdaten (vor Anwendung der internen Fehlerkorrektur) auslesen kann um sich selber ein Bild über die Qualität der gebrannten Medien zu machen. Daher bekommt man Fehler erst mit, wenn es zu spät ist.
Ich überlege gerade, wie ich pro Scheibe Paritätsdaten für alle einzelnen Dateien erstellen und hinzufügen kann.
Z.B. 5% oder 10% der Rohling Kapazität (25GB)
Würde das reichen? Genau für diesen Fall das irgendwann mal Daten defekt sind, also wenn quasi die Hardwarekorrektur nicht mehr ausreicht ???
Geht sowas überhaupt`?

fgordon schrieb:
Ich fülle dann den Rest der Disk noch zusätzlich mit PAR Dateien.
Quick Par kann das nicht richtig? Es erstellt auch Container. Und das will ich gerade vermeiden.
 
Naja wenn man 2-3 BR Laufwerke hat, die alle die gebrannten Medien problemlos einlesen, kann man immerhin mit grosser Wahrscheinlichkeit sagen ob der Brenner in der "Serienstreuung" ist.

ZIP davon gehe ich aus wird es IMMER geben - ich nutze ISO9660 UND gleichzeitig UDF.

Par ist OpenSource auch da stehen die Chancen nicht schlecht, dass es da immer eine Implementierung geben wird.

Ja klar sind erstellte PAR2 "Container" - es sind ja RS Codes - aber solange es PAR2 Programme gibt kommen die wohl mit den PAR2-Containern klar. Daher ist das doch egal ob das in Containern ist oder nicht.:)

Und es müssen keinesfalls alle oder bestimmte PAR2 Container vorhanden oder lesbar sein für eine Wiederherstellung es müssen nur genügend noch lesbar sein - egal welche.

ist also ABC.ZIP nicht lesbar und PAR2 Datei 3, 5, und 9 sind auch nicht lesbar ist das egal dann kann man ABC.ZIP trotzdem wieder herstellen wenn die anderen lesbaren PAR2 Dateien zusammen genug Blöcke haben.

Auch können die lesbaren PAR2 Dateien alle selbst teilbeschädigt sein, auch das ist egal solange genug Blöcke übrigbleiben - denke das schon eine nette Zusatzsicherheit und kost ja nur den Rechner ein bisserl Zeit.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Maitry
Maitry schrieb:
Ich überlege gerade, wie ich pro Scheibe Paritätsdaten für alle einzelnen Dateien erstellen und hinzufügen kann.
Z.B. 5% oder 10% der Rohling Kapazität (25GB)
Würde das reichen? Genau für diesen Fall das irgendwann mal Daten defekt sind, also wenn quasi die Hardwarekorrektur nicht mehr ausreicht ???
Geht sowas überhaupt`?
fgordon macht es in seinem Skript genauso (allerdings für Linux):
https://www.computerbase.de/forum/threads/backup-script-fuer-anschliessend-bluray-brennen.2075917/

Mit par2 (und sicher auch QuickPar) kannst Du einstellen, wie viele Paritätsdaten Du möchtest. Ob Dir dann 5% genügen oder Du lieber das Medium damit voll schreibst, bleibt Dir überlassen. Je mehr umso wahrscheinlicher ist es, dass Du auch große Datenausfälle auf dem Medium wieder herstellern kannst.

par2 hat dabei den Vorteil, dass man es vollständig automatisieren kann und nicht QuickPar von Hand aufrufen muss.

Dazu gibt es zip und par2 als ANSI-C Quelltext womit man die Sachen auch in ferner Zukunft auch dann noch prüfen/korrigieren/entpacken kann, wenn MS endgültig durchdreht und Windows auf der dann verfügbarne HW nicht mehr akzeptabel ist.

fgordon schrieb:
ist alo ABC.ZIP nicht lesbar und PAR2 Datei 3, 5, und 9 sind auch nicht lesbar ist das egal dann kann man ABC.ZIP trotzdem wieder herstellen wenn die anderen lesbaren PAR2 Dateien zusammen genug Blöcke haben.
Das Problem ist allenfalls, dass man mit PAR2 nur das ZIP wieder herstellen kann und im zweiten Schritt daraus die Dateien extrahieren muss. Für jemanden, den es nicht stört, dafür ein paar GB mehr an Ramdisk/Plattenplatz zu benötigen, ist das natürlich egal. Wenn ich aber hier im Forum sehe, dass die Leute immer noch kleine SSD kaufen um ein paar Euro zu sparen, mag das für gewisse Leute später ein Problem werden.

Falls Du bei einem GUI-Tool bleiben möchtest, kannst Du Dir auch mal MultiPar ansehen
https://www.computerbase.de/forum/threads/quickpar-multipar-was-fuer-ein-fortschritt.1911550/
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Maitry
Unter Windowes nutze ich auch MultiPAR das echt prima. Brenne ich auch auf jede BR mit drauf - einfach damit ich das im Restorefall nicht suchen muss xD

Ich zippe halt die Daten zusammen auch damit ich ISO9660 und UFS parallel brennen kann - ohne mir gross Gedanken um Limits dieser FS machen zu müssen.

Wenn man halbwegs regelmässig backuppt hat man auch recht bald einige M-Disc BR BackupMedien - die ganz wichtigen Daten sind meist eher älter als 2 Wochen - so dass man die dann auch mehrfach hat, wenn man immer ein Vollbackup macht.

Hehe ich bin bei mir zumindest an einem Punkt an dem ich sage wenn ich die Daten jetzt komplett verliere, dann muss ich micht nicht ärgern, das maximal Sinnvolle habe ich meiner Meinung nach gemacht.

Und das ist ja das worauf es beim Backup ankommt, dass man sich auch wenn alles weg ist nicht über sich selber ärgern muss.

Meine Backupmedien sehen so aus, ich halte das für relativ zukunftssicher, einfach weil ich sage wenn es ZIP nicht mehr gibt dann brauch ich die Medien eh nicht mehr - wenn ich dann ein Backup brauche steig ich einfach in meine Zeitmaschine, fliege zurück in der Zeit als die Daten noch vorhanden waren und kopiere die Daten auf meinen USB Stick 5000 und reise wieder dann in die Gegenwart. Evtl kauf ich dann auch noch ein paar bestimmte Aktien und tippe die Gewinnerlottozahlen - wenn man eh schon in der Vergangenheit ist :D:lol:
 

Anhänge

  • backup.jpg
    backup.jpg
    69,2 KB · Aufrufe: 206
Zuletzt bearbeitet von einem Moderator:
Maitry schrieb:
Wären die Daten ungepackt auf der Disk, wären vielleicht nur 2,3,4... Dateien defekt (an der Stelle wo eben der der Defekt oder die Korruption ist) und der Rest noch kopierbar.
Ist das richtig? Bitte korrigiert mich, das Thema interssiert mich brennend (wie passend:)-)

Das ist richtig. Aber legst du manuell Prüfsummen für alle deine Dateien an? Wie erkennst du - abgesehen von offensichtlichen Fehlern - dass die Daten okay sind?

Archive haben eben gerade den großen Vorteil, dass sie beim Entpacken automatisch zumindest mit CRC32 die Integrität prüfen bzw. dafür vorher automatisch eine Prüfsumme kalkuliert wird.
 
Banned schrieb:
Archive haben eben gerade den großen Vorteil, dass sie beim Entpacken automatisch zumindest mit CRC32 die Integrität prüfen bzw. dafür vorher automatisch eine Prüfsumme kalkuliert wird.
Das haben alle gewöhnlichen CD/DVD/BD-ROM-Formate aber auch.
 
Das überleg ich mir mal mit dem PAR2. Hab mich damit noch nie beschäftigt.

Die Frage ist wie und wo auf einer BD und BD M-Disc sich mit der Zeit Fehler einschleichen.
Ob da Bits sporadisch an bestimmten Stellen beginnen nicht mehr lesbar zu sein?
Kratzer gibt es bei mir nicht. Ich verpacke und lagere auch alles gut. Luftdicht, Kühl, Dunkel.

Ich hab über CRC nicht viel googlen können. Wie funktioniert das?
Wie kommt ein CRC Fehler beim Kopieren zustande?
Daten werden beim Kopieren doch nicht geprüft oder - weder bei HDDs noch bei BD/DVD ?
FAT/NTFS hat auch keine Prüfsummen.
Legt eine HDD Prüfsummen an z.B. pro Sektor?
 
M-Disc ist ja anorganisch - glaube da muss man sich tatsächlich nur noch eigentlich um mechanische Beschädigung Sorgen machen oder natürlich extreme Hitze - aber die dann wohl im Höllenfeuer Bereich :evillol:


Sicherlich gibt es das auf Hardwareebene.

Aber entscheidend ist hier die Dateisystemebene - hier gibt es Filesysteme wie ZFS, BtrFS die automatisch Checkusmmen aller Daten anlegen - und je nach Einstellung auch redundante Daten so dass das Filesystem wenn redundante Daten vorhanden sind die Dateien automatisch repariert, wenn es Fehler feststellt.

Wenn man einen (kleinen) Server daheim hat finde ich ist das fast ein "Muss"- denn noch wichtiger als ob Daten da sind oder nicht ist ja dass man sich darauf verlassen können muss, dass sie auch unbeschädigt sind.

Ich nutze bei mir ECC-RAM, ZFS RAIDZ2 auf meinen Servern (die zusätzlich komplett gespiegelt sind) - wenn man gebraucht kauft kostet das nicht viel (bis auf die HDDs) - aber man kauft ja sowas nur alle paar Jahre im Normalfall.

Für Dateien ist meiner Meinung nach PAR2 der mit sinnvollste Weg wenn man kein Filesystem hat, das die Funktion bietet -wenn man weiss Dateien sind defekt will man die in der Regel gerne wieder reparieren xD

Nun wenn man regelmässig Vollbackups macht hat man ja nach einem Jahr vielleicht 10 oder 20 Backupsets - ob da dann im schlimmsten Fall 1 oder 2 irgendwann in Jahren oder Jahrzehnten an einer Stelle nicht mehr funktionieren ist dann doch überschaubar.
 
Zuletzt bearbeitet von einem Moderator:
Maitry schrieb:
Die Frage ist wie und wo auf einer BD und BD M-Disc sich mit der Zeit Fehler einschleichen.
Ob da Bits sporadisch an bestimmten Stellen beginnen nicht mehr lesbar zu sein?
Kratzer gibt es bei mir nicht. Ich verpacke und lagere auch alles gut. Luftdicht, Kühl, Dunkel.
Ich hatte schon >10 Jahre alte originalverpackte/verschweißte DVD+RW oder auch DVD-R, die im Außenbereich der Reflexionsschicht (von der Beschriftungsseite) dunkele Stellen gezeigt haben. Die Medien waren dann dort auch nicht mehr beschreibbar.

Genauso soll es Medien geben, bei denen sich nach Jahren/Jahrzehnten die Reflexionsschicht einfach in Teilen auch ohne eine Beschädigung abgelöst hat.

Bei mir waren die äußeren Bereiche der CD/DVD diejenigen, die am ersten Probleme bereitet haben. Damit konnte ich z.B. auf alten DVD-Rs meine Filme noch zu 90% fehlerfrei lesen und den Rest nicht mehr.

Bei M-Disc sollte das ganze kein Problem sein, wenn man den Tests/Aussagen der Hersteller vertraut. Die Datenschicht soll sich nach dem Beschreiben chemisch nicht mehr ändern können. Und wenn man dann der Versiegelung der Reflexionsschicht traut, sollte auch dort kein Problem auftreten.

Maitry schrieb:
Daten werden beim Kopieren doch nicht geprüft oder - weder bei HDDs noch bei BD/DVD ?
Es gibt durchaus gewisse Prüfungen auf dem Kopierweg. Zumindest die Prüfung durch die Firmware des Quelllaufwerkes und die Prüfung der einzelnen übertragenen Byte über das Datenkabel (SATA).

Danach hört die automatische Prüfung jedoch auf (außer beim Datenkabel zum Ziellaufwerk). Verarbeitet der PC die Daten falsch (z.B. Fehler im RAM ohne ECC) werden andere Daten geschrieben wie sie gelesen wurden.

Daher gibt es Software, welche die geschriebenen Daten (nach dem Löschen der Caches vom Dateisystem) nochmal liest und mit dem Original vergleicht.

Maitry schrieb:
FAT/NTFS hat auch keine Prüfsummen.
Stimmt, dafür gibt es andere Dateisysteme wie BTRFS oder ZFS, die sowas tun. Das kostet aber Speicherplatz auf dem Medium.

Maitry schrieb:
Legt eine HDD Prüfsummen an z.B. pro Sektor?
Ja tut sie, genauso wie CD/DVD/BD und SSD. Genauso wie sie gewisse Korrekturdaten ablegen, aber halt räulich zusammen mit dem Nutzdaten. Kippt auf der BD nicht nur ein Bit (wie bei HDDs/SSDs schonmal möglich) sondern ist der gesamte Sektor nicht mehr lesbar, nützen diese Korrekturdaten auch nichts.

Das geschieht aber alles auf Laufwerks/Firmwareebene und mit Ausnahme von einigen CD/DVD Laufwerken liefert keine aktuelle Firmware die Rohdaten bzw. das Ergebnis der internen Prüfung/Korrektur der Daten. Bei einigen DVD-Laufwerken kann passende Software je Sektor ausgeben, ob der Sektor korrekt (ohne Korrektur durch das Laufwerk), mit Korrektur oder fehlerhaft gelesen werden kann.

Bzgl. Prüfsummen:
https://de.wikipedia.org/wiki/Prüfsumme
und hier dann die Methodik für CRC (die 32 steht für die 32 Bit der Prüfsummengröße)
https://de.wikipedia.org/wiki/Zyklische_Redundanzprüfung

Und bzgl. HDDs:
https://de.wikipedia.org/wiki/Festplattenlaufwerk
Logische Struktur der Scheiben
....
Jede Spur ist in kleine logische Einheiten unterteilt, die man Blöcke nennt. Ein Block enthält traditionell 512 Byte an Nutzdaten. Jeder Block verfügt dabei über Kontrollinformationen (Prüfsummen), über die sichergestellt wird, dass die Information korrekt geschrieben oder gelesen wurde.

Banned schrieb:
Das ist richtig. Aber legst du manuell Prüfsummen für alle deine Dateien an? Wie erkennst du - abgesehen von offensichtlichen Fehlern - dass die Daten okay sind?
Bei meinen gut 400k Bildern mache ich es exakt so. Da gibt es Prüfsummen für jedes Bild (erstellt direkt nach dem Kopieren von der Speicherkarte auf die SSD des PCs/Win-Tablets erzeugt, daher fallen Kopierfehler bei der ersten Sichtung der Bilder sofort auf).

Damit kann ich auch problemlos die Korrektheit des Archiv oder der Backups davon testen. Beim Rest der Daten ist es ähnlich: entweder erstelle ich dort gelegentlich selber Prüfsummen oder das Dateisystem BTRFS erledigt dies für mich.

Nur für die wenigen monatlichen Backups gibt es für eine Sicherung (derzeit auf 3 DVD+RW) par2 Dateien, mit denen ich nicht nur prüfen sondern auch Fehler korrigieren könnte ohne auf ein Backup der Daten zurück greifen zu müssen.

Banned schrieb:
Archive haben eben gerade den großen Vorteil, dass sie beim Entpacken automatisch zumindest mit CRC32 die Integrität prüfen bzw. dafür vorher automatisch eine Prüfsumme kalkuliert wird.
Dann weiss ich, dass das Archiv defekt ist. Mit viel Glück kann ich alle Daten bis auf die defekten auch wieder herstellen. Mit Pech hört unzip an der defekten Stelle auf und ich muss entweder ein zweites, intaktes Archiv besitzen oder entsprechende par2-Daten.

Was ZIP davon aktuell macht, habe ich schon lange nicht mehr getestet.

fgordon schrieb:
Wenn man einen (kleinen) Server daheim hat finde ich ist das fast ein "Muss"- denn noch wichtiger als ob Daten da sind oder nicht ist ja dass man sich darauf verlassen können muss, dass sie auch unbeschädigt sind.
In der Theorie gebe ich Dir Recht. Wenn ich mir aber ansehe, dass nachweislich (mit ext. Prüfummen) noch auf keiner meiner einfachen HDDs der letzten 20 Jahre eine Datei durhc bitrot o.Ä. kaputt gegangen ist, habe ich auch in altuelle HDDs mittlerweile soviel Vertrauen, dass ich mir überlege, ob ich für mein NAS/Heimserver noch BTRFS benötige. Von Wunsch nach einem RAID (in welcher Form auch immer) habe ich mich dort schon lange verabschiedet.

Und für so schöne Dinge wie Snapshots, Deduplikation, Kompression und was BTRFS/ZFS da noch so bieten, ist der Nutzen bei mir auch zu gering, um dafür eine moderne und sehr gut ausgestettete Maschine 24/7 laufen zu lassen.
 
  • Gefällt mir
Reaktionen: Maitry
Wieso muss man denn ein Server 24/7 laufen lassen? der läuft dann wenn man ihn braucht und sonst nicht.
Meine Server verbrauchen wenn sie laufen je 65-70 Watt - und laufen im Schnitt übers Jahr gerechnet knapp über 2h am Tag (hängen beide an einem SOnOff, der erfasst das von alleine, einer ist eh nur Backup für den anderen) Und das ist bis auf die Festplatten, Netzwerkkarten und Netzteile günstige alte Hardware. Und die meisten Heimserver sind sicher eher kleiner und verbrauchen noch weniger.

Naja ich sage mir einfach wenn ich die Vorteile von Btrfs / ZFS und Co haben kann, wieso sollte ich darauf verzichten? Ich nutze auch ECC Ram zumindest auf den Servern - weil es halt wenn man z.b. DDR3 nutzt "nichts" kostet, das wird einem fast hinterhergeworfen, weil das aus den alten Servern fliegt und 99% der Nutzer das nicht verwenden können.

Snapshots haben den Vorteil Verschlüsslungstrojaner können die Daten des Snapshots nicht verschlüssen - weil nicht mal das Betriebssystem selber die Daten darin ändern kann.

Ist eben wie mit Airbag und Co - extrem selten wird der tatsächlich gebraucht - aber wenn doch ist das halt mehr als 12 Flaschen Sonnenblumenöl wert. :D Deshalb fülle ich auch meine Backupmedien mit PAR2 auf - ich gehe nicht davon aus die wahrscheinlich zu brauchen, aber falls doch sind sie halt immer mehr wert als leerer sinnlos "verschwendeter" Platz auf den Medien.

Die Frage ist halt nicht nur wie wahrscheinlich ist es dass man das braucht, sondern wieso sollte man auf die Extra Sicherheit verzichten?
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Banned
Zurück
Oben