Martin Pool
Martin Pool
a21737b8e89456040089858c6b35e2b35f12d906 changed Conserve so that it assumes that blocks referenced by previous indexes are present in the archive. That helps performance, but it does mean that blocks that are missing...
Perhaps use http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia which has samples of various file types. Scenarios: 1. initial backup of everything 1. incremental backup with no changes 1. incremental backup with files touched but no...
From https://github.com/sourcefrog/conserve/pull/133#issue-440960172 Current code (https://github.com/sourcefrog/conserve/blob/bd6759f13915e6c2eccc02ab93642162fd1e5709/src/index.rs#L237-L256) to determine the number of index hunks probes for each of them, which is a bit inefficient. However this is only done once per restore,...
From https://github.com/sourcefrog/conserve/pull/133#issue-440960172 Conserve 0.6.4 onwards has a count of hunks in the band tail file. We could use this to validate that exactly the expected number are present.
At the moment if the metadata does not match, the whole file is read and hashed (probably unavoidably) and the file is counted as modified. It might be a bit...
It would be useful to have an archive on local, limited-size, fast storage, and then to periodically copy some versions to a second archive that is perhaps bigger but intermittently...
Ideally should break down MB in * all files * unchanged files * new files * changed files
When writing a backup, Conserve checks whether hash-addressed blocks are already present in the archive, before bothering to write them. This turns into just one `stat` per file, which is...
conserve log /archive /subdir Could show a list of versions that changed anything matching that path (or the whole archive by default) including whether files where added, deleted, or modified.