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.
Did you guys ever find a good solution to this problem?
Thanks!
If you mean daily/weekly/monthly/yearly backups: the easiest for now is to use own cron jobs with dedicated backup locations, which can be done with the CLI. But the amount of backups kept for each location is the same: see the crontab @Joulinar suggested above, but use the full path to the script: Add more time options to dietpi-backup - #3 by Joulinar
Such can be added to a custom crontab file, like /etc/cron.d/dietpi_backups.
0 0 * * * root /boot/dietpi/dietpi-backup 1 /mnt/backup/daily
0 1 * * 1 root /boot/dietpi/dietpi-backup 1 /mnt/backup/weekly
0 2 1 * * root /boot/dietpi/dietpi-backup 1 /mnt/backup/monthly
0 3 1 1 * root /boot/dietpi/dietpi-backup 1 /mnt/backup/yearly
When using the above, disable daily backups in dietpi-backup, else it doubles with above daily job. Based on the comments I wrote above, I think I missed the fact that this uses different backup locations via CLI, and hence daily or custom backups won’t rotate/remove weekly/monthly ones. So the above works quite well. There will be redundant backups at some points, but the enhancement done with DietPi v9.17 reduces the impact this has on disk usage.
You could use a script or extend the commands above to edit the AMOUNT setting before each run, to have different amounts each:
0 3 * * * root sed -i '/^AMOUNT=/c\AMOUNT=8' /boot/dietpi/.dietpi-backup_settings && /boot/dietpi/dietpi-backup 1 /mnt/backup/daily
0 2 * * 1 root sed -i '/^AMOUNT=/c\AMOUNT=3' /boot/dietpi/.dietpi-backup_settings && /boot/dietpi/dietpi-backup 1 /mnt/backup/weekly
0 1 1 * * root sed -i '/^AMOUNT=/c\AMOUNT=2' /boot/dietpi/.dietpi-backup_settings && /boot/dietpi/dietpi-backup 1 /mnt/backup/monthly
0 0 1 1 * root sed -i '/^AMOUNT=/c\AMOUNT=1' /boot/dietpi/.dietpi-backup_settings && /boot/dietpi/dietpi-backup 1 /mnt/backup/yearly
This would keep 8 daily, 3 weekly, 2 monthly and 1 yearly backups. Note I reversed the hour of execution compared to the first example, so the daily job runs last at 03:00 AM, so that the amount matches the daily one if you manually create a backup outside ot 00:00 - 03:00 AM where these 4 jobs can run.
Thank you! This is super helpful.
As always, I really appreciate the time and effort that you, and the rest of the team, put into helping and supporting the community.
1 Like