Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > ger.ct > #630558

Re: Backup, dateibasiert, volumenuebergreifend

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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