Idea: Configuration may include when to backup #616

New Issue

Closed

opened 2022-11-26 13:12:24 +00:00 by lamyergeier · 5 comments

lamyergeier commented 2022-11-26 13:12:24 +00:00

Copy Link

Rather than defining when to backup in the external tool like cron or systemd, we could define it in the configuration file(s). And every hour I can run borgmatic with systemd . Borgmatic could check the backup schedule defined in the configuration file, and determine if its necessary to backup and proceed accordingly.

What do you think? (This is how backintime works, it let user define the scheduling in the configuration itself and then edits the crontab. I am not asking you to edit crontab, but it would be nice if boegnmatic can determine if backup is necessary or not).

We could have a separate option for forced backup to disregard the schedule.

Rather than defining when to backup in the external tool like cron or systemd, we could define it in the configuration file(s). And every hour I can run borgmatic with systemd . Borgmatic could check the backup schedule defined in the configuration file, and determine if its necessary to backup and proceed accordingly. What do you think? (This is how backintime works, it let user define the scheduling in the configuration itself and then edits the crontab. I am not asking you to edit crontab, but it would be nice if boegnmatic can determine if backup is necessary or not). We could have a separate option for forced backup to disregard the schedule.

witten commented 2022-11-26 17:25:07 +00:00

Owner

Copy Link

Thanks for filing this! On the one hand, I generally would like to avoid reinventing cron/systemd. On the other hand, the feature you described is basically how the consistency check frequency feature already works. (There's even an existing --force option to disregard the schedule.) And so it wouldn't be a big stretch—either technically or in terms of feature creep—to extend such functionality to backups.

I think my main question at this point is the why behind this ask. Is it just more convenient to do scheduling in borgmatic's configuration than via systemd?

Thanks for filing this! On the one hand, I generally would like to avoid reinventing cron/systemd. On the other hand, the feature you described is basically how the [consistency check frequency](https://torsion.org/borgmatic/docs/how-to/deal-with-very-large-backups/#check-frequency) feature already works. (There's even an existing `--force` option to disregard the schedule.) And so it wouldn't be a big stretch—either technically or in terms of feature creep—to extend such functionality to backups. I think my main question at this point is the *why* behind this ask. Is it just more convenient to do scheduling in borgmatic's configuration than via systemd?

lamyergeier commented 2022-11-26 17:42:37 +00:00

Author

Copy Link

I think its ok, users can use external tools like cron and systemd as you said. I saw the systemd service, systemd timer.

I was wondering of a use case that one can have a schedule to be backed up on external harddrive. And if the external drive is not always available, and the schedule was missed then the backup could start immediately when the drive is plugged. This is how backintime used to function.

I think its ok, users can use external tools like cron and systemd as you said. I saw the [systemd service](https://projects.torsion.org/borgmatic-collective/borgmatic/raw/branch/master/sample/systemd/borgmatic.service), [systemd timer](https://projects.torsion.org/borgmatic-collective/borgmatic/raw/branch/master/sample/systemd/borgmatic.timer). I was wondering of a use case that one can have a schedule to be backed up on external harddrive. And if the external drive is not always available, and the schedule was missed then the backup could start immediately when the drive is plugged. This is how backintime used to function.

witten commented 2022-11-27 17:13:33 +00:00

Owner

Copy Link

Got it. Are you aware of the existing borgmatic support for occasional backups? That's intended to support a use case just like what you describe—a backup repository (or source directory) that's not always available. But it sounds like you'd like scheduling layered on top of that?

Got it. Are you aware of the existing borgmatic support for [occasional backups](https://torsion.org/borgmatic/docs/how-to/backup-to-a-removable-drive-or-an-intermittent-server/)? That's intended to support a use case just like what you describe—a backup repository (or source directory) that's not always available. But it sounds like you'd like scheduling layered on top of that?

witten added the

waiting for response

label 2023-03-27 03:20:59 +00:00

witten commented 2023-03-27 03:23:43 +00:00

Owner

Copy Link

Just checking in again on this one. It sounds like you're wanting to go a little beyond scheduling capabilities in borgmatic and perhaps run it as a daemon process that waits until a configured removable drive is plugged in and then initiates a backup? I'm guessing that's because this is just more convenient than manually running borgmatic whenever the drive is plugged in?

Just checking in again on this one. It sounds like you're wanting to go a little beyond scheduling capabilities in borgmatic and perhaps run it as a daemon process that waits until a configured removable drive is plugged in and then initiates a backup? I'm guessing that's because this is just more convenient than manually running borgmatic whenever the drive is plugged in?

lamyergeier commented 2023-03-27 06:07:23 +00:00

Author

Copy Link

I am satisfied with your previous reply and with the current reply. We can close this issue. Thank you.

I am satisfied with your previous reply and with the current reply. We can close this issue. Thank you.

👍 1

lamyergeier closed this issue 2023-03-27 06:07:24 +00:00

witten removed the

waiting for response

label 2023-03-27 06:10:13 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#616

No description provided.