Problem Backup einspielen "Timestamp Fehler"

[merlincu2n8]

Hi zusammen,

das ich mit der aktuellen RaspberyMatic Version (3.37.8.20181026) enorme Probleme mit dem DutyCycle habe (permanent 99%) wollte ich die alte Version nochmal aufspielen (3.37.8.20180929), mit der ich diese Probleme nicht hatte.
Ich mache per Crontab jeden Tag Backups auf meinem NAS, so dass ich eigentlich kein Problem darin sah, eine neue SD-Card zu flashen und eine altes Backup einzuspielen: lange Rede, kurzer Inhalt:
nach dem ersten Start der neu geflashten SD-Card und dem anschliessendem Einspielen des Backups folgende Fehlermeldung:

Unbenannt.PNG (17.85 KiB) 1008 mal betrachtet

Ja, stimmt, diese besagten Dateien haben den angemahnten TimeStamp.
Testweise weitere Backup-Dateien probiert, gleicher Effekt.
Durch manuelles Umstellen des Datums auf das Jahr 2023 klappte dann der Restore...

Die Frag ist nun, was ist da schief gelaufen beim Backup und kann man den Timestamp im Nachhinein ändern!??
PS: JA, NTP Server ist im Raspy hinterlegt.

Vielen Dank

[hoedlmoser]

probier mal die files aus der zukunft zu identifizieren, verbinde Dich per SSH zur CCU ... beim touch bitte eine urhzeit in der zukunft angeben, eine stunde reicht.

Code: Alles auswählen

cd /usr/local/tmp/
touch -t 1844 tmpfile
find / -newer tmpfile

Du hast ja ein backup, also kann eigentlich nix schief gehen, also das filesystem mal rw mounten und alle dateien aus der zukunft mal antouchen.

Code: Alles auswählen

mount -o remount,rw /
find / -newer tmpfile | xargs touch

das sollts gewesen sein.

[jmaus]

Die Frag ist nun, was ist da schief gelaufen beim Backup und kann man den Timestamp im Nachhinein ändern!??

Nun, was schiefgelaufen ist, ist ja eigentlich klar. Zur Zeit der Backuperstellung war die Zeit deines RaspberryMatic in der Zukunft.

Das Problem hierbei ist jedoch, das die Restore Mechanismen in der Firmware anscheinend solche fälle nicht einfach ignorieren, was sie jedoch sollten und stattdessen einen Fehler rauswerfen der zu dem von dir beschriebenen Problem führt. Ich werde mal schauen das die die Restore Routinen entsprechend anpassen werde damit diese Timestamp die in der Zukunft liegen einfach ignorieren.

Für RaspberryMatic bietet sich in solch einem Falle in der die WebUI ein Problem findet übrigens an das Restore mit dem Kommandozeilen tool /bin/restoreBackup.sh durchzuführen. D.h. einfach per SSH einloggen und dann folgenden Befehl aufrufen:

Code: Alles auswählen

/bin/restoreBackup.sh <PFAD zur *sbk Datei>

Danach dann einfach ein "reboot" machen und das Restore sollte problemlos durchlaufen auch wenn die Timestamps in der Zukunft liegen.

[jmaus]

Für alle die es interessiert, hier der entsprechende Fix für das Problem:
https://github.com/jens-maus/RaspberryM ... a5e8a699b6

[merlincu2n8]

Die Frag ist nun, was ist da schief gelaufen beim Backup und kann man den Timestamp im Nachhinein ändern!??

Nun, was schiefgelaufen ist, ist ja eigentlich klar. Zur Zeit der Backuperstellung war die Zeit deines RaspberryMatic in der Zukunft.

Wird das Problem denn "weiter geschoben"?
Wie gesagt, ich mache täglich Backups meines Raspberry und die letzten 14 Backups hatten diesen Timestamp-Fehler; ältere habe ich jetzt nicht mehr kontrolliert.
Aber vielen Dank für den Hinweis mit dem "/bin/restoreBackup.sh <PFAD zur *sbk Datei>"!

Auch vielen Dank an hoedlmoser: hat mit Deiner Anleitung ebenfalls geklappt!

Merci!!

[hoedlmoser]

Wird das Problem denn "weiter geschoben"?
Auch vielen Dank an hoedlmoser: hat mit Deiner Anleitung ebenfalls geklappt!

die backups die Du nach dem Du meine anleitung durch bist erstellst sollten das problem nicht mehr haben. und in der nächsten release sollte so ein problem auch nicht mehr schlagend werden, jmaus hats ja schon auf github gefixt.