VCSA 7.0 restore issue

[maksh84]

I am restoring VCSA 7.0 from Backup which is on FTP. while Step 1 is completed successfully step 2 is getting the error with below statement

Metadata and system validation failed.

Error: Unknown system resource type vtsdblog

Error: Unknown system resource type vtsdb

and so on attached.

I have installed the VCSA 7.0 with default settings and backup taken on FTP. Now when restoring it from backup it throws these errors any clue please ?

Thanks

Manish

[ryanrpatel]

Try this...

1. Shut down the VCSA created during stage 1 of restore.
2. Edit settings of virtual machine.
   
   Ensure the following settings match the vCenter Server Appliance which was backed up:
   - CPU Hot Add
   - Memory Hot Add
   - Memory assigned
   
3. Once settings have been changed and saved, power on virtual machine.
4. Connect to restored vCenter Server Appliance on port 5480 and continue with restore.

[maksh84]

Thanks for reply.

I have tried all these setting and tried again but no luck.

It has same problem popping up everytime.

Thanks

Manish Sharma

[Raudi]

Did you created the backup with the same version and same build of the VCSA?

[maksh84]

Yes, all versions are same. However as I am testing the backup and restore, I am now reconfiguring the VCSA (as it's in my test lab) and again take the backup and will try to restore.

I will update here my result once I repeat the same.

Thanks

[jefftse]

what happened to this?  I'm getting the same thing.  These Vcenter updates are terrible.  It screwed me up every time. 

[Raudi]

A few days ago i restored a VCSA 7.0.0a from my backup, firtst i got the metadata validation error too, and a additional info that i should increase the memory from 12 to 16 gb, after i had done that and tryed the restore again all works fine.

So it is important that the new VCSA VM is identical to the source VM...

[MillardJK]

That error is a horrible one, mostly because it doesn't really tell you what's going on...

The 'backup-metadata.json' in the backup has a section that indicates the size (in GB) that each volume requires to restore. If that size doesn't match up with (or is exceeded by) volumes in your new vCenter, it throws that error.

Other posters are correct: if you stop the new vCenter, and balloon the size of the volumes to the size expected by the JSON data, it will pass muster.

Alternatively, if you know that the existing volumes will store the restored data (ie, you know from before that >25% free space was available in the volume), you can instead edit the JSON for the volume to be the size-as-deployed instead of the original size. This is one nice way to reduce space consumed by the VCSA: in my case, I was able to shrink the "seat" and "vtsdb" volumes from 550G each to 25G, and still have *tons* of capacity still in the volumes.

[SE-Devops]

Just wanted to reply to say thanks.

That saved me a lot of head ache and worked perfectly as described.

Needed to turn on SSH and log physically into the new instance though, picking up the right sizes with fdisk -l.

That's so annoying...

[dbutch1976]

I'm my case I'm working with the new vCenter 8 and getting a very similar error:

Metadata and system validation failed.
Error: Unknown system resource type seat
Error: Unknown system resource type vtsdb
Error: Unknown system resource type vtsdblog
Error: Unknown system resource type lv_lvm_snapshot

Here are the contents of my json file:

{
"Parts": [
"seat",
"common"
],
"HashAlgorithm": "sha256",
"Compression": "gzip",
"Encrypted": "False",
"Messages": "Manual Test",
"StartTime": "2022-10-21T16:05:39.869Z",
"EndTime": "2022-10-21T16:06:00.171Z",
"Duration": "0:00:20.302450",
"Build": "20519528",
"Version": "8.0.0.10000",
"NodeType": "embedded",
"SshStatus": "active",
"PNID": "VCDESSLOCH.LEBRINE.local",
"SizeInfo": {
"memory": 14,
"lv_root_0": 48,
"swap1": 25,
"core": 25,
"log": 10,
"db": 10,
"dblog": 15,
"seat": 550,
"netdump": 1,
"autodeploy": 10,
"imagebuilder": 10,
"updatemgr": 100,
"archive": 50,
"vtsdb": 550,
"vtsdblog": 15,
"lifecycle": 100,
"lv_lvm_snapshot": 500,
"cpu": 2
},
"PrimaryNetworkInfo": {
"ipv4": {
"mode": "dhcp",
"address": "192.168.0.11",
"prefix": 24,
"defaultGateway": "192.168.0.1"
},
"ipv6": {
"dhcp": false,
"addresses": [],
"autoconf": false,
"defaultGateway": ""
},
"NetDnsServers": [
"192.168.0.2"
],
"MacAddress": "00:0c:29:2b:25:2f",
"DUID": "",
"IAID": ""
},
"NetworkInfo": {
"NetAddrFamily": "ipv4",
"NetMode": "dhcp",
"NetAddr": "192.168.0.11",
"NetPrefix": 24,
"NetGateway": "192.168.0.1",
"NetDnsServers": [
"192.168.0.2"
],
"MacAddress": "00:0c:29:2b:25:2f",
"DUID": "",
"IAID": ""
},
"MultiHoming": {
"defaultNic": "nic0",
"interfaces": [
{
"name": "nic0",
"status": "up",
"mac": "00:0c:29:2b:25:2f"
}
],
"totalNics": 1,
"ipv4": [
{
"interface": "nic0",
"mode": "dhcp",
"address": "192.168.0.11",
"prefix": 24,
"defaultGateway": "192.168.0.1",
"updateable": true
}
],
"ipv6": [
{
"interface": "nic0",
"dhcp": false,
"autoconf": false,
"addresses": [],
"defaultGateway": "",
"updateable": true
}
]
},
"DeletedFiles": [
"/etc/applmgmt/appliance/localaccounts.conf",
"/etc/applmgmt/appliance/watermark.json",
"/etc/nscd.conf",
"/etc/vmware-rbd/ssl/castore.pem",
"/etc/vmware-rbd/ssl/crl.pem",
"/etc/vmware-rbd/ssl/rootcert.pem",
"/etc/vmware-sso/trusts_cache",
"/etc/vmware-vcha/vmware-vmon.service.bak",
"/etc/vmware-vsan-health/.cns_pgpass",
"/etc/vmware-vsan-health/silent.json",
"/etc/vmware/appliance/firewall.conf",
"/etc/vmware/appliance/firewall/ccm-firewall.conf",
"/etc/vmware/appliance/firewall/vmware-mbcs",
"/etc/vmware/vsphere-ui/patch_version.txt",
"/etc/vmware/wcp/guestclusters/*",
"/storage/log/audit/sso-events",
"/usr/lib/vmware-mbcs/conf/mbcs-log4j.properties",
"/usr/lib/vmware-mbcs/conf/mbcs.properties",
"/usr/lib/vmware-sca/conf/sca-log4j.properties",
"/usr/lib/vmware-vcha/data/pg-firewall-block.conf",
"/usr/lib/vmware-vcha/data/pg_hba_block.conf",
"/var/lib/likewise/krb5-affinity.conf",
"/var/lib/vmware-vlcm/ndu.json",
"/var/lib/vmware/analytics/silenced-health-tests/silent.json",
"/var/lib/vmware/vmafdd_config/krb5/krb5.lotus.conf",
"/var/vmware/applmgmt/global-fips-flip",
"/var/vmware/wcp/certs/*"
],
"BackupSize": 644350645,
"Archives": {
"ConfigFiles": [
{
"Name": "ConfigFiles",
"FileName": "config_files.tar.gz",
"Checksum": "2bc007f82be3cee5a24dd5de864c03ba349006d0dff432e0615024f38ed0c50f"
}
],
"ComponentScripts": [
{
"Name": "vpxd",
"FileName": "vpxd.gz",
"Checksum": "9290f92c73aba3d6aec522215711de9cf5a75c37bdf24995a69e3607b221bf1d"
},
{
"Name": "wcp",
"FileName": "wcp.gz",
"Checksum": "85cea451eec057fa7e734548ca3ba6d779ed5836a3f9de14b8394575ef0d7d8e"
},
{
"Name": "rbd",
"FileName": "rbd.gz",
"Checksum": "22185b8a4438f450c61c90f0ac2c84570e4477dd68f6db16d5e1edff92413215"
},
{
"Name": "imagebuilder",
"FileName": "imagebuilder.gz",
"Checksum": "e20166ad65f1efbf482dc530014a90968a1f88b0cce6c69e1d5929cfbc9de94d"
},
{
"Name": "vum",
"FileName": "vum.gz",
"Checksum": "7ddec4902d93933a172ef01e0403e8d34f77e197f04cea6e9bf4c2b5a57b25e4"
}
],
"VCDB": [
{
"Name": "VCDB",
"FileName": "database_full_backup.tar.gz",
"Checksum": "ca71cfb3b3852b0521594dd7731b2a3e1c2b0986c0148e58e9940cad46551688"
},
{
"Name": "VCDB",
"FileName": "wal_dir_struct.tar.gz",
"Checksum": "887d558897b85e31f4f7715fbf4cebf029f5e739ac42da3fb23bb23ba4ca80de"
},
{
"Name": "VCDB",
"FileName": "backup_label_file_data.tar.gz",
"Checksum": "488b236be2db5e5b1c26f4d7b25f4873c0f7c8387c38fbc94c53ff78e0de4504"
},
{
"Name": "VCDB",
"FileName": "wal_backup_1.tar.gz",
"Checksum": "8136fcf9415d1d83aecc57ff3f46fa76b76014c2fcaafc46ea3a74e550d77f74"
},
{
"Name": "VCDB",
"FileName": "full_wal_backup_meta.tar.gz",
"Checksum": "bc78b5be19f68e0ac1f106a697ed3061ed6d10eb1dc39eb772588869d5f26712"
}
],
"Lotus": [
{
"Name": "Lotus",
"FileName": "lotus_backup.tar.gz",
"Checksum": "a9940224f9c6d927d04cc26d738f5b1354e3d55768f2e3b6891dc7b9243a0a81"
}
],
"VTSDB": [
{
"Name": "VTSDB",
"FileName": "vtsdb_init.gz",
"Checksum": "d7ca19559e978d16d21030493a69138ef00f7967f46b0f12916edc4fe174fd77"
},
{
"Name": "VTSDB",
"FileName": "vtsdb_globals_data.gz",
"Checksum": "855ee5b569739756637c828ae02da202f711d6f81624d04076b746278e596460"
},
{
"Name": "VTSDB",
"FileName": "vtsdb_schema.gz",
"Checksum": "d450648c3fa7b31d0168f98547e6a5e19dc5e1292c467e00be0f529855e92343"
},
{
"Name": "VTSDB",
"FileName": "vtsdb_revision_history_data.gz",
"Checksum": "f2368700bdc7e4354b41dec232f21d14b63b2a104a04a14a675d01a1fc7939d7"
}
]
},
"DeploymentSize": "tiny",
"Product": "VC-8.0.0",
"ReplicationPartners": [
"VCD20.LEBRINE.local"
],
"DcPort": 443,
"DomainName": "vsphere.local"
}

Here is the configuration of the appliance deployed by the installer (I'm using a vCenter 8 installer):

See anything I'm missing?

[pmichelli]

What is the size of your Hard Disk 5? That is the log volume it is complaining about. The file shows it should be 10GB in size.  Did you extend it?

[dbutch1976]

Disk 5 is 10GB as expected, I did not extend it. Any other possibilities?

[pmichelli]

Use this list and compare each volume size to what is listed in your JSON file.  Have any of the volumes been resized?

https://kb.vmware.com/s/article/78515

memory": 14,
"lv_root_0": 48,
"swap1": 25,
"core": 25,
"log": 10,
"db": 10,
"dblog": 15,
"seat": 550,
"netdump": 1,
"autodeploy": 10,
"imagebuilder": 10,
"updatemgr": 100,
"archive": 50,
"vtsdb": 550,
"vtsdblog": 15,
"lifecycle": 100,
"lv_lvm_snapshot": 500,
"cpu": 2

Please confirm your new vCenter was selected with 2 vCPU and 14GB of memory.  These are the volumes you need to double check

[dbutch1976]

Thansk for the reply but I just decided to blow away the vcenter, remove it from the SSO domain, redeploying it and re-linking it. It means starting from scratch, but luckily this is a lab. I didn't get a chance to perform the confirmation but since it is a lab there wasn't much on the vCenter. 

I suspect this was caused because I did an upgrade from vCenter7 --> vCenter8.

Now that it's been cleanly deployed I'm going to back it up and try the restore again, if it fails this time I think it's a vCenter8 problem.

[FoW]

https://netsphere.one/@FoW/110814898832789986

I too upgraded vCenter from version 7 to version 8 (VM replacement) and am experiencing the same thing as dbutch1976.
The size info in the backup is too different from the volume info after the initial deployment, and the vCenter Installer uselessly blocks the next step. My backups are not doing their job.
I'm on vCenter 80U1.

I noticed that some volume size information was stored with incorrect values.
- lv_lvm_snapshot
- seat
- vtsdb

[pathfinder1985]

Hey team, i have same problem.

Its a lab, backup of VM currently not working, when trying to restore from vCenter file backup restore i get below error:

And edit of vCenter VM is :

I would ditch it, but its vSAN and i would hate to wreck it up....

[pathfinder1985]

I have managed to clear all except below error, any ideas?

[pathfinder1985]

I changed metadata.json and delete 1 from swap and adjusted size, ill report if restore will go as it should.

[pathfinder1985]

Huh it worked, thanks to this thread.

[truonghq54]

i have edited the JSON file and it worked

"SizeInfo": {
"memory": 30,
"lv_root_0": 48,
"swap1": 50,
"lv_lvm_snapshot": 500,
"core": 50,
"log": 25,
"db": 25,
"dblog": 25,
"seat": 550,
"netdump": 10,
"autodeploy": 25,
"imagebuilder": 25,
"updatemgr": 100,
"archive": 100,
"vtsdb": 550,
"vtsdblog": 25,
"lifecycle": 100,
"cpu": 8
},