staging.inyokaproject.org

Der "heilige Gral" der Backupprogramme 😉. Mir gefällt's sehr gut und da es seit 16.04 ein Paket für Ubuntu gibt, erstelle ich mal eine Wiki-Seite.

Hilfe und Anregungen (vor allem von attic- und borg-Nutzern) willkommen ☺.

Hallo,

auch wenn der Artikel noch (lange) nicht fertig ist, schon mal eine Anmerkung.

IMHO sollte die Einleitung geteilt werden: der 1. Teil bleibt drin, der zweite Teil wird in einen eigenen Abschnitt "Technik" (oder "Funktionsweise" oder so ähnlich) gelegt. Macht mehr Sinn, denke ich.

Gruß, noisefloor

Ja, danke für die Anmerkung. Ich schreib erst mal alles rein und dann können wir umbauen und den Feinschliff machen.

Cool, endlich schreibt einer den Artikel ☺

Anregungen:

• der Einleitungsteil ist eine Textwüste. Ich prsl. hab es lieber kürzer und auch gerne mit Spiegelstrichen / Aufzählungen, um schneller das relevante zu erkenne. Das geht hier unter. Ein Bsp: gleich im 1. Satz damit zu kommen das es ein Fork von Attic ist, ist schlecht. So was gehört unter Trivia. Das interessiert ja auch erst mal nicht bzgl. Funktionalität. (Mal ehrlich: wer Borg nicht kennt, der kennt auch Attic nicht).

• Installation: ich selbst nehme nicht die Quellen, da wie so oft hinten dran. Auf der Borg-Seite ist ja kurz beschrieben, wie es alternativ geht. Verlinken oder übernehmen. Im Übrigen gab es m.E. auch eine Major Change zwischen dem aktuellen Stand und dem alten Stand der Quellen, so das man bei Neubeginn sowieso besser mit dem aktuellen bedient ist.

• die wesentlichen Stärken, auch im Vergleich zu anderen Backup-SWs:

  • Deduplizierung. Ein großer Vorteil bei z.B. DB-Dumps oder VM-Ständen.

  • Filessystem der Zielplatte ist egal. Das kann auch z.B. NTFS sein, ohne das Dir Info verloren geht (Rechte, Symlinks, ...)

• Bsp-Skript für den Hausgebrauch: Sicherung von z.B. /home und /etc sollte dazu. Könnte ich beisteuern, beruht i.W. auf dem, was auf der Borg-Seite steht.

• Restore-Aspekt fehlt bei so Sachen oft. Z.B.: wie mounte ich das Backup, um eine eben gelöschte Datei daraus zu holen?

Wenn gewünscht kann ich bei Bedarf hier mitschreiben, falls Zeit. Bis 1.11. ist ja noch hin.

Seebär schrieb:

• der Einleitungsteil ist eine Textwüste.

Das ist auch so gemeint und meine Arbeitsweise. Erst einmal etwas "Masse" produzieren und dann "modulieren". Ich hätte das auch erst einmal lokal ausformulieren können aber das heißt ja hier Baustelle. Danke für die vielen Anregungen.

Ich würde gern erst einmal 1-2 Wochen allein am Artikel schreiben. Danach würde ich den Text dann "freigeben" und mich über tätige Mithilfe sehr freuen. Ein Skript wollte ich auch auf jeden Fall mit reinnehmen und wäre Dir dankbar, wenn Du etwas beisteuern könntest.

Grüße, Thomas

Thomas_Do schrieb:

Ich würde gern erst einmal 1-2 Wochen allein am Artikel schreiben.

Na logan, nur keine Hast, Dann modelliere mal 😉 Script s. unten, Kernpunkte:

• Repo anlegen falls nötig

• Sicherungen mit Hostname + Zeitstempel sauber auseinander halten (das Script ist dann auch so auf anderem Rechner einsetzbar)

• Alte Sicherungen reduzieren

Die "targetdisc" = Mountpoint des Sicherungsmediums muss man halt 1x anpassen, habe da mal meinen Username entfernt (das $USER muss nicht sein). Aber mit der Steilflanke sollte man es leicht selbst schaffen, das anzupassen, wo nötig.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#!/bin/bash

targetdisc=/media/$USER/backupdisc-03
repo=$targetdisc/borg

# check for root
if [ $(id -u) -ne 0 ]; then
  echo "Sicherung muss als root-user ausgeführt werden."
  exit 1
fi

# Init borg-repo if absent
if [ ! -d $repo ]; then
  borg init --encryption=none $repo  
  echo "Borg-Repo erzeugt unter $repo"
fi

# siehe https://borgbackup.readthedocs.io/en/stable/quickstart.html
# backup data
SECONDS=0
echo "Start der Sicherung $(date)."

borg create --compression lz4 --exclude-caches --one-file-system -v --stats --progress \
    $repo::'{hostname}-{now:%Y-%m-%d-%H%M%S}' \
    /etc                                      \
    /home                                     \
    --exclude '/home/*/.cache'

echo "Ende der Sicherung $(date). Dauer: $SECONDS Sekunden"

# Alte Sicherungen reduzieren
borg prune -v $repo --prefix '{hostname}-' \
    --keep-daily=7 --keep-weekly=4 --keep-monthly=6

Auch im Homeverzeichnis unter ~/.cache sollten mehrere Gigabyte für die Indexierung frei sein.

Woher kommt diese Aussage? Ich kann das nicht bestätigen. Bei mir liegen da gerade mal Daten im Bereich von 30 .. 60 MB. Auch während laufender Sicherung. Das wäre auch schlecht, wenn dem so wäre.

Seebär schrieb:

Auch im Homeverzeichnis unter ~/.cache sollten mehrere Gigabyte für die Indexierung frei sein.

Woher kommt diese Aussage?

Das kommt von hier. Der Speicherbedarf hängt sowohl von der Anzahl als auch Größe der Dateien ab. Bei mir ist es auch viel weniger. Ich hab' hier eine Sicherung von ca. 750 GB und einen Cache von ~50 MB. Könnte noch aus attic-Zeiten stammen, als noch kleinere Chunks verwendet wurden. Wir sollten da mal Erfahrungen anderer User sammeln.

Naja, das hast Du sehr frei und m.E. nicht korrekt interpretiert/übersetzt, zumal es ja auch noch recht vage formuliert ist. Du schreibst eindeutig "mehrere GB im .cache". Das steht da nicht. Und faktisch ist es ja nicht so. Ist daher eher falsch / verwirrend als richtig. Unter einer solchen Prämisse würde ich das Backupsystem fast nicht verwenden, müsste ich auf dem Quellsystem(!) zusätzlich GB-weise Platz vorhalten.

make sure that there is always a good amount of free space on the filesystem that has your backup repository (and also on ~/.cache). A few GB should suffice for most hard-drive sized repositories.

.cache wird ja nur nebenbei erwähnt, "few" ist einige/wenige und bezieht sich wohl eher auf das repo selbst. Ich würde den Hinweis schlicht herausnehmen.

Seebär schrieb:

Naja, das hast Du sehr frei und m.E. nicht korrekt interpretiert/übersetzt, zumal es ja auch noch recht vage formuliert ist. Du schreibst eindeutig "mehrere GB im .cache". Das steht da nicht. Und faktisch ist es ja nicht so. Ist daher eher falsch / verwirrend als richtig. Unter einer solchen Prämisse würde ich das Backupsystem fast nicht verwenden, müsste ich auf dem Quellsystem(!) zusätzlich GB-weise Platz vorhalten.

make sure that there is always a good amount of free space on the filesystem that has your backup repository (and also on ~/.cache). A few GB should suffice for most hard-drive sized repositories.

.cache wird ja nur nebenbei erwähnt, "few" ist einige/wenige und bezieht sich wohl eher auf das repo selbst. Ich würde den Hinweis schlicht herausnehmen.

"a few GB" müsste wohl völlig korrekt mit "einige GB" übersetzt werden. Es muss sich hier den Cache beziehen und nicht auf das Repo selbst da von einen "Festplattengroßen Repo" gesprochen wird. Und das sind nun sicher mehr als einige GB. Mal schauen, was andere zur Cachegröße meinen.

Wenn man sich diese Quelle ansieht, dann sind mehrere Gigabyte schon korrekt.

Ich habe gerade mal meine Datenplatte sowie zwei Installationen und ein wenig Kleinkram vom Krusader zusammenzählen lassen und komme da auf 1.657.224 Dateien mit einer Gesamtgröße von 1,3 TB. Da ist kommt man dann auf einem Gesamtspeicherbedarf von mehr als 2 Gbyte. Und es wäre schon fatal, wenn man beim ersten Lauf an mangelndem Plattenspeicher scheitert.

Seebär schrieb:

Unter einer solchen Prämisse würde ich das Backupsystem fast nicht verwenden, müsste ich auf dem Quellsystem(!) zusätzlich GB-weise Platz vorhalten.

Du darfst nicht vergessen, dass dieser Speicherplatz benötigt wird, um die Deduplizierung zu erreichen. Alle Datei werden in ca 1 MB große Stücke zerlegt, und diese werden dann mit den nachfolgenden Stücken verglichen. Da dieses zerstückeln auf eine intelligente Art passiert, wird so erkannt, wenn solch ein Stück bereits einmal gespeichert wurde, weil beispielsweise ein Bild mehrfach auf Deiner Platte vorhanden ist, oder weil Dein Rechner mehrere Ubuntu-Installationen enthält, die teilweise die gleichen Dateien benutzen. Hier wird dann diese Datei nur einmal gespeichert und man spart auf dem Backupmedium entsprechend Speicherplatz. Auch wenn man beispielsweise seine Bilder umsortiert und in andere Ordner verfrachtet, wird eine gewöhnliche Backupsoftware diese dann unter dem neuen Pfad erneut abspeichern. Borg erkennt, dass diese Bilder bereits gesichert sind und erstellt nur einen Verweis. Das spart dann Zeit und wiederum Backupspeicher.

Aber um dies erreichen zu können, muss während des Backups ein entsprechend großer Index aufgebaut werden, um all diese Stücke vergleichen zu können. Und dass sind bei ensprechend vielen Dateien eben durchaus mehrere Gbyte.

Wenn Du mal ne Stunde Zeit hast, höre dir den Vortrag des Entwicklers an, der am Ende verlinkt ist, da wird Dir klar, dass dieser temporäre freie Platz gut angelegt ist.

Der Sinn des Index ist unbestritten (wobei es ja auch ohne geht, dann aber auf Kosten der Geschwindigkeit). Deduplizierung an sich ist auch schon klar. Das der Index (zwingend?) auf dem Quellmedium liegt überrascht aber. Eine rote "Achtung!"-Box wäre mir das dennoch nicht wert. 1,3 TB? Wow, ein Jäger und Sammler...

Seebär schrieb:

Eine rote "Achtung!"-Box wäre mir das dennoch nicht wert.

Für ein Backup mal locker 3 GB freihaben zu müssen, damit würde ich unvorbereitet nicht rechnen. Da find ich ein wenig Achtung nicht unangemessen.

1,3 TB? Wow, ein Jäger und Sammler...

😀
Ich habe mal gerade durchgesehen: Die ältesten Daten, über die ich beim überfliegen gestolpert bin, stammen aus 1999 - und sind alle unter Windows entstanden und nicht etwa mit dem C64 oder einem anderen Museumsstückchen … 😉

Seebär schrieb:

Eine rote "Achtung!"-Box wäre mir das dennoch nicht wert.

Die Achtungbox ist für den freien Platz im Cache und im Repository.