How to import NAS Backup?

[marcelplett]

Hello,

I had to move a NAS Backup to another disk. Now I want to import the Backup to Veeam.
When I try to import it, Veeam wants a .vbm or .vbk file which does not exist. In the root Folder of the NAS Backup there is only a .vstore file.
How do I import this Backup?

Regards,
Marcel

[Egor Yakovlev]

Add storage with moved NAS Backups as a Veeam Repository and select "[X] Search the repository for existing backups and import them automatically" at the Review step of New Repository wizard.

NAS Backups will get imported and be accessible under Home -> Backups -> Disk (Imported) for restore operations.

/Cheers!

[marcelplett]

Thanks! That worked!

[sdelacruz]

I recently started using File Share Backups to bring over users documents being saved on remote File Servers.

Most of the were able to run over our wan connection but I have several servers that have over 2 TB of data that is hard for the first full backup to complete.

What i did I ran a File Share backup at my remote location, then moved it over on an external drive.

I copied the veeam files over to my Main Veeam Backup and replication server and want to somehow feed that to my first full backup.

I tried mapping the job but I do not see the folder I moved from my external drive.

Can this be done?

Thanks in advance.

Sam

[sdelacruz]

I think I found the way. I had to rescan the backup repository. Now I can see the File Share Backup I moved from my remote File Server.

[fraack]

Hi Egor,

does this import works also for the archive repository? Was wondering about this topic because one of my customers is storing nas backup data since half a year. He bought a DataDomain for archvie purpose and we want to switch the configuration to use the datadomain as the archive repository. If we copy all the data in advance, add the DataDomain and switch the archive repo to the data domain, will Veeam realise that historical data is already there?

Or is there any other solution to move historical data to a new archive repository?

Thanks
Florian

[Gostev]

Yes, the import works for the archive repository as well.

As for migrating data between archive repositories, I'd wait for the PMs to comment, especially since Data Domain is involved - which is a non-standard repository with its own access API, meaning you cannot just copy data there normally.

[Dima P.]

Hello Florian,

You can move the nas archive (entire folder with the nas backup job name) from one repository to another, do a rescan of such repo and then restore will be possible. However, it's not possible to map existing archive to the job, so when the archive repository is changed in the job properties we will start a new archive. Cheers!

[restore-helper]

Another question, is it true that one can not map an existing backup chain ( from a NAS backup to an NAS backup job or an NAS backup copy job?

[Egor Yakovlev]

Backup Mapping option for NAS backups as of today available only for primary NAS Backup Job data.
You cannot map NAS Backup Secondary Backup data nor NAS Backup Archive data.
/Thanks!

[manaboom]

Hi and thanks for this info however after I try to restore the imported backup, I am then getting an error (cannot upload image of screenshot here): Agent: failed to process method; {MetaExtent.InitBackupStorage}:Failed to pass link: blahblahblah.
This for me is only a restore simulation from external disk but I would like to figure out what went wrong to avoid panic in live moments. Thanks for any info.

[Mildur]

but I would like to figure out what went wrong to avoid panic in live moments.

Looks like Veeam Support can help you with that. Please open a support case.
They will find out whats happening with the debug logs.

[talltim]

We recently moved our File share backup repository from an Azure VM to a local physical Windows server. All new backup go to the new repository OK. I copied the backup files from the Azure VM before it was removed, but I can't work out how to add them back into VBR.
This page is about VM backups https://helpcenter.veeam.com/docs/backu ... ml?ver=110
The files are on one of the existing repository servers, but on a different drive to that mapped in the repository in use for backup jobs
I have tried adding a new repository pointing to the drive, with the Search the repository for existing backups... setting ticked, which takes only a few seconds on the finding backup section and doesn't add anything into the Disk (Imported) section. Running a rescan on the new repository reports No backups found.
The backups contain .vstore. .vstorecopy, .vindex, .vslice and .vblob files
I'm sure I'm just doing it the wrong way, could anyone point me in the right direction?
Thanks

[Mildur]

Hi Tim

I moved your question to this topic.
Please follow Egor's advice in his first comment. File Share Backups will be imported on a rescan.
There is no Import Button for this sort of backup.

Best,
Fabian

[talltim]

Thanks Fabian. I had found this topic and done as Egor suggested, but the backups do not appear in Disk (Imported). If I have been doing the right thing but something isn't working I will log a case.

[Mildur]

Hi Tim

Yes, a case would be helpful. Please provide us the case number.
Please also check that your files are in the right structure. If not, maybe that can be the cause why you don't see backups.
https://helpcenter.veeam.com/docs/backu ... positories

Best,
Fabian

[talltim]

Ah, I think I know the issue. The files I have are an archive, not a backup.

[Max93]

Hello everyone,

we have set up a backup job intended to retain all files from the last 30 days without deleting any. However, we now need to restore a file from October 2023. Unfortunately, under "Backups" in "Veeam Backup & Replication v12," it does not display the restore points until January 1, 2024.

How can we import the old .vblob files into the backup? The "Import" function only allows us to import ".vbm" or ".vbk" files.

We still have all ".vblob" files available up to November 2022.

We hope you can assist us.

Thank you very much.

Max93

[Mildur]

Hi Max

I suggest to open a case with our customer support team. They will assist you in troubleshooting the import issue.
Normally you should move the entire folder with all NAS backup files (keep the exact structure) to a repository and rescan the repository. Backups will then be imported.
Please note, don't mix your old and new backups in the same folder. I don't know in what state your vblob files are. Are those from another backup job or the same job which is still active? Then importing may become difficult.

Best,
Fabian

[Max93]

Thank you for your help @Mildur - I have forwarded the case to the support team as we were unable to import / rescan the backups.

[Mildur]

Hi Kiara

Manual import only works for machine backups (VBM or VBK required).
For NAS backups, you need to copy the entire NAS backup folder to the repository and run a rescan. Manual import doesn't accept *.vstore files.

Best,
Fabian

[Max93]

Hey Mildur,

Unfortunately, even that doesn't seem to do the trick. Particularly when I attempt to copy the entire NAS backup folder via Windows, it proves problematic. Surprisingly, even the slightest move of a single file ends up causing the complete destruction of the SMB file share backup.

SMB file backups are quite delicate, aren't they? The metadata seems especially sensitive. It's something that might be worth considering for improvement in the future.

[Gostev]

They are not more or less delicate, the idea is exactly the same as with image-level backup including redundant metadata. Just spread out to more files for scalability, otherwise it would be impossible to support PB-scale file shares, which was the design goal.

Sensitivity is also the same as with image-level backups. Where "even the slightest move of a single file" will make your latest backup unrecoverable. Just try moving a VBK or any one VIB out of the chain...

So to be safe, in both cases you should copy/move the entire root folder with your backups, and never touch individual files. There's no situation when managing individual files is a good idea. Just like with image-level backups on object storage for that matter, where you should never manage individual objects.

Now, if the "entire copy" approach does not work, then this is definitely unexpected or a known issue, so this should be reviewed with our Support. As this potentially indicates an issue with the primary backup, which might be incomplete due to a storage-level corruption. You should take it seriously, as effectively what you're doing is a DR test in the scenario where "everything is lost" except actual backups.