A method to trigger a backup for a container "now" #8

Open
opened 2025-08-29 18:46:21 -04:00 by kareem613 · 5 comments
kareem613 commented 2025-08-29 18:46:21 -04:00 (Migrated from github.com)

It would be good to be able to set a label on a container to trigger a test backup.
Or perhaps repliqate.schedule=now
Just to be able to confirm everything would work when scheduled.

It would be good to be able to set a label on a container to trigger a test backup. Or perhaps repliqate.schedule=now Just to be able to confirm everything would work when scheduled.
WiggleWizard commented 2025-09-05 11:55:39 -04:00 (Migrated from github.com)

I think a great "first iteration" of this would be to simply just run all backup jobs on repliqate startup. I'll add this on as an optional config property

I think a great "first iteration" of this would be to simply just run all backup jobs on repliqate startup. I'll add this on as an optional config property
kareem613 commented 2025-09-05 12:35:53 -04:00 (Migrated from github.com)

I think a great "first iteration" of this would be to simply just run all backup jobs on repliqate startup. I'll add this on as an optional config property

In this scenario it would probably be handy if it immediately exited as well. Then testing is just a matter of starting it again. Nice quick iteration.

> I think a great "first iteration" of this would be to simply just run all backup jobs on repliqate startup. I'll add this on as an optional config property In this scenario it would probably be handy if it immediately exited as well. Then testing is just a matter of starting it again. Nice quick iteration.
bcurran3 commented 2025-12-08 02:19:17 -05:00 (Migrated from github.com)

I don't want repliqate to do backups on every container every time it restarts; even with a configurable flag to enable. I am very much against this implementation idea. This means EVERY TIME you reboot your server/vm and your waiting for everything to get going again... repliqate is going to run and start backing up everything and make you wait longer. It also means every time you update repliqate with a new image causing it to restart it's going to kick off all those backups. Please, no automated now option. It needs to be a purposeful and planned MANUAL do it now option. Current suggestions are random and very much chaotic. (No offense. The idea is wonderful, but the implementation just doesn't seem good as I don't think the consequences where thought-out. IMHO!)

I do see the advantage of doing kicking off a spontaneous backup on demand though. A better (controlled!) implementation would be to add parameters to the repliqate executable inside the container to support it; e.g. something like:
repliqate backup container_name --now

For now we could simply do docker exec repliqate repliqate backup container_name --now and have it kick off... and it would be easily scriptable.

It would be nice to see on the roadmap (Does one exist?) the addition of a simple web interface which would show all the running containers with a Backup Now button along with a plethora of other options. This Backup Now option would then simply call repliqate with the, then already baked in, above mentioned command to kick off the backup.

I personally don't foresee the need to force a backup on demand often considering I know it is/could be scheduled to do so soon enough, but the simple solution of the program supporting it through arguments/parameters is definitively a positive feature.

Then again, what do I know? I can't get it to work yet unless I rejig all my Ansible roles to mount the volumes a different way. :-( I'm REALLY rooting for https://github.com/lminlone/repliqate/issues/21 to get done!

I don't want repliqate to do backups on every container every time it restarts; even with a configurable flag to enable. I am very much against this implementation idea. This means EVERY TIME you reboot your server/vm and your waiting for everything to get going again... repliqate is going to run and start backing up everything and make you wait longer. It also means every time you update repliqate with a new image causing it to restart it's going to kick off all those backups. Please, no automated now option. It needs to be a purposeful and planned MANUAL do it now option. Current suggestions are random and very much chaotic. (No offense. The idea is wonderful, but the implementation just doesn't seem good as I don't think the consequences where thought-out. IMHO!) I do see the advantage of doing kicking off a spontaneous backup on demand though. A better (controlled!) implementation would be to add parameters to the repliqate executable inside the container to support it; e.g. something like: `repliqate backup container_name --now` For now we could simply do `docker exec repliqate repliqate backup container_name --now` and have it kick off... and it would be easily scriptable. It would be nice to see on the roadmap (Does one exist?) the addition of a simple web interface which would show all the running containers with a Backup Now button along with a plethora of other options. This Backup Now option would then simply call repliqate with the, then already baked in, above mentioned command to kick off the backup. I personally don't foresee the need to force a backup on demand often considering I know it is/could be scheduled to do so soon enough, but the simple solution of the program supporting it through arguments/parameters is definitively a positive feature. Then again, what do I know? I can't get it to work yet unless I rejig all my Ansible roles to mount the volumes a different way. :-( I'm REALLY rooting for https://github.com/lminlone/repliqate/issues/21 to get done!
WiggleWizard commented 2025-12-08 05:07:34 -05:00 (Migrated from github.com)

Hey, thanks for the passionate reply!

I agree with the sentiment. I do want to create a manual backup trigger option; ideally via the web interface, but as an interim it should be via a command. I've been working on and off a command solution that connects to repliqate via IPC, so I can add that to the commands list when it's done.

No roadmap as yet, but you can see the tickets I've opened myself to get an idea of what will be worked on next.

I've taken a small hiatus for professional reasons, and will be getting back on repliqate soon. Will tackle #21 likely first as it seems like a simple task

Hey, thanks for the passionate reply! I agree with the sentiment. I do want to create a manual backup trigger option; ideally via the web interface, but as an interim it should be via a command. I've been working on and off a command solution that connects to repliqate via IPC, so I can add that to the commands list when it's done. No roadmap as yet, but you can see the tickets I've opened myself to get an idea of what will be worked on next. I've taken a small hiatus for professional reasons, and will be getting back on repliqate soon. Will tackle #21 likely first as it seems like a simple task
bcurran3 commented 2025-12-08 16:36:10 -05:00 (Migrated from github.com)

Awesome! Thank you in advance.

Awesome! Thank you in advance.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
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
lminlone/repliqate#8
No description provided.