CDR not replicating some files - why not?

[hutchingsp]

We have CDR replicating from a source file server to a destination file server. I have a row of green lights in Data Replication Monitor.

However, when I look at the “Failed Files” for each pair, I see various failures such as:
• 05/28/09 17:13:54 F:\ LUN1_Replica\$Extend\$ObjId Error: 2
• 05/28/09 17:22:42 F:\ LUN1_Replica\$Extend\$ObjId Error: 2
• 05/28/09 17:30:54 F:\ LUN1_Replica\$Extend\$ObjId Error: 2
• 05/28/09 17:52:53 F:\ LUN1_Replica\$Extend\$ObjId Error: 2

Plus lots of others that seem to be mostly Outlook PST files, .tmp files (possibly when people open Word documents?) and database files from a few apps that use their own database file format.

The error is always “Error: 2” and they always appear under the destination machine in the “Failed Files” list. The source/destination volumes show no errors with chkdsk and the file permissions look fine/as expected which is generally “Administrators and System = F/C” plus groups for the users(s) who need access.

Clearly this is a huge concern to us as the whole point of adding CDR to our Commvault setup is that we have a consistent snapshot of the data on our main file server available without having to hit tapes should we lose it – and that doesn’t appear to be the case.

I need to log this with technical but does anyone know what is going on here please?

Thanks!

 

[rodneysmith]

The error 2 means "The system cannot find the file specified."
The files may be getting deleted while it was doing its initial scan of what to replicate and when it got to that file it was gone and freaked out.

The green lights mean that data has been replicated recently.

We have set up exclusions in our CDR sets to not try and replicate tempory files as they are not really of much use in most cases.

If you really do need them look to confirm the file is still at the source and what permisions it hasthen make sure CDR is running with an account that has this access at bth sides (my default it uses local system)

hope this helps
rgds rod

 

[hutchingsp]

OK still got this issue.

Both source and destination are 2003 R2 x64.

Galaxy 8.0 SP3.

Formatted the destination LUNs and created new pairs and did a full re-sync which took pretty much all weekend.

Low and behold tonight I'm greeted with a bunch of folders on the destination that don't contain files that clearly exist on the source, primarily PST's but also some TXT files.

Has anyone had similar experience as on the one hand I'm thinking surely CDR is an "enterprise" product, but on the other hand we just have a single file server, nothing out of the ordinary yet I simply can't trust that the damned thing is actually in sync!

 

[605]

In your case, i would investigate/repair the source drive. Here are some links which might help you - the error also occurs in other scenarios:

http://forum.kaspersky.com/index.php?showtopic=54113

http://www.pcreview.co.uk/forums/thread-3626465.php

http://help.lockergnome.com/windows/extend-Objid-corrupt-unreadable--ftopict582564.html

 

[markey164]

Might be nothing, but check the attributes of the files in question. See if they are read-only, or have some kind of restrictive permissions on them.

I had a similar issue when i was doing some archive testing, and Commvault wasn't archiving random files that it was told to archive. We found they were set with a 'read-only' attribute. We had to do a reg edit to fix this.

As i say, might not be this at all, but worth a quick check ;o)

 

[hutchingsp]

They definitely are not read-only.

It's odd that the vast bulk of the failures are around files that are usually temporary or use "strange" lock methods i.e. a lot of .PST files, Word/Office temp files and so on.

The basic issue is that we're using this to recover quickly in the event of DR but it doesn't seem to be capable of guaranteeing a consistent copy of the source data.