|<B>1) Exists in inventory database; not on targetB>||If a chunk exists in the inventory database, but not on the target, brackup wont store it on the target, and youll think a backup succeeded, but its not actually there.|
|<B>2a) Exists on target; not in inventory database (without encryption)B>||You re-upload it to the target, so you waste time & bandwidth, but no extra disk space is wasted, and no chunks are orphaned. Actually, chunks are un-orphaned, as the inventory database is now updated and contains the chunk you just uploaded.|
|<B>2b) Exists on target; not in inventory database (with encryption)B>||When using encryption, each time a chunk is encrypted with gpg, the contents are different. So if the inventory database says a given chunk isnt already stored on the server, it will be re-encrypted and stored (uploaded) again. You may or may not have an orphaned chunk on the server, depending on whether or not its referenced by any other *.brackup meta files.|
In any case, its not tragic if you lose your inventory database... it just means youll need to upload more stuff and maybe waste some disk space until you next run a brackup-target gc garbage collection, which cleans up orphaned chunks. If youre feeling paranoid, its safer to delete your inventory database, tricking Brackup into thinking your target is empty (even if its not), rather than Brackup thinking your target has something when it actually doesnt.
The inventory database makes use of Dictionary modules (Brackup::Dict::*) to handle database storage. The default dictionary used is Brackup::Dict::SQLite, which stores the cache as an SQLite database in a single file. The schema is created automatically as needed... no database maintenance is required.
The dictionary type can be specified in the [TARGET] declaration in your brackup.conf file, using the inventorydb_type property e.g.:
[TARGET:amazon] type = Amazon aws_access_key_id = ... aws_secret_access_key = ... # specify the lighter/slower Brackup::Dict::SQLite2 instead of the default inventorydb_type = SQLite2
The inventory database file (for file-based dictionaries) is stored in either the location specified in the inventorydb_file property of a [TARGET] declaration in ~/.brackup.conf e.g.:
[TARGET:amazon] type = Amazon aws_access_key_id = ... aws_secret_access_key = ... inventorydb_file = /home/bradfitz/.amazon-already-has-these-chunks.db
Or, more commonly (and recommended), is to not specify it and accept the default location, which is .brackup-target-TARGETNAME.invdb in your home directory (where it might be shared by multiple backup roots).
This is made automatically for you, but if you want to look around in it, the schema is:
CREATE TABLE target_inv ( key TEXT PRIMARY KEY, value TEXT )
The key is the digest of the raw (pre-compression/encryption) file/chunk (with GPG recipient, if using encryption), and the value is the digest of the chunk stored on the target, which contains the raw chunk. The chunk stored on the target may contain other chunks, may be compressed, encrypted, etc.
<raw_digest> --> <stored_digest> <stored_length> <raw_digest>;to=<gpg_rcpt> --> <stored_digest> <stored_length>
sha1:e23c4b5f685e046e7cc50e30e378ab11391e528e;to=6BAFF35F => sha1:d7257184899c9e6c4e26506f1c46f8b6562d9ee7 71223
<raw_digest>[;to=<gpg_rcpt>] --> <stored_digest> <stored_length> <from_offset>-<to_offset>
Which is the same thing, but after fetching the composite chunk using the stored digest provided, only the range provided from from_offset to to_offset should be used.
|perl v5.20.3||BRACKUP::INVENTORYDATABASE (3)||2010-03-27|