Hey all,

We are proud of our new setup, full XCPng hosting solution we racked in a datacenter today.
This is the production node, tomorrow i'll post the replica node !

XCPng 8.3, HPE hardware obviously, and we are preparing full automation of clients by API (from switch vlans to firewall public IP, and automatic VM deployment).

This needs a sticker "Vates Inside" #vent

Hi,

Smart backups are wonderful to manage smart selection of VMs to be backuped.

When we browse the RESTORE section, would be cool to get the TAGs back visually, and possibility to filter them
I'd like to get "all VMs restorable with this particular TAG" type of filter, hope i'm clear.

Perhaps something to add to XO6 ?

just to #brag

Deploy of worker is okay (one big rocky linux with default settings 6vcpu, 6Gb RAM, 100Gb vdi)

first backup is fine, with decent speed ! (to a xcp hosted S3 minio)

will keep testing

@sluflyer06 and I wish HPE would be added too

is there anywhere where we can check the backlog / work in progress / to be done on XO6 ?

I did stick to version: 1 in my working configuration

Had to rename my "Ethernet 2" nic name to Ethernet2 without the space

You have to put the exact template nic name for this to work.

@MajorP93 throw in multiple garbage collections during snap/desnap of backups on a XOSTOR SR, and these SR scans really get in the way

Could we have a way to know wich backup is part of LTR ?
In veeam B&R, when doing LTR/GFS, there is a letter like W(weekly) M(monthly) Y(yearly)to signal the fact in the UI

That's pure cosmectics indeed, but practical.

hey,

Could be of some interest for french speakers and why not others in the forums :
https://go.veeam.com/webinar-technical-cloud-club-france

@Bastien-Nollet okay i'll do that tonight and will report back

Re: FILE RESTORE / overlapping loop device exists

we still had this annoying probleme where we couldn't FLR our backup, source VM could be Windows or linux, with or without LVM... (see error logs in previous thread, overlapping loop...)

latest XOA is installed.

on a secondaray XO CE, I mounted the same remote, and NO PROBLEMS AT ALL... soooo I thought my main XOA is probably beaten up somewhere... but that was not it.

all remotes on main XOA are attached to a XO PROXY (official, not CE) !
on the XO CE that is in another datacenter, I mounted the S3 remotes directly WITHOUT the proxy use, and it worked.

On main XOA, we offload all backup tasks to proxies, so all remotes are attached to a proxy...
I duplicated a remote, same conf, but without proxy, so that XOA would do the restore job, not the proxy, and voila, all is working as intended, FLR is okay on main datacenter.

TLDR : FLR is not working with proxy attached remotes, if you duplicate the remote without the XO PROXY, all good

@florent @bastien-nollet I think there is something to look into.
probably a race condition, the XOA and the XO PROXY both try to mount the loop device ?

@flakpyro yup still aggressive on memory consumption
I have a task that reboots XOA & XOPROXIES every two days to mitigate

since 6.3 / 6.3.1 it seems more aggressive on the ramp up (I updated just yesterday... was still on 6.1.2)

I only modified @florent code, not the second one you gave me

@pierrebrunet with your modification on XO PROXies, it seems to be working now !

I should have thought about the proxy doing the actual job...

@Bastien-Nollet why doni have weekly or monthly rétention points that are not fulls ?
could not theses rétentions points be merged in fulls when tagged ?

keeping a monthly incremental suppose to also keep previous inc. and based full

@pierrebrunet said:

• const scheduleId = this.#props.schedule?.id ?? this.#props.scheduleId

done,
but still same error

          "result": {
            "message": "Cannot read properties of undefined (reading 'id')",
            "name": "TypeError",
            "stack": "TypeError: Cannot read properties of undefined (reading 'id')\n    at IncrementalRemoteWriter._prepare (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:93:39)\n    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:87:32\n    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/Task.mjs:108:24\n    at Zone.run (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/node-zone/index.js:80:23)\n    at Task.run (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/Task.mjs:106:23)\n    at IncrementalRemoteWriter.prepare (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:87:17)\n    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/IncrementalRemote.mjs:92:48\n    at callWriter (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/_Abstract.mjs:33:15)\n    at IncrementalRemoteVmBackupRunner._callWriters (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/_Abstract.mjs:52:14)\n    at IncrementalRemoteVmBackupRunner._run (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/IncrementalRemote.mjs:92:18)"
          }
        }
      ],
      "end": 1775118782797,
      "result": {
        "message": "Cannot read properties of undefined (reading 'id')",
        "name": "TypeError",
        "stack": "TypeError: Cannot read properties of undefined (reading 'id')\n    at IncrementalRemoteWriter._prepare (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:93:39)\n    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:87:32\n    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/Task.mjs:108:24\n    at Zone.run (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/node-zone/index.js:80:23)\n    at Task.run (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/Task.mjs:106:23)\n    at IncrementalRemoteWriter.prepare (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:87:17)\n    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/IncrementalRemote.mjs:92:48\n    at callWriter (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/_Abstract.mjs:33:15)\n    at IncrementalRemoteVmBackupRunner._callWriters (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/_Abstract.mjs:52:14)\n    at IncrementalRemoteVmBackupRunner._run (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/backups/_runners/_vmRunners/IncrementalRemote.mjs:92:18)"
      }
    },

@ph7 try to put RETENTION to 1 in the schedule, as you are using LTR parameters

@wgomes yup thanks for bumping this topic, still having the problem too

@abudef I've been there, here is my vision on the topic.

in terms of RETENTION of the schedule, if you put 21, not using the FULL BACKUP INTERVAL in the job, you will get : one full and 20 subsequent deltas. on the 22nd point, a delta will be done and the oldest delta (the one just next to the full) will be merged in the full. its like a forever incremental.
Put 7 in FULL BACKUP INTERVAL, and every 7 days (if it runs once every day), it will make a full.

other way to do it : as you told, two schedules, with forced full on sundays.

difference between the two ? you really choose wich day the full occurs.
in the first way, the full is "7 days after the chain begins"

do not mix these two way of configuring, you would have unnecessary fulls in your chain.

in terms of LTR, @florent and @bastien-nollet recommended me this :
if you use LTR (lets says 14Daily, 4Weekly, 2Monthly), keep the SCHEDULE retention to 1
the LTR parameters will keep the retention points as intended
try not to mix with FULL BACKUP INTERVAL

LTR is still early, because i would like the WEEKLY/MONTHLY/ANNUALY to always be fulls or specific merged fulls, this is not the case...
it is still not clear, as you can't choose it, which day is the WEEKLY (sunday ? monday ?) the MONTHLY (1st ? last day of month ?)

trial & error mode activated.

tried either by manual run, or relaunched the schedule to see if context of schedule was needed to get id of the schedule, but to no avail

schedule or schedule.id seems to be undefined