NDMP snapshots are not getting deleted after retention expire,   Currently there is no business impact but there could be potential impact if this issue not addressed on priority ... View more

I have 50 SnapCenter agents deployed and am planning an upgrade from version 5 to 6. Version 6 is not compatible with three critical servers that are our last Server 2008R2 boxes [yes we are working on migrating them :)]. For those boxes only, I would at least like to upgrade to 5.0P1. Is there an easy way to do that without upgrading the entire environment to 5.0P1 and then upgrading to 6.0? I'd rather just push the patch out to the three servers rather than upgrade everything. Any suggestions on the most efficient way to do this? ... View more

Hello I've upgraded SnapCenter from version 5.0 to 6.0 and since upgrade ALL jobs are failing with below error: Error: The proxy tunnel request to proxy 'http://x.x.x.x:3128/' failed with status code '403'."   The fun fact is that I've never used proxy for SnapCenter and I've even noticed that I have the same proxy error for migrating SnapCenter  repository backup schedule which is local on SnapCenter host: I've tried to search where could the proxy settings be configured - in the appsettings.json  there is nothing - I only found this: "ProxyTo": ""   Does anyone knows where the proxy settings could be located? And why they changed after upgrade? ... View more

What is the impact of using the "-nodata" option when running an "isync"?   For example, we had a partial copy of source data on a destination NetApp volume (a previously failed XCP copy due to stability issues on the source non-NetApp storage box. We had to use a different source box so couldn't reuse the previous copy catalog ID). We needed to establish a new catalog of the current state along with resuming the copy operation, so we opted to use isync rather than deleting all destination data and starting a fresh copy. (we're talking 250Tb over a 1Gb network link... ancient hardware with no option to improve the speed)   Due to the slow 1Gb link, iSync was taking a long time because XCP was reading in all data over the 1Gb link from the source so it could do a byte-for-byte check. Things drastically improved when we used the -nodata option, but what impact could using this have on the isync process besides being faster? What are we loosing out on?   The source data is live so changes can occur during each XCP run. Once the isync finishes I plan to use "sync" with the new catalog ID. Would this be ok?    Why does sync not have a -nodata option compared to isync? How does a sync check if a source file has changed without reading the whole file into the XCP server to do a byte-for-byte comparison?    Thanks in advance, Paul. ... View more