I could imagine making it toggle-able if it serves the index encryption feature. Dunno if that's easy, hard, or impossible.
On Tue, Jan 30, 2024 at 10:31 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > > Isn't the intent to ensure we don't waste time/space creating a > > useless backup of something that is, I suppose, already corrupted? > > Space is one benefit, yep. > > The other reason is to avoid giving users a false sense of security. A > user would be very frustrated to find out at restore-time that the failsafe > backup they've been relying on is useless. Better to surface that > information at backup time when the source collection is healthy and the > backup can be retried, etc. > > > On Tue, Jan 30, 2024 at 10:18 AM Bruno Roustant <bruno.roust...@gmail.com> > wrote: > > > > Isn't the intent to ensure we don't waste time/space creating a > > useless backup of something that is, I suppose, already corrupted? > > > > That's right. And I didn't read the code enough; a clear effort has been > > put here since the last time I read the code, to make all implementations > > consistent to verify the checksum. > > > > Hum, this is annoying for directory-based encryption. The only way becomes > > to have an encryption extension for each and all different implementations. > > Less clean than a FilterBackupRepository. > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
