dietpi-backup is really cool. I really like having backups. However, having multiple daily backs aren’t as helpful in case an issue goes unnoticed for awhile. A more ideal solution would be able to set it to have a daily backup, a weekly backup, and a monthly backup. It would be cool if the dietpi-backup menu allowed you to specify different time intervals: Something like
Daily Backup : [Off] Daily backups via cron job
Amount : [1] The amount of backups to keep
Weekly Backup : [Off] Weekly backups via cron job
Amount : [1] The amount of backups to keep
Monthly Backup : [Off] Monthly backups via cron job
Amount : [1] The amount of backups to keep
1 Like
Agreed, that would be helpful. I’m just thinking about a neat logic to do this all with the same daily cron job, just rotating one of 7/30 daily backup instances further until the week/month limit has been reached, which would also avoid parallel/redundant backups, which is a risk when using the weekly/monthly cron job instead.
Or simply create own individual cron jobs 
0 0 * * * dietpi-backup 1 /mnt/backup/daily
0 1 * * 1 dietpi-backup 1 /mnt/backup/weekly
0 2 1 * * dietpi-backup 1 /mnt/backup/monthly
0 3 1 1 * dietpi-backup 1 /mnt/backup/yearly
1 Like
That’s exactly what I ended up doing Just making a suggestion to make it a feature in the UI.
1 Like
Jep that works as well, but it means that once a week/month/year there are 2/3/4 redundant updates done and in theory they can run concurrently (breaking each other). But by default there is more than an hour delay between each other, so should be fine.
Ah and without doing a manual rotation e.g. the monthly backup isn’t kept for a month.
of course there is room for improvement, compare to a very simple cron setup 
If there isn’t the hour delay and they do run concurrently, they would break each other? How so? Is the backup dir part of the backup?
And I guess I’m not seeing why the monthly backup wouldn’t be kept for a month?
you could exclude backup dirs from being part of any backup. However at the end of a backup, services will be restarted. This could lead to inconsistency on other still running backups. Not even counting the duplicate I/O due to the multiple runs.
Ah that makes sense, and answers the first part. But why wouldn’t the monthly backup be kept for a month?
The default setting as to what to backup is:
+ /mnt/dietpi_userdata/
- /mnt/*
- /media/
Which would exclude the backup dir by default, no?
depends where you do your backup on. Usually we exclude everything in /mnt/*. Except /mnt/dietpi_userdata/, which is included again.
Right, so the default settings backs up to /mnt/dietpi-backups which is excluded from the default backups. But it could still break if they try to run at the same time due to inconsistent state since things will be stopping and starting, so best to run the an hour apart to be safe.
I still don’t understand what @MichaIng meant when he said that the monthly backup wouldn’t be kept for a month without a manual rotation?
dietpi-backup 1 always rotates the last iteration to the first place and updates it. Hence when you configure an amount of X, after X days/runs at latest all old backups are updated. And in fact once a year when daily, weekly, monthly and yearly cron run one after another, there are 4 identical backups while only X - 4 older backups left 
. No this crontab is not a good idea 
. But when changing the target location before running each job, it would work fine.