Directory

A dir destination specifies a filesystem directory where HashBackup should write copies of the backup. The directory can be on any type of filesystem since HashBackup doesn’t depend on special capabilities on destination filesystems. NFS, FAT, SMB/CIFS, SSHFS, WebDAV, Google Drive, Dropbox, etc. should all work fine. Backed-up file system metadata like hard links, extended attributes, ACLs, and file modification times will still be saved and restored correctly, even if the destination filesystem does not support these features.

A dir destination is used to make a copy of the backup data. Do not repeat the main backup directory here (the path after -c) as that will cause an error.

The destination directory must already exist. HashBackup will not create it to prevent the problem of creating a directory in /mnt that was supposed to be an already-mounted filesystem.

If the dir destination is a device that physically seeks (moves disk heads), like a spinning hard drive, setting workers to 1 gives higher performance. With the default worker setting of 4, there could be 4 simultaneous copies to the disk, causing seeking back and forth. With 1 worker, backup files are copied sequentially with few seeks.

Rotating USB Sticks Or Hard Drives

An easy and efficient backup strategy is to rotate drives, keeping one onsite and one offsite. To backup to several different USB sticks or hard drives in rotation, list each drive in dest.conf as a type dir destination with a different destname and mount point (the dir keyword value). If only one of the sticks/drives is inserted, it will cause errors for the missing drives, but when drives are swapped on a later backup, HashBackup will copy all missing files to "catch up" the drive. Consider adding onfail ignore to prevent backup errors caused by missing drives.

When rotating drives, either:

Multiple Directories

The dir destination explained above uses a dir keyword to indicate the single directory where all backup data is copied. A variation of the dir destination with type dirs (added s) allows specifying multiple destination directories. Backup data is distributed over this set of directories. This is useful with multi-drive external disk enclosures configured as JBOD (Just a Bunch Of Disks). It is possible to configure these units as one large RAID0 drive and use a dir destination, but that reduces reliability: if any disk fails, all data is typically lost. A RAID > 0 configuration is most reliable, but also reduces capacity. A JBOD configuration using the dirs destination type with multiple directories is a middle ground: if a disk is lost, only the backup data on that drive is lost. This is an especially reasonable configuration if there is another copy of the backup data stored at another destination since HashBackup can sync the lost data when a new drive is installed with dest verify and dest sync commands.

The dirs destination requires a dirs keyword specifying multiple target directory paths, separated by colons. When reading from the destination, HB will check all directories until it finds the file it needs. When writing arc files, HB will check available space in each directory and copy to a directory with enough space to hold the file. When copying non-arc files, HB makes copies in every directory that has room, to increase the chances of a recover in case the local backup directory is lost and one or more JBOD disks are also lost.

Keywords

dir

The directory where a copy of backup files should be stored. This keyword is for type dir destinations, ie, only 1 directory.

dirs

A list of directories separated by colons (:) where a copy of backup files should be stored. Arc files are copied to one of these directories by default (see copies). This keyword is for type dirs destinations, ie, multiple directories.

copies

Integer keyword for type dirs destinations specifying how many copies of arc files to create to increase redundancy. Each copy is stored in a different directory. The default is 1.

spread

Boolean keyword for type dirs destinations that causes arc files to be distributed over all disks rather than filling disk 1 before using disk 2. Using spread by itself will enable the feature.

iosize

The size of writes and reads for this destination. Some targets like synchronous NFS may benefit from larger I/O sizes. The default is 512K (524288).

symlink

Boolean keyword to use symlinks rather than copying data from the destination when the local backup directory cache is limited by the cache-size-limit config option. Using symlink causes HB to read data directly from the destination, which could be good or bad depending on how fast the destination can do I/O. If the destination can do small I/O’s quickly, symlink might be useful to avoid a large file copy, especially if only a few blocks are needed (hb get of a small file for example). If the destination is a slow USB drive, it may be better to sequentially copy an arc file to the local backup directory in iosize hunks and read the small blocks from copies in the local backup directory.

Directory Examples