Offline
Ah, I found my own solution after a little digging.
A little background. My XO install was built from sources on Debian Bullseye.
Looking through the logs on XO when I attempted a file restore on a Windows machine I see these entries:
After googling that, I ran across this thread, which had the solution:
Windows file restores are working fine now.
Rocky, rest easy. Your post did help someone in the future. 
olivierlambert I tried restarting the toolstack, but it never came back. I killed all the cron processes, leaving hundreds of the associated dead "sadc" processes .
Not wanting to end up breaking something with the big hammer, I ended up simply having to reboot. That box runs my main workstation and my firewall for the house, so the natives were getting restless. Everything came back up just fine.
Not sure what happened there. The first indication that something was wrong was that the Marvell RAID software I installed for my cheap RAID controller (as seen in this thread) had spawned hundreds of apache processes.
At this point, I'm going to chalk it up to the box simply running out of RAM, and guessing that it was that RAID card software.
I appreciate you guys being available in-person in the support forums for freeloaders like me.
Hmm. Also hundreds of /usr/sbin/CROND processes running "/usr/lib64/sa/sadc -F _L -S DISK 1 1 -".
Something is up with this box.
Hi there!
I have an issue with my homelab 8.2.1 host. This is a very modest machine; an i7-3770k with 32G of RAM, 4T of RAID10 and a 128G RAID1 boot disk.
My machine occasionally (perhaps every 3-4 months) will go crazy with hundreds of spawned /opt/xensource/bin/xapi processes. They have chewed up all the RAM on dom0. The box is crawling because it's in swap now.
Is there a way to safely restart the xapi processes without a full host reboot?
(And I have a confession to make: because I have so little RAM...32G is the max for this chipset...I have tweaked the RAM on dom0 down to 1.5G. Again, home lab....not production.)
TheNorthernLight I doubt it's necessary. My XO is built entirely from source. It's probably just missing a dependency in the image I downloaded.
(From here, in case anyone is curious: https://github.com/ronivay/XenOrchestraInstallerUpdater)
Thanks!
Ah, I found my own solution after a little digging.
A little background. My XO install was built from sources on Debian Bullseye.
Looking through the logs on XO when I attempted a file restore on a Windows machine I see these entries:
After googling that, I ran across this thread, which had the solution:
Windows file restores are working fine now.
Rocky, rest easy. Your post did help someone in the future.
I'm having an issue with file restores on Windows guest backups. On Linux guests, I can drill down to individual folders and files for my selection, but on my Windows Server 2019 guest I can't. The dialog looks like this:
I am curious what the red triangle icon means in the screenshot; I don't see this on the Linux guests. I can't find any documentation on it.
I do get a warning on the file restore screen saying "Only the files of a Delta Backup which are not on an SMB remote can be restored". I am using an SMB remote. However, the Linux guests seem to restore just fine.
Any help appreciated!
XCP-NG 8.2
xo-server 5.86.3
xo-web 5.91.2
(XO compiled from sources at commit 422a2)