Add SSH remote backup support, new commands, and test suite

  - Add remote mode for SSH-based backups to servers like TrueNAS
  - Add SSH_IDENTITY_FILE config for non-root SSH keys
  - Add new commands: backup, status, list, dryrun
  - Add dependency checks for rsync, ssh, flock
  - Add timestamped logging
  - Fix: duplicate cron jobs on repeated setup
  - Fix: use mktemp for temp files
  - Fix: use portable sed instead of grep -oP
  - Fix: strengthen input validation with regex anchors
  - Fix: handle paths with spaces (newline-separated includes)
  - Change license from MIT to GPL v3
  - Add automated test suite (25 tests)
  - Update README with new features and testing docs

1 files changed, 0 insertions, 73 deletions

diff --git a/todo.org b/todo.org
deleted file mode 100644
index e2a1374..0000000
--- a/todo.org
+++ /dev/null
@@ -1,73 +0,0 @@
-* Rsyncshot Open Work
-** [#B] crontab should offer more schedules
-*** 2024-05-06 Mon @ 15:51:58 -0500 problem to solve
-currently, rsyncshot has the following
-hourly each day
-daily each week
-every week
-
-...and that's it. Of course, the user can fiddle with this as they please to achieve any backup schedule they desire. However, most users won't want to mess with cron.
-
-We should do it for them. Here's what I suspect these two will be the most common:
-
-DATE BOUND
-- hourly, expiring past a specific date period (e.g., month or year)
-- daily, expiring past a specific date period  (e.g., month or year)
-- every X minutes, expiring past a specific date period  (e.g., month or year)
-
-STAGGERED
-- every 10 mins for the hour (max 5, as the last will be the hourly)
-- every hour for the day (max 23, as the last will be daily)
-- every day for the week (max 6 as, the last will be weekly)
-- every week for the year (max 51 as, the last will be yearly)
-- every year (ongoing)
-
-This means that a full year will have 86 backups.
-The user can choose to not do the 10 min or hourly backups and just allow for day, week, year.
-** [#B] backup pruning should be more robust
-*** 2024-05-06 Mon @ 16:21:29 -0500 problem to solve
-if the user uses a
-use awk to identify files outside of range and delete via loop
-** [#C] strip - and -- to ease users finding help/usage options
-*** 2024-05-06 Mon @ 15:31:50 -0500 problem to solve
-The user may not know how to even get help on the command line
-typical command line arguments are --help -h and others.
-let's make it easy for the user by stripping off the
-** [#C] help should be able to tell more about environment and act on it
-*** 2024-05-06 Mon @ 15:34:10 -0500 problem to solve
-is there a drive mounted on /media/backup (or the default location)?
-has rsyncshot been installed?
-have the cron jobs been set up?
-
-instructions should then change based on install state
-- if not installed, setup instructions are clear
-- if installed, install and log location is clear
-- if installed but no cron jobs, tell user how to set them up, offer to set up dailies, etc.
-- if no drive mounted, give user the command line option or offer to mount the drive
-
-You could tackle this in pieces: installation check, cron job check, mounted drive check, etc.
-** [#C] backup drive should have an optional command line argument
-*** 2024-05-06 Mon @ 15:47:56 -0500 problem to solve
-reason: users may want to backup to a different directory via crontab or manually
-default exists now (i.e., "/media/backup")
-changing it means changing the source
-
-we should allow the user to pass -d (for destination) with a path
-- validate the path exists
-- assigning the destination
-** [#C] ability to trigger immediate backup
-*** 2024-05-06 Mon @ 16:21:53 -0500 problem to solve
-the user has to wait for the cron job to kick off for a backup
-however, they may want to manually trigger a backup immediately
-they can do this by: "rsyncshot <some-random-name> <some-random-number>
-
-however, we should make it easier for them.
-options:
-- no command line arguments issues the equivalent of rsyncshot BACKUP 100
-  the downside here is that the user may expect this to be a way to get usage information.
-- a command line option like: "rsyncshot --backup-now"
-  it's not obvious what to choose for the switch.
-  what have other authors chosen for an option in similar situations?
-
-* Rsyncshot Resolved
-** DONE [#B] backups should be contained in a subdirectory based on hostname