I had two servers in SBG. Thankfully nothing that wasn't already replicated elsewhere.
Servers were offline. Logged into XO backups all there :). Commence restoring.
So thanks to Xen Orchestra for making what could have been a disaster into no big deal.
Does this basically mean there could be effectively a new version of XOSAN which can leverage local storage across a cluster?
I realise it may come across as annoying. But 8.2 being out before xcp-ng Center support catching up has highlighted an issue for me.
I use XO for a lot of things. Especially the backups process. But it being the only option for admin of 8.2 has to be frank, frustrated me.
It is just my way of working. But I do everything from the xcp-ng Center tree view. Collapsed it shows my entire infrastructure then I can expand the list to show VMs on machines I'm interested in, and importantly do this on several machines at once, sometimes all of them, and see exactly what is going on.
This is harder in XO. All the information and functionality is there but much more hidden away on different screens and more difficult to get a quick view of what is going on.
I hope you take this as friendly feedback 
I have an SQL Server instance which has a 1TB main drive disk and then a shed load (technical term 
) of other disks for storing the databases. The whole thing takes up too much disk space for snapshotting to work.
Is there any means to use XO to back up just the boot disk and not back up the data drives? These are backed up by other means anyway.
Servers to be backed up, all in OVH.
20x xcp-ng8.0 1-2Gbit NIC
SATA hard drives. Not the fastest in the world but can usually manage 20-30MBbps during live migration or VM transfers.
Backup server
xcp-ng8.0 10Gbit NIC.
SAS hard drives 12x arranged in RAID0. xcp-ng and the VMs run from a single SSD drive.
VMs on the server:
XOA
Centos7 server with the RAID array direct mounted, XOA accesses this through NFS.
XOA and the Centos7 server communicate using a network internal to the xcp-ng server.
Testing on the RAID array from the NFS server using dd gives speeds of around 600-800MB/s reading & writing.
I've tested backups by setting a seperate backup job on 10 of the xcp-ng servers, none of them are in a pool, all seperate installs. For the first few machines they amount of data received by XOA and passed onto the NFS server goes up, then it's maxed out at around 70MB/s. Any further machines sending backups through to XOA doesn't increase that total instead reduces the individual speed of each of the backups.
The network input to XOA is a constant 70MBps (give or take) but the output to the NFS server is in pulses maxing out at around 200MBps.
I've done some network testing and using simultaneous iperf from 5 servers I've managed to max out the 10Gbit NIC so the network connectivity into there isn't in question. I wasn't able to test the connectivity into XOA itself, so that could still be a bottleneck, it does seem busy CPU wise.
Any advice as to where to look and what to try? The backup performance isn't bad per-se, it just could be better given the hardware.
There's always the possibility I've made a hideous multiplication by 10 error here somewhere.
Found this by googling. Is there any news on being able to exclude disks at the snapshot level?
I have a couple of big SQL server VMs that are too big to snapshot, but the OS disk is relatively small and the attached disks are backed up by a seperate process anyway. So literally just need the OS image backing up.
Any chance you can share initial thoughts on where XO is likely to go with the XO6 update? More of the same or a total overhaul?
@julien-f said in Error: footer1 !== footer2:
@markhewitt1978 In that case, please open a support ticket there and then, open a support tunnel for us to investigate
Thanks. I shall run it one more time manually to make sure. And if it fails I’ll open a ticket
Thanks.
@julien-f said in Error: footer1 !== footer2:
@markhewitt1978 Are you using XO from the source or are you using an XOA?
XOA
@julien-f said in Error: footer1 !== footer2:
@markhewitt1978 Yep, XO should properly detect that and fix it during the next run.
It has been doing it for a while now. Maybe 4-5 times.
As the title. I am getting this error when backing up a particular VM. All the other VM backups are running ok.
Any ideas on how to resolve it?
1 Failure
UUID: 3de6c09a-7bd5-3552-eb25-9e641296ca9f
Start time: Wednesday, October 20th 2021, 5:00:00 am
End time: Thursday, October 21st 2021, 12:05:59 pm
Duration: a day
Error: footer1 !== footer2
@olivierlambert said in XO console keyboard on iOS and iPadOS - no input possible:
No but it doesn't mean this won't be solved with a virtual keyboard anyway
It would need to be able to trigger the built in iPad / iPhone keyboard for it to be properly usable.
Having just got an iPad I’ve noticed this too. Have to RDP to my office machine to get onto xcp-ng Center. Ideally it would be great to have an iPad app as interface to XO. But of course won’t happen.
@olivierlambert said in OVH fire:
Hey @markhewitt1978
You are exactly the kind of user we'd like to put some spotlight on. Would you agree to do a small written interview with us for a blog post?
Sure no problem. I don't think there's any confidentially issues. But I'll have to run any answers past management.