Script to backup data to specific USB Drive

Get-WmiObject has been superceded by Get-CimInstance since PowerShell 3 and removed since PowerShell 6, so you should avoid using it to ensure forward compatibility.

Use Get-ChildItem with the -File or -Directory parameters so you don't have to do all these PSIsContainer checks.

Consider using comment-based help to document your script. And please explain why you feel the need to wrap exit inside the function ex?

Be consistent in naming your variables: I recommend adopting the camelCase style for naming variables in PowerShell. Use more descriptive names for your variables: what does $FPBackup mean?

Avoid using Write-Host:

The use of Write-Host is greatly discouraged unless in the use of commands with the Show verb. The Show verb explicitly means 'show on the screen, with no other possibilities'.

[...]

Replace Write-Host with Write-Output or Write-Verbose depending on whether the intention is logging or returning one or more objects.

I find it easier to do the querying in PowerShell cmdlets than WQL. This has the added benefit of not needing to escape backslashes and quotation marks, and to quote the WQL documentation linked earlier:

When working with WMI, and especially with WQL, don't forget that you are also using Windows PowerShell. Often, if a WQL query doesn't work as expected, it's easier to use a standard Windows PowerShell command than to debug the WQL query.

Unless you are returning massive amounts of data from across bandwidth-constrained remote systems, it's rarely productive to spend hours trying to perfect a complicated WQL query when there is an acceptable PowerShell cmdlet that does the same thing.

So this block of code:

$diskdrive = Get-WmiObject win32_diskdrive

foreach($drive in $diskdrive){
  $partitions = Get-WmiObject -Query "ASSOCIATORS OF {Win32_DiskDrive.DeviceID=`"$($drive.DeviceID.replace('\','\\'))`"} WHERE AssocClass = Win32_DiskDriveToDiskPartition"

    foreach($part in $partitions){
        $name=$drive.model
        $vols = Get-WmiObject -Query "ASSOCIATORS OF {Win32_DiskPartition.DeviceID=`"$($part.DeviceID)`"} WHERE AssocClass = Win32_LogicalDiskToPartition"

    foreach($vol in $vols){
       If($name -eq "General UDisk USB Device" ){
       $USBDisk=$vol.name
       }
     }
  }
}

becomes easier to write and more readable when rewritten without WQL:

$USBDisk = Get-CimInstance Win32_DiskDrive `
    | Where-Object { $_.Model -eq "General UDisk USB Device" } `  
    | Get-CimAssociatedInstance -Association Win32_DiskDriveToDiskPartition `
    | Get-CimAssociatedInstance -Association Win32_LogicalDiskToPartition `
    | Select-Object -ExpandProperty Name

and similarly when using Windows Storage Management-specific cmdlets:

$USBDisk = Get-Disk `
    | Where-Object { $_.Model -eq "General UDisk USB Device" } `
    | Get-Partition `
    | Get-Volume `
    | Select-Object @{ Name="Name"; Expression={ $_.DriveLetter + ":" } }

though with the caveats that the Windows Storage Management APIs require Windows 8 and above, and Get-Disk does not return dynamic disks, which is a deprecated technology slated to be fully replaced by Storage Spaces. This blog post (translated into English from the original Japanese at https://8thway.blogspot.com/2014/04/wmi-ssd.html?m=0) compares the properties of the MSFT_Disk, MSFT_PhysicalDisk and Win32_DiskDrive WMI classes.

The way you check if there is enough free space on the backup drive to hold the files is flawed. Different filesystems and different allocation sizes, for example, would produce different outcomes, so this method of checking is bound to be imprecise.

About Robocopy: this tool is overrated, but I am still testing it and searching for alternatives. So far, I can list 9 negatives of using this tool:

1. It has a different, almost bizarre, syntax for syncing files than syncing folders.
2. It lacks unicode support. The /UNILOG: and /UNICODE options are a lie.
3. It seems to mistaken extended-length paths (those that begin with \\?\), and by extension the volume GUID paths, as UNC paths, so we have to access the volumes by their assigned drive letters.
4. In my tests so far with a full backup on an SMR HDD with UASP support and a flash drive, Robocopy only performed on par or slightly better than copying files through File Explorer or the PowerShell command Copy-Item most of the time, and that required a lot of testing and tweaking different flags for different file compositions. If you get the parameters wrong, it could be almost an order of magnitude slower than plain old copy.
5. It can do folder synchronization by using the /MIR option that only checks for a difference in file size or modified time, but can not do delta backups like rsync.
6. The progress feedback is very primitive.
7. Statistics are misleading and require getting used to.
8. The multithreading flag /MT messes up both normal output and the final statistics.
9. Unpredictable behaviors and bugs and vague documentation that is the result of many years of neglect by Microsoft.

Due to the many drawbacks of using Robocopy as listed above, I am really pondering whether I should just use Copy-Item or rsync in WSL, which share almost none of the problems, and call it a day.