Questions and Answers
What happens if a snapshot is interrupted?
Nothing! Whatever blocks have been uploaded will be uploaded, but the snapshot is only added to the tag once the entire filesystem has been snapshotted. So just start the snapshot again. Any files that have already be uploaded will then not need to be uploaded again, so the second snapshot should proceed quickly to the point where it failed before, and continue from there.
Unless the vault ends up with a partially-uploaded corrupted block due to being interrupted during upload, you'll be fine. The filesystem backend has been written to avoid this by writing the block to a file with the wrong name, then renaming it to the correct name when it's entirely uploaded.
Actually, there is *one* caveat: blocks that were uploaded, but never make it into a finished snapshot, will be marked as "referenced" but there's no snapshot to delete to un-reference them, so they'll never be removed when you delete snapshots. (Not that snapshot deletion is implemented yet, mind). If this becomes a problem for people, we could write a "garbage collect" tool that regenerates the reference counts in a vault, leading to unused blocks (with a zero refcount) being unlinked.
Should I share a single large vault between all my filesystems?
I think so. Using a single large vault means that blocks shared between servers - eg, software installed from packages and that sort of thing - will only ever need to be uploaded once, saving storage space and upload bandwidth. However, do not share a vault between servers that do not mutually trust each other, as they can all update the same tags, so can meddle with each other's snapshots - and read each other's snapshots.
CAVEAT
It's not currently safe to have multiple concurrent snapshots to the same split log backend; this will soon be fixed, however.