The cache directory stores information about your archives on the Tarsnap servers to improve the speed and privacy of the service. This directory will not be backed up by Tarsnap, so it should not be used for any other purpose.

The cachedir is not a temporary work space; if you lose the cache directory or it becomes corrupted, it must be re-created by running tarsnap --fsck, which will download all the metadata for all your archives (~0.1% of the total archive size).

The cache directory contains:

• cseq: this stores the sequence number of the last committed transaction. Note that this is stored as a symbolic link, but the link target does not exist; this is deliberate and is entirely harmless.
• cache: this file records "the last time we looked at file /foo/bar, it contained blocks X, Y, and Z". Without this file, you will have extra disk I/O and CPU time as Tarsnap re-examines everything. This file also contains raw data from small files and sometimes the ends of large files.
• directory: this file records the hashes of blocks stored on the server, and reference counts to those blocks.
• lockf: this lock file ensures that Tarsnap cannot run two concurrent "create" or "delete" operations.

Security concerns

If someone can read the cache directory, they can obtain some of your data. If they can tamper with the cache directory, they could trick a delete script (as part of a backup rotation scheme) into deleting data which is still needed by other archives; alternatively, they could potentially trick your archive-creation script into not storing data (but that's harder and would require them to know exactly what data is going to be backed up).

On a single-user system with an unencrypted hard drive (or $HOME directory), no special care needs to be taken. However, if your data is normally encrypted "at rest", then you probably want your cache directory to also be encrypted.