Nice one, thanks guys.

Hey peeps,

We fell victim to the "delta backups always full" issue over Christmas, and just before you released the fix for it we tried deleting and recreating our worst affected backup job that was eating all of our storage at one site.

Before that new job actually finished the fix came out, so I aborted the job and installed the update, expecting the one VM that was still backing up to have been marked as failed and do another full job that evening. But that didn't happen, and instead did a delta.

I'm now not very confident that that VM is safely backed up so I'd like to force the next job to be full. I know I can specify a full backup for every x runs, but is there any way to do this for just the next one?

Cheers for any help.

Doing a bit more hunting it seems like if we could get Arcserve to use the nolock option then that would likely solve the problem, but there's nowhere to add any options and the Arcserve Proxy itself uses the Windows NFS client behind the scenes.

Right now we've worked around the problem by creating a separate, read-only SMB share pointing to the same location and using that for Arcserve instead. Our only concern now is what could happen if XO starts a job while Arcserve is still doing its own backup.

Edit: I did a bit more Googling after posting the above and came across this thread: https://www.truenas.com/community/threads/nfs-the-process-cannot-access-the-file-because-another-process-has-locked.12644/ ... which suggests that it's actually a long-standing TrueNAS bug.

Buried within the comments is this suggestion:

If you're having trouble with the NFS locking mechanism, and you would like to use the "NET USE" command, or the [WNetAddConnection] function to mount a NFS share without locking, there's an undocumented registry entry hidden in the NFSNP.DLL:

"HKLM\Software\Microsoft\Client for NFS\CurrentVersion\Users\Default\Mount" REG_DWORD "Locking"
If the value is "0x0" then locking will be disabled globally.
If the value is "0x1" then locking will ben enabled globally.

We'll test it and report back.

@fohdeesha Thanks for your reply and apologies for the delay in getting back to you.

You've provided some good avenues to check, most notable right now is that we have lock files in that share going back to July! I assume it's safe to delete these and/or restart the statd and lockd services to see if we can clear things up...

Hey peeps,

We've been backing up our VM estate via XO to various TrueNAS based NFS targets for quite some time now to great success.

However we're currently bolstering our backup resiliance by using Arcserve to backup as much as we can to a custom appliance and ultimately to tape, and we'd like to backup the XO backup locations this way too. Unfortunately while we can point the Arcserve agent at the NFS share and it can see everything inside, it's unable to open any files due to file locks, regardless of whether there's an active XO backup running at the time or not.

We've tried applying the nolock option to the mount but it hasn't made any difference (I may have mis-understood what that option actually does).

So what would be the recommended way for Arcserve to access these files, in a strictly read-only fashion of course?

Options we've considered but not yet tried:

• A separate NFS share pointing to the same place. Can't see it making any difference, as I believe the locks are at the server filesystem level?
• Using an SMB share for Arcserve. Just feels risky somehow and not sure it would work for the same reason as above.
• Backing up from a TrueNAS snapshot instead of the main share itself. But snapshots must have the time and date in their name and there's no "latest" symlink so I don't know how we could make that work.

Any thoughts?

Quick post to report that it worked, thanks.

Well, that sort-of worked, but it doesn't copy over any registration info, and my boss with the premium enabled login is off till Monday. Glad I didn't delete the old appliance!

@Danp said in Netdata package is now available in XCP-ng:

@mike Check under Settings > Plugins to be sure the Netdata plugin is active.

I was about to because no it wasn't, but attempting to enable it generates the error: Netdata is not available on this appliance, please deploy a new one.

I guess that answers that! The XOA instance was first installed maybe 18 months ago, so I'm back to my initial question re: backing up the config and importing to a new XOA. Does that keep all of the backup-ng history etc intact?

Thanks all, and happy new year etc.

Hmm, what am I doing wrong here? I've just upgraded my pool to 8.0, fully patched, and running Premium XOA, but I'm getting the "Netdata plugin is necessary" message.

I even tried changing from the stable channel to latest but it's made no difference. Do I need to re-deploy? (I assume I can just download the config and re-apply it to a fresh instance).

Well I can click View/Show Hidden Objects easily enough.

Literally the main advantage of XCP-ng Center is the tree view. I personally try to use XO as much as possible, but for features that are available in both I do find myself falling back to XC for the more logical view. I'll very much be looking forward to this prototype!

Colour me intrigued! But I get the impression it's some way away.

Wonder if there's a scripty way to apply that flag to VMs with the CR tag then. Hmmmm.

Hey guys,

Yesterday I got round to implementing something I've been meaning to do for a long time: I tagged a bunch of VMs at our HQ as 'Critical', and setup a Continuous Replication job for them to replicate to another office's XCP-ng pool on a 2-hourly basis. Additionally, so that we can also roll back a full day if we need to, I set the retention to 12. Job done, I gave myself a pat on the back and went home.

Just got into work this morning and had a look at XCP-ng Center to see how it was all looking. Picture the combined amusement and surprise to find 8 copies of each replicated VM cluttering up the view. In hindsight this makes sense, but is there any way to filter these from the XCP-ng Center view? I know I can do it easily enough in the XOA, but in XC (that we use for >50% of VM management tasks) it isn't so obvious.

I see that VMs can be hidden by adding the key HideFromXenCenter=true to the other_config parameter for the object (https://docs.citrix.com/en-us/xencenter/7-1/intro-hiddenobjects.html). Can this be added perhaps as an advanced option for the backup jobs? Or better yet, is there a way to make it happen already?

Thanks in advance for any help. Let me know if you need any more info from me!

@olivierlambert Thanks for the super-quick reply as usual! I feel like I should make a new thread for it, but what are you views on using raw VDIs to get around the limit? http://www.ervik.as/how-to-create-a-raw-logical-volume-manager-virtual-disk-infrastructure-with-xenserver/

I realise you can't snapshot raw disks, but are there any other pitfalls to it?

Quick (hopefully not dumb) question: Will XCP-ng 8.0 support VDIs larger than 2TB? I see mention of the qcow2 format dotted around but nothing concrete about if/when it will be implemented. Cheers.

Hey guys,

We made the mistake of running the only two domain controller VMs in a remote site from the same storage, and when that storage killed itself we lost both of those VMs. No problem, we'll restore from the backups we took via XOA. It was only a week later that we discovered both of these DCs had suffered from USN Rollback issues and were no longer syncing changes.

We've got it fixed now after forcibly demoting both and promoting them again, but I thought XCP-ng was supposed to support VM-GenerationID so that AD can recognise when it's been restored from a snapshot and recover gracefully? XenServer has apparently supported it since version 6.2 and the required device is indeed showing in all of our virtualized DCs.

The only thing I can think is that maybe it's something to do with the restore process in XOA (which is why I've posted here). Either way it would be nice to know that we can safely restore a failed DC from our XOA backups should anything go South again.

Any thoughts/input? Thanks a lot!