Separating the corruption check from the copy would be clean but I think it
would be intrusive in the public API, and currently making the check while
reading has better performance that I don't want to disturb for edge cases.
Making it toggle-able is feasible with the plugin init args. It would be
Having used the BackupRepository for other things than backups in the ZERO
branch, I suspect there might be two separate concerns that are mixed into
the same class/abstraction.
One is verifying the data to be persisted is not corrupted (this heavily
depends on the type of data being persisted obvi
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 wrote:
>
> > Isn't the intent to ensure we don't waste time/space creating a
> > useless backup of something that is, I sup
> 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
> 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 veri
On Tue, Jan 30, 2024 at 4:02 AM Bruno Roustant wrote:
>
> I noticed two points that I propose to change in some BackupRepository
> implementations and in BackupRepositoryFactory:
>
> 1- Two implementations (S3BackupRepository, GCSBackupRepository) compute
> and verify the checksum of index files b
I noticed two points that I propose to change in some BackupRepository
implementations and in BackupRepositoryFactory:
1- Two implementations (S3BackupRepository, GCSBackupRepository) compute
and verify the checksum of index files being copied. Other implementations
do not.
=> I propose to remove