[question] Is it possible to run before_backup hook not only once, but everytime a repo starts #320

New Issue

Closed

opened 2020-05-28 17:47:33 +00:00 by caioau · 7 comments

caioau commented 2020-05-28 17:47:33 +00:00

Copy Link

What I'm trying to do and why

Im backuping up an VPS into a mini pc in my home, but I use port knocking to access the mini pc, so I put the port knocking script into before_backup hook, but I have 2 repos (1 to backup into the internal hdd and another in the external hdd), so when the 2th repo backup starts it fails (bacause the port is now closed).

Can I instruct before_backup to run everytime before starting a repo backup? Or maybe create a new hook called before_repo_backup , not sure.

Thanks very much! I been using borgmatic and it's awesome. Keep up the awesome work.

#### What I'm trying to do and why Im backuping up an VPS into a mini pc in my home, but I use port knocking to access the mini pc, so I put the port knocking script into before_backup hook, but I have 2 repos (1 to backup into the internal hdd and another in the external hdd), so when the 2th repo backup starts it fails (bacause the port is now closed). Can I instruct before_backup to run everytime before starting a repo backup? Or maybe create a new hook called before_repo_backup , not sure. Thanks very much! I been using borgmatic and it's awesome. Keep up the awesome work.

caioau changed title from [question] Is it possible to run before_backup hook not only once, but everytime starts every repo. to [question] Is it possible to run before_backup hook not only once, but everytime a repo starts 2020-05-28 17:49:25 +00:00

witten commented 2020-05-28 17:58:56 +00:00

Owner

Copy Link

Thank you for filing this ticket, and for the kind words!

I could see adding a hook called before_repo or before_repository. Question though: Would it make sense to run regardless of actions specified (create, prune, check, etc.)? I imagine that for any action that needs to interact with the remote repository, you'd need the port knocking script to run first...?

Thank you for filing this ticket, and for the kind words! I could see adding a hook called `before_repo` or `before_repository`. Question though: Would it make sense to run regardless of actions specified (`create`, `prune`, `check`, etc.)? I imagine that for any action that needs to interact with the remote repository, you'd need the port knocking script to run first...?

caioau commented 2020-05-28 18:04:49 +00:00

Author

Copy Link

Yes, it would be needed to run for any action.

Yes, it would be needed to run for any action.

witten commented 2020-05-28 18:05:35 +00:00

Owner

Copy Link

Okay, thanks!

Okay, thanks!

witten added the

design finalized

label 2020-05-28 18:05:43 +00:00

caioau commented 2020-05-28 18:08:33 +00:00

Author

Copy Link

ah another cool thing for this feature, is the possibility to pass the repo hostname to the script, to make it more generic, so the repos are in diffrent hosts, something like this:

before_repo: port_knocking_script.sh %h

ah another cool thing for this feature, is the possibility to pass the repo hostname to the script, to make it more generic, so the repos are in diffrent hosts, something like this: before_repo: port_knocking_script.sh %h

witten commented 2020-05-28 18:15:11 +00:00

Owner

Copy Link

That's a great idea.. I've thought of something similiar with some of the existing hooks. For simplicity's sake, I could see just unconditionally passing in the repository path as the first parameter to the script (no %h needed). And then it's up to the script to do whatever it wants with that.

That's a great idea.. I've thought of something similiar with some of the existing hooks. For simplicity's sake, I could see just unconditionally passing in the repository path as the first parameter to the script (no `%h` needed). And then it's up to the script to do whatever it wants with that.

👍 1

networkjanitor referenced this issue 2020-08-04 19:48:53 +00:00

borg backup in pull mode #346

witten commented 2022-04-22 06:18:46 +00:00

Owner

Copy Link

Part of this will be implemented once #473 is released. Specifically, all the before_backup, after_backup hooks will run on a per-repository basis, and the full repository path (including hostname) will be able for interpolation as the repository variable.

The one part of this ticket that isn't yet implemented is a general per-repository hook that gets run for all actions (create, prune, etc.).

Part of this will be implemented once #473 is released. Specifically, all the `before_backup`, `after_backup` hooks will run on a per-repository basis, and the full repository path (including hostname) will be able for [interpolation](https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/#variable-interpolation) as the `repository` variable. The one part of this ticket that isn't yet implemented is a general per-repository hook that gets run for all actions (`create`, `prune`, etc.).

witten commented 2023-02-04 21:59:51 +00:00

Owner

Copy Link

This was implemented a while ago! (It's in borgmatic 1.7.0+.) before_actions/after_actions are the new hooks for this and they run once per configured repository.

This was implemented a while ago! (It's in borgmatic 1.7.0+.) `before_actions`/`after_actions` are the new hooks for this and they run once per configured repository.

witten closed this issue 2023-02-04 21:59:51 +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#320

No description provided.