I think you are referring to extended mode which has a couple scenarios. Partition extended mode: In this mode the MediaAgents host partitions from multiple storage pools (up to 20 storage pools per grid). Each storage pool can be configured with 1, 2, 4, or 6 partitions.You can use the partition extended mode in the following scenarios:When you want the primary copy of the data on the disk and the secondary copy on the cloud. In this case, create 1 disk storage pool and 1 cloud storage pool using the same MediaAgents. In case of multi-tenancy, where the total back-end size of multiple tenants together is within the limit of the grid. In this case, to segregate data for each tenant you can configure the partition in extended mode by creating a separate storage pool for each tenant using the same MediaAgents.In the past extended mode had a 3rd use case - where we’d separate out short and long term retention. Before the garbage collection DDB enhancements, mixed retention could reduce sc
Hi Pirx,We had guidance around randomizing the folder names to achieve better performance many years ago - then enhancements in AWS and Commvault meant that it wasn't required and we removed that guidance, explicitly so in the architecture guide.I have not come across customers hitting an API rate limit like this before. That being said, you can add multiple mount paths to a cloud library which will give you exactly what AWS is suggesting - each mount path can have a different base folder name which will then split requests across both.It might not help immediately as all your data is under that one path - but it could help eventually moving forward. But as mentioned, I have not seen an AWS S3 request rate limit hit like this before - so I suspect there may be something else going on to be causing this.
Hi @SHASHA,This is a strong focus area for Commvault - there are elements of the product that speak to AI OPS already, but a very healthy roadmap exists. Today, we have anomaly reporting which uses ML to detect when things are out of the ordinary and report that back to the admin to take action - “Manage by exception”. There is also desired state SLA’s baked into plans that optimizes backup scheduling using ML to ensure jobs are run in the right order to ensure it meets the desired state SLA.So there are in-roads, but as I mentioned, there is a very healthy roadmap which addresses much more powerful capabilities in this space…Let me know if there is anything specific you are looking for, or specific capabilities your organization is interested in.
https://kb.commvault.com/article/81342 👈 👍
if i mark job as bad on all copies will it mark its unique blocks bad also for future jobs? Unfortunately that wont do it - all it does is prevent it from being copied - besides, there might be other jobs relying on one or more of the blocks associated with this job that are good - you don't want to mark those bad. The best way is the one I mentioned, its exhaustive but it literally checks each block to make sure its good, and if not, it immediately stops de-duplicating against it to protect future jobs.
I see a lot of support cases relating to HPUX and this error that were fixed with: “Name resolution for localhost has been corrected“ Can you check that localhost name resolution and ensure it looks right?
Hey @Comtech Yes absolutely, single CommServe is the way to go - and yes you can auxiliary copy from one to another. Just need to figure out the networking and set the right networking topology.
You might want to perform a data verification. Please also check this KB, as it could also be the cause: https://ma.commvault.com/Article/Details/80349
Hi @Tomer A,You should use a DDB verify operation (with option #2) to find and mark the bad blocks as bad, and then you can initiate a recopy operation. You want to do this as future auxcopies are likely to be unrestorable if they reference bad blocks - its not good enough to simply re-copy a job alone as it assumes the blocks are good and does not replace them. If you suspect there are bad blocks on the primary copy you should verify that first
Can you double check that the file system agent is installed on the CommServe? this is required for copy software to function correctly. It is usually installed by default but may have been skipped if there was some other issue.
@Nutan Pawar G Thanks for the response. Please confirm as its not mentioned on documentation. The Commserve DR backup from SQL server 2012 can be used to restore to SQL server 2019? Thanks, Aravind Hey @Aravind To answer your question directly, yes you can restore a DR backup taken on SQL 2012 into SQL 2019 no problem. There are a few articles that can help you explain the process of migrating to a new SQL version using a hardware refresh / reinstall. How do you upgrade to a supported SQL release for the CommServe?Most SQL 2012 installations are legacy installs left over from V10 to V11 upgrades. SQL 2012 included with V10 was enterprise edition, whereas V11 shifted to standard edition. Unfortunately, there is no upgrade path that can change SQL editions, and so a hardware refresh or reinstall of the Commvault software is required to install a more up to date version of SQL server. The process is fully outlined in this documentation page, or watch the video which also explain
Awesome - with that out of the way we can try tackle the copy issue.I found a lot of previous cases with this error - it seems like the vast majority are related to an issue that causes this error to show - but it is purely cosmetic and does not affect the copy operating. Meaning, the Job copies just fine, but this error shows up erroneously. There is a pending fix for that slated to release in FR11.34.So I wanted to double check - does the job keep progressing or does it enter a pending state?
Hey @FeRox,Can please run a data verification just to ensure the data is good and help validate that perhaps the issue is with the copy and not the read? Also you might want to peak into HPWCatalyst.txt on the Media Agent, it may have more information regarding the errors return from the catalyst. By the way, I love your post 😍
The software does not automatically convert to a full backup upon indexing failure - there are scenarios where it will automatically will, but not this one. Is it possible to allow the Media Agents and Virtual Server Agents in both DC’s to communicate with each other freely?This way the index for the previous backups can flow between. If not, there is likely a setting that allows conversion to full upon this type of indexing failure - but you’d have to open a support case and check with them and see if there is another workaround. @wgrande may have an opinion on this
I think there is a log that shows the XML that is executed when the action is performed manually, however I cannot remember the log that was monitored in the past. webserver.log or qsdk.log generally. Sometimes you can increase the debug to get more verbose outputs.
Hi @Fauzi Japri It is configurable in the CommCell console - docs You can perform a remote install - just have to ensure the required ports are open. Installing from setup executable may work too, but remote install is usually how.
Hi @Michal Antos -The restore part of the workflow probably needs to be replaced with a qcommand and virtual server XML - you can get the XML by running a restore and then using “save as script” and put it into the workflow.
The typical recovery from your original scenario would be to restore a CommServe database from prior to the deletion of the jobs. If the jobs are gone from the CommServe database they are unrecoverable unless its on tape (which allows for a re-import process called catalog and merge).
My logic around sealing these legacy stores, was that it could further minimize any related DDB activity. Sounds good. Sealed stores are still referenced for data aging but will never be used for other purposes. Of course if jobs never meet retention then no data aging will happen anyway 👌
My bad, it was the backup set that was changed. That explains the retention settings being as they were Ah no worries. Glad you figured it out!
But in all seriousness, I think @MFasulo nailed it. There will be specific business requirements that may dictate which OS you roll with - but if given unlimited choice, you want to pick the one you can most confidently manage.
DDB is needed for data aging - but since its infinite retention I’d do what @Emils mentioned and move it to a low spec Media Agent for archival. Technically if you plan to never backup to the associated storage policies or auxcopy, we could figure out a way to remove it. Indeed we have DDB backups so it is technically archived anyway. However that is a little messy, so if you can find a place to preserve it that would be a better idea.
I’m going to go on a limb here and say - maybe that is not such a good idea. My own personal opinion 😍, but VTL is a very legacy technology and brings no benefits to Commvault. Many of our competitors require a deduplication appliance since they don’t have built-in deduplication capabilities - but not so for us.Since its VTL it should expose an emulated tape interface - so there is something you need to do to ensure your Media Agent can see the drives. I’m not sure how these work but there many be installable software that connects a tape driver to the appliance. If you want to use it as an NFS (disk) target, you should mount the NFS share to your Media Agent (assuming its linux) and then use the local path on your Media Agent. Not sure if the appliance supports SMB shares for windows - but if that is the route you are going then try access the share from the windows machine first to ensure its working before putting the path and credentials into Command Center.
Hi @Kiwi_Dave,This is a strange one to me, I have a bunch of questions to try figure this out 😁. Where are you seeing the extended retention being applied? in the estimated age date or some other place? Does it specifically say extended retention?Do you know if you are using V1 or V2 indexing (VM centric)Also, how are the VMs shifting between subclients, is this because of discovery or is there somebody manually doing it? One VM per subclient or multiple VMs in each subclient?
Hey @Mauro This sounds like a bug to me - jobs should never get stuck and require a suspend/resume. However, there is something that may work (I’m not a huge fan of tuning on the Job queue feature).Try set a blackout window for the servers in question for 19:59 to 20:10 or something like that. In the window option there is a transaction log specific option which I believe applies to archive logs as well. You can do it at a server/client group to make it easier.This will prevent archive log backups just for that window to allow the DB backup to get through without having to massively modify your schedules. See if that helps?
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
