Upgrade

The -n option checks for a new version and shows the release notes but does not replace the hb binary. Release notes are written to stderr, so use this command to redirect them to a file:

If the file notes.txt is empty, you already have the latest version.

The -p option upgrades to the preview release rather than the official release. The preview release is to try out upcoming changes on non-production backups and provide early feedback before release. -p must be used every time you want the preview version.

To ensure the download package is an authentic version of HashBackup it’s signed with a private RSA-4096 key during the build process. This private key is not stored on the download server. The matching public key built in to the HB executable verifies the file signature and contents to prevent installing a corrupt or fake version of HashBackup.

HashBackup may do an automatic database upgrade the first time a new version is used. There have been over 30 database changes since the initial release, on production backups stretching back to 2012.

If it has been a while since you have upgraded, there may be multiple database upgrades, as in the example below. If there is any problem during the upgrade, the database is rolled back to its original state.

New releases of HashBackup automatically perform database upgrades whenever the database format changes to support new features. But if no HashBackup commands have been run on a backup within the last year, or the HashBackup program has not been upgraded regularly, the latest release of HashBackup may not be able to upgrade the backup because it is too old. In that case it may be necessary to download and run an older version of HashBackup to partially upgrade the database, then run newer versions to fully upgrade the database. The instructions to do that are given when an upgrade fails for this reason.

To ensure you have a version of HB that can read your backup, consider setting the config option copy-executable to True. This stores a copy of the HB executable on every remote destination. Or make sure to run HashBackup against your backup at least a few times a year with the latest release to keep the database upgraded. For more information, see "Using HashBackup for Archiving" on the Backup command page.

Upgrade sends messages either to stdout or stderr. In an interactive session, both of these normally are tied to the terminal screen so there is no distinction. For shell, cron, or background jobs, the distinction can be important.

The HashBackup version and copyright heading and "You already have the latest version" are sent to stdout. Since these are not very useful in scripts or cron jobs, stdout is usually sent to /dev/null and these messages are suppressed:

All other messages including the release notes are sent to stderr. In a cron job where upgrades are automated, these messages are emailed to you when an upgrade occurs. To send stderr to a file instead, use:

To ensure that you have the latest updates to the HashBackup program and your backup database stays up to date, it’s a good idea to setup automated upgrades. This is easy with a system cronjob, either with your regular backup command or as a separate cron job.

To check for upgrades after every backup, the line in /etc/crontab looks like this:

You can adjust the start time in the first two fields, minute first, then hour, the -c backup directory, and other options as necessary. The upgrade is done after the backup so that the HashBackup upgrade server isn’t hit with many simultaneous upgrade requests. Everyone’s backup will take a different amount of time so this puts the upgrade checks on a somewhat random schedule.

If backups are frequent, say every hour, you can check for upgrades on an independent schedule. Use an entry like this to check every day at 12:30AM (change to a random time):

Cron will send an email with the release notes when a new version is installed.

OSX systems may not have an /etc/crontab file, but if you create one, it will work. Begin your edit command with sudo to create this system file in /etc.

A private HashBackup upgrade server is easily configured and sites with more than 10 copies are encouraged to use a private server. To create an HB upgrade server, run a cron job on your private server no more than once a day please to mirror the HashBackup release with rsync. Adjust the target below for your private http server. The source is an rsync module, so two colons are used:

To mirror the preview release, use ::preview instead of ::release. To archive past releases omit --delete-after

To upgrade from your private upgrade server:

This functions exactly like the official HashBackup upgrade server, using RSA-4096 signature verification to ensure the binary is authentic.