ubuntuusers.de

Ich habe jetzt eine Weile im BackInTime-Github gestöbert. Da besteht wohl immer noch Uneinigkeit, ob das nicht eigentlich ein Bug in rsync ist, deswegen scheint sich nichts zu bewegen. Ich werde erstmal mit den 800+K leben müssen.

Miq19 schrieb:

san04 schrieb:

Das kannst du doch leicht mit --no-perms in der GUI überschreiben. Dein Hauptproblem bleibt meiner Meinung nach die Option --executability. Wenn dann solltest du danach schauen, denke ich.

Nein, das geht eben nicht. Die "--no-perms" werden nur zusätzlich angehängt, das vordere "--perms" bleibt drin.

Das ist richtig, aber das hintere überschreibt das vordere, kannst du mit dem von BiT kreierten rsync Befehl testen...

Deshalb werden ja die Optionen

--no-perms --no-group --no-owner

bei Github vorgeschlagen.

Dein Problem ist, wie oben beschrieben, die --executability Option. Dafür gibt es keine Negation a la --no-executability. Das kannst du also nur unwirksam machen durch z.B. --chmod=u+x mit den beschriebenen Nebenwirkungen. Dann läuft das Backup aber durch und erkennt vorangegangene Snapshots. Rechte sicherst du auch vorher schon nicht mit, sofern du die Optionen mitgibst.

Sorry Berlin_1946, aber du bist völlig offtopic. Ich hatte oben schon geschrieben, dass ich 1.4.3 aus dem Github gebaut hab. Was neueres wirst du wohl auch in keinem PPA finden... Und Timeshift hat hiermit nun wirklich nichts zu tun.

san04 schrieb:

Sorry Berlin_1946, aber du bist völlig offtopic.

Ich hatte die Idee, dass es bei Snapshots zu Verbindungsproblemen mit Zeitabhängigkeiten kommen könnte. 😎

Hatte ich gelesen, dass so was bei NAS passiert sein soll, aber es gibt ja auch viel Qua... in Netz. Sry

Es scheint im Moment für mich so auszusehen, dass es dann überhaupt nichts mit dem NAS zu tun hat, sondern "nur" mit BiT.

Liege ich denn da wenigstens richtig?

Berlin_1946 schrieb:

Es scheint im Moment für mich so auszusehen, dass es dann überhaupt nichts mit dem NAS zu tun hat, sondern "nur" mit BiT.

So würde ich das sehen, bin aber auch nicht ganz sicher. Lokal auf ext4 tritt das Problem scheinbar nicht auf. Vielleicht könnte man den Samba-Server auch anders konfigurieren, aber damit kenne ich mich gar nicht aus... Vielleicht meldet sich dazu ja noch jemand.

Hallo in die Runde,

ich habe mal den Bandwurm des rsync angesehen, da ist laut man-Page etwas nicht so okay, oder ich verstehe da was völlig falsch:

rsync ... --perms --executability ...

• --executability, -E # steht das nachfolgende unter diesem Punkt

• --perms is enabled, this option is ignored.

Versteht ihr das?

Ist mir auch beim Lesen der manpage aufgefallen. Der BiT Befehl ist also eh etwas unsinnig, würde ich sagen. Bei dem Vorschlag:

--no-perms --no-group --no-owner

wird die Option ja negiert und dann gilt --executability wieder. Daher hatte ich folgendes getestet:

--no-perms --no-group --no-owner --chmod=u+x

Hallo in die Runde,

ich mache mal einen großen Spruch:

Wenn BiT so ist, wie es z.Zt. ist und mit dem (unterstellten) Bug nicht zu Potte kommt, dann ...

Skripte/Backup mit RSYNC

Da kann dann noch eher eingriffen als mit kompilieren usw.

Was meint Ihr?

Ich stimm(t)e dir zu 😛

Ich persönlich würde mir da lieber ein kleines Backupskript selbst bauen und auf die GUI verzichten: Skripte/Backup mit RSYNC

san04 schrieb:

Ich persönlich würde mir da lieber ein kleines Backupskript selbst bauen und auf die GUI verzichten: Skripte/Backup mit RSYNC

Sry, hatte ich leider schon vergessen, das du das schon geschrieben hattest.

Wie sagen die ...

Zwei Seelen und ein Gedanke ... oder Doppelt hält besser.

Achtung Ironie:

Wir sind ja erst auf Seite 3

Ich habe in /usr/share/backintime/common/tools.py (in 1.4.1 Zeilen 891ff.) kurzerhand die missliebigen Optionen auskommentiert:

    # if no_perms:
        cmd.extend(('--no-perms', '--no-group', '--no-owner'))
    # else:
        # cmd.extend(('--perms',          # preserve permissions
                    # '--executability',  # preserve executability
                    # '--group',         # preserve group
                    # '--owner'))         # preserve owner (super-user only)

Jetzt wird also komplett ohne Berechtigungen, User, Gruppen und die Executable-Umwandlung gesichert. Was soll ich sagen? Klappt.

Dann habe ich jetzt alles wieder aktiviert, nur das "--executability" nicht. Der nächste Snapshot kopierte wieder die bekannten Dateien, aber das hatte ich wegen der zuletzt geänderten x-Berechtigung eigentlich erwartet. Aber: der danach gestartete Snapshot macht es wieder?!?

Deswegen ein letzter Versuch mit "--no-perm" etc. in den erweiterten Optionen. Und der läuft wieder ohne Extrakopien.

Es ist total schade, dass es diesen internen Parameter no_perms für die BackInTime-Konfiguration nicht gibt.

Also funktioniert für dich jetzt (bis zum nächsten Update) das Auskommentieren von --executability in der tools.py und dann setzten der --no-perm in der GUI, verstehe ich das richtig?

Es ist total schade, dass es diesen internen Parameter no_perms für die BackInTime-Konfiguration nicht gibt.

Den hättest du gerne in der GUI klickbar, oder wie meinst du das?

san04 schrieb:

Also funktioniert für dich jetzt (bis zum nächsten Update) das Auskommentieren von --executability in der tools.py und dann setzten der --no-perm in der GUI, verstehe ich das richtig?

Yes.

Es ist total schade, dass es diesen internen Parameter no_perms für die BackInTime-Konfiguration nicht gibt.

Den hättest du gerne in der GUI klickbar, oder wie meinst du das?

Genau.

Ich habe meine Erkenntnisse mal an den Issue-Thread https://github.com/bit-team/backintime/issues/1437 im BackInTime-Github gesetzt.

Miq19 schrieb:

san04 schrieb:

Also funktioniert für dich jetzt (bis zum nächsten Update) das Auskommentieren von --executability in der tools.py und dann setzten der --no-perm in der GUI, verstehe ich das richtig?

Yes.

Okay, das ist ja dann das oben schon beschriebene --no-perm --no-executability... nur, dass es letzteren Befehl eben leider nicht gibt.

Dein Problem wäre ja vermutlich schon behoben, wenn beim snapshot-Aufruf no_perms nicht gesetzt würde, oder? Mal schauen, was sich da tut.