Most people solve this issue by keeping multiple versions, not by trying to "validate" the backups somehow.
Metrics for todoist-fullsync:
name 1 days ago 8 days ago
------------------------------
files 1 1
bytes 82363 86661
items 85 87
> Not only do you have to validate a file looks like a .jpg/.json/.zip file, you also need to validate that it looks semantically correct (ie. the file format is valid but a chunk of it is missing).
But you don't have to do that perfectly to get value out of it; for example:
- If the .json file parses as json, then at least you probably didn't truncate the download mid-stream.
- If it also contains a particular attribute, then you probably didn't save a structured error response instead of the actual data, or save something from a radically-nonpassively-changed endpoint that might no longer be adequate.
- If it also has roughly the number of elements you expect, you probably didn't miss entire pages of the response.
I haven't found a good way to verify these without doing a full database restore and seeing if the logs apply cleanly, along with having the DB do internal checks.
JFTR, this is supported on Linux as well and, especially when using LVM, is quite simple and straightforward.
You can do it manually [0,1] or using tools made for just this purpose, such as mylvmbackup [2] (which should be available in most distribution's package repositories).
---
[0]: https://www.badllama.com/content/mysql-backups-using-lvm-sna...
[1]: https://www.percona.com/blog/2006/08/21/using-lvm-for-mysql-...