Acceptable amount of bugs in backlog

@Damian Copello, Would you consider a product with bugs releasable to the customer? How would that impact the value delivered?

I'm currently cleaning up the backlog for my project which consists on reviewing old bugs and deleting them if they don't occur anymore, or assigning them to a dev if they do.

Is this a Scrum question?   Why are you "assigning" anything to a Development Team member?

I'm currently cleaning up the backlog for my project which consists on reviewing old bugs and deleting them if they don't occur anymore, or assigning them to a dev if they do.

To echo Timothy Baffa, this doesn't sound like Scrum. Bugs should be just like any other Product Backlog Item - refined, estimated, and ordered based on how your team does these things. Work should not be assigned, but the Development Team should be pulling work into a Sprint based on historical performance, forecasting their future capacity, and the goals crafted in collaboration with the Product Owner.

This is something that will take me several weeks as we have a pretty huge backlog and I'm requested to write a report every week with, among other things, the current amount of ToDo bugs we have.

Why do you need to write a report? One of the central pillars of Scrum is transparency. Stakeholders should have visibility into the Product Backlog. By viewing the Product Backlog, they would be able to see the bugs that known and where they sit in relation to other known work that's in front of the Development Team. If you're using an electronic tool for your Product Backlog, it should be extremely easy to create reporting that falls out of the tool.

My problem is that every week new bugs enter the backlog so the amount doesn't really reflect the actual progress we are making.

It's somewhat concerning that you are introducing or finding new bugs more frequently than you can review bugs already logged. This is something that I'd look into - why are these bugs being introduced? Are they bugs because the desired behavior of the system doesn't align with what's delivered? Are you missing issues in testing before calling new work "done"? These are things that may be good to discuss at a Sprint Retrospective.

Is there an amount (%) of bugs that is considered acceptable or considered a "healthy" backlog? Or any way to measure how many bugs is thought as OK as I will never get to a Zero-bugs scenario.

There's no measure here.

In a perfect world, you'd have no bugs. You would fully understand the needs of your users and then deliver software that satisfies them. Any errors introduced would be caught between refining a Product Backlog Item and calling that Product Backlog Item and the Increment it is part of "done".

But our world isn't perfect. I tend to favor ensuring that all known issues are represented in the Product Backlog and these are reviewed on a regular basis to ensure that they are still valid given the changes in the system. I favor electronic backlog management tools, so it's easy to generate reports, metadata, and traceability around bug reports. Having the known issues is also useful if it was necessary to generate reports of known issues for clients or users. Your processes should minimize the number of new bugs introduced, strive for fixing as many bugs as possible (ideally all of them) in-process and reaching the end of each Sprint with no new added known issues.

My problem is that every week new bugs enter the backlog

The first course of action is to stop rework from accumulating. From your understanding of Scrum, what is the most important thing a team ought to do in this regard?