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.
if the user uses a use awk to identify files outside of range and delete via loop
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
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.
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
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?