Since index files only contains information related to recreating the database, they can be recreated directly from a working database.
This PR adds an automatic repair feature that replaces index files if they are missing content. This will gradually repair remote index files if they are affected by the compact bug that re-wrote index files without the blocklists.
To fully repair, it is possible to run the `Test` command with the option `--full-remote-verification=indexonly` and a large number of samples. Since the new option `--replace-faulty-index-files` is default set to `true` this will repair any defective index files and ignore all others.
This update uncovered that the Test method would previously not verify the presence of blocklists in the index files. This is likely a very old bug, caused by the fact that the original implementation did not place blocklisthashes in the index files. The omission of this check is the reason the extent of the compact issue was not discovered earlier.
With this PR it is now also visible that there is ample room for error in creating the index files during the backup process. This is caused by the parallel processing and carry-over, where the index files are created on-the-go, so they are ready to upload once the blocks are filled.
While this is likely good for performance, it has some drawbacks.
- A failed block upload will cause a rewrite of the index file
- An elaborate callback system is needed to update the index file
- It is possible to race against the database and create extra blocklist hashes, bloating the index files (causes problems on verification)
A subsequent task is to rewrite the logic to not touch the index files outside the backend manager, so the backend manager will just use the database to create the index file. This means the same code will be invoked for both the create, the recreate, and the replacement.
For now, extra content in index files is logged with the verbose log level.
This fixes#6296
This adds an extra option to allow setting the SQLite page cache size as a regular option.
Prior to this commit it was only possible to set the SQLite page cache size via environment variables.
The option to use environment variables is preserved, and as options from the environment variable are applied after the new setting, environment variables take precedence.
The default value for the new option is to use 1% of the system memory for the page cache. For the restore process, a connection per worker may be made which defaults to half the number of cores, so the maximum amount of memory is 1% * half the CPU cores.
This is just the upper limit, and SQLite may choose not to use all of it.
This fixes#6178
The option is turned into an enum with values True, False, ListIndexes
True and False are for compatibility with the existing backups.
ListIndexes is equivalent to True but don't handle block volumes.
This is to make more workable a strategy of full remote testing
after each backup.
When referencing virtual members in a constructor, the behavior may be
ill-defined as the overridden implementation may depend on uninitialized
instance members.
Since the TABLE_PREFIX, TABLEFORMAT, INSERTCOMMAND, and INSERTARGUMENTS
properties were only referenced in the Basiclist constructor, we can
remove the abstract keyword and provide the values as constructor
parameters.
While this does not affect any behavior, it more accurately describes
the accessibility. Since abstract classes can only be instantiated by
an instance of a derived type, the constructors should at most have
protected access.
Implemented better output for Restore.
Fixed a problem with errors during dispose, and a problem with selecting filesets that do not exist.
Fixed a bug with restore if a file existed with some correct data, a copy would be restored with partial data.
Added check to try to avoid excessive restores of the same files if a file in another version already exists.
Carl Johnsen