bottomless: validate snapshots before queuing them to be sent #717

Activity

1. psarna commented on Oct 2, 2023

   

   psarna

   on Oct 2, 2023

   Author

   More actions

   ah and since we probably compress the snapshots, we should also check if our compression libraries support additional validation/checksumming.
2. Horusiath commented on Oct 2, 2023

   

   Horusiath

   on Oct 2, 2023

   Last edited by Horusiath

   Contributor

   More actions

   My idea was to: currently the snapshot upload comes in two parts:

   1. Gzip db file into local disk.
   2. Upload gzipped db file as /db.gz.
   3. Upload change counter (which keeps [u8;4] used to compare local and remote db versions) as /.changecounter.

   My idea was to change snapshotting process to:

   1. Gzip db file - to be sure that we have enough disk space to do so.
   2. While gzipping, compute a checksum (any one will do).
   3. Upload gzipped db file as /db.gz.
   4. Upload change counter AND checksum as /.changecounter. This is basically our finaliser.

   Now during restore, first thing we do is always downloading remote .changecounter first and comparing it against local. With this change we can also download checksum. When we download db file, compute its checksum and verify it again against the one from .changecounter file.

   Now if the checksum will fail, let's try to see if we have a .dep file which describes previous generation. If there is any let's try to recover from it instead and then potentially try to apply the WAL from current generation, skipping the damaged snapshot.