staging.inyokaproject.org

Hallo,

beim Starten von Back in Time kam eine Meldung, etwa: "Back in Time unterstützt ein neues Format, soll angepasst werden?" Ich habe auf "Ja" geklickt. Seitdem bricht das Snapshot erstellen immer mit Fehler "23" (s.u.) ab. Habe Back in Time neu installiert, alle Konfigurationsordner gelöscht, versucht einen ganz neuen Snapshot zu erstellen (ohne mit alten zu vergleichen) - immer der Fehler.

In den Einstellungen gibt es einen Punkt, wo man festlegen kann, dass er bei Fehlern weiter machen soll. Wenn ich das aktiviere läuft der Snapshot durch, es steht dann nur "With Errors!!!" da.

Die Fehlermeldung lautet: [I] Snapshot erstellen (rsync: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7])

Anbei ist auch die Logdatei.

Vielen Dank für Eure Hilfe, VG, Markus

Hallo,

rsync kann nur Dateien und Attribute übertragen, die es lesen darf - du hast ziemlich viele Dateien dabei, die deinem Benutzer nicht gehören dürften. Das Verhalten ist eigentlich normal und dürfte daher schön früher aufgetreten sein (vgl.). Erstell doch mal nur eine Sicherung deines Homes und versuch es nochmal. Die Fehlermeldungen dürften dann nicht auftauchen. Schau mal, ob dies so ist und ob dein Fehler immer noch auftritt.

Das Log würde ich an deiner Stelle stark kürzen - es gibt mehr Informationen über dich preis, als dir lieb sein dürfte 😉!

Hallo zero77,

vielen Dank schon mal!

ja, war da wohl etwas blauäugig. rednight war so lieb und hat das bereinigt.

Zum eigentlichen Problem: Nein, der Fehler ist ganz neu, habe BiT seit ca. 3 Jahren problemlos in Benutzung. Wieso dürften denn meinem Benutzer viele Dateien nicht gehören? Ich bin doch der einzige?

Eine frische, ganz neue Sicherung des Home habe ich jetzt versucht: selbe Fehlermeldung (scheint im Logfile aber die einzige zu sein, die Fehlermeldungen in dem anderen File schienen ja alle vom etc zu stammen)

Was kann ich tun?

Danke! Markus

Und Hilfe! Wie krieg ich das Logfile aus meinem Posting raus?

Ich antworte mal erst und lese dann nach. 😀

egrep -i "rsync|backintime" /var/log/syslog ~/.xsession-errors

Edit:

Evtl. musst du rsync mit sudo ausführen, da dir natürlich nur dein Home gehört und NICHT Systemordner wie etwa /bin oder /etc!

Danke Benno-007,

habe Deinen Befehl im terminal ausgeführt, er hat sicher die angehängte Syslog erstellt. (da steht ja wohl jetzt nicht soviel Intimes drin 😉 )

Hilft's was?

Benno-007 schrieb:

Evtl. musst du rsync mit sudo ausführen, da dir natürlich nur dein Home gehört und NICHT Systemordner wie etwa /bin oder /etc!

Bisher ging es immer im normalen Modus. Habe es allerdings gerade im "Root" - Modus probiert und der Snapshot lief glatt durch! Das wäre ja kein Problem. Ich beobachte noch ein bisschen und wenn weiterhin alles im Root - Modus klappt, kann ich ja dann als gelöst kennzeichnen.

Schon mal dankeschön!

❗ Edit: Bei grafischen Programmen wie BackInTime gksudo oder gksu verwenden anstatt sudo! Und sichere bitte nur auf ein Linuxdateisystem wie ext4 (externe Festplatten nutzen standardmäßig keines!).

Am interessantesten ist sicherlich diese Meldung:

backintime (markus): WARNING: Command "rsync -rtDH --links --no-p --no-g --no-o  --delete --delete-excluded  -v  --chmod=Du+wx  --exclude="/media/MyDrive" --exclude="/home/markus/.local/share/backintime" --include="/home/" --exclude=".gvfs" --exclude=".cache*" --exclude="[Cc]ache*" --exclude=".thumbnails*" --exclude="[Tt]rash*" --exclude="*.backup*" --exclude="*~" --exclude="/home/markus/Ubuntu One" --exclude=".dropbox*" --exclude="/home/markus/Musik" --exclude="/home/markus/Bilder" --exclude="/home/markus/Videos" --include="/home/**" --exclude="*" / "/media/MyDrive/backintime/Computer/markus/1/new_snapshot/backup/" 2>&1" returns 5888

Dort sieht man nämlich auch mal die ganze rsync-Befehlszeile mit allen Optionen, die backintime bei dir benutzt! Die Optionen sind in der Manpage von rsync erklärt. Den Fehler könnte man mal in einer Suchmaschine suchen (wenn nicht in der Manpage vorkommend): backintime returns 5888.

Ursache des nötigen sudo könnten vereinzelte Dateien mit root- oder fremden Rechten sein, etwa wenn du mal mit sudo/ gksu(do) gearbeitet hattest. Wichtig wäre dann, das in rsnyc eingestellt ist, dass die Dateirechte erhalten/ 1:1 mitgesichert werden sollen - nicht dass sie dann auf einmal alle root gehören. Das wäre eine Sicherheitslücke beim Zurückspielen des Backups.

        -p, --perms                 preserve permissions

ist bei dir jedoch gar nicht gesetzt, sondern sogar das Gegenteil:

--no-p

Mangels praktischer Erfahrung kann ich dir aber noch nicht sagen, wie sich das genau auswirkt. Du kannst dir aber leicht selbst die Rechte und Besitzer anzeigen lassen:

ls -hal XXX

XXX ist Ordner oder Datei in Sicherung. Mit sudo könnte sich der Besitzer (je nach Optionen) auf root ändern, was schlecht wäre. Durch --no-p werden auch die Rechte nicht erhalten, so dass Standardrechte gesetzt werden (nicht nur per sudo/ mit root). Auch das ist meines Erachtens Mist. (Die Standardrechte hängen davon ab, ob das Zieldateisystem ein Linuxdateisystem ist und von der Ausgabe von umask. Bei Nichtlinuxdateisystemen gehen die Rechte verloren und sie werden mit der umask eingebunden, die mount festgelegt hat. Aber das führt hier vielleicht zu weit für euch.)

Vorschlag zum Testen (ohne sudo!):

1
2
3
4
5
6
7

cd ~
mkdir rechtetest
cd rechtetest
touch test1
touch test2
chmod go+x test2
ls -hal

Erklärung:

1. ins Home wechseln

2. Ordner anlegen

3. in den neuen Ordner wechseln

4. Datei anlegen

5. Datei anlegen

6. Rechte von test2 ändern

7. Rechte anzeigen

Folgend:

1. Sicherung dieses kleinen Ordners mit BiT ohne sudo.

2. Wie 1., nur mit sudo.

Danach vergleichst du mit ls (s.o.) die Rechte und Besitzer. Kannst du hier posten. Sollte sich Besitzer auf root ändern und bei test2 die x-Rechte (Ausführbarkeit) von group und others (in der Mitte und am Ende der Zeichenkette) weg sein, wurden die Rechte nicht mit gesichert bzw. der Besitzer verändert...

❗ Edit: Bei grafischen Programmen wie BackInTime gksudo oder gksu verwenden anstatt sudo! Und sichere bitte nur auf ein Linuxdateisystem wie ext4 (externe Festplatten nutzen standardmäßig keines!).

puh, ne Menge Stoff, mit dem ich mich nie beschäftigen zu müssen hoffte... (was für ein deutsch...)

In den Einstellungen von BiT gibt es eine Option "Preserve extended attributes (xattr)". Der Haken ist nicht gesetzt. Das könnte es doch sein, oder? Verstehe ich das richtig: wenn ich den Haken setze, werden die Berechtigungen beibehalten?

Benno-007 schrieb:

❗ Edit: Bei grafischen Programmen wie BackInTime gksudo oder gksu verwenden anstatt sudo! Und sichere bitte nur auf ein Linuxdateisystem wie ext4 (externe Festplatten nutzen standardmäßig keines!).

oh, das wußte ich nicht, dann werde ich wohl meine externe Festplatte erst mal formatieren müssen?

Du müsstest eigentlich nur meinen Anweisungen folgen, das wäre dann ein geführter Crashkurs - das bekommt nicht immer jeder geboten. 😉

Das --no-p verhindert übrigens das Behalten des Besitzers. War das alles schon so gesetzt oder nach welchen Kriterien oder Anleitungen hast du die Optionen gesetzt?

In der GUI rumfummeln ist kompliziert, du kannst aber die Befehlszeile nehmen und anpassen, im Grunde macht sie dann dasselbe wie BiT, nur dass du BiT nur noch für grafische Veränderungen des Befehls bräuchtest. 😉 Für unseren Test stört die grafische Oberfläche mehr als sie nutzt, denn die Optionen sind hier klar benannt und erklärt und mit Bildschirmfotos oder anderen Bezeichnungen für die Optionen kommen wir hier auch nicht weiter.

        -X, --xattrs                preserve extended attributes

Das ist was anderes:

       -X, --xattrs
              This option causes rsync to update the remote extended attributes to be the same as the local ones.

              For systems that support extended-attribute namespaces, a copy being done by a super-user copies all names‐
              paces except system.*.  A normal user only copies the user.* namespace.  To be able to backup  and  restore
              non-user namespaces as a normal user, see the --fake-super option.

Nach dem Überfliegen verstehe ich da erst mal auch nur wenig. Habe nur Ideen, will aber Fakten - Google liefert:

http://linux.die.net/man/2/setxattr

http://en.wikipedia.org/wiki/Extended_file_attributes#Linux

Es geht also wohl auch um unter anderem erweiterte Attribute zur Sicherheit, womit wir uns jetzt hier nicht herumplagen müssen. Aber auch diese würde ich erhalten, falls welche gesetzt sind (also immer mit sichern).

Kann natürlich sein, dass BiT für Home und ohne gksu entsprechend gut/ ausreichend vorkonfiguriert wäre, der Besitzer etwa ist dort eigentlich sowieso immer man selbst, also ändert sich ohne gksu (!) sowieso nichts, wenn man die Rechte nicht erhält - sie werden dann einfach wieder auf den Kopierer (man selbst) gesetzt. Bei den Rechten sieht es anders aus. Aber auch die sollten im Home eigentlich immer 755 oder 700 sein, also nur der Besitzer darf alles, der Rest nicht schreiben, aber ausführen und lesen (755) oder gar nix (700). Einprägsamer ist die Schreibweise rwx (lesen, schreiben, ausführen), je für Besitzer, Gruppe und andere. Siehe Rechte. Ist nicht so schwer, du musst nicht alles verstehen. 😉

vielen, lieben Dank für Deine Mühen!!

Eigentlich möchte ich ja nur immer mal mein Home- und etc-Verzeichnis auf der externen Platte sichern. In den letzten 3 Jahren hat das auch immer prima mit BiT unter KDE, Gnome und jetzt XFCE funktioniert. Seit gestern halt plötzlich nicht mehr (siehe erster Beitrag). (hatte mir der Einfachheit halber eine GUI gesucht, da ich mit dem Terminal überhaupt nicht fit bin)

Deinen Crashkurs werde ich wohl erst in 1 oder 2 Wochen durchführen können (scheint mir etwas umfangreicher zu sein 😉 )

Gibt es vielleicht ein Back up - Verfahren für den Durchschnitts - User, bei dem man dann nicht soviel verkehrt machen kann?

Ich will dich nicht überlasten, hier werden viele Themen wie Backups, Rechte und Dateisysteme sowie Images und Umrechnungen angeschnitten, aber ich nehm dich an die Hand und kaue dir alles vor, ok? Kannst dir ein Lesezeichen zu dem Thema machen und dann nachsehen. Natürlich kannst du später auch wieder grafische Oberflächen benutzen, aber die kenne ich nicht alle, da es für manche Befehle entweder keine oder nur verwirrendere als Befehle gibt (mit vielen Bildschirmfotos und Klickfolgen zum Erklären nötig) oder es gibt gleich 10 Oberflächen und jeder nutzt eine andere - darum gleich Befehle, die sind ein-eindeutig, ok? Es geht hier ja auch mal ums Testen, Lernen, Anlegen eines passenden Dateisystems für dich, ohne Formatieren (Löschen) zu müssen...

Kommt drauf an, was steht denn im Wiki zu Back In Time? Ansonsten mal in der Forensuche nach Erfahrungen schauen.

Wenn BiT die Rechte nicht separat sichert und keine Krücken wie UMSDOS (Rechte auf FAT-Partition in einem UMSDOS-Ordner gesichert) verwendet werden sollen (und du sowieso NTFS statt FAT hast), sind die Rechte erst mal weg.

Für Home ist das egal, da man einfach alles auf 755/700 setzen kann:

chmod -R 700 ~

Außerdem wird das automatisch beim Erstellen oder Zurückkopieren (ohne Übernahme der Rechte) von Dateien erledigt, wenn die

umask

0022 anzeigt (entspricht 755, da 755 + 022 =777). Musst du nicht verstehen, nimm es einfach mal so hin. Mach ich auch. 😉

Problematisch sind deine Einstellungen für andere Ordner, etwa das System "/". Das kannst du in die Tonne werfen, wenn die Rechte nicht stimmen, die bekommt man nie mehr sicher hingebogen. → Neuinstallation wäre fällig.

Aber zu deiner eigentlichen Frage: Solltest du außerhalb Home etwas sichern, müssen die Besitzer und Rechte erhalten werden (auch die xattr, also erweiterten Rechte). Beim Rückspielen dasselbe. Das Dateisystem muss dann ein Linuxdateisystem sein. Wenn du nicht umformatieren (Löschen aller Daten!) der externen Festplatte willst, kannst du eine Art "Container" mit Linuxdateisystem anlegen. Eine Image-Datei, ähnlich einer ISO einer Ubuntu-CD, die man brennen kann:

❗ Vorsicht mit dd, nur wie beschrieben bzw. richtig verstanden anwenden!

1
2
3

cd /media/platte/backup   # in den Backupordner der Zielplatte wechseln
sudo dd if=/dev/zero of=/media/platte/backup/backup.iso bs=4k count=5242880 conv=noerror # Datei mit 20 GB Größe erzeugen (dauert!)
sudo mkfs.ext3 /media/platte/backup/backup.iso   # Formatieren

2.: 4KB*5242880 = 20 GB. Du kannst die Zahl 5242880 auch verdoppeln, dann kannst du 40 GB sichern.

Nun kannst du die virtuelle Platte verwenden: Anklicken dürfte nicht reichen, da es dann nur als Archiv geöffnet wird, aber es sollen ja auch andere Programme darauf zugreifen können. Platte normal anklicken wie immer und dann zum Öffnen der virtuellen Platte mit Option loop mounten:

sudo mount -o loop /media/platte/backup/backup.iso /mnt

Dies würde die Platte in /mnt anzeigen. Möchtest du andere Ordner, müssen diese angelegt werden, Beispiel:

sudo mkdir /media/virtuelle_platte

Ich schlage vor, du probierst einfach mal einiges aus und lernst durch Learning-by-doing, also dem Ausprobieren. Ich hoffe, die Anleitung nützt wem! Natürlich geht vieles auch grafisch, aber da gibt es zu viele Oberflächen und Fehlerquellen - die Befehle hier funktionieren immer und haben weder neue Fehlerquellen und Bezeichungen noch sind sie so eingeschränkt oder nichtssagend/ mehrdeutig wie viele grafische Oberflächen! Das funktioniert und zwar eindeutig so wie festgelegt. 😉

Viele Grüße, Benno

womit habe ich das verdient, vielen Dank für Deine Geduld! ☺

Back In Time hier ist mein Problem und die Lösung dazu übrigens beschrieben! Sorry, wer lesen kann...

Ich setze das Lesezeichen, und wenn mal Gelegenheit ist, beschäftige ich mit dem Thema und berichte dann hier.

In der Hoffnung, dass bis dahin meine Platte nicht crasht, verabschiede ich mich temporär. Ein schönes Wochenende wünsch ich!

Grüße, Markus

Ich wollte auch gerade nach dem dort erwähnten Log fragen:

Nun kann man sich aber im oberen Menü über "View Snapshot Log" anzeigen lassen, welches Verzeichnis oder welche Datei genau die Fehler verursacht und auf Ursachensuche gehen oder diese einfach auf die Liste der nicht zu sichernden Ordner und Dateien setzen.

Welche Datei war denn Schuld? Hast du eine Idee, wie es dazu kam? Wie sahen ihre Besitzer und Rechte denn aus?

ls -hal dateiname

ah, dann hast Du Dir das Log doch nicht angeschaut, bevor es vom Admin gelöscht wurde? 😉

Das betrifft eine Unmenge an Dateien, wirklich sehr viele, könnte man nie alle per Hand bearbeiten. Ich guck dann mal, woran es liegt und melde mich.

Grüße, Markus