What does "Restore this library" do in SharePoint?

It rolls the entire document library back to its state at a chosen moment in the last 30 days, using version history and the recycle bin. Every change made after that moment by anyone is undone (changed files revert, new files move to the recycle bin).

Can you restore previous versions of multiple files in SharePoint at once?

Not in the browser — version history is per file. In PowerShell you can loop over files matching a filter (modified by, modified after, path) and restore each one's last version before a date with Restore-PnPFileVersion. Rollback365 does the same with a dry run first.

How far back can you restore a SharePoint library?

Restore this library covers the last 30 days. Version history goes back as far as the versions exist (500 major versions by default, or the trimmed limit). Microsoft 365 Backup, if licensed, has its own restore points.

Why can't I see "Restore this library"?

You need to be a site owner or admin, and the library must have versioning on. It is under the library's Settings gear, not in Library settings.

'Restore this library' will undo everyone's work. How to roll back only the files that were actually damaged

Microsoft's library restore rolls back every file to a point in time and reaches only 30 days. When one user, one flow or one sync client damaged a subset, you want a targeted rollback. Here is both routes.

Someone's sync client, a Power Automate flow, a bulk-edit script or a piece of ransomware has just modified several hundred files in a library. Microsoft's answer is Restore this library: pick a moment, roll everything back. It works. It also rolls back the 40 files your colleagues legitimately edited since that moment, and moves every file created since then into the recycle bin.

For an incident that touched everything, that is the right tool. For an incident that touched a subset, it is the blunt one. This post covers both.

When Restore this library is right

Ransomware that encrypted the whole library.
A migration or sync run that rewrote everything.
You are inside 30 days and you can accept losing every change since the chosen moment.

Library → Settings gear → Restore this library. Pick a date, or drag the slider to the exact operation in the activity graph, and confirm. Files changed after that point revert to their earlier version; files created after it go to the recycle bin (recoverable); files deleted after it come back. It needs versioning on and site owner rights.

Two things it cannot do: reach further than 30 days, and restore some files without restoring all of them.

When it is wrong: the subset problem

The common shape is not "everything changed". It is:

one user's sync client rewrote 300 files in three folders at 09:12 on Monday,
a flow overwrote every PDF in one folder,
someone did a find-and-replace in Excel across a template library,

and meanwhile twenty other people kept working in the same library. Restoring the library to 09:11 on Monday throws their week away.

What you want is: for each file that user changed after that moment, restore the last version from before it, and leave everyone else's files alone.

The PowerShell route

Version history is per file, so this is a loop: find the files, find the right version, restore it.

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Finance -Interactive

$library = 'Shared Documents'
$who     = 'sync.user@contoso.com'
$after   = Get-Date '2026-07-13 09:00'      # the incident started here

Get-PnPListItem -List $library -PageSize 2000 -Fields FileRef,Modified,Editor |
  Where-Object { $_['Editor'].Email -eq $who -and $_['Modified'] -gt $after -and $_.FileSystemObjectType -eq 'File' } |
  ForEach-Object {
    $prev = Get-PnPFileVersion -Url $_['FileRef'] | Where-Object Created -lt $after | Sort-Object Created -Descending | Select-Object -First 1
    Restore-PnPFileVersion -Url $_['FileRef'] -Identity $prev.Id -Force
  }

Restoring creates a new version; nothing is deleted, so a wrong rollback is itself reversible.

What this does not do, and what you will hit on a real library: files with no prior version (created during the incident) make the restore call fail mid-loop; files checked out by someone else fail too; files someone already fixed by hand get rolled back again; and you have no list of what it is about to do until it has done it.

That is the 80% version. The checks that stop it restoring the wrong files — showing you the list first, skipping files it should not touch, and confirming afterwards — are the part we built the tool for.

Doing the dry run properly

The dangerous part of any rollback is not the restore. It is confidence in the list. Before touching anything you want to see: how many files match, which ones have no earlier version, which ones are checked out, and what the target version of each is. Then a typed confirmation, then the restores, then a verification pass that the current version is now the one you expected.

That workflow is what Rollback365 packages: filter by who changed it, when, where and what type; a dry run that classifies every file (restorable / no prior version / checked out / created after / already current); type RESTORE to run it. It restores named prior versions and removes nothing, so it is safe to run under the signed-in user's own permissions.

After the rollback

If the cause was a sync client, get that user off Sync and onto Add shortcut to OneDrive for the library.
If it was a flow, add a condition on Modified By or a folder scope before it runs again.
Keep the list of what was restored. It is the audit trail of what was changed and what was put back.