Failed sprint - every single time

Would you describe product ownership as being effective? Does the Product Owner help the team to agree clear and valuable Sprint Goals which make the selection of work coherent?

Your post seems full of excuses for bad behavior.  Your #2 brings to mind bad refinement practices, external dependencies that are not identifed, siloed knowledge on the Development Team. Someone getting sick should not prevent a cross-functional self-organizing team from adapting their workload to pick up work from their teammate.  Meetings not occurring is an excuse for not gathering the necessary information ahead of work starting or some kind of gating sign-off.  Both are refinement activities that seem to be incomplete. 

We always plan the "leftover" SP into the next sprint, so that the people should be able to finish everything, but nothing seems to work. And everything is always super important and cannot be moved to way later. 

This takes me to @Ian Mitchell's questions. If everything is always super important then your Product Owner should be ordering the items so that Development Team's efforts are focused on the items that provide the most value in a timely manner.  Limiting the Work in Progress will enable the team to focus on specific items and complete those before starting more work. 

That statement also points to bad refinement practices.  If the items are taking longer than a Sprint, there are probably activities you can do to discover more informaiton and break the work into increments that can be completed in a single Sprint.  For example, deliver a working portion of the feature instead of the complete feature. 

A suggestion for you to gain some control. If you have a Sprint with incomplete work your Retrospective should focus entirely on why those items were not completed.  Plan your next Sprint with those items and get agreement from all of the Scrum Team that no work will begin on new items until the in progress work is completed.  If that Sprint still results in those items being incomplete, the Retrospective again focuses on why.  Then plan your next Sprint with nothing but the incomplete items in it.  That way there is nothing to move focus from completing them.  Do this until those items are completed with Retrospectives each time on why they are still not done. The learnings from the Retrospectives will be used to improve your refinement activities, backlog ordering and Development practices. 

every single sprint is failed and we have tons of tickets, that are not ready, which are moved to the next sprint.

————Need to thoroughly discover and summarize the reasons on the restrospective, And implement improvements to the next sptint

1. the team is to big. I would split this in 2 teams. There would then be just one product backlog but 2 sprint backlogs, is that correct? 

————There is only one Peoduct backlog, and whether the Sprint backlog is shared by each team or a separate one depends on the team’s own decision;

If most Sprint backlog Item has high dependency, it is recommended to share a Sprint backlog;

Regardless of the format, during the process from Peoduct backlog to Sprint backlog, it is the responsibility of the PO to allow everyone on the team to reach a clear and consistent understanding of the PBI.

2. there are always problems with the tickets: somone got sick, the necessary meetings could not be held, as the other person was not available, etc. And all is plausible and I could not have changed this.

We always plan the "leftover" SP into the next sprint, so that the people should be able to finish everything, but nothing seems to work. And everything is always super important and cannot be moved to way later. 

————The team needs to fully consider whether the goal can be DoD during Sprint planning. Once committed and moved into Sprintbacklog, it will be completed. If someone falls ill temporarily, the other members of the team will work hard to complete.

How could we start from a clean slate so that this will not happen in the future, as I think, if we continue like this, nothing will change.

————In the restrospective meeting, let the team members self-retrospective, and then more thoroughly

What are your sprint goals? Moving all Sprint Backlog Items to Done should not be a goal, but a byproduct. If the PO can craft a real sprint goal with the team, that should help the team and PO get focus on what is "realy" important. Next to that, it will also be a good indicator if any leftover over should indeed be in the  next sprint or if des not contribute to the goal of that sprint 

Also make transparent that the team is responsible for getting things done. So any, even plausable, reason things are not moving forward does not remove this responsibility for the team.

thank you for your support! This helped a lot!