Guten Tag scott ribe,
am Dienstag, 6. Juni 2017 um 16:28 schrieben Sie:
> You seem to be assuming that the files were changed close to the
> time you found the problem;[...]
No, I assume that the files were last changed at the time of the last
written timestamp in the production system. Which would make my
backup corrupt if it has the same size/timestamp but different data.
And that change in my backup could have been introduced anytime
between the last backup and now, I simply don't know, because I don't
calculate hash sums for my backups or use some checksumming file
system like BTRFS or ZFS. So it might be that my backups are simply
broken for various reasons and I need to have a closer look at this.
OR MAYBE Postgres resets timestamps in production and what I see is a
perfectly valid use case for some reason I don't understand yet. But
seems pretty unlikely, as Laurenz Albe already mentioned that Postgres
doesn't care about timestamps. And that's what I see in my tests,
timestamps always increase if a file is written in production.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow