What you are doing here is not Scrum as Scrum is defined. Some of the deviations include multiple Scrum Masters and a lack of a Sprint Goal. This makes it difficult to give an answer in the context of Scrum.
Now, with that out of the way, you are asking four distinct questions, but they are all closely related:
- What is my Sprint Goal?
- How is my Sprint Goal related to my Sprint Backlog?
- Can we change the Sprint Backlog?
- Can we change the Sprint Goal?
Your Sprint Goal should be established at Sprint Planning. The purpose of the Sprint Goal is to give the Development Team focus to ensure that the outcome of the Sprint - the potentially releasable Done Increment - is something that is useful and valuable to the stakeholders. Throughout Sprint Planning, the goal helps to drive the selection of appropriate Product Backlog Items for the Sprint, with the past performance and forecast capacity helping to drive the number of Product Backlog Items. The goal is a negotiation between the Product Owner and the Development Team to make sure that it's something that everyone believes is achievable. At the end of the Sprint Planning, the Development Team needs to be able to commit to the Sprint Goal.
The Sprint Backlog is the selection of Product Backlog Items for the Sprint as well as a plan for getting them to Done. Scrum doesn't say what this plan looks like, but some teams decompose the Product Backlog Items into subtasks and that becomes the plan. Other teams may produce their plan in different formats. The purpose of planning is to simply give confidence that the team is able to achieve the Sprint Goal and to promote visibility into that progress as the Sprint progresses, up until the Sprint Review where the progress is one of the things reviewed.
The Sprint Backlog is entirely owned by the Development Team. They can change it as they see fit. The existence of the Sprint Backlog is to make the selected work and progress visible to stakeholders. Unless your Development Team spends a whole lot of time planning (which I would not encourage), I would expect the Sprint Backlog to change as other Product Backlog Items are decomposed and the team learns the fine details about what is or is not necessary to get everything to Done.
In traditional, single-team Scrum, I would expect that the Sprint Goal would be fixed. Scrum does allow for the termination of a Sprint, but calls this a "traumatic" event and is not frequent. If your Sprint Goal is regularly becoming outdated or irrelevant, that may be the sign of deeper issues around either your Sprint cadence or the Scrum Team's understanding of what is valuable to the users and other stakeholders. In scaled Scrum, terminating a Sprint early is more difficult since there may be dependencies across teams in order to progress work, so I would expect an outdated Sprint Goal to be handled differently.