Overview

Home‎ > ‎

HashBackup is software to create encrypted, deduplicated backups. These design goals have guided the development of HashBackup since 2009:

ensure high security in a convenient way
be easy to use for simple backup situations
provide optional features for more complex backups
make efficient use of CPU, memory, and disk resources
minimize remote operations and storage costs
hide complexity on the inside, show simplicity on the outside
minimize frustration with great documentation
prioritize solving customer problems over new development

In the simplest situation, you have some files to backup. That can be as easy as 2 short commands, init and backup:

[jim@mb ~]$ hb init -c hb

Backup directory: /Users/jim/hb

Permissions set for owner access only

Created key file /Users/jim/hb/key.conf

Key file set to read-only

Setting include/exclude defaults: /Users/jim/hb/inex.conf

VERY IMPORTANT: your backup is encrypted and can only be accessed with

the encryption key, stored in the file:

/Users/jim/hb/key.conf

You MUST make copies of this file and store them in secure locations,

separate from your computer and backup data. If your hard drive fails,

you will need this key to restore your files. If you have setup remote

destinations in dest.conf, that file should be copied too.

Backup directory initialized

[jim@mb ~]$ hb backup -c hb IMG_*

Backup directory: /Users/jim/hb

Backup start: 2019-03-25 11:41:40

Copied HB program to /Users/jim/hb/hb#2197

This is backup version: 0

Dedup not enabled; use -Dmemsize to enable

/Users

/Users/jim

/Users/jim/IMG_0826.JPG

/Users/jim/IMG_0827.JPG

/Users/jim/IMG_0828.JPG

/Users/jim/IMG_0829.JPG

/Users/jim/IMG_0830.JPG

/Users/jim/IMG_0831.JPG

/Users/jim/IMG_0832.JPG

/Users/jim/IMG_0833.JPG

/Users/jim/IMG_0834.JPG

/Users/jim/IMG_0835.JPG

/Users/jim/hb

/Users/jim/hb/inex.conf

Time: 0.4s

CPU: 0.3s, 68%

Mem: 65 MB

Checked: 15 paths, 9395547 bytes, 9.3 MB

Saved: 15 paths, 9395547 bytes, 9.3 MB

Excluded: 0

Dupbytes: 0

Space: 9.3 MB, 9.4 MB total

No errors

Unlike tar, HashBackup does not create a backup with a single file. Instead it uses a directory to store the backup. Showing the contents of the backup is just as easy:

[jim@mb ~]$ hb ls -c hb

Backup directory: /Users/jim/hb

Most recent backup version: 0

Showing most recent version

/ (parent, partial)

/Users (parent, partial)

/Users/jim (parent, partial)

/Users/jim/IMG_0826.JPG

/Users/jim/IMG_0827.JPG

/Users/jim/IMG_0828.JPG

/Users/jim/IMG_0829.JPG

/Users/jim/IMG_0830.JPG

/Users/jim/IMG_0831.JPG

/Users/jim/IMG_0832.JPG

/Users/jim/IMG_0833.JPG

/Users/jim/IMG_0834.JPG

/Users/jim/IMG_0835.JPG

/Users/jim/hb (parent, partial)

/Users/jim/hb/inex.conf

The basic backup operation is to read files, split large files into blocks, merge small files into blocks, write groups of blocks into encrypted, compressed, deduplicated "arc" (archive) files, and record the relationship of all backup data in a database so that the original data can be reconstructed on demand.

Backups are usually taken periodically, with only changed data being stored. A single file may have many versions stored in the backup. A site retention policy is developed to decide how many versions to keep and for how long, and this is implemented in HashBackup with the retain command, also run periodically.

It often happens that large or confidential files are included in a backup by mistake. To remedy this, HashBackup allows removing files and directories from the backup, but only by the owner who saved the files.

As more features are added to manage the backup, it becomes important to restrict access in various ways:

individual commands can be password protected
encryption keys can be password protected
public key encryption can be enabled for "write-only" backups
remote credentials can be stored in the encrypted database

The backup made above is not very useful because it resides in the same filesystem as the items backed up. There are 2 ways to get your backup separate from your data:

using -c, write to a different physical disk
using Destinations, send data to another location

HashBackup supports many different kinds of destinations, from local storage and local servers to remote storage. One backup can be sent to multiple destinations, and HashBackup ensures that all of these destinations remain in sync so that any of them can be used for restores. New destinations can be added at any time and all historical backup data is automatically synced to the new destination.

This brings up a question: how much data should be kept locally, for quick access, and how much should be only on remote destinations to conserve local disk space? And when old versions of files are removed from the backup, how is space managed on remote destinations? These are handled with:

config options to set limits on locally stored backup data
config options to control how remote data is managed (packing)

It is also important to be sure that the backup data is accurate and can be relied on when needed. HashBackup has many features related to backup integrity:

an extensive selftest command to check backup data
the use of strong cryptographic checksums (hashes) to verify backup data
commands to check remote data, both quickly and more exhaustively
unalterable audit logs to record what has been done to the backup
detailed statistics for monitoring growth, space requirements, and utilization

Of course, the main purpose of any backup software is to provide the original data when needed. This happens via:

a mount command, to expose the backup as a regular filesystem
a command to restore files from the backup (get)
a command to recreate the entire backup directory from remote data (recover)

For simple situations HashBackup can be very simple to use, and this is a good way to get familiar with it. As the situation gets more complex, HashBackup has the optional features necessary to accommodate nearly any backup scenario.

Finally, we all realize that software is constantly changing and in need of upgrades, and may sometimes behave in unexpected or even incorrect ways. Great documentation has been provided so that in most cases, problems can be solved on your own with a little reading. A detailed Change Log explains changes in every release. Bugs and customer issues are prioritized over new development, so if you think you have run into a bug, please send an email using the contact link at the bottom of the Home page.

Enjoy your adventure with HashBackup!

Comments