Dirvish ToDo List

List items are not in a prioritised order.

List item marks designate some intent.

• to be done before next version.
• normal.
• ongoing.

dirvish

• Allow vault[:branch] as an argument so --vault and --branch options aren't needed.
• Enhance the password-file: parameter so that if given a relative path use the config-file search function (when written).
• Add a meta-owner parameter like meta-perm to specify a owner:group for meta-files in images.
• Enhance recognition and assessment of rsync errors and warnings.

dirvish-expire

• Allow vault[:branch] as an argument so --vault option isn't needed.
• Move non-expiration notices to bottom of dirvish-expire output.
• Put functionality for doing cleanups of hist files to deal with deleted backups somewhere in dirvish-expire. A possible approach would be for --histck to remove hist entries having no matching images on disk. --hist might remove hist entry during expiration but that would complicate things.
• Rework to eliminate the internal find. Have dirvish-expire walk the vaults like dirvish-locate.
• Improve internal logic to handle failed images better. Instead of using just sort order it should track a latest successful image to keep. Preferring an unexpired, but saving an expired one if no unexpired available.

dirvish-locate

• Improve the performance of index file parsing.
• Report all file dates with year even those without year in index.

in general

• Allow config-file search that searches bank/vault/dirvish/ also search /etc/dirvish/vault/ for files.
  Do this with a new function that can also be called for other file-based looking.
• Add command-line options for non-interactive install.sh runs.
• Add the ability to create an initial set of configs to install.sh.

Dirvish Wish List

These items are low-priority. It is recognised that they have merit and they have been given some thought but are, at present, not considered sufficiently important to invest the needed time. If a paying client wished one of them the priority would change but until that happens or the author's requirements change they are shelved.

• Add a mechanism for dirvish and dirvish-expire to log their activity.

  This would probably a config parameter where you could either specify a file name or a syslog "facility" such as daemon or local3.

• Add option to run arbitrary command instead of rsync.

  This would allow dirvish to schedule jobs that don't involve rsync but belong under the same process management as the main backups. Having to maintain multiple backup systems and schedulers can be a pain.

• Extend EXPIRE-RULES to support multi-stage actions

  The date specifier of an expire rule would contain a designator set elsewhere in the config file. The value of the designator (expire action) would be a list of date-specs and actions to be done.

  For example:

  expire-rule
  	wd { sun } md { 1-7 }               expire-monthly
  
  expire-monthly
  	+1 month	clean-tree clean_list
  	+6 months	delete-tree
  	+1 year		delete-image
  

  The actual format will probably differ and the image manager (dirvish-expire) will need to know what to do with the actions and record completion in the summary file to prevent repeats.

  Probable actions would be:

  delete-image	delete whole image including metadata.
  delete-tree	delete image tree leaving metadata.
  compress-tree	create a compressed archive of the tree (tree.cpio.gz) and delete the tree.
  clean-tree	lean the image tree by deleting files that match patterns in a file.
  run	run an executable/script.

• Add --replace and --inplace to config to allow overwriting of an existing image.

  If reference == image don't delete tree and don't use --link-dest.

  If reference != image and --replace, delete image before reuse because the delta from the reference image is most likely less than the reused image But if --inplace specified don't delete even if reference != image. Inplace is especially useful if the backup is incomplete and you wish to re-run it manually.

• Create the scheduler.

  Most of the functionality is already documented in dirvish.conf(5) as comments not visible to man.

  The scheduler would generate a priority ordered run queue of jobs that can be run and launch as many would be permitted by the Max-jobs and Max-load limits. When a job completes recalculate whether any jobs still on the queue can run (window and limits) and launch them. If the queue is empty rescan for jobs that may now be runnable. Exit when there are no running or runnable jobs.

  The scheduler would use a /var/run/dirvish.pid file to prevent multiple dirvish-sched processes from running at once. The scheduler could be launched by cron at intervals.