Posts made by Gheppy

I don't think so, I see this message before the update

It seems that the task failed 5 minutes a go, with the error >> HTTP connection has timed out <<, I restarted the task and now everything is displayed.

Thank you

This task is an XOCE CR, which appears to run. I see disk growing on backup SR.
It's just that I no longer see it in the task and I no longer see the estimate time to finish.
Except that is not displaying the tasks, everything seems to work.
I will probably find out later what is really happening, now it is at 80% transferred by my calculation.

It is not the task is not running, it is (on the first 3 photo), but it disappear from task list.

The setting is for 3 days.

I have the same message, but the CR is ok. I tested and it starts with no issue

After 24+ hours of transfer nothing is displayed in task tab. Yesterday the transfer was displayed in tasks tab.
I'm on commit e48bfa2c88d5e33fff44e9b004f43041166375e0

I have attached what is displayed below.
Backup is running

It runs for more than 24 hours

Server has activity

But nothing in the tasks tab

Hi,

I compiled version f4bf56f159db7cc6020060252fadd4a91f17641f
and I get the warning below

eslint-config-standard@17.0.0" has incorrect peer dependency "eslint-plugin-n@^15.0.0"

Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

This is on testing environment.
Version of XOCE

Transfer without setting

Transfer with setting

From what I've seen:

• when nothing is set, XOCE makes the transfer using a single vCPU to the maximum and the rest up to 5% max . The maximum transfer being up to 23Mb/s
• when the setting exists, XOCE uses all 12 vCPUs between 30% and 45%. The transfer is between 145Mb/s and 350Mb/s.

In both cases, the transfer is done on a 10Gib LAN and I use http mod for connecting to Servers

I had the same problem. I have a CR that until applying the setting took up to 5 days (I interrupted the backup to see where the problem is) to make a backup, now with the setting it takes 12 hours.
But the stability of the transfer is better by at least 15% compared to commit afadc8f95adf741611d1f298dfe77cbf1f895231.

@Andrew said in Slow backups (updated XO source issue):

@julien-f The time it takes for CR to run seems to be back to normal with the added config

[backups.vm.defaultSettings]
validateVhdStreams = false

I have Concurrency set to 4.

There's more than enough local ethernet bandwidth between machines and XO is running on the pool master. There's lots of cores and memory for XO. But with validateVhdStreams = true there seems to be some single threaded issues with node because it uses 90%-120% cpu.

With validateVhdStreams = false the CPU usage is about 110%-150%, so still some single threaded issues but a lot less as node is able to use more than one core (but not all of them).

Also... I see the warning that appeared from an earlier commit but does not cause problems:

 transfer
 Suspend VDI not available for this suspended VM

XOCE commit d7da83359f007236784f2644213b288e24759823

I can't modify a Pool metadata backup, I get the error below.
I can create it without problems, but I can no longer modify it.

schedule.set
{
  "id": "b7bbc539-36a2-469b-9dd7-ee521a5a7dc0",
  "cron": "0 1 1,15 * *",
  "enabled": true,
  "name": "",
  "timezone": "Europe/Bucharest"
}
{
  "code": 10,
  "data": {
    "errors": [
      {
        "instancePath": "/name",
        "schemaPath": "#/properties/name/minLength",
        "keyword": "minLength",
        "params": {
          "limit": 1
        },
        "message": "must NOT have fewer than 1 characters"
      }
    ]
  },
  "message": "invalid parameters",
  "name": "XoError",
  "stack": "XoError: invalid parameters
    at Module.invalidParameters (/opt/xen-orchestra/packages/xo-common/api-errors.js:26:11)
    at Xo.call (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:65:20)
    at Api.#callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:397:19)"
}

Hello,
I have windows 2008R2 with SQL 2008R2 and a database of 4.3Tb, I use CR successfully (for 2+ years now), I do the transfer on a LAN link in http mode.

For a transfer on a 1G LAN, you will have a transfer time of 60-72 hours. You must set in XCP-ng the time to kill the task for 72 hours minimum, in /etc/xapi.conf line 306 set: pending_task_timeout = 259200 # 3 days in seconds.

For a transfer on a 10Gb LAN you will have a transfer of 7-14 hours.
I don't use snapshot with memory but the recovery was ok, I had an event.

Backup Delta always refers to the last Full Backup. So the ones before the Full Backup can no longer be restored on a backup made after them

@manilx
I chose ext4, precisely so as not to waste unnecessary space

base copy it's the reference, it's that vdi that contains all the information before snopshoot.
If you use the LVM format it is normal to be like this, if you use the ext4 (vhd) format it will only be the difference.
Because you don't have space, use the ext4 format for SR

I tested the same thing with XCP-ng 8.3, it seems to work. I can't wait for it to be ready for production. The first impression is very good.

@olivierlambert
Ok, thank you

I have a virtual machine with the following configuration: sda - with OS, sdb - with data and sdc - hdd usb attach. As in the photo below.

And I want to make a backup only to sda and I receive the era below. How to configure the backup so that I don't have this error?

It is working for me to, thank you