The endpoint of s3ql can point to local space, not only s3. I know that corruption is almost not existant with cloud space and zfs, but still, better safe then sorry.
So to have some little redundancy on those files with some parity could safe a lot of trouble to rescue an s3ql filesystem. I still hope it can be an option in the future. About borgbackup You did answer my question. It does check by default on the metatags said to speed up backup, I will run some test and see if it is otherwise and traffic floods my router. Thanks for your time. Op donderdag 9 september 2021 om 15:30:15 UTC+2 schreef [email protected]: > On Sep 09 2021, Amos T <[email protected]> wrote: > > But whatabout the metadata and data of s3ql? Do you provide some parity > > there? > > No, S3QL relies completely on the filesystem where this data is being > stored. > > > > 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? > > Well, in principle everything is possible. I don't think anyone is > planning to do that work though. > > It's also not clear to me why people worried about filesystem corruption > can't just use a file system that provides the necessary guarantees > instead of relying on individual applications to make up for that... > > Best, > Nikolaus > > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > -- 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/08d085d3-976b-4aef-9746-7d48c3d0c608n%40googlegroups.com.
