Guten Abend!
ich mache schon seit Jahren die Sicherungskopien, indem ich die Dateien
1 zu 1 auf das BackUp-Medium kopiere - ganz einfach per copy & past.
Zwischenzeitlich ist das BackUp-Medium fast voll da ich immer mehrere
Sicherungspunkte behalte und nur die ältesten lösche.
Nun habe ich mir überlegt ob ich das Backup nicht komprimieren soll.
7zip sagt jetzt so auf anhieb dass ich rund 40% Datenvolumen einsparen
könnte.
Welches ist nun das wohl geeignetste Dateiformat für dieses BackUp?
Wenn ich unter Win10 mit 7zip arbeite, sehe ich keine Möglichkeit dem
Archiv eine Wiederherstellungsinformation hinzu zufügen.
7zip bietet mir eben das 7z-Format, zip und tar an.
Die Option der Wiederherstellungsinformation kenne ich von *.rar -
WinRAR habe ich aber derzeit nicht installiert...
Ist das mit der Wiederherstellungsinformation im Falle eines Falles
wirklich hilfreich oder eher esoterisches Schlangenöl?
Welches Dateiformat sollte man wählen?
- Backup-Platte mit btrfs formatieren und mit erzwungener Kompression
mounten.
- Backup mit rsync
- snapshot anfertigen.
- Backup mit rsync
- Snapshot
- rsync
- Snapshot
- rsync
- Snapshot
...Etc.
Also wie die klassische Hardlinkfarm, nur ohne Hardlinks und stattdessen
mit btrfs subvolume Snapshots auf der Backup-Platte. Das komprimiert,
das ist schneller als Hardlinks, dennoch genauso inkrementell und
genauso platzsparend und alle alten Sicherungen sind auch hier nach dem
Mounten direkt zugreifbar ohne irgendwelche Software zu brauchen.
Kann ich jedem nur empfehlen. Ein Script das das macht ist schnell
geschrieben.
Für nicht-inkrementelle Backups nehme ich squashfs:
https://en.wikipedia.org/wiki/SquashFS
Das ist ein komprimiertes (gzip, lzo, xz) Archiv und lässt sich
read-only mounten.
Früher hatte ich tar.gz, tar.xz, 7z verwendet, aber um an eine einzelne
Datei oder ein Verzeichnis heranzukommen, hat mir das Auspacken und
Durchsuchen des ganzen Archivs zu lange gedauert. Mit squashfs also:
mount, cp backup/foo restore, umount.
Danke für Eure Antworten, die sind für mich aber allesamt unbefriedigend
- Schade!
7zip macht eine CRC, das ist mir bekannt.
Jedoch nützt mir diese ja nichts wenn die Datei beschädigt ist. Anhand
der CRC habe ich keine Wiederherstellungsinformation - Dieses war die
einzige, brauchbare Information, die ich hier mitnehme...
Ich bin eigentlich nicht der Typ, der in Foren bei fremden Leuten um
Hilfe bietet, und anschließend rumstänkert, aber hier muss ich jetzt
echt mal etwas los werden!
Die anderen beiden Antworten sind absolut indiskutabel!
ich frage nach einem Windowsprogramm ähnlich 7zip oder WinRAR und
bekomme als Antwort, ich solle doch die Backup-HDD mit einem
experimentellen Betatreiber in ein Windows-fremdes Dateiformat
formatieren, damit ich dann meine Sicherung abspeichern kann!?
Ich könnte natürlich auch direkt Windows den Rücken kehren und auf
openBSD oder Solaris umsteigen!
Da hatte ich ja direkt Glück, dass mir noch keiner die Sicherung auf
Lochkarte vorgeschlagen hat!
Ich habe überhaupt kein Problem mit alternativen Vorschlägen und Leuten,
die etwas weiter über den Tellerrand hinaus schauen, aber meint Ihr
nicht auch, dass ein völlig fremdes Dateiformat weit über das Ziel
hinaus schießt?
Ich hätte mir erhofft dass jemand etwas sagt wie "nimm' WinZip, da gibt
es Wiederherstellungsblöcke in der Datei", oder Verweise auf WinACE,
Plugins für 7zip ect. pp.
Naja...
Hast Du denn mit den "Wiederherstellungsinformationen", die RAR
anbietet, schon irgendwelche Erfahrungen unter Realbedingungen gemacht?
Wenn das funktioniert und also Dein Problem löst -- nimm doch einfach
RAR.
> Die anderen beiden Antworten sind absolut indiskutabel!
Nö. Du verwendest den relativ nichtssagenden Begriff
"Wiederherstellungsinformation", unter dem sich nicht jeder etwas
vorstellen kann.
Eine angemessene Antwort wäre gewesen, daß CRC nur beim Erkennen, aber
nicht beim Beseitigen von Fehlern hilft, und Du gerne ein
Kompressiondateiformat mit ECC hättest.
Diese Wiederherstellungsblöcke kannst du auch sepperat zu jeder
beliebigen Datei erzeugen.
D.h. du hast ne ZIP Datei und erstellst dann dazu mit einem Tool eine
separate Datei die die Wiederherstellungsinfos zu dieser Datei erstellt.
Das Stichwort ist Reed-Solomon. https://de.m.wikipedia.org/wiki/PAR2
Norbert schrieb:> die etwas weiter über den Tellerrand hinaus schauen
Du kannst doch von einem Unix-Freak nicht erwarten, dass er irgendetwas
ausserhalb seines Unix-Tellers vorschlägt. Meistens wird Linux dd
empfohlen,
Norbert schrieb:> Ist das mit der Wiederherstellungsinformation im Falle eines Falles> wirklich hilfreich
Das kann nur sicherstellen, dass auch Dateien, die nach der Beschädigung
liegen, wiederhergestellt werden können, manche Programme brechen da ja
einfach ab. Den Schaden an sich zu beheben geht nicht, da müsste man
redundante Daten speichern, was die Komprimierung ad absurdum führen
würde. Alles doppelt oder dreifach sichern kannst du ja selbst.
Ich benutze für Image-Sicherungen die Acronis-Versionen der
Festplattenhersteller, aber leider werden die von Version zu Version
weiter eingeschränkt. Immerhin kann man gerade noch ein Image erstellen,
sonst wären sie ja komplett sinnlos. Für Sicherungen von Teilbereichen
nehme ich auch manchmal Nero BackItUp, weil das halt mitgeliefert wurde.
Brauchbare kostenlose Backup-Software ist aus der Mode gekommen.
Viele Programme sind auch völlig überladen, z.B. weil man sich zwingend
erst mal ein Client-Server-System einrichten muss, was an einem Heim-PC
ziemlich sinnloser Aufwand ist.
Georg
georg schrieb:> Den Schaden an sich zu beheben geht nicht, da müsste man redundante> Daten speichern, was die Komprimierung ad absurdum führen würde. Alles> doppelt oder dreifach sichern kannst du ja selbst.
Wie gesagt... Reed-Solomon
Du speicherst z.B. 10% extra als Wiederherstellunginfos. Dann können bis
zu 10% der Datei fehlen (egal wo, das ist das coole dran) und du kannst
sie trotzdem komplett wiederherstellen.
Norbert schrieb:> Welches ist nun das wohl geeignetste Dateiformat für dieses BackUp
Das, von dem du nichts merkst, weil das Betriebssystem es selbst macht,
so daß auch bei einem restore alles transparent ist, keine zusätzliche
Software nötig, keine versteckenden Effekte für Suchprogramme und
direktes Öffnen so als ob es nicht komprimiert wäre:
Nimm NTFS, es erlaubt als Dateisystem eine Kompression die genau so gut
wie ZIPpen ist, einfach einschalten.
Michael B. schrieb:> Nimm NTFS, es erlaubt als Dateisystem eine Kompression
Kostet Performance, für ALLES was dort gespeichert wird. Interessant
wird auch die Rechte-Frage beim Zugriff gegenüber RAR.
Ansonsten ist natürlich ein komplettes Image mit Clonezilla eine schöne
Lösung, wo alle Programme und Einstellungen der Festplatte bitgenau
gespeichert und wenn möglich komprimiert gespeichert werden.
oszi40 schrieb:> Kostet Performance, für ALLES was dort gespeichert wird.
a) interessiert das bei einem Backup-Medium nicht
b) ist es sicher immer noch viel schneller als RAR oder ZIP vorweg
anzuwenden
c) hört man auch Gegenteiliges, wenn es nicht gerade SSD ist, weil
Kompression weniger Daten schreiben muss, weniger Sektoren, und bei
normalen Platten das Schreiben das bottleneck ist, also zeitbestimmend,
die Kompression bzw. das Expandieren hingegen von der CPU ratz-fatz
gemacht wird, beim üblichen ZIP sind alle Tabellendaten im CPU cache.
d) Man kann auch Datei- und Verzeichnisweise die Kompression einschalten
Bei Windows gibt es "Hardlinkbackup". Komprimiert nicht, versioniert
aber sehr effizient, ohne Vervielfachung gleicher Files. Kein Programm
für Restore nötig.
Was spricht gegen die Windows (10) eigene Sicherungssoftware?
Verschlüsselten Datenträger, NTFS drauf, ggfs. Komprimierung aktivieren,
inkrementell darauf sichern lassen, meinetwegen stündlich.
Läuft intern vmtl. so ähnlich ab wie das oben vorgeschlagene BTRFS (nur
besser, nicht wie btrfs+rsync, eher wie btrfs send+receive), und nur mit
Windows Bordmitteln. Kann aber sein, dass die "Home"-Version nicht
reicht.
Norbert schrieb:> Die anderen beiden Antworten sind absolut indiskutabel!> ich frage nach einem Windowsprogramm ähnlich 7zip oder WinRAR und> bekomme als Antwort, ich solle doch die Backup-HDD mit einem> experimentellen Betatreiber in ein Windows-fremdes Dateiformat> formatieren, damit ich dann meine Sicherung abspeichern kann!?
Du musst dir eingestehen, dass aus deinem Ausgangspost nicht explizit
hervorgeht, dass du etwas für Windows suchst. In diese Richtung steht da
nur "Wenn ich unter Win10 mit 7zip arbeite", und was ist, wenn nicht?
(https://de.wikipedia.org/wiki/Lakonisch#Herkunft)
Die 7z und WinRAR Formate kann man unter nicht-Windows nämlich auch
verwenden.
> Ich habe überhaupt kein Problem mit alternativen Vorschlägen und Leuten,> die etwas weiter über den Tellerrand hinaus schauen, aber meint Ihr> nicht auch, dass ein völlig fremdes Dateiformat weit über das Ziel> hinaus schießt?
Hättest du z.B. den verlinkten SquashFS Wikipedia-Artikel gelesen,
hättest du u.A. gefunden, dass "The tools unsquashfs and mksquashfs have
been ported to Windows NT[4] - Windows 8.1.[5] 7-Zip also supports
Squashfs.[6]". Das qualifiziert es IMHO jetzt nicht als "völlig fremdes
Dateiformat"...
Rufus Τ. F. schrieb:> Eine angemessene Antwort wäre gewesen, daß CRC nur beim Erkennen, aber> nicht beim Beseitigen von Fehlern hilft, und Du gerne ein> Kompressiondateiformat mit ECC hättest.test schrieb:> Das Stichwort ist Reed-Solomon. https://de.m.wikipedia.org/wiki/PAR2
Das macht die Festplatte bereits transparent auf unterster Ebene. Wenn
der TO zusätzliche Ausfallsicherheit möchte, könnte er auch ein RAID
verwenden. Oder eine zweite Platte mit einer weiteren Kopie der
Sicherung und SHA-Prüfsumme zur Fehlererkennung (hat analog georg schon
geschrieben). Andererseits möchte der TO anscheinend aber kein weiteres
physisches Medium ("[...] ist das BackUp-Medium fast voll [...] Nun habe
ich mir überlegt ob ich das Backup nicht komprimieren soll."), obwohl
eine neue Platte sicherlich nicht die Welt kosten dürfte und die
Datensicherung recht einfach umzusetzen wäre.
georg schrieb:> Norbert schrieb:>> die etwas weiter über den Tellerrand hinaus schauen>> Du kannst doch von einem Unix-Freak nicht erwarten, dass er irgendetwas> ausserhalb seines Unix-Tellers vorschlägt. Meistens wird Linux dd> empfohlen,
Beziehungsweise das mit dd nicht verwandte GNU ddrescue:
https://www.gnu.org/software/ddrescue/ (CTRL-F "compression of backups")
https://en.wikipedia.org/wiki/Ddrescuehttp://www.nongnu.org/lzip/lzip.html> The lzip format provides very safe integrity checking and some data> recovery means. The lziprecover program can repair bit-flip errors> (one of the most common forms of data corruption) in lzip files, and> provides data recovery capabilities, including error-checked merging of> damaged copies of a file.http://www.nongnu.org/lzip/lziprecover.html> Lziprecover is able to repair slightly damaged files, produce a correct> file by merging the good parts of two or more damaged copies, extract> data from damaged files, decompress files and test integrity of files.
Je nachdem, wie kompliziert du es dir machen willst, würde ich folgende
Vorschläge machen (nach Aufwand sortiert)
- weitermachen wie bisher und zusätzliche Festplatte anschaffen, alte
ins Archiv und/oder auch auf die neue kopieren, falls die alte
verhältnismäßig klein ist
- NTFS-Kompression einschalten. Zumindest auf drehenden Scheiben erhöht
es (bei mir zumindest) den Datendurchsatz bei gleichzeitiger
Platzersparnis bei geringer CPU-Mehrbelastung
- (Einfache ZIPs wären hier, würde ich aber nicht empfehlen, weil es das
Durchsuchen erschwert und kaum Vorteile gegenüber NTFS- oder anderer
transparenter Kompression bringt
- Windows Sicherung
- Duplicati
- Ein NAS mit ZFS, Cloudspeicher etc
Wenn du zusätzlich Sorge vor Bitfehlern oder sonstwas hast, dann erstell
zusätzlich Paritydaten mit MultiPar, gegen schimmelnde Bits reicht 1%
Redundanz meiner Meinung nach aus
Jiri D. schrieb:> Das macht die Festplatte bereits transparent auf unterster Ebene
War aber ausdrücklich gewünscht. Und ist eine extra Hilfe bei einer
evtl. notwendigen Datenrettung.
Unbedingt notwendig ist es bei HDD Backups natürlich nicht.
test schrieb:> Jiri D. schrieb:>> Das macht die Festplatte bereits transparent auf unterster Ebene>> War aber ausdrücklich gewünscht. Und ist eine extra Hilfe bei einer> evtl. notwendigen Datenrettung.
Ja, schon. Aber eine Platte, bei der so viele Fehler auftreten, dass sie
nicht mehr durch die interne Fehlerkorrektur ausgeglichen werden können,
würde ich auch nicht mehr so ganz über den Weg trauen. Fehler
korrelieren oft ja mit weiteren Fehlern.
IMHO ist die einfachste Lösung eine zweite Platte und das (ggf.
komprimierte) Backup auf beiden Platten abzuspeichern.
Jiri D. schrieb:> IMHO ist die einfachste Lösung eine zweite Platte und das (ggf.> komprimierte) Backup auf beiden Platten abzuspeichern.
Erst wenn die Daten auf mindestens 2 separaten Datenträgern vorliegen,
ist es überhaupt ein Backup. Nur auf einem Datenträger vorhanden, ist es
eine Ablage und mehr nicht.
Zippen tue ich nur, wenn ich mehrere Dateien zusammenfassen will (z.B.
Gerber-Daten für die Platinenfertigung).
Ansonsten einfach unter NTFS bei Komprimierung das Häckchen setzen.
Große Dateien (Fotos, Videos, Musik) sind aber in der Regel schon
komprimiert (jpeg, mp4, mp3).
Peter D. schrieb:> Erst wenn die Daten auf mindestens 2 separaten Datenträgern vorliegen,> ist es überhaupt ein Backup. Nur auf einem Datenträger vorhanden, ist es> eine Ablage und mehr nicht.
Nach dem ersten Virus wird er froh sein, wenn er noch einige gesunde
Platten im Schrank findet. Deswegen sind ein paar kleine 2TB Platten
sinnvoller als nur eine große. Kein kluger Bauer legt alle Eier in EINEN
Korb!
Peter D. schrieb:> Nur auf einem Datenträger vorhanden, ist es> eine Ablage und mehr nicht.
Es ist noch schlimmer: hat man einen Fehler auf der Original-Platte,
überschreibt man beim Sichern die bis dahin noch vorhandene korrekte
Sicherung mit den fehlerhaften Daten. Bricht die Sicherung wegen des
Fehlers ab hat man GARNICHTS mehr.
Erstaunlicherweise wird dieses Szenario immer vollkommen ignoriert,
obwohl ein Harddisk-Fehler ja nicht soo unwahrscheinlich ist. Wenn alles
perfekt wäre bräuchte man ja keine Sicherung.
Georg
Wer ein Backup machen will, sollte auch ein Backup-System nutzen und
nicht mit Zip herumfummeln.
Ich persönlich teste gerade dies hier und finde es sehr angenehm zu
nutzen:
https://www.duplicati.com/
oszi40 schrieb:> Michael B. schrieb:>> Nimm NTFS, es erlaubt als Dateisystem eine Kompression>> Kostet Performance, für ALLES was dort gespeichert wird. Interessant> wird auch die Rechte-Frage beim Zugriff gegenüber RAR.
Mit NTFS kann man auch auf Verzeichnisbasis komprimieren, das
funktioniert super. Man sollte sich aber klar machen, das die
Kompression von NTFS aus Performancegründen nur eine schwache
Kompression ist. Mit zip und 7z in den besten Modi kann sie nicht
mithalten.
Bei reinen Backupdaten ist die Performance ziemlich egal.
Ich selbst nutze die NTFS Kompression sogar für den Map Ordner des
Computerspieles ARK. Damit habe ich ca. 50 GB Speicherplatz eingespart
bzw. wieder freibekommen und Performancetechnisch hat es da auch keinen
großen Unterschied gemacht, weil die Kompressionsrate schwach ist und
das Nadelöhr eher das Laden vom Blockdevice ist, als die
Echtzeitdekompression auf der CPU. Es ist somit sogar möglich, dass das
Laden schneller geht, vor allem bei Festplatten.
@Threadstarter
Der Hinweis auf par2 und Read-Solomon würde ich auch ebenfalls geben.
Das Programm solltest du dir also durchaus mal ansehen:
https://de.wikipedia.org/wiki/PAR2
Ansonsten wäre ich bei Kompression generell vorsichtig, gerade weil die
Daten zusammengestaucht werden und schon kleine gekippte Bits genügen,
dass man dann an die Daten nicht mehr herankommt, wenn man eine
Kompression verwendet hat, die keine Korrektur der Daten erlaubt.
Zum Testen kann man übrigens ein paar Daten komprimieren und dann mit
einem Hexeditor ein paar Bits der komprimierten Datei umkippen.
Wie gut dann das Kompressionsprogramm dann die Daten wieder entpacken
kann, kann man so direkt ausprobieren.
Ich würde zu dem keine proprietären Programme für die Datensicherung
einsetzen, außer die, die von Windows direkt kommen.
Immerhin muss auch gewährleistet sein, dass man an die Daten auch noch
in ein paar Jahren herankommt.
Offene Formate wie ZIP und PAR2 zu dem es auch Open Source Software
gibt, wären also der richtige Weg.
Ansonsten sei noch gesagt, dass die Nutzung der Betriebssystemfunktion,
also bspw. die Kompression mit NTFS in der Praxis sehr bequem und
transparent ist.
Alles andere, wie bspw. ZIP + PAR2 ist mit wesentlich mehr Arbeit
verbunden.
Besser als NTFS wäre allerdings ZFS oder BTRFS.
Unter Windows gibt's die beiden letzteren Formate allerdings nicht, aber
dafür gibt es dort, sofern man eine Enterprise oder Pro Version besitzt
ReFS.
Bei Platzproblemen kann man sich übrigens auch über ein NAS Gedanken
machen.
Da kann man dann ein paar Festplatten bei Bedarf einfach dazustecken.
Natürlich ist ein NAS kein Backup, aber wenn man es nicht dauernd im
Netzwerk hängen hat, kann man es durchaus auch wie ein Backup nutzen.
Ideal wären hier zwei NAS Geräte.
Etwas OT, aber dennoch:
1. gutes OS nutzen
2. ZFS
Mit diesem Windows-Müll wird man immer wieder an Grenzen stoßen - und
wer Windows zwingend braucht, kann es unter MacOS, BSDs oder Linux
virtuell laufen lassen, dann stellt sich auf Windows Ebene die
Backupfrage auch nicht
Nano schrieb:> ZFS z.B. zusammen mit FreeNAS ist natürlich am besten.> Man sollte dann dafür aber auch einen Rechner mit ECC RAM einsetzen.
Das mit ECC ist schon richtig - aber ich muss gestehen, dass dass einige
meiner Rechner auf denen FreeBSD mit ZFS läuft, kein ECC haben;-)
Schau Dir mal Drive Snapshot http://www.drivesnapshot.de/de/ an, das
nutze ich seit Jahren auf meinen (wenigen) Windows-Rechnern. Es ist ein
sektorbasiertes Image-Programm, welches differentiell arbeitet,
komprimiert, man kann auch verschlüsseln und man kann konsistente !!!
Backups im laufenden !!! Betrieb erstellen. Interessant ist auch, dass
man die Sicherungs-Dateien als Laufwerk einhängen und so einzelne
Dateien und Ordner lesen kann. Gibt es jedes Jahr auf der c't-CD mit
einer Jahres-Lizenz bzw. von der Homepage als Test-Lizenz für 30 Tage.
Walter K. schrieb:> Nano schrieb:>> ZFS z.B. zusammen mit FreeNAS ist natürlich am besten.>> Man sollte dann dafür aber auch einen Rechner mit ECC RAM einsetzen.>> Das mit ECC ist schon richtig - aber ich muss gestehen, dass dass einige> meiner Rechner auf denen FreeBSD mit ZFS läuft, kein ECC haben;-)
Wenn du wegen einem kippenden Bit deinen zpool verlierst ist der
entstandene Schaden groß.
Ich hoffe du hast Backups und dir ist das Risiko bewusst.
Ansonsten würde ich in so einem Fall lieber auf ext4 setzen, da sind die
Auswirkungen nicht ganz so verheerend, wenn im RAM mal ein Bit kippt.
Nano schrieb:> Wenn du wegen einem kippenden Bit deinen zpool verlierst ist der> entstandene Schaden groß.> Ich hoffe du hast Backups und dir ist das Risiko bewusst.
Wenn man ZFS nimmt, macht man natürlich Snapshots! Das ist ja gerade
neben vielen anderen Dingen das Geniale!
Und ext4 ist ja eher was für Linux - aber nicht für BSD oder MacOS
Man sollte hier auch nicht den Eindruck erwecken, so wie das von
Linux-Jüngern gerne getan wird, dass ZFS für die meisten nichts sei, nur
weil außerhalb der Serverwelt in seltensten Fällen ein Rechner ECC RAM
hat!
Walter K. schrieb:> Wenn man ZFS nimmt, macht man natürlich Snapshots!
Nur werden Snapshots auf dem gleichen Festplattenplatz gespeichert - das
hat mit Backup nicht das geringste zu tun. Ein Backup ist nur ein
sinnvolles Backup auf einem anderen Medium, egal ob andere Festplatte,
DVD, Band oder Cloud. Und wie schon erwähnt, nicht nur von mir, nicht
nur ein Backup, sondern mindestens zwei.
Georg
georg schrieb:> Walter K. schrieb:> Wenn man ZFS nimmt, macht man natürlich Snapshots!>> Nur werden Snapshots auf dem gleichen Festplattenplatz gespeichert - das> hat mit Backup nicht das geringste zu tun. Ein Backup ist nur ein> sinnvolles Backup auf einem anderen Medium, egal ob andere Festplatte,> DVD, Band oder Cloud. Und wie schon erwähnt, nicht nur von mir, nicht> nur ein Backup, sondern mindestens zwei.>> Georg
Es ist richtig, dass Snapshots grundsätzlich kein Backup ersetzen!
Es ist auch richtig, dass Snapshots erstmal auf dem ZFS Datenträger
liegen - aber wer Snsoshots auf ZFS Ebene macht, wird dann natürlich
auch so klug sein und diese automatisch auf ein anderes Medium
exportieren lassen.
Somit entsteht ( für privat und wenig sensiblen Bereich ) sehr wohl ein
Backupersatz!
Wenn dann noch die Datasets im ZFS klug angelegt sind und auf dem System
Windows und Linux Maschinen virtuell laufen ist das sogar vorteilhafter
als so mancher Backupmurx!
Norbert schrieb:> Ist das mit der Wiederherstellungsinformation im Falle eines Falles> wirklich hilfreich oder eher esoterisches Schlangenöl?
Du willst ein Backup eines Backups? Wozu?
Wenn du dem Backup-Medium nicht traust, ist
das Backup an sich zu hinterfragen.
Regelmäßig Backups in einer Art, dass einzelne
Dateien zugreifbar sind und gut ist.
merciless
Walter K. schrieb:> Nano schrieb:>> Wenn du wegen einem kippenden Bit deinen zpool verlierst ist der>> entstandene Schaden groß.>> Ich hoffe du hast Backups und dir ist das Risiko bewusst.>> Wenn man ZFS nimmt, macht man natürlich Snapshots! Das ist ja gerade> neben vielen anderen Dingen das Geniale!
Ein Snapshot schützt dich bei einem Verlust des zpools nicht!
Wenn der zpool kaputt ist, dann ist alles was da drin ist, verloren.
Auch deine Snapshots.
> Und ext4 ist ja eher was für Linux - aber nicht für BSD oder MacOS
Das ist richtig.
Ich bezog mich auch eher auf ein NAS.
Hat man keinen Rechner mit ECC RAM um FreeNAS zu verwenden, dann kann
man bspw. OpenMediaVault verwenden, das ist Linux basiert und bietet
etc4 und btrfs.
Das gleiche gilt für Synology NAS Geräte.
> Man sollte hier auch nicht den Eindruck erwecken, so wie das von> Linux-Jüngern gerne getan wird, dass ZFS für die meisten nichts sei, nur> weil außerhalb der Serverwelt in seltensten Fällen ein Rechner ECC RAM> hat!
Darum geht es überhaupt nicht. Es geht darum, dass es fahrlässig ist,
ZFS auf einem Rechner ohne ECC RAM einzusetzen.
Das liegt vor allem daran, weil ZFS im RAM eine Datenstruktur aufbaut
von der ZFS im laufenden Betrieb vollständig abhängig ist.
Kippt da ein Bit, dann ist im Worst Case Fall dein pool Schrott.
Bei ext4 & Co, also den klassischen Dateisystemen (btrfs gehört nicht
dazu) ist das anders, die hangeln sich, vereinfacht ausgedrückt, auf dem
Speichermedium quasi durchs Dateisystem, die Chance, dass du dir damit
das gesamte Dateisystem schrottest, nur weil ein Bit im RAM kippt ist
praktisch kaum vorhanden. Im Notfall hast du umfangreiche
Reparaturmechanismen.
ZFS und btrfs spannen bspw. Baumstrukturen im RAM auf, wenn ein Knoten
in die falsche Speicheradresse verweist, weil ein Bit gekippt ist, war's
das.
ZFS vertraut dem RAM, es vertraut nicht dem Datenträger.
Bei EXT4 ist es genau umgekehrt.
Siehe dazu die Doku von FreeNAS.
Wer also FreeBSD einsetzt, aber keinen Rechner mit ECC RAM hat, der
sollte besser UFS2 verwenden, das gibt es für FreeBSD.
Nano schrieb:> ZFS vertraut dem RAM, es vertraut nicht dem Datenträger.> Bei EXT4 ist es genau umgekehrt.
Kleine Korrektur.
EXT4 vertraut dem Datenträger.
Dass das RAM sauber arbeitet, davon geht es aus, wenn aber was passiert,
sind die Auswirkungen nicht so schlimm.
Nano schrieb:>> Wenn man ZFS nimmt, macht man natürlich Snapshots! Das ist ja gerade>> neben vielen anderen Dingen das Geniale!>> Wenn der zpool kaputt ist, dann ist alles was da drin ist, verloren.> Auch deine Snapshots.
Snapshot im Filesystem für Wiederherstellung einzelner Files oder
Directories, z.B. wenn man im Excel Mist gebaut hat und die Version vom
letzten Freitag braucht. Separate Disks für Defekt/Verlust des
Filesystems - da sind aber nicht viele Stände nötig, kann auch Image
sein.
Wer dem obigen Link im FreeNAS Forum folgt, der wird auch irgendwann auf
diese Praxiserfahrung stoßen:
https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/page-4#post-87136
Mit defektem RAM schreibt man sich bei ZFS also praktisch den ganzen
pool kaputt. Die Erklärung findet man im Link, den ich schon im
vorherigen Kommentar genannt habe.
Also, man kann es drehen und wenden wie man will, aber wenn man einen
Rechner ohne ECC RAM hat, dann sollte man tunlichst kein ZFS verwenden.
Dann ist jedes normale andere Dateisystem in dem Fall besser geeignet.
Nano schrieb:> Wer dem obigen Link im FreeNAS Forum folgt, der wird auch> irgendwann auf diese Praxiserfahrung stoßen:>> https://forums.freenas.org/index.php?threads/ecc-v...>> Mit defektem RAM schreibt man sich bei ZFS also praktisch den ganzen> pool kaputt. Die Erklärung findet man im Link, den ich schon im> vorherigen Kommentar genannt habe.>> Also, man kann es drehen und wenden wie man will, aber wenn man einen> Rechner ohne ECC RAM hat, dann sollte man tunlichst kein ZFS verwenden.> Dann ist jedes normale andere Dateisystem in dem Fall besser geeignet.
Sorry - aber solche pauschalen Aussagen sind Blödsinn!
Die meisten Leute, die privat FreeBSD, Solaris oder Forks von diesen
Systemen nutzen haben eben keine Maschine mit ECC RAM - und nutzen
trotzdem ZFS!
Ich habe ZFS sogar auf fast allen Memory Sticks.
Es stimmt, dass RAM Fehler einen ZFS Pool zerstören können ... aber die
können auch noch ganz andere Schäden verursachen.
Anstatt hier die Leute mit pauschalen Aussagen zu verunsichern - besser
einfach mal selbst mit arbeiten!
Nano schrieb:> Mit defektem RAM schreibt man sich bei ZFS also praktisch den ganzen> pool kaputt.
Es muß nich immer der RAM kaputt sein. Es reicht schon wenn der Strom
mal weg ist. Dann ist Dein RAM auch leer! Schöne Sicherheit!
georg schrieb:> Nur werden Snapshots auf dem gleichen Festplattenplatz gespeichert
Man kann auch snapshots auf dem Backupmedium machen um inkrementelles
Backup zu implementieren (Snapshots als Ersatz für Hardlinks):
rsync -> snapshot
rsync -> snapshot
rsync -> snapshot
usw.
oszi40 schrieb:> Es muß nich immer der RAM kaputt sein. Es reicht schon wenn der Strom> mal weg ist.
Dann würde jemand wie ich geneigt sein ZFS als ein Dateisystem im
hochexperimentellen Betastadium zu betrachten das tunlichst noch nicht
für produktive Zwecke eingesetzt werden sollte solange bis diese Bugs
gefixt sind.
Dirk K. schrieb:> Du willst ein Backup eines Backups? Wozu?
Redundanz. Ohne Redundanz ist ein Backup nur ein Schritt vor dem
Abgrund.
> Wenn du dem Backup-Medium nicht traust, ist> das Backup an sich zu hinterfragen.
Nö, siehe Redundanz.
Obendrein ist ein archivierendes Backup sinnvoll. Wenn man nur ein
Backup hat (z.B. den Stand von gestern abend), dann hat man ein Problem,
wenn man feststellt, daß Daten vor dem Erstellen des Backups bereits
verschwunden sind/beschädigt wurden.
Bei einem archivierenden Backup kann man in so einem Fall einen älteren
Stand rekonstruieren.
Walter K. schrieb:> Sorry - aber solche pauschalen Aussagen sind Blödsinn!
Nein, lies einfach mal den Beitrag vom Moderator des FreeNAS Forums.
> Die meisten Leute, die privat FreeBSD, Solaris oder Forks von diesen> Systemen nutzen haben eben keine Maschine mit ECC RAM - und nutzen> trotzdem ZFS!
Es gibt auch Leute, die fahren > 250 km/h auf der Autobahn.
Nur weil es geht, bedeutet es nicht, dass es besonders weise ist.
> Ich habe ZFS sogar auf fast allen Memory Sticks.
Es geht nicht darum, worauf du dein ZFS verwendest, sondern welche
Maschinen davon auch ECC RAM haben.
> Es stimmt, dass RAM Fehler einen ZFS Pool zerstören können ... aber die> können auch noch ganz andere Schäden verursachen.
Richtig, es gibt aber trotzdem einen Unterschied zwischen totaler
Zerstörung und lokal begrenzten Auswirkungen.
Und natürlich ersetzt man defektes RAM so schnell wie möglich, aber wenn
ein Defekt auftritt, dann hast du recht schlechte Chancen bis du den
Defekt wirklich bemerkst. Das kann dann an dem Tag sein, bei dem dir
dein Rechner beim hochfahren meldet, dass er zpool kaputt ist.
> Anstatt hier die Leute mit pauschalen Aussagen zu verunsichern - besser> einfach mal selbst mit arbeiten!
Ich nutze zfs!
Ich habe hier nämlich einen FreeNAS NAS Server und selbstverständlich
hat der auch ECC RAM.
Würde ich aber zfs nutzen, wenn ich mir für mein NAS keine Hardware mit
ECC RAM gekauft hätte?
Nö, würde ich nicht. Ohne ECC RAM würde ich was anderes nutzen und das
eben aus gutem technischen Grund, die ich eben kenne. Ich wähle nicht
einfach rein nach ideologischen Gesichtspunkten ein Dateisystem aus.
oszi40 schrieb:> Nano schrieb:>> Mit defektem RAM schreibt man sich bei ZFS also praktisch den ganzen>> pool kaputt.>> Es muß nich immer der RAM kaputt sein. Es reicht schon wenn der Strom> mal weg ist. Dann ist Dein RAM auch leer! Schöne Sicherheit!
Richtig, aus dem Grund habe ich für das NAS eine USV.
Der Zappelstrom kann also ruhig kommen, ich bin vorbereitet.
Schwachstellen gibt's dann zwar beim nicht redundanten Netzteil oder der
Rechnerkomponenten selbst, die können ja auch irgendwann ausfallen, aber
irgend einen Tod muss man immer sterben.
Die wahrscheinlichsten Schwachstellen sind bei mir minimiert. Ansonsten
gibt's noch das gute alte Backup.
Bernd K. schrieb:> oszi40 schrieb:>> Es muß nich immer der RAM kaputt sein. Es reicht schon wenn der Strom>> mal weg ist.>> Dann würde jemand wie ich geneigt sein ZFS als ein Dateisystem im> hochexperimentellen Betastadium zu betrachten das tunlichst noch nicht> für produktive Zwecke eingesetzt werden sollte solange bis diese Bugs> gefixt sind.
Das ist nicht fixbar, da es prinzipbedingt vom Design abhängt.
Wenn du aber ECC RAM und eine USV hast, dann ist zfs für den Einsatz auf
NAS Geräten das wahrscheinlich beste Dateisystem überhaupt.
Theoretisch könnte an der Stelle auch btrfs stehen, aber das ist noch
nicht so weit.
Hat man keinen Rechner mit ECC RAM, dann ist man mit ext4 besser
beraten.
Gibt es eigentlich Filesysteme bzw. Archivsysteme, die Daten nach
einiger Zeit und nach bestimmten Regeln in offline Bereiche verschieben?
Das ganze wäre natürlich mit einem open source Filesystem wie ext4 oder
xfs schön ....
Norbert schrieb:> Die anderen beiden Antworten sind absolut indiskutabel!> ich frage nach einem Windowsprogramm ähnlich 7zip oder WinRAR und> bekomme als Antwort, ich solle doch die Backup-HDD mit einem> experimentellen Betatreiber in ein Windows-fremdes Dateiformat> formatieren, damit ich dann meine Sicherung abspeichern kann!?
In deinem Eingangspost hast du Windows mit keiner Silbe erwähnt.
BTRFS verwende ich in mehreren Gentoo-Systemen, welche am Tag mehr Last
sehen als andere Systeme über ihre komplette Lebensdauer. Ich bin sehr
zufrieden damit und kann es nur empfehlen.
wrzl schrieb:> Gibt es eigentlich Filesysteme bzw. Archivsysteme, die Daten nach> einiger Zeit und nach bestimmten Regeln in offline Bereiche verschieben?
Was verstehst du hier unter offline Bereich?
In der ernstgemeinten Datentechnik gibt es derartige Systeme, "offline"
sind Daten, die z.B. auf Bänder ausgelagert werden. Auf die kann mit
einer gewissen merklichen Zeitverzögerung lesend zugegriffen werden
(Tapelibrary lädt Bandkassette, Bandgerät spult Band hin & her und lädt
gewünschte Datei).
Das aber ist recht hochpreisige Technik, allein ein simples (aber
ernstgemeintes) Bandlaufwerk kostet jenseits der 1000 EUR, die
Tapelibrary (ein Gerät, das mehrere Bänder automatisch dem Bandlaufwerk
zuführen kann) kostet auch so einiges, und die für den Betrieb nötige
Infrastruktur (SAS- oder Fibrechannel-Hostcontroller etc.) kommt neben
der nötigen Software noch dazu.
Mit anderen Worten: Die wenigsten von uns werden solchen Installationen
begegnen.
Anon Y. schrieb:> In deinem Eingangspost hast du Windows mit keiner Silbe erwähnt.
Naja, "Win" ist doch eine Silbe von "Windows" ...
Norbert schrieb:> Wenn ich unter Win10 mit 7zip arbeite, sehe ich keine Möglichkeit dem> Archiv eine Wiederherstellungsinformation hinzu zufügen.
Nano schrieb:> Wenn du aber ECC RAM und eine USV hast, dann ist zfs für den Einsatz auf> NAS Geräten das wahrscheinlich beste Dateisystem überhaupt.
Das bezweifle ich, nachdem ich zahlreiche kranke USVs mit magelhafter
Wartung erlebt habe und ob Dein NAS zwei Netzteile hat, wovon eins OHNE
USV auskommt, weiß ich nicht. Ein "schönes" Dateisysem ersetzt noch
keine Backups im Schrank.
unter windows paar externe xTB platten, ntfs drauf und hardlinkbackup.
KISS prinzip.
* an die "kompressionsrate" von hardlinks kommt kein
kompressionsprogramm ran.
* es wird zum datei suchen/restoren kein spezialprogramm benötigt.
* backup und restore brauchen keine prozessorzeit (wie
kompressionsprogramme), nur plattenzugriff
nachteil:
* offene dateien können ggf. nicht gesichert werden. windows interner
design fuckup.
* wie bei jedem backup… man muss es halt machen, ggf platten austauschen
um mehr als ein medium zu haben. es macht halt zusätzliche arbeit - aber
eigentlich nicht viel.
ich "sichere" meine windows spielekiste bei jedem herunterfahren.
steam verzeichnis, c:\users und dergleichen auf eine interne 2TB platte.
auf arbeit und meinen restlichen rechnern läuft linux, und da mach ichs
im prinrip genauso - halt mit rsync und selbstgeschriebenem script
anstatt windows-klickibunti.
ah nochwas.
im windows spielerechner hab ich 3 platten.
1TB SSD fürs betriebssystem und spiele, 2TB für hardlinkbackup, und eine
weitere 2TB platte zum sichern der ersten.
auf dieser 3. platte ist ein linux, clonezilla. davon kann ich booten
und die SSD komplett sichern.
mach ich in unregelmäßigen abständen um vor windows-update fuckups
sicher(er) zu sein.
diese zusätzlichen platten musste ich nicht zusätzlich für windows
kaufen, sondern die sind übrig geblieben, als ich die linux
sicherungsplatten von 2 auf 4/8 TB geupdatet habe.
sowas "hat man"/"passiert" wenn man mal damit anfängt backups zu machen.
c.m. schrieb:> auf dieser 3. platte ist ein linux, clonezilla.
Clonezilla ist mit einem USB-Stick zufriedenzustellen, dafür muss man
keine komplette Platte reservieren. Oder meinst Du damit den Speicherort
für erstellte Images?
Ansonsten: Beachte bei Deinen Wechselrahmen die Anzahl der Steckzyklen,
die die SATA-Steckverbinder durchstehen. Die ist nicht besonders hoch.
Rufus Τ. F. schrieb:> Mit anderen Worten: Die wenigsten von uns werden solchen Installationen> begegnen.
Und es werden seit Jahren immer weniger. Auch Bandroboter werden ggf
durch sekundäre oder tertiäre Disk-Speicher ersetzt, wenn die
Räumlichkeiten eine ausreichende Trennung ermöglichen, oder eine Leitung
in eine andere Lokation billiger ist als ein Turnschuhnetzwerk. Sei es
über Replikationsmechanismen von NAS-Systemen oder Backup-Programmen,
sei es in Form von Bandemulation für alte Softwarestrukturen.
Wenn man sich hier die ganzen Kommentare zu ZFS durchliest - und
zusammenfasst weshalb ZFS nun absolut ungeeignet sei:
- hoch experimentell
- nur mit ECC RAM
- nur mit USV
- nur mit redundanten Powersupplies
- Snapshots in anderen Pool auf anderes Device exportieren: zu schwierig
Etc. pp
dann muss es den Windows und Linux-Anhängern schon ziemlich weh tun,
dass sie es nicht oder nur sehr eingeschränkt nutzen können.
LOL
Walter K. schrieb:> - hoch experimentell
Es war mal üblich, Datasheets so lange als "preliminary" zu
kennzeichnen, bis die Halbleiter aus der Produktion liefen. In diesem
Sinn sind wohl alle Filesysteme so lange hoch experimentell, bis sie
derart veraltet sind, dass sie in neuen Systemen allmählich abgelöst
werden. ;-)
> - nur mit ECC RAM
Was ich bei Fileservern mit kritischem Inhalt generell empfehlen würde,
ob ZFS oder nicht. Schrott ist Schrott und Schrott in zentralen
Metadaten kann sich auch bei anderen Filesystemen grossflächig
auswirken.
> - nur mit USV
Nein. Gerade COW Filesysteme sind vom Verfahren her gut in der Lage, mit
Crashes und Powerdowns zurecht zu kommen. Vorausgesetzt, die Ordnung der
Schreibzugriffe des Filesystems auf die realen Devices wird nicht von
unabhängig arbeitenden Caches konterkariert.
Oben wurde der Fall von Speicherverlust genannt, indem ein kurzzeitiger
Stromausfall zu teilweisem Ausfall einzelner Systemkomponenten wie RAM
führt, ohne dass das System dies erkennt. Wenn man dem System nicht über
den Weg traut, kann eine USV helfen. Besser ist es freilich, ein System
zu bauen, in dem dieser Fall erkannt wird.
Wenn man ein von Haus aus instabiles Filesystem verwendet (wie FAT
Varianten), oder die Geduld für ausgiebige Filesystem-Checks nach einem
Blackout nicht aufbringen kann, ist eine USV sinnvoll. Das betrifft
allerdings idR nur betriebliche Umgebungen. Wenn das Stromnetz etliche
Male im Jahr die Grätsche macht, dann ist das auch eine Überlegung wert.
> - nur mit redundanten Powersupplies
Wenn man anderseits ein sehr gutes Stromnetz und eine miese USV hat,
kann man sich mit einem redundanten Netzteil wenigstens gegen Ausfälle
der USV absichern (die sind nicht so selten). ;-)
Firmen verwenden redundante Netzteile routinemässig weil
- sie technisch einfach zu realisieren sind,
- verglichen mit anderer Redundanz nicht viel kosten,
- häufiger Defekte haben als andere Komponenten.
Rufus Τ. F. schrieb:> c.m. schrieb:>> auf dieser 3. platte ist ein linux, clonezilla.>> Clonezilla ist mit einem USB-Stick zufriedenzustellen, dafür muss man> keine komplette Platte reservieren. Oder meinst Du damit den Speicherort> für erstellte Images?
ich hab clonezilla direkt auf platte installiert und sichere auch auf
diese platte. so spar ich mir das rumgefummel mit einem usb-stick.
einfach beim booten F12 -> WDC platte auswählen und los gehts.
> Ansonsten: Beachte bei Deinen Wechselrahmen die Anzahl der Steckzyklen,> die die SATA-Steckverbinder durchstehen. Die ist nicht besonders hoch.
die bleiben normalerweise drin - ist nur der windows rechner, nur
spiele. nichts was ich ernsthaft sichern muss.
c.m. schrieb:> ich "sichere" meine windows spielekiste bei jedem herunterfahren.> steam verzeichnis, c:\users und dergleichen auf eine interne 2TB platte.
Wozu das Steamverzeichnis?
Das kann man ja alles neu downloaden.
Sichern muss man eigentlich nur die Spielstanddaten, die im Steamordner
im Ordner userdata liegen, sowie natürlich das, was man unter users an
Daten, Spielständen, Dokumenten usw. hat.
Aus dem Grund habe ich, als ich noch kein NAS hatte, meine Daten per
selbst geschriebener rsync Skripte auf eine externe Platte gesichert.
So konnte ich ganz gezielt nur das sichern, was ich auch wirklich
sichern muss und nicht das, was ich auch wieder downloaden kann oder
sonst irgendwie als für Backups unnütze Daten anfällt.
Damit sinkt auch das Risiko, dass man Schadsoftware mit aufs Backup
sichert. Denn die installierten Programmordner werden so ja nicht
mitgesichert.
Erwähnenswert wäre noch, dass ich die rsync Skripte unter Linux für die
Bash geschrieben habe und somit für ein Backup, auch für die Daten unter
Windows, Linux boote.
Das hat den Vorteil, dass ich die Skripte auch dann anwenden kann, wenn
mein Windows aus welchen Gründen auch immer, Probleme macht.
Ich benötige dann unter Windows auch kein cygwin und dergleichen, kann
dennoch rsync nutzen und meine Daten kann ich so dann auch auf andere
Dateisysteme, als ntfs, auf der externen Festplatte sichern.
Walter K. schrieb:> Wenn man sich hier die ganzen Kommentare zu ZFS durchliest - und> zusammenfasst weshalb ZFS nun absolut ungeeignet sei:>> - hoch experimentell>> - nur mit ECC RAM>> - nur mit USV>> - nur mit redundanten Powersupplies>> - Snapshots in anderen Pool auf anderes Device exportieren: zu schwierig>> Etc. pp>>> dann muss es den Windows und Linux-Anhängern schon ziemlich weh tun,> dass sie es nicht oder nur sehr eingeschränkt nutzen können.>> LOL
Wenn du etwas über zfs wissen willst, dann schau dir dazu einfach mal
diesen Vortrag an:
https://www.youtube.com/watch?v=knKedtlCsa8
Danach wirst du auch zfs einsetzen wollen. :)
A. K. schrieb:>> Firmen verwenden redundante Netzteile routinemässig weil> - sie technisch einfach zu realisieren sind,> - verglichen mit anderer Redundanz nicht viel kosten,> - häufiger Defekte haben als andere Komponenten.
Ich würde das auch machen, wenn der Markt redundante Netzteile mit
leisen langsam drehenden großen Lüftern > 120 mm anbieten würde.
Tut er aber leider nicht und die 40 mm Brülllüfter, die in redundanten
Servernetzteilen verbaut werden, kann ich in meinem NAS, welches in
meiner Wohnung steht, nicht gebrauchen.
Mit entsprechendem Platz im Keller wäre das natürlich einfacher, aber
das hat dann andere Nachteile.
Bezüglich Ausfallsicherheit hat sich die gesamte Industrie leider nur
auf Firmenumgebungen spezialisiert. An die Privatkunden hat keiner
gedacht.
Nano schrieb:> Ich würde das auch machen, wenn der Markt redundante Netzteile mit> leisen langsam drehenden großen Lüftern > 120 mm anbieten würde.> Tut er aber leider nicht und die 40 mm Brülllüfter, die in redundanten> Servernetzteilen verbaut werden, kann ich in meinem NAS, welches in> meiner Wohnung steht, nicht gebrauchen.
Habe ich selber getauscht. Den 40er intern einfach mit R in der Spannung
halbiert und auf die einblasende Seite gesetzt und dann von aussen am
Gehäuse einen 120er drauf, der richtig rauszieht.
Nano schrieb:> Tut er aber leider nicht und die 40 mm Brülllüfter, die in redundanten> Servernetzteilen verbaut werden, kann ich in meinem NAS, welches in> meiner Wohnung steht, nicht gebrauchen.
Abgesehen von der Powerup-Phase können Tower-Server wie beispielsweise
der Dell T320 bemerkenswert leise sein. Trotz kleiner Netzteil-Lüfter.
Nicht immer stehen solche Typen in einem separaten Raum.
Offline Medien müssten ja nicht unbedingt Tapes sein. Eine billige 4TB
sata Platte ist günstiger als eine entsprechende Tape Lösung.
Schön wäre es, wenn auf solchen billigen Platten, die selbst mit einem
0815 FS betrieben werden, der automatisch generierte Offline Inhalt
abgelegt werden würde. 0815 FS, da bei einer Korruption von Teilen des
ges. Archives, immer noch Daten zugreifbar wären.
storebackup kann sowas.
Das schreibt seine Versionen in ein Verz. alles was ein gewisses Alter
überschritten hat wird auf extern verlagert oder gelöscht oder.... das
Ding ist sehr flexibel konfigurierbar.
Hatte gestern einen Sektorfehler auf einer Backup-HDD. Reparieren mit
mkfs schlug fehl, Platte soweit unlesbar. Vielleicht hätte man das noch
mit Verrenkungen hinbekommen habe über google aber nix brauchbare
gefunden.
Dieses Backup wäre im Bedarfsfall also am Arsch gewesen und deshalb habe
ich ne zweite Backupplatte für solche Fälle.
Nur mal so als Anmerkung was schief gehen kann. Immer mehrfach redundant
sichern, lesson wieder mal the hard way learned.
Märchenonkel schrieb:> Dieses Backup wäre im Bedarfsfall also am Arsch gewesen und deshalb habe> ich ne zweite Backupplatte für solche Fälle.
Dass ein einziges Backup, das beim nächsten Aufruf überschrieben wird
bevor es ein neues Backup gibt, hochgradig gefährlich ist, habe ich
schon mehrfach versucht hier klarzustellen - Resonanz Null, niemand will
so etwas hören.
Georg
Märchenonkel schrieb:> Hatte gestern einen Sektorfehler auf einer Backup-HDD
Alter Spruch: Kein kluger Bauer legt ALLE Eier in einen Korb!
Diese eine Platte hätte auch geklaut sein können od. rm -r
georg schrieb:> Walter K. schrieb:>> Wenn man ZFS nimmt, macht man natürlich Snapshots!>> Nur werden Snapshots auf dem gleichen Festplattenplatz gespeichert - das> hat mit Backup nicht das geringste zu tun.
Au contraire!
Snapshots helfen bei dem #1 Fehlerquelle sehr wohl!
Sie sitzt meist 0,5m vor dem Bildschirm!
Morgen gehts wieder los:
11:00 Anruf: Bitte um Wiederherstellung vom Arbeitsverzeichnisses $USER
Stand heute 07:00..
Gegen Crypto-Würmer helfen einfache Snapshots auch.
Ja, Snapshots ersetzen kein Offsite Backup...
Ich sehe das Problem mit 7z nicht, aber die Platzersparnis ist nicht so
toll, wenn die kopierten Daten selber schon mehr oder weniger stark
komprimiert sind.
Die Zugriffsfrage sehr wichtig ist, könnte es die in der Thematik
erfahrenen Mitleser verstören, hier keine oder nur ungenaue Angaben zu
bekommen.
Wenn die Platzersparnis eine Rolle spielt, dann kann man sich
Ökonomisierungen überlegen, sofern sie nicht naheliegen.
Der Kopf der noch ungeborenen Babys z.B. darf nicht größer werden..
OT: Es gab einen Mann, der hat ein Komprimierungs-Algo geschrieben, mit
dem es möglich ist mehrere GB auf ein paar kb zu reduzieren. Ganz egal
um was es sich handelt. (Verlustfrei) Der Algo selbst ist +300MB
gewesen, und bringt seine eigene "Dekomprimierungs-Db" mit (diese ist
anscheinend durch verschiedene Dateien und Typen entstanden und
"angelernt" worden). Kurz vor der offiziellen Veröffentlichung ist der
Mann spurloß verschwunden! Damit wurden angeblich mehrere Kinofilme auf
einen einzigen 64k Flash gespeichert! Das möchte ich ggf auch mal
benutzen! Im Netz gibts irgend einen Ableger davon. Ich finde jetzt aber
leider den Namen (vom Mann bzw. Software) nicht mehr! Vielleicht weiß da
jemand was...
Tim S. schrieb:
> Ganz egal> um was es sich handelt.Jemand schrieb:> Dass das Informationstheoretisch überhaupt nicht möglich ist, ist> natürlich vollkommen irrelevant.
Es ist zumindest das, was ich darüber weiß. Wie und warum das so ist und
ob das überhaupt so "möglich" ist steht ja ganz wo anders. Warum sollte
es nicht möglich sein?
Immer wiederkehrende und auch lange Fragmente mit einer ID versehen.
(Die lokale +300MB DB) Und das komprimierte kennt nur IDs mit Offset am
Anfang und Trimm am Ende. Und ganz einmalige Sachen kommen mit in das
komprimierte rein. Wie bei Huffman. // nur Spekulation.
Rufus Τ. F. schrieb:> Das muss dann ein Verwandter vom "Krypto-Chef" gewesen sein, ...
Das beschriebene ist aber schon sehr sehr viel älter, als die URLs oder
was da drinne steht. Vor 2000
Tim S. schrieb:> Warum sollte es nicht möglich sein?
Ja, warum eigentlich nicht. Man kann für jeden beliebigen endlichen
Datensatz ein Programm schreiben, das genau diesen Datensatz auf die
Länge von einem Bit komprimiert. ;-)
Tim S. schrieb:> Und ganz einmalige Sachen kommen mit in das komprimierte rein.
Bei nur 300MB DB sind ALLES einmalige Sachen, die einfach so ins
Komprimierte reinkommen ;-)
Jemand schrieb:> Dass das Informationstheoretisch überhaupt nicht möglich ist, ist> natürlich vollkommen irrelevant.
Da stimmt ja auch nicht, es ist praktisch nicht möglich, aber
theoretisch. Das Verfahren wird in der Literatur als Gödelisierung
erwähnt. Man überträgt dazu eine sehr sehr grosse Zahl in kompakter
Schreibweise wie z.B. 2^a^b^c^d^e oder ähnlich, das sind nur ein paar
Bytes. Für einen Text mit 10000 Zeichen muss diese Zahl aus etwa 200000
Primfaktoren bestehen. Der Empfänger zerlegt diese Zahl in ihre
Primfaktoren, daraus ergibt sich der codierte Text: ist 3 mal 2
enthalten, fängt der Text mit "c" an (2 ist die erste Primzahl und c der
dritte Buchstabe). 15 mal 3 heisst "o", 13 mal 5 heisst "m" usw.
Eine riesige Zahl in 200000 Primfaktoren zu zerlegen übersteigt die
Möglichkeiten der Menscheit bei weitem, aber das ist etwas anderes als
unmöglich. Der Informationstheorie widerspricht auch nichts an dem
Verfahren.
Georg
Juhu hab nochmal geschaut, und doch den Eintrag in der Cronik wieder
gefunden. (Anderer Browser...)
Jan Sloot - data compression
Sorry wegen der Falschinfo: er stab an Herzversagen.
https://www.youtube.com/watch?time_continue=3&v=kQsWP6n03EU
Ob / Wann es wohl mal ein FileSystem damit gibt?
A. K. schrieb:> Ja, warum eigentlich nicht. Man kann für jeden beliebigen endlichen> Datensatz ein Programm schreiben, das genau diesen Datensatz auf die> Länge von einem Bit komprimiert. ;-)
Es ist auch voll logisch und sinnvoll, das zu machen!! (Fast
vergleichbar wie in dem Video [?] wenn es denn so wäre) Es ist bestimmt
schlecht, wenn die komprimierte Datei irgendwo auf dem Weg einen
Bitfehler bekommt ;-) Bei 1 Bit länge.
:OT
