Sdrsync überprüfen

[FrankH1]

Hallo,
ich habe ein Verständnisproblem mit dem Mirroring.
Nach eine Neuinstallation OH 4.1.1 auf einem Raspi 4 mit nachfolgendem Import der alten Konfig von OH3.3 läuft das System nun nach einigen Anpassungen stabil. Wollte mich daher daher um den Sicherheitsgurt kümmern.
Manuell Option 53 ausgewählt und doppelt so große SD-Karte im externen card reader.
Die Installation lief, die Karte wurde partitioniert und scheinbar lief auch die volle 1:1 Kopie.

Code: Alles auswählen

 lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 59.5G  0 disk
├─sda1        8:1    1  256M  0 part
├─sda2        8:2    1 29.6G  0 part
└─sda3        8:3    1 29.6G  0 part /storage
mmcblk0     179:0    0 29.8G  0 disk
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 29.6G  0 part /
zram0       254:0    0    1G  0 disk [SWAP]
zram1       254:1    0  750M  0 disk /opt/zram/zram1
zram2       254:2    0    1G  0 disk /opt/zram/zram2

Der nächtliche timer für die Differentialsicherung ist gesetzt und scheint zu laufen.

Code: Alles auswählen

 systemctl list-timers
NEXT                         LEFT                  LAST                        PASSED       UNIT                    >
Sun 2024-02-18 00:00:00 CET  5h 57min left         Sat 2024-02-17 00:00:02 CET 18h ago      exim4-base.timer        >
Sun 2024-02-18 00:00:00 CET  5h 57min left         Sat 2024-02-17 00:00:02 CET 18h ago      logrotate.timer         >
Sun 2024-02-18 00:00:00 CET  5h 57min left         Sat 2024-02-17 00:00:02 CET 18h ago      man-db.timer            >
Sun 2024-02-18 02:08:14 CET  8h left               Sat 2024-02-17 02:00:17 CET 16h ago      sdrsync.timer           >
Sun 2024-02-18 02:22:55 CET  8h left               Sat 2024-02-17 03:42:57 CET 14h ago      firemotd.timer          >
Sun 2024-02-18 03:10:58 CET  9h left               Sun 2024-02-11 03:10:13 CET 6 days ago   e2scrub_all.timer       >
Sun 2024-02-18 04:55:23 CET  10h left              Sat 2024-02-17 13:21:04 CET 4h 41min ago apt-daily.timer         >
Sun 2024-02-18 06:58:31 CET  12h left              Sat 2024-02-17 06:58:19 CET 11h ago      apt-daily-upgrade.timer >
Sun 2024-02-18 13:34:52 CET  19h left              Sat 2024-02-17 13:34:52 CET 4h 27min ago systemd-tmpfiles-clean.t>
Mon 2024-02-19 00:13:08 CET  1 day 6h left         Mon 2024-02-12 00:13:32 CET 5 days ago   fstrim.timer            >
Mon 2024-07-01 01:15:00 CEST 4 months 12 days left n/a                         n/a          sdrawcopy.timer         >

11 timers listed.
Pass --all to see loaded but inactive timers, too.
lines 1-15/15 (END)

Nun die Frage. Ich dachte die inkrementelle Sicherung speichert geänderte Dateien nach storage (also SDA3) . Müsste man dann nicht die Dateien in storage sehen? Das Verzeichnis ist leer. Vielleicht habe ich ja gegen Mitternacht einige Fehlermeldungen - aber wo könnte ich die sehen?

[FrankH1]

Hab das Problem inzwischen gelöst...
War ein Doppelfehler
1) Denkfehler meinerseits - ich dachte das sdrawcopy macht 2*jährlich eine 1:1 Kopie und die geänderten Dateien werden täglich separat (auf sda3 = storage) gespeichert. Tatsächlich wird für die tägliche incrementelle Sicherung sda2 gemounted und die geänderten Dateien überschrieben. Man kann also nicht auf den ersten Blick erkennen, ob die tägliche Sicherung erfolgreich gelaufen ist.
2) Ich hatte offensichtlich einen etwas labilen externen Kartenleser - das hat die externe Karte manchmal unerreichbar gemacht. Hab nun eine andere Hardware im Einsatz.
Habe eingedenk dieser Erfahrungen etwas zusammenprogrammiert, was sich wie folgt kurz beschreiben lässt:
Über einen Timer wird täglich
a) eine Datei im Home-Verzeichnis geschrieben
b) sda2 gemounted und das Datum dieser zuletzt gespeicherten Datei (vom Vortag) im externen Speichermedium gelesen und in eine Datei (sdcopydate.txt) geschrieben, danach sda2 unmounted
Openhab liest über ein exec/python das gespeicherte Datum aus der Datei (sdcopydate.txt) und lädt es in ein item, welches ich auf der Benutzeroberfläche darstelle.
Somit sehe ich sofort, wenn ein Sicherungslauf nicht erfolgreich war. Geht bestimmt auch eleganter, aber es funktioniert.