I have never been in a team where ‘losing’ the bugs was not an issue. I typically have a suggestion which may seem extreme, and I have never been able to test it (but I know people who have).
It goes a little something like this: Either fix logged bugs now or report them as “won’t fix”. That means (essentially) that all of your 222 ‘lost’ bugs should be marked as won’t fix.
If the project can live with the bugs, then the fix isn’t necessary. That is, it takes more effort to fix it than it is worth. If the fix adds value, then it will be fixed immediately.
There is another possible option with new bugs (the 222 should still be tossed to the side). That is, assign them to a specific sprint/project/time-frame immediately so the team knows that there is a fix planned, but not right away.
This attitude comes from my first official testing job where my product manager would routinely give me a list of hundreds of issues (mostly from before my time) and ask me for a progress report on them. I would spend days, sometimes weeks, re-testing these issues to find that out of those hundreds, maybe one might still be a problem. The rest were either fixed under-the-radar, accidently fixed when someone refactored the code for another feature, so minor or rare that they didn’t remove value from the project as a whole, Not a correct issue (testing error), and so on.
So the PM spent hours (or sometimes days) looking through dead-issues. The test team spent days (sometimes weeks) filtering the dead issues. The programmers spent hours answering the test team’s questions about their recollection of the issues.
And no value was added.