I will try to address the general concepts then, in the conclusion, address things more specific to your situation. Let me start by saying, Scrum is very flexible; however, the parts the must be there, must be there. So, some of these ideas are not part of the Scrum framework as described by the Scrum guide.
Tests Exist - Bugs Still Get Released
If you have automated testing, and the assumed continuous integration processes, in place, but bugs are still getting into releases, it seems like either the tests are incomplete (testing only the happy path) or hey are simply testing the wrong things. Try to account for more time per ticket item (not sure if you are using stories, epics, etc.); whether you are using story points or time doesn't really matter, try to increase either or both to afford your team the opportunity to create more robust/proper tests.
You may also consider examining the test writing process itself.
Diversity of Knowledge & Two Teams
The Scrum has a general recommendation of 3-to-9 people (6 +/-3), to ensure a certain diversity of knowledge and background among team members. Those with testing backgrounds, those with back-end backgrounds, marketing, design, etc. If you can bring on more people to facilitate the creation of two teams, you may consider something described in the book, Leading Lean Software Development by the Poppendiecks; the team becoming support.
The basic principle here is Team A works on a bunch of new functionality. For Scrum, the Product Owner accepts the deliverable during the Sprint Review. Team A now becomes support for the release, taking all the calls, updating all the materials, and fixing defects. Meanwhile Team B, during the same period, is continuously integrating the work of Team A into the work they are doing on new features. Now, if there are too many bugs for Team A to handle alone, then the PO may want to abandon the sprint for Team B so they can join Team A in correcting defects (this is a serious sign there is something wrong in the testing and/or review process).
The Fast Track, Level of Commitment, and Nice-to-Haves
When bugs come in, this an interruption to new feature development; however, it does happen. Take a look at the history of your sprints, how much time was spent dealing with defect interruptions (correcting technical debt)? Then, during the next sprint planning meeting, try to account for this in your estimates. Basically, determine the level of commitment the team is willing to take on for the sprint. While we would like to say 100% all the time, reality does not really concern itself with what we want. So, if 50% of the team's time in the last couple of sprints has been spent on overcoming technical debt, don't take on so much in the following sprint; instead, maybe take a different approach to the sprint planning meeting.
First, let everyone know that the team thinks they are capable of dedicating 50% of their time to new functionality; just in case. But, what you would like to do is create a first pass sprint backlog assuming 100% dedication is possible. Then, you, the team, and the PO can determine which, among those items is absolutely, positively, bar-none gonna be done in this sprint - based on a 50% commitment.
By doing it this way, you allow for what is commonly referred to as a fast track. Basically, a defect is reported. All work stops on the other tickets until the bug is fixed - it "fast tracks" passed all the other work (but you should still write tests for it to try to curtail regression). Now, since we know which items don't necessarily need to be done by the end of the sprint - those marked as nice-to-have - as long as the team doesn't get bombarded by defects over the 50% time they truly committed to - the PO shouldn't have to abandon the sprint.
Eventually, you should be able to overcome the technical debts currently in the system and, hopefully, reduce the amount of technical debt in the system; thereby, increasing the level of commitment the team is comfortable taking on per sprint.
In conclusion, if your automated tests aren't covering the defects making into the wild - the process of their creation and what exactly they are covering should probably be reviewed. Given your team size is 7, to maintain a diversity of knowledge, you probably shouldn't split the teams. The "buffer" is a good idea; however, should not be allowed to become a crutch - the team shouldn't be spending a lot of time fixing bugs, because the technical debt shouldn't be getting out there - try to figure out why it is happening. The last thing I will mention, and this is something you should consider honestly, is does your team take on too much in a sprint for 7 days? It is not meant to be a criticism of the capabilities of the team; however, given the continuous improvement nature of Scrum, maybe the definition of done has increased in its sophistication while your complexity estimates have not adjust to accommodate, for example.
Hope that helps, and answers the question. If you would like clarification or expansion on any of the ideas, please feel free to comment.