I do not understand the relation between system cron, the cron prop in config file, and autorestic cron command. My conclusions on this (might be falsy)

[Kenya-West]

The docs page do not mention the relations of these at all.

The questions are:

1. Why do I need to define cron prop in .autorestic.yaml if I have already setup a cronjob like: autorestic backup -c ~/.autorestic.yaml -av --ci for every hour 0 * * * * * in the system?

2. Why do I need to run autorestic cron command if I have the same job already setup from above?

3. The cron command docs page does not explain what the autorestic cron command do. It is mentioned that it should be run by system cron. Why?

4. Can the cron prop in .autorestic.yaml config file be defined in the global section? There is no schema for the config...

Despite the absenced info, I have made some conclusions:

• I can define cron prop in global section of .autorestic.yaml config file;
• The autorestic cron will generate and register cronjobs in the system for each backend;
• I manually set these generated cronjobs to run every minute;
• The cronjobs will be skipped if they do not satisfy the keep strategy defined in config file.

Am I right?

[martinjuhasz]

I would love to know an answer to these exact same questions.

[dotboris]

I tried to explain it here #425 (comment)

I'll try to explain it here as well and I'll go into some more details.

Why do I need to define cron prop in .autorestic.yaml if I have already setup a cronjob like: autorestic backup -c ~/.autorestic.yaml -av --ci for every hour 0 * * * * * in the system?

You don't. Technically speaking there's two ways to handling periodical backups.

1. You can run autorestic backup ... in your system's cron like you're doing
2. You can let autorestic manage this through autorestic cron

You need to pick one of those options.

So what's the point of autorestic cron then? Honestly, I'm not 100% sure. There's a difference in implementation but you can achieve mostly the same things with either solution.

When using autorestic cron, you're meant to run it very often (I run it every 5 minutes). What's important here is that this doesn't perform a backup every 5 minutes. Instead, you then define a cron: ... option in each of your locations that you want to backup periodically. Internally, autorestic will keep track of when it last backed up your location with autorestic cron and store that in its lock file.

So when you run autorestic cron, it checks to see if there's any backups to perform using the state in the lock file and the cron: ... option in the locations. Then, if there's a backup to perform it'll perform it. What's important to note here is that autorestic cron will do nothing most of the time because it's not yet time to perform the backup.

There are some benefits to this but you could achieve the same thing using the system cron in most cases:

• You can configure your cron settings right next to your location. This may be nicer for some people who find it easier to just mess with one file. You only have to touch your crontab once.
• You can configure different cron schedules for different locations. You can achieve the same thing using your system cron tho.
• Your cron state will persist between reboots. If your computer / server is not running while the backups should be happening, then it'll get run the next time it can. This is more helpful when you run backups weekly for example. Also, it's possible to achieve the same thing with systemd when using its persistent timers. I don't believe you can do this with the system cron tho.

With this context, I should be able to answer your questions and address your conclusions:

Why do I need to run autorestic cron command if I have the same job already setup from above?

You don't. Either manage everything yourself using the system cron or run autorestic cron frequently and configure cron: ... options in your locations.

The cron command docs page does not explain what the autorestic cron command do. It is mentioned that it should be run by system cron. Why?

Why does the documentation not explain these things? That's because autorestic is an open source project worked on by volunteers. Lacking documentation is unfortunately a thing that happens in those circumstances.

Why does should it be run by the system cron? That's only needed if you want to use the cron: ... option in the location config.

Can the cron prop in .autorestic.yaml config file be defined in the global section? There is no schema for the config...

I just read the code around the cron, locations and global options and I don't think that this is possible.

Now onto your conclusions:

I can define cron prop in global section of .autorestic.yaml config file;

I don't think that this is true. The cron, location or config loading code doesn't do anything special to access the global config in the context of a cron execution.

The autorestic cron will generate and register cronjobs in the system for each backend;

I'm not 100% sure I understand what you mean by this but I can tell you the following:

• autorestic does not touch your system or user's crontab at all
• When using autorestic cron, the cron schedules are defined on locations and not on backend.

I manually set these generated cronjobs to run every minute;

Following the previous point, I don't think so. There are no generated cron jobs.

The cronjobs will be skipped if they do not satisfy the keep strategy defined in config file.

This is not the case. When you use autorestic cron, it uses a combination of the configured cron: ... option for your location and the cron state in the lock file to determine if it should run (or skip) the backup during this invocation.

The keep configuration is used after the backup process is done. First autorestic runs restic backup ... which creates a new snapshot and then if you have keep: ... settings configured, it'll run restic forget ... passing it those settings as flags. restic forget is used to remove old snapshots while keeping only some of them. It's useful for implementing a generational backup scheme See: https://restic.readthedocs.io/en/latest/060_forget.html