Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ulrich D i e z <ud.usenetcorrespondence@web.de> |
|---|---|
| Newsgroups | ger.ct |
| Subject | Re: Backup, dateibasiert, volumenuebergreifend |
| Date | 2024-11-27 14:00 +0100 |
| Message-ID | <vi7543$e8al$1@solani.org> (permalink) |
| References | <5600555409.a7aba743@duerrhauer.de> <vhta0j$1b5bt$1@solani.org> <v1r91lx5b5.ln2@diedrich.ddnssec.de> <vi2q01$3b99$1@solani.org> <vi72gf$dlf$1@dont-email.me> |
Wendelin Uez schrieb: >>> Du verwechselst Raid mit Backup. Was hilft dir die physische Redundanz >>> gegen versehentliches "sudo rm -rf /" oder gegen versehentliches "drop >>> table" in irgendeiner Datenbank? >> >> Ich verwechsle da nichts. > > Du hast denen eigenen Angaben zufolge ... > Man darf jetzt spekulieren, was öfters passiert: Der unvorhergesehene > Ausfall einer Platte oder das unbeabsichtigte Löschen/Überschreiben eines > Datei. Ersteres ist mir in den letzten Jahrzehnten nicht ein einziges Mal > passiert, letzteres geschätzt einmal pro Jahr. Ersteres ist mir öfter begegnet als zweiteres. Insbesondere mit in tragbare Geräte eingebauten HDD-Festplatten. Und mit USB-Sticks und Speicherkarten und SSD-Laufwerken und HDD-Laufwerken, bei denen mit einem Schlag immer mehr Sektoren so defekt waren, dass sie sich nicht mehr durch neu formatieren etc richten ließen. Ich meine, beschrieben zu haben, was ich bezüglich Ausfall eines Datenspeichermediums für Vorkehrungen getroffen habe (ZFS-RAID) und auch, wenn auch weniger ausführlich, wie ich es mit Backups halte (rsync, Clonezilla). Den Hinweis, den Punkt "Vorkehrungen zum Rückgängigmachen versehentlicher/ungewollter Ändern des Datenbestandes ohne dass Beschädigung eines Datenträgers eine Rolle spielt" etwas stiefmütterlich abgehandelt zu haben, lasse ich mir ja gefallen. Aber das hat nichts damit zu tun, etwas verwechselt zu haben. Da ich privat keine großen Datenbanken unterhalte, bei denen es unpraktisch wäre, jedes mal die ganze Datenbank zu sichern bevor Änderungen vorgenommen werden, sichere ich mich, wo es mir wichtig ist, gegen Zweiteres durch Verwendung einer Versionsverwaltung ab. Wo mir Versionsverwaltung zu umständlich ist, kopiere ich geänderte Dateien per rsync. Wenn beim Ändern etwas schief geht, kopiere ich eben in die andere Richtung. ;-) Zur Zeit überlege ich mir, mit aufs (advanced multi layered unification filesystem) oder mit einem ähnlichen Overlay-Dateisystem zu arbeiten - <https://de.wikipedia.org/wiki/Aufs> . Da könnte ich dann, bevor Dateien geändert werden, ein neues Layer anlegen lassen. Gefällt mir eine Änderung nicht, zB wegen fälschlich überschriebener/gelöschter Daten, ist der ungeänderte Stand in älteren/"weiter unten liegenden" Layers noch erhalten. Damit es nicht zu viele Layer werden, die "übereinander gelegt" werden, müsste ich etwas haben, um ab und zu mehrere Layer zu einem einzigen Layer mit dem neuesten Stand zu vereinigen. Und daran mangelt es mir derzeit noch, auch, weil ich noch nicht tief genug in die Overlay-Dateisystem-Materie eingestiegen bin. Eine ZFS-RAID-Redundanzgruppe mit einem Overlay-Dateisystem - das wärs doch. ;-) Mit freundlichem Gruß Ulrich
Back to ger.ct | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Backup, dateibasiert, volumenuebergreifend Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2024-11-23 10:59 +0100
Re: Backup, dateibasiert, volumenuebergreifend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-23 11:15 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-24 14:50 +0100
Re: Backup, dateibasiert, volumenuebergreifend Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-11-24 16:02 +0100
Re: Backup, dateibasiert, volumenuebergreifend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-25 09:55 +0100
Re: Backup, dateibasiert, volumenuebergreifend Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-11-26 17:35 +0100
Re: Backup, dateibasiert, volumenuebergreifend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-25 09:50 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-23 12:00 +0100
Re: Backup, dateibasiert, volumenuebergreifend Joerg Walther <joerg.walther@magenta.de> - 2024-11-23 15:49 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-11-23 20:22 +0100
Re: Backup, dateibasiert, volumenuebergreifend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-11-23 21:37 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-24 15:26 +0100
Re: Backup, dateibasiert, volumenuebergreifend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-11-24 16:21 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-11-25 22:26 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-27 13:13 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-11-27 14:00 +0100
Re: Backup, dateibasiert, volumenuebergreifend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-11-27 17:03 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ruediger Lahl <ruediger.lahl@gmx.de> - 2024-11-23 16:51 +0100
Re: Backup, dateibasiert, volumenuebergreifend Frank Nitzschner <nospam@nitzschner.de> - 2024-11-24 09:50 +0100
csiph-web