Incremental Remote Backup copy converting to Full copy

Last post 11-11-2010, 9:45 AM by dpringle. 9 replies.
Sort Posts: Previous Next
  • Incremental Remote Backup copy converting to Full copy
    Posted: 09-07-2010, 11:09 AM

    I have logged this issue with support but wondering whether anyone else had come across the following issue we are seeing. We have recently setup remote backup (DDR) copies at quite a few remote sites and are noticing that at some of these sites FULL syncs/copies have been kicked off instead of the scheduled Incremental syncs or copies. We saw something similar when we were testing this solution and were told by support that we needed to increase the size of the journal as we had experienced a journal wrap issue which had caused a FULL rather than an Incremental copy to kick-off. At one of the sites we did increase the journal size to what Commvault recommended but we have still run into this issue. Once a FULL kicks off , we pretty much have to kill the job as our lack of bandwidth at these remote sites doesnt allow for the FULL job to complete. We then have to reset the site up from scratch by running the out-of-band sync process which requires us to send USB drives out to the sites in the various countries.A bit of a nightmare in short. Im hoping that we can identify what causes this issue so that we can resolve

    Anyone else had a similar issue ?

    thanks in advance

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 09-07-2010, 2:59 PM

    IF the CJ size was already increased i would suspect a different error caused the full sync the subsequent time.  Similar issues can be seen with DCE also as it ties into CJ.  What type of machine is this and our frequent is the data changing that CJ is rolling over in such a manner?

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 09-08-2010, 4:42 AM

    Thanks Vincenzo , our clients that are being backed up like this are all Windows 2003 Domain Controllers that are also acting as file servers with mainly user data/docs being backed up.There is also a SQL database on the server which gets re-indexed daily and although this isnt backed up by commvault , im not too sure if this could be affecting the size of the CJ. The data we have chosen to be backed up on these servers is quite small. On average about 1GB gets copied as part of an incremental backup. Not a whole lot of changes are occuring within that 1GB that gets backed up.

    We only increased the size of the CJ on the D drive as if you delete and recreate the CJ on the C drive of a Domain Controller , it breaks AD replication until restored. We only back up one small directory on the C drive so we thought leaving the defualt CJ size on C would be fine. Most of the data that we backup is on the D drive.

    Im hoping support will be able to analyse the logs that i sent them and tell me what caused the Full to occur. This problem is now occuring at quite a few sites

    thanks , Duncan

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 10-18-2010, 5:17 AM

    Just an update on this if anyone is interested. It seems these FULLs were kicking off on our clients after either a server crash (ungraceful reboot) or even in a few circumstances after a graceful shutdown. Changes to the CJ file arnt being committed correctly on shutdown and as a result a FULL occurs on next backup as the CJ isnt trusted. I am still working with support on this issue...

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 11-10-2010, 12:23 PM

    There is a new CDR update (18919) out that prevents an issue where upon reboot CDR may lose the JournalID and the pair may go into a Full Sync instead of a SmartSync.

    It would be recommended to install this update before the next reboot of the machine which have CDR installed.

    From the Update Readme:


    1. JournalId may change erroneously between reboots leading to the next backup converting to a full sync.


  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 11-11-2010, 6:42 AM

    Thanks Ted. Yip , support sent this update through to us after our issues and we have installed it on our CDR clients. Sofar it seems to have resolved the problem of FULLs kicking off after scheduled reboots which is good. Unfortunatly it doesnt resolve the issue of FULLs kicking off after unscheduled reboots which is a big issue for us. We have been using a commvault tool , DirDiff , with mixed results  to help us bring CDR sites back in sync after these unscheduled reboots rather than have FULLs kick off. At this point there is nothing else commvault can do for us on this issue ....

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 11-11-2010, 8:52 AM

    When you say "unscheduled reboot" are you referring to bluescreen/crash? 

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 11-11-2010, 9:00 AM

    yip , bluescreens or crashes. Happens more than we would like on our remote sites servers. After each crash , our next DDR remote backup goes into baseline mode and does a full due to commvault not trusting the CJ file

  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 11-11-2010, 9:20 AM

    Stuck between a rock and hard place type scenario.  If CJ could be compromised the chunks may not be consistent on the destination, thus the full resync scenario comes into play. I'm sure YMMV depending on how you want this scenario to be treated by I'd rather have data consistency then not trust replication and have aux copies/restores fail. 

    9.0 DASH or replication with optimized would be of benefit here, since replication with optimized checks the destination and will not replicate data that is already consistent.

    Has the origin of the bluescreens & crashes been discovered?  I would fear that these events would compromise more then just replication on these servers.


  • Re: Incremental Remote Backup copy converting to Full copy
    Posted: 11-11-2010, 9:45 AM

    thanks for that Vincenzo , yip , it is a tricky one. Our crashes are due to various issues - site power issues , app issues etc etc. While they dont happen too often , we have over 40 servers running this solution all over the globe so we are getting a few crashes each month. I did see another post by Ted on another replication issue where he mentioned some of the new v9 features wrt replication. The Optimized Sync was the one that interested me the most. If we could use that for DDR backups , we wouldnt need to use the DirDiff tool after a crash. I think its going to be a priority for us to upgrade to v9 !

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy