> [...] But whatabout the metadata and data of s3ql? Do you provide > some parity there? > If not, can that be extended by s3qlcmd so in a very worse case > scenaria, when > metadata and data of the s3ql files happens, it can recover? The metadata of S3QL is a SQLite database. No parity or error correction here. But you can of course use the SQLite tools to try to recover a corrupt database. I would guess that this has a high change of success for a single bit-flip (bitrod). If your HDD has corrupt sectors, you might be out of luck.
If you use ZFS anyways, use Z1 or Z2 to protect your data against these kinds of problems and do regular scrubs to detect and correct bitrod or other hard-drive failures. If you only have one drive, you could use ditto blocks ( https://en.wikipedia.org/wiki/ZFS#Additional_capabilities ) and regular scrubs to secure the metadata (put it on its own sub-filesystem). If the worst case happens and you will loose your local metadata, S3QL keeps several backups in the backend storage. The default is to upload the metadata every 24h hours to the backend. You would of course loose up to 24h of filesystem changes. > [...] But seen Your story of the critical cache, it looks to me I > should have rather a small cache > for those files that need to be uploaded or to be accessed quickly.[...] Regardless of the size of the cache S3QL will persist dirty (i.e. changed) data as soon as possible to the backend storage (Wasabi in your case). > [...] So in that case my a safely assume when borgbackup checks for > data modification, the > file in question is not downloaded ? [...] Yes. A simple stat will not trigger a download. That can be handled solely with the local metadata. -- 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/b3961663-49fc-e1ac-f3bb-6fa904741f49%40jagszent.de.
