On Friday, April 10, 2020 at 4:09:01 AM UTC+10, Nikolaus Rath wrote: > > > My guess is that it is simple corruption of the data. The original email > said that the server crashed. This means that the SQLite database can > get corrupted. >
Looking through snapshots of the database, it was corrupted 2 hours before the server was shut down (didn't crash, but an s3ql session was in progress at shutdown). The corruption was, I think, due to the device being full during an unmount, and SQLite not being able to rollback properly. This seems to fit with the history pretty well (mount.log showing device full errors, database snapshots being good before those errors, corrupt after). Obviously I am rethinking the hourly mount/rsync/unmount cycle since it's harder to ensure unmount at system shutdown, and have not moved everything to a drive with more space. Unfortunately, I have a lot of s3ql snapshots, which means I have a huge DB which takes about 5 minutes to sync to amazon; that time would be added to any shutdown so permanently mounting it is not a clear win. If I do a lazy dismount, then shutdown, am I correct an fsck will still be needed? I guess the solution there would to always do an fsck before mount after system boot. -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/s3ql/e6f8f0f6-080d-4bf9-9bc6-0eb62cde8cff%40googlegroups.com.
