'It is backed up on the server' sounds responsible - until the server share corrupts the very file it was protecting. PSTs belong on a local disk, and Microsoft has said so for years.
Putting the PST on a network drive or NAS share is one of the most reasonable-sounding mistakes in small-office IT. One central copy, covered by the server backup - what could go wrong? Quite a lot, in a specific technical way, and Microsoft's own documentation has warned against network-stored PST and OST files for a long time. Here is why, and what to do instead that keeps the backup benefit without the corruption risk.
Microsoft's long-standing guidance (Knowledge Base article 297019) is that storing PST and OST files on network shares is not supported. Not 'discouraged for performance' - not supported, full stop. In practice it may run for months, which is what makes it dangerous: the first sign of trouble is usually the trouble itself, in the form of a file that will not open one Monday morning.
A PST is a database that Outlook holds open all day, writing small changes constantly and expecting disk-like, immediate, reliable answers. A network adds latency to every one of those writes and adds new failure modes - a dropped connection, a busy NAS, a server reboot - in the middle of them. A write interrupted halfway is precisely how database files corrupt. Add a second user opening the same file from another PC, which shares invite, and corruption stops being a risk and becomes a schedule.
Keep the live PST on the PC's local drive where Outlook expects it, and get the central-backup benefit a different way: a scheduled copy of the closed PST to the server (after Outlook exits, a plain file copy or your normal backup software), or mail kept on an Exchange / Microsoft 365 mailbox where the server is the store by design. The rule is short: the network may hold copies of the PST; it must not hold the working PST.
Do not just drag it while Outlook is open. Note the file's location, close Outlook fully, copy the file to the PC's local drive, then point Outlook at the local copy via File - Account Settings - Data Files, open it, verify mail and folders, and only then retire the network copy. Raising the limit only moves the wall. An oversized PST opens slower, searches slower and corrupts more easily, and the repair takes longer the bigger the file gets. The registry change is a bridge that buys you time - the real cure is archiving old mail out, compacting, and keeping every PST at a sensible size. A local file with headroom and a backup routine is the whole game.
With the file safely local, the video shows how to give it proper headroom with the one click limit fix.
Watch Full VideoRAID protects against a disk in the NAS failing. It does nothing against the actual PST-on-network problem: interrupted writes, latency and two PCs touching one open database file. It faithfully mirrors a corrupted file to every disk in the array.
No - same family of problem. Sync engines copy and lock the file while Outlook is writing it, and two machines syncing one PST will conflict and corrupt it. Microsoft's own guidance treats cloud-sync folders as unsuitable for live PST files too. Sync the closed backup copy if you like; never the live file.
That is genuinely common, and it is how the trap works - the failure is rare per day and catastrophic when it lands, and the odds accumulate with file size, users and network load. Moving the files local costs an afternoon; the alternative costs whatever was in the mailbox.