mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 23:15:57 +03:00
[GH-ISSUE #1056] Cron-based backup of TRMM with backup rotation. #2592
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#2592
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fts-tmassey on GitHub (Apr 8, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1056
I created a very straightforward Bash script to generate TRMM backups via cron, as well as only keep a maximum number of backups. There's nothing very clever in this, but if I can save a few minutes for each new installation, then great.
https://github.com/fts-tmassey/tacticalrmm-cronbackup
@fts-tmassey commented on GitHub (Apr 8, 2022):
Closing issue.
@dinger1986 commented on GitHub (Apr 8, 2022):
thanks, maybe a write up on how to implement it or a basic install script would be helpful?
@fts-tmassey commented on GitHub (Apr 8, 2022):
I went ahead and expanded the installation/configuration information in the readme: https://github.com/fts-tmassey/tacticalrmm-cronbackup/blob/main/README.md
It's literally a single file, and it needs to be updated based on what user and path the admin used to install TRMM. Given that TRMM doesn't specify that information, it could be anything. Seeing as building a script to collect and manage that information properly would be longer than the script itself... I'm going to leave it with manual installation.
Besides, if you can install and administer an RMM system that is actively under construction, I really hope you can handle copying a single file and updating a couple of variables... :) But I did expand on the necessary details, with suggested actions: if you follow the doc, you should get a working process.
@dinger1986 commented on GitHub (Apr 8, 2022):
Thanks!
Agreed but some wont know how to use it, if it was integrated into a script it would pull all the info, I can always look at that.
Lol you would think everyone running these servers could it, scary sometimes!
@fts-tmassey commented on GitHub (Apr 8, 2022):
I just updated my readme to also include how to get the backup.sh script in the first place. In doing so, I put in a link to the TRMM backup doc, and noticed that the included wget (to get the script) points at the old repo. You will likely want to update that for the new repo name. (That's gonna be a lot of ongoing cleanup fun for the team...)
@dinger1986 commented on GitHub (Apr 8, 2022):
wget looks right to me, says amidaware?
@dinger1986 commented on GitHub (Apr 8, 2022):
@fts-tmassey commented on GitHub (Apr 8, 2022):
Not in the doc: https://amidaware.github.io/tacticalrmm/backup/
@dinger1986 commented on GitHub (Apr 8, 2022):
eh ok, were using https://docs.tacticalrmm.com/, wonder wtf the other one is! We will get it sorted
@fts-tmassey commented on GitHub (Apr 8, 2022):
Ahh, the sin of multiple copies... :) I've updated the readme to point to the docs URL instead.
@dinger1986 commented on GitHub (Apr 8, 2022):
yeah need to sort that out! Thanks for pointing it out
@silversword411 commented on GitHub (Apr 8, 2022):
Looks awesome to me! :)
github.com/amidaware/trmm-awesome@a806d77fd4@fts-tmassey commented on GitHub (Apr 8, 2022):
While rooting around for something else, I found that there's a backup.sh in the /rmm directory. Is this now officially part of the install? If so, two things:
Thanks for the info!
@dinger1986 commented on GitHub (Apr 8, 2022):
I'm sure it gets downloaded as the install script grabs the git repo, maybe even updates do as well?
@fts-tmassey commented on GitHub (Apr 8, 2022):
I'm not worried about updates: the backup.sh script takes care of itself. I'm worried about why the doc says to manually download the script, when it's already in /rmm. If its presence in /rmm is an accident, the doc makes sense, and I need to ask the user to do a few extra steps. But if the presence of the script is both intentional and supported, I can remove all that stuff from the process of setting up the script. And if that's the case, the doc should be updated to remove that extraneous stuff, too.
In other words: do the developers "bless" the presence of backup.sh in /rmm?
It makes all the sense in the world for it to be there and to stay there. All I need is someone to tell me that the developers agree with that - and if that's the case, it would be wise to update the doc to reflect this as well.
@dinger1986 commented on GitHub (Apr 8, 2022):
I guess all that's needed is comparing backup.sh with the current one in the repo and see if they are the same.
I'll check mine and confirm, saves the devs time unless they get back before then lol.
@fts-tmassey commented on GitHub (Apr 8, 2022):
Again, the problem is not is the script there or is it right. It is there, and it is right. The question is: is it supported? Only the devs can answer that. And why am I asking? Because that directly conflicts with the documentation. If the doc agreed, I wouldn't be asking right now -- but I wouldn't have done it the "wrong" way, either.
I'm not asking for a technical answer: I know it will work today. But is it supported?
And if it is: I suggest updating the doc to avoid this argument in the future! :)
@silversword411 commented on GitHub (Apr 8, 2022):
It says that....because.
So actually the entire /tacticalrmm repo is there as of your last git sync...and update.sh checks to make sure he's updated in case of user craziness...but depending on last git sync as part of update.sh, or something else docs officially just make you explicitly get the right...and latest when doing stuff. I've considered changing docs to use the git managed stuff, but I think there's an occasional problem depending on time/mars alignment/which foot you're standing on at the moment so #BetterSafeThanSorry
@dinger1986 commented on GitHub (Apr 8, 2022):
Yeah so checked (with Wh1te) and it is meant to be there and updates with every update.sh.
In theory when setting up backups you want to check you have the newest backup script it's good practice hence the docs being different.
So docs will stay the same but feel free to point to that one. (Need to chmod +x it)
From a supported point of view it will be there and keep updating so best pointing to that one if its automated with cron really.
@fts-tmassey commented on GitHub (Apr 11, 2022):
Good enough. Thank you for the information.
For the record, backup.sh (and restore.sh, which I've never touched) are both +x on my install. I kept the +x in my instructions, but it seems it's unnecessary (and if you're gonna make the script an official part of the install, the install should absolutely be responsible for that... but whatever).
I also updated the script to use the owner of backup.sh to run it. So with those two changes, there's no no need for the user to modify the script by default, which is great,
Unless anyone has any suggestions, I'm considering this complete for the moment. Like I said in the readme, I'm too lazy right now to go digging around and figure out how to do the Audit Log and Pending Actions Prune DB Tables action from the command line, but the TRMM doc suggests this should be done periodically and it would be nice to automate. At this time, that's the only thing I'm aware of that might benefit by stuffing into a cron script.
But I'm still way at the beginning of learning about TRMM... :)