Open jamiemc1 opened 3 years ago
I really like this idea.
I can't see anyway to do this without adding new settings to the .conf files -- with hard-coded defaults in the .sh script for old .conf files that don't have the new settings.
It can get super complex/tricky very fast. For example, you may want specific rules for previous week, and someone may want specific rules for 2 weeks prior.
How are you thinking of handling the logic?
I can think of two options:
nBackup.sh
that reads in a delete rule (in some specific syntax). That way, you'd make X # of additional calls to nBackup.sh
with rules for what to delete. It could even read multiple delete rules like nBackup.sh -d "delete rule syntax" -d "delete rule syntax" -d "delete rule syntax" ....
.conf
file that nBackup.sh
iterates over. Something like:
DELETE_RULE_1=....
DELETE_RULE_2=....
DELETE_RULE_A=....
nBackup.sh
would just iterate over all of the variables that start with DELETE_RULE
.
Coming up with the delete rule syntax is the hard part.
I'm keenly interested to hear your thoughts.
In the inspiration you linked they touch on having a unique script call for daily snapshots and lower frequency snapshots.
I would like to implement a varying frequency backup call. For example, in the previous day keep a backup every hour, in the previous week keep a backup every day, in the previous month keep a backup every week, etc.
I can certainly fork the repository and implement this logic. But it would make sense to push the changes upstream.
Given this, how would you approach the logic to cause zero changes to old .conf files?
I can see some changes would be needed in the functions
deleteOld<XXX>Backups
to include an additional argument tofilterFilesToDelete
. Additionally I would need to rebuildfilterFilesToDelete
to account for this logic.Let me know if you have any ideas, I'll start building on the logic in the week.
Thanks.