StoreBackup Changelog

New in version 3.4.3

November 11th, 2013
  • now supports colors and a bug regarding dedup with "blocked files" is fixed.

New in version 3.4.2 (September 27th, 2013)

  • This version adds support for handling sparse files and progress reports based on periods of time.

New in version 3.4.1 (September 9th, 2013)

  • This release delivers some bugfixes plus the new chapter "Internals" in the documentation.

New in version 3.4 (July 29th, 2013)

  • This release adds the ability to select via special marker files whether files in directories are backed up or compressed.
  • It's possible to store special files in archives if your target file system doesn't allow you to store them natively.
  • There are minor fixes.

New in version 3.3.1 (April 25th, 2013)

  • Bugs were fixed.
  • If you use, you will have to adjust your options.
  • Other scripts also have a few new options.

New in version 3.3 (October 5th, 2012)

  • This version can make an estimation if a compression might reduce the file size. E.g. when traveling, you can make backups without access to the master backup, and integrate these backups later into the central one.
  • Backups can be replicated (automated), so you can generate copies of your backups (e.g. on another external disk).
  • storeBackup can validate your backup via checksums.
  • With, it can validate unchanged files in the source directory against checksums in the backup, e.g. to recognize bit rot.

New in version 3.2.1 RC1 (February 13th, 2012)

  • This bugfix release includes important fixes if you use lateLinks/lateCompress or de-duplication with blocked files or devices.

New in version 3.2 (July 20th, 2009)

  • Minor bugfix release.
  • It fixes all known bugs from v3.1 and introduces option highLatency.

New in version 3.1 (May 25th, 2009)

  • storeBackup did not backup sockets, now it does
  • for new files, the md5 sum is now calculated before *and* after copying / compressing for safety reasons. The file could have been changed during that time. So the md5 sum would not match the real one. A file with the firstly calculated md5 sum later could be hard linked to the changed file which means there is no backup of its content.
  • If both md5 sums do not match, an warning is generated and the md5 sum is set to ggggg... which is a not possible value. This problem does not exist for blocked files in v3.0.
  • improved statistic at the end of a run (sum of warnings and errors)
  • added options checkBlocksParallel and checkDevicesParallel
  • added option linkToRecent name clashes because of compressing files (eg. add .bz2) were not handeld corretly - bug was introduced in 3.0 corrected
  • when making a backup with source while not using includeDir then the md5 sums of all files were calculated also after the first backup
  • corrected some issues with the statistical output
  • option copyBWLimit is now deprecated because
  • of internal performance optimization
  • it is useless
  • new option suppressWarning
  • if sourceDir=/, for the very first backup with option lateLinks an empty 'linkFrom' file was generated which lead to (useless) error messages. corrected.
  • now also checks if files in the backup are not listed in .md5CheckSum
  • the directories in the path to the restored files / directories were not set the original permissions, corrected llt
  • added option --epoch to calculate human readable dates from epoch based dates
  • man:
  • man pages for all programs (Thanks to Ryan Niebur)
  • all programs:
  • solved issues with single quotes in path and filenames