Skip to main content
Question

Synthetic Full failures after migration

  • June 8, 2026
  • 2 replies
  • 16 views

Forum|alt.badge.img+1

We recently migrated our Commserve to a new physical server and now several weeks post migration we are getting errors on about 90% of our synthetic fulls when they reach the end of the job, they will continously run at 99% but looking at the synth full logs we see alot of this:

30236 5280 06/05 12:34:18 13071395 SdtDecryption::ProcessBuffer:218 Cannot decrypt data for afid [28434509]. cur_afid [28725857], orig_afid [28434509]
30236 574c 06/05 12:34:18 13071395 SdtDecryption::ProcessBuffer:218 Cannot decrypt data for afid [28434509]. cur_afid [28725857], orig_afid [28434509]

 

The event viewer gives the generic Unable to communicate with Media Agent or Pipeline error. Opened a high priority ticket about a month ago and we’re being told we need to seal every DDB store in our environment and re-base. We have several thousands of VMs with some over 60TB in size. I feel like re-basing is going to take weeks, and we may not even have enough storage to do it.

 

Any other thoughts or ideas would be VERY much appreciated. We had to re-install the software a few times on the new box - They suspect that somehow when the CSDB was moved from the old physical hardware to the new that somehow jobs were written in-between this time that are causing issues but we were very careful during the migration, I selected new DB and used the CSDB Recovery tool after with someone from support on the line the whole time and making sure the services on the old hardware were never started at the same time.

The only other issue we had was the Replace Media Agent tool failed on some mount paths, but I assume we’d be looking at different issues in the logs.

2 replies

Scott Moseman
Vaulter
Forum|alt.badge.img+23

If there’s corrupt or unavailable blocks, you absolutely want to seal the DDB and get a new baseline going immediately. If your Synth Fulls cannot complete you can assume you cannot restore either.  Your existing jobs are at risk until you get new jobs completed writing new blocks.

I imagine you could run a full Data Verification and have the jobs marked bad which have corrupt or missing blocks, but that will take a fair amount of time and if there’s enough data missing it won't be much different from sealing and starting over.

Thanks,
Scott
 


Forum|alt.badge.img+1
  • Author
  • Novice
  • June 10, 2026

Thank you for the reply Scott,

I was afraid of that as well but so far restores seem to be okay from the incrementals, who knows for how long though. We definitely don’t have the storage to re-base so tomorrow I’m going to aux copy everything from our storage array to our old hardware (spinning disk), hopefully make enough room temporarily, and seal everything. The tough part is coming up with an estimate of how long we’ll be down during the re-base, we’re local government so even one day is a huge deal. I've calculated roughly 500 TB for the current baseline on all DDBs.