VDR and Edit Comments issue

[Paul_Brannon]

Has anyone else ever seen this with VDR?  It has been a constant source of annoyance for me since VDR 1.0.

Occasionally, my attempt to Edit Comments on a mounted destinations fails.  The change in the Comments will not take place.  Worse, the destination becomes unavailable for Backup jobs or Integrity checks.

During the early days of VDR, I attributed this to VDR quirkiness and vowed to not edit comments.  However,  even with Appliance version 1.2.1.1616, and plug-in 1.2.1.3 I still see this problem.

Later, I thought it another sympton of the problems I have in backing up to the Iomega ix4-200r NAS.  Problems still unresloved to this day I might add.

However, while testing a QNAP NAS, the problem occurred again yet the QNAP has shown excellent backup reliability.  So I concluded this issue was indeed with VDR and since no one in this forum has ever brought it up nor does it show in the Knowledge Base, there is something about my software install on this and other laptops we use that induces the problem.

Restarting VDR, removing and re-adding the destination disk to VDR, reformatting the destination disk, none of it helps.  But today I shutdown VDR, disabled and enabled the plug-in, restarted VDR and bingo I could edit the comments for that particular destination disk.

I will try this again the next time it happens to see if it has the same effect and report back to this thread.

paul

[RParker]

Of all the things I really despise about VDR, comments always worked..  Not sure why they don't work for you.

as a side note, VDR 2.0 will work with 4.1 (probably not supported) you have to upgrade to the VDR plug-in also.  Try the new one, see if it works better.

[Paul_Brannon]

Thanks RParker.  I'll try out VDR 2.0 on 4.1.  I do need to figure out the problem with this version however.

I took a look at the Client Log after failing to Edit Comments.  Here's the error that is the root of the problem:

Exception:  "RefBackupset::Connect error -2246"

This error is generated multiple times after the Mount.  The mount succeeds.  The restore points are available.   But I can't back up to it, Edit Comments or run an Integrity Check.

I searched this forum and the knowledge base for "2246" and found it refenced in KB 1024210.  And then it all came back to me, I've been down this road before.  I've deleted the catalog files and rebuilt them.  It doesn't immediately fix the problem.

Just now, I've gone back to my Destinations and there's the comment field filled out.  It was empty before.  So the connection succeeded just enough to retrieve the comment field.  Oops, now the log is showing the connection error again.  And I can't Edit Comments.

So this is intermittent and I have no workaround as I suggested in my initial posting. 

I now think this is a NAS problem.  I've seen it before working with the ix2-200r because that unit has issues with NFS mounted vmdk's.  And now I'm seeing it with the QNAP not with the internal array but with an eSATA connected external drive.   So the problem is intermittent connections between VDR 1.2 on ESX 4.1 and a QNAP connected external hard drive.

I'll post here if I discover anything more.

paul

[Paul_Brannon]

I titled this thread "VDR and Edit Comments" issue and that's been a good choice.  The absence of comments after mounting a VDR destination is an indication you will see "RefBackupset::Connect: error -2246" logged in the VDR Client log (Shift-Log).  Your mount will appear successful.  You will see restore points.  But you won't be able to backup to the destination.  And you won't be able to perform an Integrity Check.

The knowledge base gives an example of a 2246 error but in the context of performing a backup.  Not just after mounting as I see it.  I use to follow it's advice of rebuilding the catalogs but it did not fix the problem.  Then, at some point, the mount would work.  The comments would reappear.  No error in the Client log.  And full destination functionality restored.

Here's what I saw today.  I ran a full backup to a QNAP TS-459U+ and it's NFS shared eSATA external drive.  The backup was successful.  However, I noticed my comments had disappeared.  The Client log was producing a steady stream of 2246 errors.  This is because if you have a Backup job pointed to a mounted destination, VDR will constantly access that destination (probably only when you have the plug-in GUI active).  In this case, VDR couldn't access it thus the 2246 error.   I added other QNAP NFS shares with destination disks I know are good.  None of them would mount with comments.  All of them showed the 2246 error when mounting.

I then added a destination drive from a ReadyNAS 2100.  The comments showed up.  No 2246 error.  Yet unmounting and mounting the QNAP drives still showed the error.  So it appears to be a QNAP problem similar to what I've seen on the Iomega NAS.

Later, the comments appeared on the QNAP drive I had mounted.  The connection had been restored.

I've made sure it isn't something like "hard disk standby".  I don't have a fix as the connection has restored itself.

I'll keep looking!

[Paul_Brannon]

I looked up the VDR 2.0.0 Release Notes and saw that vSphere 4.1 is supported.  Very good!

So I upgraded and tested it out with the QNAP.  Quite reliably, the problem is still there.  Error -2246 when mounting the QNAP eSATA external drive.  No problem mounting ReadyNAS or QNAP internal drives.

Rebooting the QNAP allowed me to mount its external drive.  Ooops, now it won't.

Oh well!

[Paul_Brannon]

Actually, external disks attached to any of the NAS devices I have tested make poor destinations for VDR.  VDR (even 2.0) won't consistently mount the destinations without the occasional -2246 error.   Bizarre that no one else sees this.

[Paul_Brannon]

I finally figured it out.  My problems mounting destination disks with VDR 1.2.1 or 2.0 have nothing to do with whether the destination is located on a particular NAS or a hard drive mounted externally to a that NAS.  Instead, it matters what SCSI ID number I give the disk when I first add it to the VDR appliance.

Here's what happens:

If after I mount a destination, its comments do not appear, -2246 errors are logged in the VDR client log (sometimes every second or so), and I find the destination declared mounted but it can't be used as a backup destination ("unavailable"), then I will find an existing backup job that was previously used with the same SCSI ID as the destination disk I am trying to mount.

The workaround is to either delete the old backup job(s) or add the destination disk to VDR with a SCSI ID different from the old backup job(s).  Then I will be able to mount the new destination cleanly with no errors. 

This has worked on VDR 2.0 and I duplicated the same fix for the guys across the hall with VDR 1.2.1.

This is why one of the "fixes" seen in this forum for problems with VDR destinations has been to delete all the existing backup jobs.  But I've never seen it explained why this worked.  These jobs are actively looking for their destinations by SCSI ID.  If you attempt to mount a different destination with the same SCSI ID, a -2246 error (and others) is generated.  But the disk will appear to mount without the comments displaying and it will be unusable.

Before I understood this, I opened a rare support request with VMware and duplicated my problems to the representative.  He is unaware of this issue as he blamed the problem on my high latency devices and recommended I stop trying to use VDR to back up to these externally mounted USB drives.  I pointed out that all my backup devices show high latencies and that it was unrealistic for the engineers to expect VDR to be used only with 20ms write latency devices such as a 12 spindle NetApp or such.

I'm attempting to reopen the support case.  VDR needs to do a better job handling this with a warning or by fixing the code.  Yes, I can see why you wouldn't want all your jobs ready to do a scheduled backup to every destination you mount.  But screwing up the mount and generating obscure client log errors is not informative.  It's been messing with my head since VDR was first released.

paul