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

Groups > ger.ct > #630497 > unrolled thread

Backup, dateibasiert, volumenuebergreifend

Back to article view | Back to ger.ct

Contents

  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

#630497 — Backup, dateibasiert, volumenuebergreifend

Hallo,

ich habe eine Mediensammlung von TV-Aufnahmen, die mittlerweile in der Größe
mindestens einen Datenträger voll und einen Teil eines nächsten Mediums
umfassen würde.

Ich habe mir bisher "rsnapshot" ausgesucht, aber der kann das
volumenübergreifend wohl nicht.

Wie sichert Ihr denn? Auf keinen Fall mag ich ein Archiv anlegen, die Dateien
sollen in den bestehenden Ordnern dateibasiert herumliegen. Idealerweise kann
man den Backuptask skripten oder automatisieren.

Kennt Ihr da was?

-- 
mit freundlichen Grüßen/with kind regards,

Christian Dürrhauer

[toc] | [next] | [standalone]

#630498

Am 23.11.24 um 10:59 schrieb Christian Dürrhauer:

> ich habe eine Mediensammlung von TV-Aufnahmen, die mittlerweile in der Größe
> mindestens einen Datenträger voll und einen Teil eines nächsten Mediums
> umfassen würde.

Ich habe Datensicherung auf ca 20 TB USB Platte
( rsync -s --delete  ..)
und  5? TB USB Festplatte für Aufnahmen, die ich mir öfter anschaue.

> Wie sichert Ihr denn? Auf keinen Fall mag ich ein Archiv anlegen, die Dateien
> sollen in den bestehenden Ordnern dateibasiert herumliegen. Idealerweise kann
> man den Backuptask skripten oder automatisieren.

shells rsync  über crontab laufen lassen?


-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#630516

>  Seitdem ich einmal einen mutmaßlichen Kopierfehler bemerkte,
>  verwende ich ein selbstgeschriebenes Python-Programm zum
>  Verifizieren, mit dem ich einen Tag nach dem Kopieren alle
>  Dateien noch einmal Bit-für-Bit mit dem Original vergleiche.

nimm den TotalCommander, verifiziere sofort und kopiere im übrigen nur die 
geänderten Files, das geht wesentlich schneller undist sicherer als per 
Image-Kopie evtl. fehlerhafte Blöcke mitzukopieren und zu hoffen, daß die 
Korrektur alle Fehler findet und auch beseitigt 

[toc] | [prev] | [next] | [standalone]

#630518

On 11/24/24 13:14, Stefan Ram wrote:

>    Seitdem ich einmal einen mutmaßlichen Kopierfehler bemerkte,
>    verwende ich ein selbstgeschriebenes Python-Programm zum
>    Verifizieren, mit dem ich einen Tag nach dem Kopieren alle
>    Dateien noch einmal Bit-für-Bit mit dem Original vergleiche.

Dazu braucht man eigentlich nichts selbst schreiben, 'diff -r' kann das 
schon.

Wobei man auch 'rsync' und dort die Option  '-c' verwenden kann.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#630527

Am 24.11.24 um 16:02 schrieb Gerrit Heitsch:
> On 11/24/24 13:14, Stefan Ram wrote:
> 
>>    Seitdem ich einmal einen mutmaßlichen Kopierfehler bemerkte,
>>    verwende ich ein selbstgeschriebenes Python-Programm zum
>>    Verifizieren, mit dem ich einen Tag nach dem Kopieren alle
>>    Dateien noch einmal Bit-für-Bit mit dem Original vergleiche.
> 
> Dazu braucht man eigentlich nichts selbst schreiben, 'diff -r' kann das 
> schon.

Was macht diff bei symbolischen links?

> Wobei man auch 'rsync' und dort die Option  '-c' verwenden kann.

Sieht nützlich aus
Momentan verwende ich bei Sicherung rsync -a --delete
Und warte eventuell ca 1 Std
-c könnte nachts durchlaufen bedeuten.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#630547

On 11/25/24 09:55, Hermann Riemann wrote:
> Am 24.11.24 um 16:02 schrieb Gerrit Heitsch:
>> On 11/24/24 13:14, Stefan Ram wrote:
>>
>>>    Seitdem ich einmal einen mutmaßlichen Kopierfehler bemerkte,
>>>    verwende ich ein selbstgeschriebenes Python-Programm zum
>>>    Verifizieren, mit dem ich einen Tag nach dem Kopieren alle
>>>    Dateien noch einmal Bit-für-Bit mit dem Original vergleiche.
>>
>> Dazu braucht man eigentlich nichts selbst schreiben, 'diff -r' kann 
>> das schon.
> 
> Was macht diff bei symbolischen links?

Gute Frage... habe ich noch nie ausprobiert. Hat das hier jemand schon?



>> Wobei man auch 'rsync' und dort die Option  '-c' verwenden kann.
> 
> Sieht nützlich aus
> Momentan verwende ich bei Sicherung rsync -a --delete
> Und warte eventuell ca 1 Std

Mein Standardaufruf ist  'rsync -aPH --delete-after'.


> -c könnte nachts durchlaufen bedeuten.

Wenn man nur testen will sollte man in die Optionen noch ein '-n' 
einbauen. Dann bekommt man nur gemeldet was gemacht würde, wenn das '-n' 
fehlt.

Auch hübsch bei rsync für versionierte Backups a la Timemaschine ist 
'--link-dest=<dir>'

  Gerrit

[toc] | [prev] | [next] | [standalone]

#630526

Am 24.11.24 um 13:14 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Ich habe Datensicherung auf ca 20 TB USB Platte
> 
>    Ich haben Daten auf externen Festplatten. Für die
>    Datensicherung einer Festplatte verwende ich eine andere
>    Festplatte derselben Größe und kopiere die Festplatte 1:1
>    (nicht sektorweise, sondern dateiweise). (Im Idealfall sollte
>    man abwechselnd auf zwei verschiedene Platten kopieren.)

Genauer gesagt, ich verwende unterschiedliche Festplatten.
Filme ( .mp4, die von VU etc ) landen auf ehre große Festplatten.

Dann gibt es Sicherungen auf 5 TB Festplatten im Wochen Wechsel.

>    Seitdem ich einmal einen mutmaßlichen Kopierfehler bemerkte,
>    verwende ich ein selbstgeschriebenes Python-Programm zum
>    Verifizieren, mit dem ich einen Tag nach dem Kopieren alle
>    Dateien noch einmal Bit-für-Bit mit dem Original vergleiche.

Bit-für-Bit?
Dateivergleich in Python os.walk(): Schleife:
if open(dateiname1,"b").read()==open(dateiname1,"b").read():

>    Der Vorgang der Organisation der Datenspeicherung und der
>    Änderung der Organisation, also Daten welcher Art sich wo
>    befinden, ist bei mir von der Datensicherung entkoppelt.

Eine Entkoppelung findet bei mir bei etliche symbolisch links statt,
weil da die Verweise auf andere partitions nicht mehr passen könnten.

Einige kleine Sicherungen sind auf Papier.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#630499

Wenn ich dich richtig verstehe, dann möchtest du mehrere Laufwerke/Pfade 
unter einem gemeinsamen Pfad ansprechen können. Gneau dafür ist MKLINK dein 
Freund, damit kannst du mehrere Verzeichnisse in ein virtuelles Verzeichnis 
bzw. Laufwerk zusammenfassen. Nennt man symbolische Verknüpfung und geht wie 
folgt:

- Eingabeaufforderung mit Admin-Rechten öffnen
- neuen gemeinsamen Ordner anlegen: MKDIR D:\LINK
- <Pfad1> und <Pfad2> in den Pfad D:\LINK als virtuellen Unterordner mappen:
- MKLINK  /D  D:\LINK\Dir1  <Pfad1>
- MKLINK  /D  D:\LINK\Dir2  <Pfad2>

Jetzt sind unter D:\LINK zwei Ordner Dir1 und Dir2 vorhanden, die auf 
<Pfad1> und <Pfad2> verweisen. Damit kann dein Windows und somit deine 
Programme unter einem gemeinsamen Pfad D:\LINK auf die beiden Verzeichnisse 
zugreifen. Auf welchen Laufwerken die beiden dann tatsächlich liegen ist 
egal, solange die Laufwerke erreichbar sind. Ein Backup von D:\LINK sichert 
dann bspw. beide.

HTH

[toc] | [prev] | [next] | [standalone]

#630500

Christian Dürrhauer wrote:

>Wie sichert Ihr denn? Auf keinen Fall mag ich ein Archiv anlegen, die Dateien
>sollen in den bestehenden Ordnern dateibasiert herumliegen. Idealerweise kann
>man den Backuptask skripten oder automatisieren.

Ich habe eine ähnlich umfangreiche Sammlung wie du und diese letztes
Jahr von 4 alten (10a+) Festplatten auf zwei neue 18TB-Platten
umkopiert. Die alten Platten hatten zwar nur ein paar hundert Stunden
Laufzeit aufzuweisen, trotzdem ist mir eine davon gestorben, das war der
Auslöser für die Aktion. Und jetzt kommt es: Datenverlust hatte ich
dabei keinen, denn von Anfang an spiegelte ich diese Sammlung (viele
seltene und wertvolle Liveaufnahmen darunter) auf eine zweite Platte.
Als die erste alte Platte anfing komisch zu knacksen, habe ich sofort
den Strom gekappt und Ersatz bestellt. Erst als der da war, habe ich die
zweite alte Platte nochmal eingeschaltet und auf die erste neue
gesichert.

Mein Vorgehen hier:
- Es wird händisch alles, was sich in den letzten Tagen als
sicherungswürdig erwiesen hat, auf den Server geschoben in das
Verzeichnis "wegsicher", das noch Unterordner für verschiedene
Dateitypen/Genres hat. Alle ~14 Tage wird über ein Script (momentan
Windows-Robocopy; in Planung ist rsync mit Linux) alles aus diesem
Verzeichnis auf die erste Sicherungsplatte kopiert, dann diese Platte
auf die zweite gespiegelt, dann pausiert das Script (damit bei einem
Hardwarefehler hier eingegriffen werden kann); wenn alles in Ordnung
ist, löscht dann das Script nach einem beliebigen Tastendruck alles aus
dem wegsicher-Verzeichnis wieder weg. 
Die Platten habe ich derzeit mit Whereisit (Windows) und VVV (Win und
Linux) katalogisiert, sodass ich auch auf dem Notebook nachschauen kann,
was auf den in einem anderen Raum in einem Dock stehenden Platten
gespeichert ist. Imho funktioniert das ganz gut. Und ja: Die Lösung ist
teuer, da da aber wirklich seltene und für mich wichtige Sachen drauf
sind, ist es mir die Sache auf jeden Fall wert. 

-jw-
-- 
And now for something completely different...

[toc] | [prev] | [next] | [standalone]

#630504

Christian Dürrhauer schrieb:

> Hallo,
> 
> ich habe eine Mediensammlung von TV-Aufnahmen, die mittlerweile in der Größe
> mindestens einen Datenträger voll und einen Teil eines nächsten Mediums
> umfassen würde.
> 
> Ich habe mir bisher "rsnapshot" ausgesucht, aber der kann das
> volumenübergreifend wohl nicht.
> 
> Wie sichert Ihr denn?

Ich arbeite inzwischen unter Linux mit ZFS-Volumes.
<https://de.wikipedia.org/wiki/ZFS_(Dateisystem)>

Meine Dateien liegen in drei zusammen eine RAID-1-Redundanzgruppe
bildenden ZFS-Volumes. Derzeit besteht ein ZFS-Volume der
ZFS-Redundanzgruppe bei mir aus einer einzigen Festplatte. Ein
ZFS-Volume einer ZFS-Redundanzgruppe kann aber auch aus mehreren
physischen Datenträgern bestehen. Dieser Umstand könnte ZFS für dich
interessant machen.

Auf diese Weise ist es nicht mehr gar so wichtig, explizit
Datensicherung bzw Backup zu fahren, da der Datenbestand physisch
dreimal da ist und ggfs ein defekter physischer Datenträger gegen einen
intakten ausgewechselt werden kann wonach sich alles mehr oder weniger
automatisch synchronisiert.

Ich fahre aber trotzdem ab und zu Backups  ZB vor anstehenden Änderungen
am Betriebssystem einer Maschine.

Solche Backups gehen - je nach Art der Datensicherung - per rsync oder
per CloneZilla an eine Freigabe eines Samba-Servers, bei dem der
Datenbestand ebenfalls als eine solche ZFS-RAID-1-Redundanzgruppe
organisiert ist.
Die Maschine mit dem Samba-Server ist gleichzeitig ein PXE-Server, der
die anderen Maschinen im lokalen Netzwerk wecken und mit einem
Boot-Image versorgen kann, welches deren Backup oder das Zurückschreiben
eines Backups fährt.
Auf diese Weise wird weder fürs Backup noch fürs Zuückschreiben das auf
der zu sichernden Maschine installierte Betriebssystem gebraucht, sodass
es bezogen aufs Backup oder Zurückschreiben des Backup nichts ausmacht
wenn das Betriebssystem, das auf der zu sichernden bzw wiederher-
zustellenden Maschine installiert ist, nicht funktioniert.
Die Maschine mit dem Samba-Server schalte ich nur ein wenn das lokale
Netzwerk nicht mit dem Internet verbunden und keine andere Maschine des
lokalen Netzwerks vom auf ihr selbst installierten Betriebssystem
hochgefahren ist. Dies soll ein Korrumpieren der für Backup und fürs
Zurückspielen verwendeten Maschinerie erschweren.

Als Besonderheit achte ich darauf, dass bei dem Samba-Server, auf dem
die Backups gespeichert werden, immer nur zwei der drei ZFS-Volumes der
ZFS-Redundanzgruppe gleichzeitig eingeschaltet sind. Das heißt zwar,
dass der Datenbestand aller Volumes der ZFS-Redundanzgruppe nie auf
einen Rutsch synchronisiert wird, sondern immer auf "zwei Rutsche".
Dafür ist aber das Risiko ausgeschaltet, dass der Datenbestand gleich
auf allen ZFS-Volumes der ZFS-Redundanzgruppe korrumpiert ist, wenn beim
Synchronisieren etwas schief geht.

Mit freundlichem Gruß

Ulrich

[toc] | [prev] | [next] | [standalone]

#630514

Ulrich D i e z meinte:

> Auf diese Weise ist es nicht mehr gar so wichtig, explizit
> Datensicherung bzw Backup zu fahren, da der Datenbestand physisch
> dreimal da ist und ggfs ein defekter physischer Datenträger gegen
> einen intakten ausgewechselt werden kann wonach sich alles mehr oder
> weniger automatisch synchronisiert.

Du verwechselst Raid mit Backup. Was hilft dir die physische Redundanz 
gegen versehentliches "sudo rm -rf /" oder gegen versehentliches "drop 
table" in irgendeiner Datenbank?
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#630517

>> Auf diese Weise ist es nicht mehr gar so wichtig, explizit
>> Datensicherung bzw Backup zu fahren, da der Datenbestand physisch
>> dreimal da ist und ggfs ein defekter physischer Datenträger gegen
>> einen intakten ausgewechselt werden kann wonach sich alles mehr oder
>> weniger automatisch synchronisiert.
>
> Du verwechselst Raid mit Backup. Was hilft dir die physische Redundanz
> gegen versehentliches "sudo rm -rf /" oder gegen versehentliches "drop
> table" in irgendeiner Datenbank?

RAID1 ist eine Sicherheit gegen Ausfall der Festplatte. Bei einer Löschung 
oder Überschreibung einer Datei ist diese mit RAID1 nur sicher gelöscht bzw. 
überschrieben, d.h. sie ist nur sicher weg. 

[toc] | [prev] | [next] | [standalone]

#630519

Wendelin Uez meinte:

>> Du verwechselst Raid mit Backup. Was hilft dir die physische
>> Redundanz gegen versehentliches "sudo rm -rf /" oder gegen
>> versehentliches "drop table" in irgendeiner Datenbank?
> 
> RAID1 ist eine Sicherheit gegen Ausfall der Festplatte. Bei einer
> Löschung oder Überschreibung einer Datei ist diese mit RAID1 nur
> sicher gelöscht bzw. überschrieben, d.h. sie ist nur sicher weg.

Ja. Sagte ich doch. RAID hilft gegen spanabhebende Datenverarbeitung, 
aber nicht gegen ZBUS-Fehler.
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#630537

Diedrich Ehlerding schrieb:

> Ulrich D i e z meinte:
> 
>> Auf diese Weise ist es nicht mehr gar so wichtig, explizit
>> Datensicherung bzw Backup zu fahren, da der Datenbestand physisch
>> dreimal da ist und ggfs ein defekter physischer Datenträger gegen
>> einen intakten ausgewechselt werden kann wonach sich alles mehr oder
>> weniger automatisch synchronisiert.
> 
> 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.

Abgesehen davon, dass solche Versehen tunlichst zu vermeiden sind, habe
ich auch umrissen, wie ich Backup mit rsync/Clonezilla mache.

Bei kritischen Anwendungen gibt es auch die Möglichkeit, das Dateiöffnen
so zu skripten, dass zuvor in Backup-Dateien kopiert wird.

Im Übrigen laufen bei mir die Betriebssysteme und Programme, mit denen
ich arbeite, alle auf dem Wirtssystem in virtuellen Maschinen oder in
Containern für die Docker-Engine, die nach der Session postwendend
entsorgt werden. Änderungen von Dateien werden nur beibehalten wenn ich
die virtuelle Maschine bzw den Container vor dem Beenden speichere oder
die betreffenden Dateien über Netzwerk aus der virtuellen Maschine
rauskopiere, zB in ein NAS. Zurücksetzen nach Versehen ist damit nicht
sehr problematisch.

Und zum Glück betreibe ich privat keine Datenbankserver, die damit
klarkommen müssen wenn hundert Nutzer zufällig alle gleichzeitig
ausgerechnet das selbe Datenfeld im selben Record der selben Datenbank
ändern wollen... ;-)

Wenn es darum geht, frühere Stände eines aus Dateien bestehenden
Projektes wiederherzustellen, empfehle ich, sich mit dem Gedanken an die
Nutzung einer Versionsverwaltung anzufreunden.

Ausgangspunkt ist aber eine Mediensammlung von TV-Aufnahmen.
Um etwas dazu sagen zu können, wie man die am besten verwaltet, müsste
man genau wissen, wie sie aufgebaut ist.

Mit freundlichem Gruß

Ulrich

[toc] | [prev] | [next] | [standalone]

#630556

>> 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 ...

> Meine Dateien liegen in drei zusammen eine RAID-1-Redundanzgruppe
> bildenden ZFS-Volumes. Derzeit besteht ein ZFS-Volume der
> ZFS-Redundanzgruppe bei mir aus einer einzigen Festplatte

also drei Festplatten, die zu einem einzigen RAID-1-Verbund zusammegefaßt 
sind.

Das ist zwar sehr sicher gegen Ausfall einer Festplatte, weil die Daten 
dreimal vorhanden sind, aber das ist trotzdem kein sicheres Backup, weil bei 
einer versehentlichen Löschung eines wichtigen Dokuments dieses dann ohne 
weiteres Backup eben dreimal gelöscht ist und eben doch kein Backup 
vorhanden ist  Da wäre ein Zweier.RAID-1 mit einer dritten Platte als Backup 
normalerweise wesentlich sinnvoller.

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. 

[toc] | [prev] | [next] | [standalone]

#630558

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

[toc] | [prev] | [next] | [standalone]

#630561

Ulrich D i e z meinte:

>> 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.

Das wundert mich. Der letzte Hardwarefehler auf den Platten der PCs 
miehner Familie ist mindestens 20 Jahre her, wenn nicht mehr. 
Versehentlich gelöscht oder überschrieben kommt sehr viel häufiger vor.

> Eine ZFS-RAID-Redundanzgruppe mit einem Overlay-Dateisystem - das wärs
> doch.  ;-)

Hat ZFS nicht einen Snapshot-Mechanismus? Oder täuscht mich a mein 
Informationsstand? Wenns das gibt, dann hast du damit doch schon eine 
ähnliche Möglichkeit.

Mein PC läuft mit btrfs, und das  bzw. dessen Snapshots nutze ich als 
erste Stufe der Datensicherung, eben gegen  ZBUS-Fehler. Das hat mir 
schonmal den PC berettet, als ein kernel-update plötzlich nicht mehr mit 
meinem BIOS zurechtkam, und es hat mir mein kaputtgegangenes 
Thunderbirdprofil mit minimalem Aufwand wiederhergestellt, Stand vom 
Vorabend. 
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#630506

*Christian Dürrhauer* schrieb:

> ich habe eine Mediensammlung von TV-Aufnahmen, die mittlerweile in der Größe
> mindestens einen Datenträger voll und einen Teil eines nächsten Mediums
> umfassen würde.
>
> Ich habe mir bisher "rsnapshot" ausgesucht, aber der kann das
> volumenübergreifend wohl nicht.
>
> Wie sichert Ihr denn? Auf keinen Fall mag ich ein Archiv anlegen, die Dateien
> sollen in den bestehenden Ordnern dateibasiert herumliegen. Idealerweise kann
> man den Backuptask skripten oder automatisieren.
>
> Kennt Ihr da was?

Das von MS mitgelieferte robocopy macht den Job bei mir für die
täglichen Änderungen und einmal monatlich ein Voll-Backup der Daten.

System-Backups macht SnapShot.

Alles Batchgesteuert und in der Aufgabenplanung automatisiert im
Hintergrund.

Aber MS-Programme werden dich wohl eher nicht interessieren.
-- 
bis denne

[toc] | [prev] | [next] | [standalone]

#630513

Ruediger Lahl schrieb :

> Das von MS mitgelieferte robocopy macht den Job bei mir für die
> täglichen Änderungen und einmal monatlich ein Voll-Backup der Daten.

Für Win nehme ich https://www.dirsync.de/ , kostenlos
für Privatanwender. Sichert die Dateien auch
anhand Checksummenprüfung.

Grüsse
Frank

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web