Skip to main content
  • EN

I see one more change in VBR V11 Beta - the handling of exported backups and of backups with no associated backup job.

 

Exported Backups:

Up to V10 exported (disk) backups were put in the section “Disk (imported)”

In V11 the exported backups are put in another section - “Disk (VeeamZIP)”. Up to V10 I have seen this section when creating a VeeamZip archive intentionally only.

 

Backups from deleted backup jobs:

Backups which were created from deleted backup jobs were put in the section “Disk (Imported)”, too. In V11 there is a new section: “Disk (Orphaned)”

 

I think this describes the status of these backups much better than before.

Looks great, thanks for sharing! 

What happens with files, not in configuration database at all? I have a problem at a customer: there are a few TB of files not known by VBR. Would this files be shown as orphaned? Did you test this?

You mean Backup Files without a backup job just copied into a repository?

After a rescan of the repository the backups appear under “Disk (Imported)” in V10 and V11. I think “Disk (Imported)” makes sense in this case.

Yes, when you say it this way, it sounds logical! :thinking: I think I mean files, created by VBR but may be corrupted by a application or server crash. I thought these kind of files cause my problem. But in the meantime I am not sure about this any more.

Ok… corrupted files due to a incomplete job because of a server crash…

I don’t think this will be fixed with a rescan. Perhaps this is a job for the backup validator?

Ok… corrupted files due to a incomplete job because of a server crash…

I don’t think this will be fixed with a rescan. Perhaps this is a job for the backup validator?

You probably right!

So it is even with v11 a good idea to search for orphaned files with a script that looks for each file in filesystem if there is a restore point accordingly in database.

Can you manually import those files or extract them with the Extract Utility?

Oh yes! Struggled with staggered data before. That's a good fix.

Yes, when you say it this way, it sounds logical! :thinking: I think I mean files, created by VBR but may be corrupted by a application or server crash. I thought these kind of files cause my problem. But in the meantime I am not sure about this any more.

I have some news about this: in an older build of 9.5 there was a bug, it causes vib-files left on repository without any reference in Veeam DB. File was merged with full correctly but at deletion something went wrong. In my case, this behavior was corrected after the upgrade to v10. So we are analyzing with files can be deleted at filesystem-level.

It would be interesting if such files are recognized by a Repo-rescan in v11.

I usually set up jobs for VMs which will then be decommissioned. We keep these backups for years and remove backup jobs for a clean situation. When removing a job, I personally don't like the "Disks Orphaned" entry: it sounds like something wrong but it's just a cosmetic consideration. In fact, I prefer "Disks Imported". This can be achieved in this way: delete the backup job, execute "Remove from configuration" on the backup file and then perform a rescan of the Backup Repository. Backup will be listed in the “Disks Imported” section and the repository column will display right informations. I hope it will be useful.

 

If you delete the job the backup remains marked as orphaned

 

When I export a backup it would be very interesting to be able to rename it custom. :P

You can only write la restore reason.

I don't understand the purpose, because I'm exporting a backupp not running a restore...

 

I think this field is named wrong.

The text written in this field is for reference only and has no effect on the restore or export.

You could write this in the forums. There is product management  reading...

Comment


Terms & Conditions