HashBackup has been actively developed since its initial release in June 2009. Over that time there has been a release every few weeks on average. There are ongoing backups of production servers from 2010 with over 3000 daily backups.
HashBackup is being used for large production backups, often to handle offsite backup requirements to supplement an existing onsite backup. The largest reported single backup is 53M files / 121TB at a college research site. The initial backup took 25 days, used 8GB of RAM, and created 57TB of backup data managed by a 17GB database, with 22TB eliminated by dedup. Other large reported backups are 26M files / 18TB at a research lab, 25M files / 1.5TB for a large imap server, 23M files / 34TB for a data archive, and 27TB of 1.5TB VM image backups using less than 1TB of backup space after dedup.
HashBackup has frequent new releases and the latest official release is the best production release.
To ensure customers stay up-to-date and allow for future paid licensing, HashBackup releases have always had an expiration date. Releases expire on a fixed quarterly schedule, on the 15th of January, April, July, and October.
|Backup is the only feature that expires, so backups can be tested and restored later, even with an expired version of the program.|
The Automation setup shows how to automate updates. Keep the expiration schedule in mind if you prefer manual upgrades.
Is there an online bug list?
Bug lists often provide a comfortable home to bugs for many months or
years. But most customers would prefer that bugs are squashed rather
than taking up residence on a bug list, so HashBackup works a
different way: when a bug is reported, it’s fixed, released to the
preview area, and a reply is sent asking the customer to do an
hb upgrade -p to get the preview release. If it’s a difficult bug, and
most aren’t, an update may be sent directly to a customer asking them
to verify that the problem is fixed before doing a release.
Bug reports and correcting bugs take priority over new development, so not having a bug list also acts as a self-regulating mechanism to balance new development and reliability.
To ensure high quality, HashBackup uses an automated bug reporter, Bugz. This saves having to report errors in many cases, ensures the bug report has complete information such as the HB release, and allows fixes to be released quicker. You’ll see this in the release notes when a fix is credited to Bugz. Reported information includes the HB release, command line, recent log history, traceback, and OS id. To maintain privacy, pathnames are replaced by numbers. For example:
HB #2772: ProgrammingError: Cannot operate on a closed database., File "/db.py", line 761, in closedb $ /usr/local/sbin/hb backup -c /1/2 /3 2022-03-03 Thu 20:44:05| /3/4 2022-03-03 Thu 20:44:05| /3/4/5 2022-03-03 Thu 20:44:05| /3/4/6 2022-03-03 Thu 20:44:05| /3/7 2022-03-03 Thu 20:44:05| /3/8 2022-03-03 Thu 20:44:05| 2022-03-03 Thu 20:44:05| Traceback (most recent call last): 2022-03-03 Thu 20:44:05| File "hb.py", line 218, in <module> 2022-03-03 Thu 20:44:05| File "/db.py", line 761, in closedb 2022-03-03 Thu 20:44:05| ProgrammingError: Cannot operate on a closed database. Linux-4.15.0-136-generic-x86_64-with-debian-buster-sid
If you have any questions, suggestions, or concerns you’d like to discuss, send an email! It’s always helpful to get feedback about HashBackup.