Backups mit Back in Time

[Tanne]

Hallo,

Da ich demnächst größere Umsortierungarbeiten vorhabe (Daten und Ordner von einem Ordner in einen neuen verschieben), frage ich mich, ob das beim Backup erkannt wird, dass es jeweils diesselbe Datei ist und es im Backup einen Hardlink vom neuen Ort zu der Datei am alten Ort des ersten Backups gemacht wird. Oder ob die Datei nochmal kopiert wird und dann hab ich lauter doppelte Dateien gespeichert.

Weiß jemand, was "wiederholend (anacron)" im Zeitplan bedeutet?

Das Backup soll auf eine externe Platte, die da nicht dauernd angeschlossen ist (und oftmals vergesse ich, sie anzuschließen). Unter Windows hatte ich ein Backup-Programm, das nachgefragt hat, wenn Backup vorgesehen war und die Platte nicht angestöpselt war (zumindest beim nächsten Hochfahren, wenn die letzte vorgesehene Sicherung nicht stattgefunden hat, und ich meine, das Backup auch sonst automatisch angestoßen hat, wenn man dann endlich irgendwann anstöpselte). Gibt es so eine Möglichkeit bei Back in Time auch?

 

[nutrix]

Weiß jemand, was "wiederholend (anacron)" im Zeitplan bedeutet?

https://answers.launchpad.net/backintime/+faq/2722

 

[foofoobar]

Da ich demnächst größere Umsortierungarbeiten vorhabe (Daten und Ordner von einem Ordner in einen neuen verschieben), frage ich mich, ob das beim Backup erkannt wird, dass es jeweils diesselbe Datei ist und es im Backup einen Hardlink vom neuen Ort zu der Datei am alten Ort des ersten Backups gemacht wird. Oder ob die Datei nochmal kopiert wird und dann hab ich lauter doppelte Dateien gespeichert.

Man könnte versuchen rsync dahingehend zu verarschen in dem man einen Link an die neue Position legt dann den inc. Backup laufen lässt und danach die Quelle löscht und dann noch einen inc. Backup laufen lässt.
Oder du ziehst die moves im Backup nach.

Aber eigentlich nutzt man aus diesen Grund irgendwas mit Deduplizierung.

 

[Tanne]

Danke Euch!

Schade, das mit den Links oder den nachziehen der Veränderungen ist mir zu kompliziert während der Umstellungsarbeiten, nur für danach. Da mich diese Arbeiten aber einiges an Gehirnschmalz kostet, wird sich das über einige Monate hinziehen).

Ich hab nun nachgedacht, ob es so schlimm ist mit den Duplikaten, wenn ich das häufige Backup (oder besser gesagt das Aufheben der Backup-Versionen nach Stufenschema) nur von den Dokumenten mache, das sind 2,6 GiB, und den Multimedia-Ordner mit eigenem Backupprofil, wo eigentlich immer nur was dazukommt und wo es reichen sollte, ein Backup vom aktuellen Stand zu haben (ca. 20 GiB). Und noch großzügig gerechnet 5 GiB zu Linuxsachen, von denen ich pro halbes Jahr ein Backup behalten will. Das ergibt bei mir insg. gut 200 GiB pro Jahr.
Das einzige Problem ist dann noch, wenn ich Daten von 2 anderen Rechnern auf der jetzigen Platte integrieren will, aber notfalls muss ich dann auf eine größere Platte umziehen o.ä., das muss ich dann sehen.

Backupprogramm mit Deduplizierung hatte ich neulich noch Deja Dup angesehen, aber ich mag das nicht so gern, da man dort das Programm braucht, um auf das Backup zuzugreifen. Ist mir nicht so geheuer, nicht zuletzt, da mein USB-Anschluß einen Wackelkontakt hat. (auch wenn das natürlich nicht so bleiben kann).

 

[foofoobar]

Backupprogramm mit Deduplizierung hatte ich neulich noch Deja Dup angesehen, aber ich mag das nicht so gern, da man dort das Programm braucht, um auf das Backup zuzugreifen.

"cp" ist auch ein gewöhnliches Programm das man braucht um auf "die" Daten zuzugreifen.

 

[Donnerkind]

Ich hab nun nachgedacht, ob es so schlimm ist mit den Duplikaten, wenn ich das häufige Backup (oder besser gesagt das Aufheben der Backup-Versionen nach Stufenschema) nur von den Dokumenten mache, das sind 2,6 GiB, und den Multimedia-Ordner mit eigenem Backupprofil, wo eigentlich immer nur was dazukommt und wo es reichen sollte, ein Backup vom aktuellen Stand zu haben (ca. 20 GiB).

Definiere mal „schlimm“. Bei den von dir genannten Volumina sehe ich absolut kein Problem, es sei denn, deine Backupplatte ist voll. Irgendwann werden die Duplikate dann sowieso ausrotiert.

Das ergibt bei mir insg. gut 200 GiB pro Jahr.

Da die Duplizierung nur ein einziges Mal geschieht, ist die im Vergleich dazu meines Erachtens sogar vernachlässigbar.

Ich habe auch noch home und Medien in getrennten Backup-Repos, aber eher aus historischen Gründen: Damals, als die SSDs noch klein waren, passte nur home auf die SSD. Der große Kram wie Fotos und Musik mussten noch auf der Festplatte bleiben. Ich überlege schon lange, das mal umzuziehen, würde aber auch starke Duplizierung bedeuten, weil ich das alte Home-Repo ja noch behalten will zwecks Versionierung (ich benutze Borg). In meinem Fall ist home über 80 GB groß.

"cp" ist auch ein gewöhnliches Programm das man braucht um auf "die" Daten zuzugreifen.

Aber es gehört zum Standardbaukasten, der wirklich überall dabei ist. Man muss es nicht mitnehmen und von extern zuführen, sondern kann sich sicher sein, es vorzufinden.

 

[foofoobar]

Aber es gehört zum Standardbaukasten, der wirklich überall dabei ist. Man muss es nicht mitnehmen und von extern zuführen, sondern kann sich sicher sein, es vorzufinden.

Ein Hinweis dazu:
https://www.computerbase.de/forum/t...es-home-backup-auf-smb.2248150/#post-30806854

 

[Donnerkind]

Ein Hinweis dazu:

Was hat der genau mit dem Vorhandensein des Programms zu tun? Denn an genau den Post musste ich
beim Verfassen meiner obigen Antwort denken. Denn auch wenn Restic statisch gelinkt ist und somit laufen sollte, muss man trotzdem selbst dafür sorgen, dass es verfügbar ist (z.B. auf dem Backup-Datenträger). cp ist wie gesagt Standard und man kann davon ausgehen, dass es auf jedem Linux-System bereits verfügbar ist, und sei es noch so exotisch (z.B. eine 32-Bit-Distro).

 

[Tanne]

Da die Duplizierung nur ein einziges Mal geschieht

Musste ich länger drüber nachdenken, aber ja, wenn ich die Dateien einmal umsortiere, ist es ein Duplikat. Wenn ich es im Laufe der Zeit z.B. 5x umsortiere, sind es 5 Duplikate, aber das dürfte für die wenigsten Dateien passieren. Hatte ich einen Denkfehler.
Ich hab da in meiner Berechnung worst-case gerechnet, nämlich jedesmal wird von jeder Datei ein Duplikat angelegt (quasi ein Fullbackup), was ja aber gar nicht stimmt. Also 52x 2,6 GiB (beim gestrigen Vollbackup waren es nur 1,7 GiB). Das macht 135 GiB von meiner Überschlagsrechnung aus. Also das ist, durch meinen Denkfehler, sehr großzügig geschätzt.

Medien und Linuxsachen weiß ich noch nicht, wie ich das mache, ob als "händisch" kopierte Ordner, jedes für sich (jedesmal Full backup), oder ob jeweils als extra Profil/Auftrag in Back in Time oder ob sich Daten-, Medien- und Linuxordner irgendwie einen Backupordner teilen können und (mit unterschiedlichen Regeln) von Back in Time verwaltet werden können. Ich glaub, ich machs erstmal in einen extra Ordner, in den gemeinsamen Backupordner kann man es später ja ggf. immer noch kopieren.

Ich habe auch noch home und Medien in getrennten Backup-Repos, aber eher aus historischen Gründen: Damals, als die SSDs noch klein waren, passte nur home auf die SSD. Der große Kram wie Fotos und Musik mussten noch auf der Festplatte bleiben.

Also das Backup von home ist auf einer SSD, das Backup der Medien auf einer HDD?

Ich überlege schon lange, das mal umzuziehen

Du meinst, beides auf eine SSD?

würde aber auch starke Duplizierung bedeuten,

Also Du meinst home auf der bisherigen und einer neuen SSD ist doppelt?
Aber wenn Du eine größere SSD nimmst, wo beides gut drauf passt, kannst Du doch das alte home Backup darauf kopieren und weiter verwenden, dann wäe es nicht doppelt, und erweiterst das Backupprogramm um die Medien (oder machst parallel einen Auftrag im Backupprogramm für die Medien in einen eigenen Ordner), oder geht das nicht? Die alte SSD kannst Du dann für anderes verwenden.
Oder Du lässt es mit den Duplikaten und nimmst die alte SSD als Teil von 3-2-1.

zwecks Versionierung (ich benutze Borg).

wie das mit Borg umzusetzen ist, weiß ich nicht.

Ist schon ein bisschen knifflig, so eine Backupplanung.

Ergänzung (Freitag um 03:06)

cp ist wie gesagt Standard und man kann davon ausgehen, dass es auf jedem Linux-System bereits verfügbar ist, und sei es noch so exotisch (z.B. eine 32-Bit-Distro).

Ja, ich hatte auch Datenrettungstools wie testdisk vor Augen. Und bin Fan vom KISS-Prinzip.

 

[foofoobar]

Musste ich länger drüber nachdenken, aber ja, wenn ich die Dateien einmal umsortiere, ist es ein Duplikat. Wenn ich es im Laufe der Zeit z.B. 5x umsortiere, sind es 5 Duplikate, aber das dürfte für die wenigsten Dateien passieren. Hatte ich einen Denkfehler.

Deduplizierung erschlägt auch den Fall das sich in einer Datei was ändert. (VM-Images, Datenbanken, usw.)
Oder mehrere Versionen einer Datei mit wenigen Deltas: https://restic.net/blog/2015-09-12/restic-foundation1-cdc/

Also das Backup von home ist auf einer SSD, das Backup der Medien auf einer HDD?

Leg dir auf dem neuen Medium 2 Filesysteme an, am besten unter lvm, und mounte das dahin wo es vorher war.

 

[Donnerkind]

Also das Backup von home ist auf einer SSD, das Backup der Medien auf einer HDD?

Nein, das eigentliche Home war auf SSD und Medien auf Platte. Die Backups sind schon immer alle auf einer gemeinsamen externen HDD.

Du meinst, beides auf eine SSD?

Ja, ich habe vor Jahren die Platte (1 TB) und die alte 512er SSD rausgeworfen, nachdem der Rechner eine 2-TB-SSD bekommen hat.

Also Du meinst home auf der bisherigen und einer neuen SSD ist doppelt?

Aktuelle Situation: ich habe ein Borg-Repo für home und eins für Medien. Wenn ich jetzt die Daten- und die Home-Partition zusammenführe, würde auch beides in ein gemeinsames Borg-Repo kommen, weil ich dann auch die Pfade aufräumen würde und alle unter /home zusammenbringen möchte.

Weil die Mediandaten viel größer sind als home, wird das bisherige home-Backup stillgelegt und die home-Daten ins Daten-Backup aufgenommen. Im Endeffekt habe ich also ein doppeltes-Home-Backup rumliegen. Ich könnte das alte zwar auch einfach löschen, aber es enthält inzwischen Inkremente mehrerer Jahre, das ist manchmal praktisch zu haben. Naja und noch ist Platz auf der Backupplatte.

Aber wenn Du eine größere SSD nimmst, wo beides gut drauf passt, kannst Du doch das alte home Backup darauf kopieren und weiter verwenden, dann wäe es nicht doppelt, und erweiterst das Backupprogramm um die Medien (oder machst parallel einen Auftrag im Backupprogramm für die Medien in einen eigenen Ordner),

Die bestehenden Backup-Repos weiter verwenden geht halt nur wieder mit Pfadjonglieren, damit ich im Backup Medien und home voneinander trennen könnte. Konkret bestehen die Medien aus Fotos, Videos und Musik. Die würden dann in meinem Home in den entsprechenden Pfaden landen (wobei ich schon ein ~/Bilder habe, wo ganz alte Fotos drin sind von bevor die Partition zu klein wurde. Du merkst, es ist kompliziert, wie so oft mit technischen Schulden.) Dann müsste ich im Home-Backup eine Ignorierregel für die Medienverzeichnisse erstellen und beim Medienbackup andersrum, das möchte ich vermeiden. Das Ziel ist, das Setup einfacher, sauberer und expliziter zu bekommen.

Achso und ein weiterer Grund: meine Home-Partition ist 100 GB groß und wird langsam eng. Ich nutze zwar LVM und könnte einfach Platz von der Datenpartition umwidmen, aber wieviel? Und wie lange hält das bevor ich es wieder tun muss? Auch deshalb möchte ich die beiden zusammen bringen.

 

[foofoobar]

Die bestehenden Backup-Repos weiter verwenden geht halt nur wieder mit Pfadjonglieren, damit ich im Backup Medien und home voneinander trennen könnte. Konkret bestehen die Medien aus Fotos, Videos und Musik. Die würden dann in meinem Home in den entsprechenden Pfaden landen (wobei ich schon ein ~/Bilder habe, wo ganz alte Fotos drin sind von bevor die Partition zu klein wurde. Du merkst, es ist kompliziert, wie so oft mit technischen Schulden.) Dann müsste ich im Home-Backup eine Ignorierregel für die Medienverzeichnisse erstellen und beim Medienbackup andersrum, das möchte ich vermeiden. Das Ziel ist, das Setup einfacher, sauberer und expliziter zu bekommen.

Symlinks?

 

[Donnerkind]

@foofoobar Das meine ich mit Pfadjonglieren. Es sind ja nicht nur die Pfade im Dateisystem, sondern auch in der Semantik. Ich möchte in Digikam wieder eine zentrale Fotosammlung haben statt sie über mehrere Wurzeln zu verteilen. Ich bin kein sonderlich ordentlicher Mensch, aber wenn ich wo Ordnung habe, dann in meinen Rechnersystemen.

 

[Tanne]

@Donnerkind:

Weil die Mediandaten viel größer sind als home, wird das bisherige home-Backup stillgelegt und die home-Daten ins Daten-Backup aufgenommen.

Aber warum machst Du es nicht umgekehrt und nimmst die Mediendaten ins home-Backup auf? Oder brauchst Du von den bisher angefallenen Mediendaten ebenfalls Versionen verschiedener Zeitpunkte?

Konkret bestehen die Medien aus Fotos, Videos und Musik. Die würden dann in meinem Home in den entsprechenden Pfaden landen

Ich benutze die vorgegeben Ordner nie, auch schon bei Windows nie. Ich hab alle meine Daten auf einer eigenen Partition und wenn mal was in den vorgegebenen Ordnern landet (z.B. Downloads-Ordner) sortiere ich das irgendwann immer in meine eigene Datenstruktur um.

Ich bin kein sonderlich ordentlicher Mensch, aber wenn ich wo Ordnung habe, dann in meinen Rechnersystemen.

Da sollte ich mich wohl ein bisschen mal an Dir orientieren, denn

Du merkst, es ist kompliziert, wie so oft mit technischen Schulden

(toller Begriff) davon hab ich einen Riesenberg.

 

[Donnerkind]

Aber warum machst Du es nicht umgekehrt und nimmst die Mediendaten ins home-Backup auf? Oder brauchst Du von den bisher angefallenen Mediendaten ebenfalls Versionen verschiedener Zeitpunkte?

Weil es mehr dupliziertes Volumen in den Backups bedeuten würde (Backup von Medien+Home plus altes Medienbackup vs. plus altes Home-Backup) und weil es weniger Schreibaufwand bedeutet, Home nach Medien zu kopieren als anders herum. Meine PC-Medienpartition enthält aktuell 1022 GiB, auf home liegen nur 163 GiB. Da beides auf LVM liegt, macht es technisch keinen Unterschied, welche von beiden ich lösche und den gewonnenen Platz der jeweils anderen anhänge. (Ich spreche gewohnheitsbedingt von Partitionen, auch wenn es sich eigentlich um LVM-Volumes handelt.)

 

[Tanne]

Ok, wenn Du von den Mediendaten auch Versionen bei den Backups hast, bringt meine Überlegung eh nichts. Das Kopieren von rund 1000 GiB vs. ca. 160 GiB ist natürlich ein gewaltiges Argument.

Eine Frage zur Größenangabe bei den Backups:
Ich hab mir die Größe der Backups bei Back in Time anzeigen lassen, auf Ordnerebene. Also einmal mit Eigenschaften bei dolphin und einmal mit Filelight. Backups von 2 Tagen waren in derselben Größenordnung. Eigentlich dürfte das 2. Backup nur minimal sein, soviele Änderungen hab ich an dem einen Tag ja nicht gemacht. Kann es sein, dass via dolphin oder filelight einfach die Größe der Datei gezählt wird, auch wenn nur per weiterem Hardlink darauf verwiesen wird? Gibt es eine Möglichkeit, rauszufinden, wie groß die neu dazugekommenen Dateien/Ordner sind? Vielleicht via Back in Time selbst?

 

[Donnerkind]

Ich kenne Back in Time jetzt nicht, aber wenn es mit Hardlinks arbeitet, dann zeigt Dolphin tatsächlich nur die augenscheinliche Größe an. Du kannst dir z.B. mit du die unterschiedlichen Größen summieren lassen. Da du Dolphin erwähnst, nutzt du vermutlich KDE. Das zugehörige Programm zur Platzanalyse heißt filelight, das rechnet Hardlinks auch raus. Ein sehr schönes TUI-Programm für diesen Zweck ist ncdu.