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.
Angehängte Dateien:
-
7zip_mitCRC.jpg
8,8 KB
Norbert schrieb: > 7zip sagt 7zip ist eigentlich recht gut, da es auch eine CRC-Prüfsumme erzeugt.
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
Norbert schrieb: > Wiederherstellungsinformation Stimmt, das hat RAR und 7zip noch nicht. https://www.pcwelt.de/ratgeber/So-funktioniert-das-Wiederherstellen-von-Archiven-mithilfe-von-Wiederherstellungsinformationen-Recovery-Records-Packer-59001.html Einen Pferdefuß hat die Komprimierung oft: Es ist mühsamer darin eine bestimmte Datei zu suchen. Deswegen speichere ich mir noch ein gut lesbares Inhaltszeichnis mit ab. dir/s > Inhalt201808_BeispielUrlaub.txt
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.
Angehängte Dateien:
-
compr.gif
11 KB
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
:
Bearbeitet durch User
Bei Windows gibt es "Hardlinkbackup". Komprimiert nicht, versioniert aber sehr effizient, ohne Vervielfachung gleicher Files. Kein Programm für Restore nötig.
:
Bearbeitet durch User
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/Ddrescue http://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
ZFS z.B. zusammen mit FreeNAS ist natürlich am besten. Man sollte dann dafür aber auch einen Rechner mit ECC RAM einsetzen.
Warum soviel Energie aufwenden einer Pfeife wie Norbert zu helfen?
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!
:
Bearbeitet durch User
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.
Es gibt noch PAR bzw. MultiPar mit dem zip- oder 7z-Archiven Wiederherstellungsinformationen hinzugefügt werden können. https://en.wikipedia.org/wiki/Parchive#Windows https://hp.vector.co.jp/authors/VA021385/ EU-Mirror https://multipar.eu/
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.
Angehängte Dateien:
-
backupplatten.jpg
19 KB
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Mir scheint, du hättest soeben Hardlinkbackup beschrieben, wenn Windows, oder rsnapshot, wenn Linux.
Die Offline Platten sollen aber "Offline" ohne Power im Schrank liegen ...
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
storeBackups liest sich nicht schlecht. Die "webseite" ist etwas hrmm ... spröde ... mal sehen. Vielen Dank, hatte ich noch nie von gehört.
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..
ich musste grade meine firefox einstellungen restoren die mir auf irgendeine weise durch rumspielen mit selenium verlustig gegangen sind. restore war einfach: platte anhängen, letztes backup suchen, ~/.mozilla nach home kopieren. kein entpacken, oder restore programm starten und rumklicken. einfach halt. weiter oben hab ich geschrieben, dass hardlinks platzschonender sind als packprogramme (plus der einfacheren zugreifbarkeit). hier mal ein beipiel: 4T platte, 9,4T gesichert, immernoch 2,5T frei. die platte dient dazu 2 rechner, node05 und orin zu sichern. [/code] root@orin:/media/node05/4T-BACKUP-DISK# du -hslc */* 2>/dev/null 273G node05_backup/2018_04_04-070531.done 273G node05_backup/2018_04_04-093935.done 273G node05_backup/2018_04_06-070432.done 273G node05_backup/2018_04_06-073135.done 273G node05_backup/2018_04_13-092933.done 274G node05_backup/2018_04_20-092503.done 273G node05_backup/2018_04_27-070422.done 273G node05_backup/2018_05_04-065719.done 274G node05_backup/2018_05_11-071302.done 273G node05_backup/2018_05_18-063535.done 274G node05_backup/2018_05_25-065529.done 275G node05_backup/2018_06_29-070121.done 276G node05_backup/2018_07_13-064807.done 352G node05_backup/2018_07_20-063653.done 276G node05_backup/2018_07_27-075513.done 275G node05_backup/2018_08_03-074801.done 276G node05_backup/2018_08_10-064513.done 276G node05_backup/2018_08_17-063330.done 276G node05_backup/2018_08_24-072044.done 276G node05_backup/2018_08_31-063414.done 185G orin_backup/2018_04_04-094112.done 185G orin_backup/2018_04_04-104244.done 185G orin_backup/2018_04_04-104815.done 186G orin_backup/2018_04_06-064647.done 186G orin_backup/2018_04_13-093246.done 186G orin_backup/2018_04_20-090949.done 186G orin_backup/2018_04_27-070855.done 243G orin_backup/2018_05_04-063754.done 243G orin_backup/2018_05_11-070625.done 243G orin_backup/2018_05_18-062254.done 241G orin_backup/2018_05_25-080026.done 193G orin_backup/2018_06_29-063621.done 198G orin_backup/2018_07_13-073304.done 198G orin_backup/2018_07_20-062455.done 199G orin_backup/2018_07_27-071541.done 199G orin_backup/2018_08_03-075626.done 200G orin_backup/2018_08_10-071621.done 200G orin_backup/2018_08_17-064523.done 200G orin_backup/2018_08_24-070512.done 206G orin_backup/2018_08_31-070206.done 9,4T insgesamt root@orin:/media/node05/4T-BACKUP-DISK# df -h . Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf /dev/mapper/luks-dca19854-3991-4bb8-b161-bd6b5425fb5a 3,6T 983G 2,5T 29% /media/node05/4T-BACKUP-DISK [/code]
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...
:
Bearbeitet durch User
Tim S. schrieb: > Ganz egal > um was es sich handelt. Dass das Informationstheoretisch überhaupt nicht möglich ist, ist natürlich vollkommen irrelevant.
Tim S. schrieb: > 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) Das muss dann ein Verwandter vom "Krypto-Chef" gewesen sein, dem Typ aus Berlin-Wedding, der die Vollbit-Verschlüsselung erfunden hat, und damit auch Bruce Schneier erfreute: https://www.schneier.com/blog/archives/2006/06/the_doghouse_kr.html https://web.archive.org/web/20140207013940/http://www.kryptochef.net/
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
:
Bearbeitet durch User
Beitrag #5559427 wurde vom Autor gelöscht.
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. ;-)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.