@SethNY you could even enhance this VM_LIST =
with TAGs on VM, so that you manage the selection directly in XOA

@k11maris said in delta backups with offline snapshot: VMs do not start after snapshot, they start after transfer is done.:

I think there is a way with changed block tracking to use delta backups without snapshots, right? I'll have to look into that.

ypu need to check those

and yes a VM that is BACKUPed and REPLICAted have 2 snaps.
didn't see a snapshot for Disaster Recovery job though (seems to be snaped, but deleted afterward as there is no need to delta on the next snap), you could use these, but full only and one temporary snapshot during the DR export.

@k11maris yeah but with new jobs, you enter a new Backup Chain ?

would be nice to keep those existing (imagine if you have LTR to re-backup)

I don't know a veeam way to "map backup" to get the chain continuity in XO Backup.

@bvitnik said in Booting to Dracut (I trusted ChatGPT):

P.S. I guess metadata backup is also XML just like XAPI state file (database). I don't know why JSON came to my mind regarding metadata backup.

Reply

perhaps because of other thread discussing metadatabackup.list in audit log

there is actually a bug there where the metadata is not only checked to be audited, but also completly dumped in JSON format.

@AtaxyaNetwork yeah but if he doesn't have metadata backups, he will have SRs full of disconnected VDIs ? and the need to recreate each VM ?

@nuentes I explored my pool metadata backups, and I see a "part.1" file, that is a big XML of all the configuration of the pool

so yeah I don't think there is something else in here like your OS parameters, only pool config.

I could be wrong, but it's all I can see in here

@acebmxer xoconfig goes to vates but not pool metadata
doesn't cost anything to put a job on it I guess

so we wait for Vates team to tell us why this vebose audit log on metadata

or perhaps it IS the metadata that would explain the fuss

@acebmxer you need to go in backup/restore/metadata

it will try to list your metadata backups by an api call

then go back to audit you will see the audit log

mine is gigantic.

@acebmxer do you have AUDIT LOGS activated ?

if so, could you check on your XOA if you have the same from-earth-to-moon audit log on metadata backup list ?

why do I have quite a full log of all my infrastructure information in this log ?
this one is a bug I guess

perhaps is it linked to the infinite refresh I had ?

EDIT : saved the log on the desktop in notepad ... 1.528 Mo !

@acebmxer yeah I know... sometimes I have to REFRESH BACKUP LIST for normal backups of VMs, but this button doesn't even exists for metadata

i'll let tomorrow sequence execute, and report back if the metadata restore points are unaivailable again.

as this job was done with a XOA proxy, i tested it WITHOUT the proxy... and the restore points are back...

but when i put again the proxy in the job configuration, they stay there, as usual... all is OK now...

I don't know what happened...
to note : I manually launched the backup to test with & without proxies, I don't know if there is a different behavior than the usual : executed by sequence.

Hi, we're on latest XOA 5.112.1

when browsing to backup/restore/metadata it loads indefinitly...

never showing the restorable points. and they exist.

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 ?

@bazzacad great, glad it worked for you

@bazzacad you do not seem to have the same number of PIFs in each host
I wish you do not have to, but you can swap names if needed, read the doc here https://docs.xcp-ng.org/networking/#renaming-nics

@bazzacad I don't know for sure this is the culprit.
but as far as I know, it is really recommanded to have strictly the same nic ordering/usage for multiple hosts in the same pool to avoid quirks.

network configuration is centrally done at the pool level and pushed on the hosts, so you better have them configured/cabled the same way.

you see your eth0/management ? you named it "voltronmanage1g", but is has been pushed on VADER host too with this name.
If you use eth0 for management, call it "management" but not with a host-attached name.

your eth2 seems physically disconnect on Vader, perhaps taking the ethernet cable from eth8 should be enough on this host ?
you should bring back the management interface on eth0 too, it's actually on eth7 on Vader.
reconfigure IP addresses on the pifs too, once connected.

try to replicate the same configuration/connections on your hosts if they are in the same pool (seems to be the case, pool TSE here)

@nuentes i GUESS if you make a clean reinstall
then restore the metadata... you should be up & running again

BEWARE before reinstalling, be sure you can restore said metadatas ! I don't want you to be in any more troubles

@nuentes where you're at, would not be possible to simply wipe/reinstall/restore metadata ?
or rejoin pool if this is multi host pool ?

is this a single host with all vms currently sitting in the inaccessible USB ?

@bazzacad and does the VM network exists on destination host ?

are your hosts strictly identical network wise ?
one screen you point eth2 and the other eth8 for the 10g network.