expertenaustausch > comp.os.* > comp.os.unix.linux.misc

Arno Lutz (02.12.2019, 21:19)
Sebastian Barthel schrieb:

> >> Das Ganze gerne mit GUI, sollte aber kein Muss sein.

> >

> Das ist was, was ich auch empfohlen hätte. Ist eine brauchbar gemachte
> Oberfläche für rsync.


da ziehe ich Grsync vor.

Gruß
Arno Lutz
Christian Garbs (02.12.2019, 21:28)
Mahlzeit!

Albrecht Mehl <invalid> wrote:

> Ich benutze rsnapshot, das bei opensuse mitgeliefert wird, als Anwendung
> für rsync - ähnliches gibt es für windows. Keine GUI, aber die
> Einstelldatei ist mit auskommentierten Zeilen gut erläutert.
> - Es werden nur neue bzw. geänderte Dateien gespeichert.


Wenn man die Dateien umbenennt oder verschiebt, klappt das nicht
mehr.

Man kann das nachrüsten, aber nur über Handstände und Klimmzüge in der
Konfiguration (so grob: einen separaten Verzeichnisbaum mit Hardlinks
auf alle Dateien erstellen, der mitgesynct wird, wo die Umbenennung
aber erst nach dem Sync nachgezogen wird).

Ansonsten nutze ich das aber auch, insbesondere wegen der
mehrschichtigen Rotation der Backups.

Seit ich jetzt auf dem ersten System ZFS im Einsatz habe, das selber
automatisch mehrschichtige Snapshots erstellt, kann ich dort das
rsnapshot wieder auf rsync zurückbauen und habe trotzdem noch Zugriff
auf alte Versionen. Schöne Sache, aber ich will die bestehenden
Systeme nicht alle neu aufsetzen oder untendrunter komplett mit neuen
Filesystemen versorgen, da ist nicht genug Platz für einen Umzug frei.

Gruß
Christian
Florian Weimer (02.12.2019, 23:44)
* Holger Schauer:

> On 9587 September 1993, Florian Weimer wrote:
> Gute Frage. Ich denke, 90% aller Dateien sind <5MB. Ausreißer sind
> einige wenige Videos und eine handvoll VM-Images.


Aber größer als 64 KiB? Die meisten neueren Backup-Lösungen haben
größere Probleme mit vielen kleinen Dateien. Sie brauchen mehrere
hundert Bytes pro Datei, teilweise im RAM, teilweise auf der Platte.
Die exakte Menge variiert natürlich von Programm zu Programm, aber die
Arbeitsweise ist i.d.R. ähnlich: Metadaten für alle Blöcke werden ins
RAM geladen und verbleiben dort während des Backup-Vorgangs, und bei
Millionen von verschiedenen Dateien gibt es eben auch Millionen von
(ggf. sehr kleinen) Blöcken.

>> Brauchst Du Kompression? Deduplikation auf Block- statt Dateiebene?

> Ja. Nein.
> Kompression brauche ich strikt genommen nur, wenn ich
> mehrere Generationen (inkrementell, full) speichern will.


Ohne Deduplizierung auf Blockebene reicht einmal Booten eines
VM-Abbilds ausreicht, um eine Vollsicherung der Datei auszulösen.
Gerade für VMs hätte ich die Deduplizierung auf Blockebenene als
Anforderung erwartet.

Für die inkrementelle Sicherung reicht meist auch die Deduplizierung
aus.

Die aktuellen Lösungen machen i.d.R. ewiges inkrementelles Backup, und
man muß alte Backups dann nach einem Plan verwerfen. Dieser Schritt
ist nicht immer effizient implementiert.
Gunter Gutzeit (03.12.2019, 09:37)
Arno Lutz schrieb am Mo 02.12.2019 20:19:55 +0100:

> Sebastian Barthel schrieb:
>>>> Das Ganze gerne mit GUI, sollte aber kein Muss sein.
>>>

>> Das ist was, was ich auch empfohlen hätte. Ist eine brauchbar gemachte
>> Oberfläche für rsync.

> da ziehe ich Grsync vor.


Sicherlich die einfachste GUI-Variante für rsync und die beste Lösung
für User, die keinen weiteren Schnick-Schnack brauchen oder wollen.
Arno Lutz (03.12.2019, 23:36)
Gunter Gutzeit schrieb:

> Sicherlich die einfachste GUI-Variante für rsync und die beste Lösung
> für User, die keinen weiteren Schnick-Schnack brauchen oder wollen.


Richtig.
Was brauch ich zig Funktionen, welche ich nicht nutze?
Und back to the roots hieße alles auf Konsole.
So fit bin ich da leider auch nicht.

Gruß
Arno Lutz
Holger Schauer (04.12.2019, 09:43)
On 9588 September 1993, Florian Weimer wrote:
> * Holger Schauer:
>> Gute Frage. Ich denke, 90% aller Dateien sind <5MB. Ausreißer sind
>> einige wenige Videos und eine handvoll VM-Images.

> Aber größer als 64 KiB?


Da müsste ich mal eine genauere Analyse machen. Da sind mit Sicherheit
eine Menge Dateien dabei, die kleiner sind als 64 KiB, aber wie genau
das Verhältnis ist, kann ich nicht aus dem Stehgreif sagen.

> Ohne Deduplizierung auf Blockebene reicht einmal Booten eines
> VM-Abbilds ausreicht, um eine Vollsicherung der Datei auszulösen.
> Gerade für VMs hätte ich die Deduplizierung auf Blockebenene als
> Anforderung erwartet.


Guter Punkt. Gut, das betrifft jetzt im wesentlichen eine VM, die ab und
an in Benutzung ist und einige Karteileichen, daher hatte ich das nicht
besonders im Auge.

Im Moment sieht das von Sven vorgeschlagene borg (bzw. borgmatic) für
mich am interessantesten aus. Die Deduplizierung bei einem einzigen
Backup-Lauf ist schon beeindruckend.

Holger
Gunter Gutzeit (04.12.2019, 12:37)
Arno Lutz schrieb am Di 03.12.2019 22:36:58 +0100:

> Gunter Gutzeit schrieb:
> Richtig.
> Was brauch ich zig Funktionen, welche ich nicht nutze?


Korrekt, man könnte auch fragen: Warum installiere ich mir überhaupt all
die unnützen Programme, die ich nicht brauche?

Linux-Neueinsteiger haben keine Wahl, um den Wechsel von Windows nach
Linux zu vollziehen. Erfahrene Linux-Nutzer haben einfach keine
Zeit :-)

> Und back to the roots hieße alles auf Konsole.


Auf der Konsole arbeiten wirklich nur die Linux-Profis. Linux-Laien sind
Desktop-Nutzer und können das volle Potential ihrer Linux-Distribution
aber nur dann ausschöpfen, wenn sie sich mit der Konsole auskennen. Nur
auf der Konsole habe sie z.B. alle Einstellungsmöglichkeiten eines
Programms zur Verfügung. Auf der GUI-Ebene habe ich immer nur die
eingeschränkten Möglichkeiten, die mir der Programmierer des
GUI-Programms zur Verfügung stellen will bzw den ganzen zusätzlichen
unnützen Müll, den kein normaler Nutzer braucht - und die Dinge, die
ich tatsächlich bräuchte, finde ich aber nicht.

Back to the roots hieße, die Möglichkeit eines tieferen
Linux-Verständnisses. Ohne Zeitaufwand, aber kein Fortschritt :-)

> So fit bin ich da leider auch nicht.


Ohne Hilfe geht es mit 'Back to the roots' leider nicht. Linux-Profis
sagen dann - wenn überhaupt -, wie kann man nur so blöde Fragen stellen
und so etwas nicht verstehen: Wenn Du schon kein Informatik-Studium
vorweisen kannst, dann lese erst einmal mehrere Linux-Bücher, bevor Du
hier dumme fragen stellst. Außerdem habe ich als Profi für diesen
Blödsinn keine Zeit :-)

Bei diesem ganzen Blödsinn:

- nicht entmutigen lassen
- trotzdem am Ball bleiben
- Vertraue Deinem gesunden Menschenverstand
- die Komplexität von Problemen reduzieren und dann eins nach dem
anderen
- selbst im Internet recherchieren
- Lösungsmöglichkeiten selbst austesten und die dann die beste (meist
die einfachste) wählen

Ohne Zeitaufwand, aber kein Fortschritt :-)
Joerg.Schilling (04.12.2019, 15:50)
In article <qs1bln$877$1>,
Tim Ritberg <tim> wrote:
>Am 01.12.19 um 20:14 schrieb Holger Schauer:
>cron, tar und 7z tuts nicht?


VORSICHT!

Wenn Leute auf Linux "tar" sagen, meinen sie leider meist "gtar" und das ist
als Backupsystem h?chst gef?hrlich, weil es mit einer Wahrscheinlichkeit von
1-5% nicht in der Lage ist, die eigenen Backups auch wieder einzuspielen.

Das ist leider etwas, da? immer gerne ?bersehen wird. Es reicht eben nicht
Backups anzufertigen, man mu? sie im Ernstfall auch wieder einspielen k?nnen
und genau hier ist gtar h?chst gef?hrlich.

- gtar mag mit einer Wahrscheinlichkeit von ca. 5% nicht die Folgearchive
von eigenen Multi Volume Backups als in die Reihe geh?rig akzeptieren.

- gtar weigert sich in bestimmten F?llen bei umbenannten Directories
mit inkrementellen Backups den darauf folgenden inkrementellen Backup
einzuspielen. Ein Testzsenario existiert und wurde als Shell Skript
gemeldet.

- gtar erzeugt dar?berhinaus riesige Archive, wenn Directories umbenannt
wurden.

gtar bewirbt seit 1992 seine inkrementellen Backups, jedoch hat das
Zur?ckspielen dieser Backups noch niemals zuverl?ssig funktioniert und es gibt
auch keine Tests, die das jemals erprobt haben.

Die Maintainer wurden ?ber dieses Problem seit September 2004 mindestens 4x
auf diesen Bug aufmerksam gemacht, ohne da? es zu irgendwelchen Reaktionen kam.
Gut, die ?bliche Reaktionszeit auf Bug-Reports liegt nach meiner Erfahrung bei
22 Jahren und da m?ssen wir vielleicht einfach noch 7 Jahre warten :-(
Joerg.Schilling (04.12.2019, 15:52)
In article <2ft3tfaqmghv8>,
Sven Hartge <reply-nospam> wrote:
>Holger Schauer <Holger.Schauer> wrote:
>obnam ist tot und wurde offizelle vom Programmierer zu Grabe getragen:
>,----
>| The Obnam project is retired. See
>| for more
>| information. Please use another backup solution instead.
>`----
>Ich nutze borg zur
>Sicherung meiner Systeme.


So ein System halte ich für suspekt....

Hat dieses Backup System bewiesen, daß es die Backups auch wieder korrekt
einspielen kann?
Gunter Gutzeit (04.12.2019, 17:33)
Joerg.Schilling schrieb am Mi 04.12.2019 13:52:15
+0000:

> In article <2ft3tfaqmghv8> ,
> Sven Hartge <reply-nospam> wrote:
> So ein System halte ich für suspekt....
> Hat dieses Backup System bewiesen, daß es die Backups auch wieder korrekt
> einspielen kann?


In der Tat - mit einem Restore aus einem fehlgeschlagenen Backup kann
man sich sehr unglücklich machen.

Immer schön misstrauisch bleiben und vorher alles gut durch testen
bevor man einer Lösung traut.

Thomas Noll (04.12.2019, 19:02)
Am Wed, 04 Dec 2019 13:52:15 +0000 schrieb Joerg.Schilling:

> Hat dieses Backup System bewiesen, daß es die Backups auch wieder
> korrekt einspielen kann?


Wozu? Restore war doch bisher auch noch nie nötig...
Tim Ritberg (04.12.2019, 19:20)
Am 04.12.19 um 14:50 schrieb Joerg.Schilling:
> In article <qs1bln7>,
> Tim Ritberg <tim> wrote:
> VORSICHT!
> Wenn Leute auf Linux "tar" sagen, meinen sie leider meist "gtar" und das ist
> als Backupsystem höchst gefährlich, weil es mit einer Wahrscheinlichkeit von
> 1-5% nicht in der Lage ist, die eigenen Backups auch wieder einzuspielen.


ich schrieb nichts von inkrementell, kannst dich wieder hinlegen...

Tim
Fritz (04.12.2019, 20:04)
Am 04.12.19 um 11:37 schrieb Gunter Gutzeit:
> ei diesem ganzen Blödsinn:
> - nicht entmutigen lassen
> - trotzdem am Ball bleiben
> - Vertraue Deinem gesunden Menschenverstand
> - die Komplexität von Problemen reduzieren und dann eins nach dem
> anderen
> - selbst im Internet recherchieren
> - Lösungsmöglichkeiten selbst austesten und die dann die beste (meist
> die einfachste) wählen
> Ohne Zeitaufwand, aber kein Fortschritt:-)


Ein paar nette kleine Übungen:
* In VirtualBox FreeBSD installieren + X + Mate Desktop + etliche
Applikationen (mit pkg - nicht ports)
* In VirtualBox (neben LinuxMint) Kali Linux (Arch basierend)
installieren und u.a. auch BIND named als Cache & Resolve DSNSEC einrichten.
* Auf dem Mac per MacPorts ebenfalls BIND named als Cache & Resolve
DSNSEC einrichten.
* Auf dem Mac gnu-bash 5 mit allen verfügbaren patches mittels Xcode
selbst kompilieren und als Default einrichten.

OpenIndiana (OpenSolaris) hatte ich auch schon in einer VM installiert,
aber es halbwegs vernünftig laufen zu sehen, dazu ist mein alter Mac
schon zu schwach. OpenIndiana seht aber sehr nett aus.

PS: Bei FreeBSD pkg nur deshalb, da ports lokal kompiliert, das würde
bei den wenigen verfügbaren Ressourcen Stunden, Tage dauern.

PPS: Ich kenne keine Grenzen zw. Linux, BSD (Unix), macOS. Arbeiten tu
ich lieber am Mac, experimentieren aber mit Allen.
Florian Weimer (04.12.2019, 20:21)
* Holger Schauer:

> On 9588 September 1993, Florian Weimer wrote:
> Da müsste ich mal eine genauere Analyse machen. Da sind mit Sicherheit
> eine Menge Dateien dabei, die kleiner sind als 64 KiB, aber wie genau
> das Verhältnis ist, kann ich nicht aus dem Stehgreif sagen.


Ich habe keine genauen Zahlen, würde aber für Borg 0.5 GiB RAM pro
Million (kleiner) Dateien schätzen. Die Borg-Dokumentation hat
Formeln, aber diese scheinen in der Praxis nicht ganz zu stimmen.

> Im Moment sieht das von Sven vorgeschlagene borg (bzw. borgmatic) für
> mich am interessantesten aus. Die Deduplizierung bei einem einzigen
> Backup-Lauf ist schon beeindruckend.


Mit dem nativen Transport braucht Borg auch ordentlich RAM auf dem
Ziel. Man kann es zur Not auch über SSHFS laufen lassen.

Restic hat nicht das Problem mit dem RAM-Verbrauch auf dem Ziel nicht,
hat aber keine (direkte) Kompression, nur Deduplikation. Die Metadaten
auf der Platte für die Quelle waren bei mir allerdings recht groß (5%
bis 10% vom Backup-Volumen, allerdings mit sehr vielen kleinen
Dateien).
Holger Schauer (04.12.2019, 20:52)
On 9590 September 1993, Joerg Schilling wrote:
> Wenn Leute auf Linux "tar" sagen, meinen sie leider meist "gtar" und das ist
> als Backupsystem höchst gefährlich, [...]


Ach Du meine Güte, ich komme mir vor wie 2002. Zum Glück brauche ich
kein Backup von CDs. Wer meldet sich als nächstes? Robin? Adam K.?

Holger

PS: F'up2 poster

Ähnliche Themen