Incomplete PBI Tasks and velocity

Recently, we had a failed Sprint because 2 PBI Tasks couldn't be completed in time

The Developers aren't there to complete a certain number of tasks in time. That would be a very poor commitment for them to make, since it would do little to bring complexity under control. It would be better to commit to a Sprint Goal which makes the selection of work coherent and which mitigates a significant risk or uncertainty.

Any work not completed in pursuit of the Sprint Goal ought to be re-estimated on the Product Backlog, since it must tell the truth at all times about how much work remains to be Done. That's it. The Product Owner can then decide how that work should be ordered and organized, assuming it remains useful to do it at all.

We are using Azure DevOps and working with "effort points" and velocity. Recently, we had a failed Sprint because 2 PBI Tasks couldn't be completed in time by developers. 

I don't think you had a failed Sprint. I think you have a failed understanding of what the Scrum framework describes as a Sprint.  In the teams I have worked with, there are often unfinished items in the Sprint Backlog. It is because they did not support the completion of the Sprint Goal so they were not prioritized.  They were returned to the Product Backlog and considered for future Sprints but not necessarily the next Sprint. 

The Scrum Guide states that the Sprint Goal is the commitment for the Developers in the Sprint. Not the completion of all the items pulled into the Sprint Backlog from the Product Backlog.  The Daily Scrum is the mechanism for evaluating the progress towards accomplishing the Sprint Goal.  If the Developers determine that the Sprint Goal is in danger during a Daily Scrum, conversations should be started with the Product Owner to determine how to adapt.  If none of this is occurring, then as Scrum Master, you should start the conversations about this in a Sprint Retrospective and start helping the team to adapt their ways. 

I once had a team that refused to use a Sprint Goal.  They wanted to commit to completing all the items they pulled into the Sprint Backlog.  So I let them do that.  After 6 Sprints, they had completed every item they pulled into the Sprint Backlog.  However, they had not delivered anything that the stakeholders found useful or valuable.  The stakeholders were refusing to use or sell the product because it was not adequate or on par with competitors. I resurfaced the Sprint Goal discussion and convinced the team to give it a 6 Sprint try.  At the end of those 6 Sprints, the attitude about the Product was completely changed. 

The Sprint Goal allows a team to understand why the Sprint is important. It helps them focus on delivering an increment that provides value and is useable. It might be useful for your team to have that kind of focus.

I appreciate your answers!

The Sprint Goal was to deliver a remote command menu, so certain devices can be monitored from an operator. In order to achieve this, the development team had to finish certain tasks in a weekly sprint. Due to unplanned outcomes during investigations, they had no time to finish those tasks. So, the Sprint Goal was not achieved. That's why the PO decided to mark the Sprint as failed. Because the development team failed to commit and reach the Goal.

Sprint Backlogs are unique artifacts. They only exist in the context of the Sprint in which they were created.

A Sprint Backlog ceases to exist at the end of the Sprint in which it was created.

Any unfinished PBIs go back to the Product Backlog or they could be abandoned and removed completely (should they no longer be worth pursuing).

A new Sprint Backlog is created by Developers during Sprint Planning. Until that time those unfinished PBIs are in the Product Backlog and should be treated like any other PBI in the backlog.

Discuss them, refine them, size them.

Don’t think of it as “re-estimating” or “re-sizing”. It is just estimating or sizing. What is so special about the first estimate that we would need to maintain it? It was just a guess. Nothing more than that. If our guess was wrong, we should make a new guess based on what we have learned. Inspect and Adapt.