Export restore point?

[sosborne]

Now I am not sure if this is the right way to phrase this, or if indeed what I am suggesting is possible, but can you export a restore point from a backup job and import it to another? Let me set the scene the two backup jobs are for the same VMs, are taken per VM, are all active fulls, are for separate retention policies a 24 restore points (on a monthly manual schedule) and 7 restore points (on a yearly manual schedule). However there was some confusion over when to take the annual so it happened at start of January rather than the end of the tax year. Ideally I want to export the annual from that job/policy and bring it in to the monthly. Can it be done?

Obviously as a low tech option I could remove it from the db, keep it elsewhere and then decrypt/import it if I need that particular point. However this is probably going to get forgotten about when it comes to deletion two years down the line.

All suggestions welcome.

BTW the reason the for the separate jobs as opposed to backup copies is to take only active fulls as retention points, and have greater control over scheduling.

[foggy]

Hi Simon, I understand your choice in favor of regular backup jobs, but what you're trying to achieve is not possible, such "exported" restore point will not be picked up by another job's retention. Thanks!

[sosborne]

Ok good to know thanks.

I had a feeling this may be the case. I will leave the files etc as is and just make a note in the docs (by the time the RP cycles out it will be irrelevant). The schedules have already been altered to accommodate the tax year.

[veremin]

Not sure whether it helps in your case, but starting from Update 4 you can export the selected restore point to independent full backup and set the desired retention on it. Thanks!

[sosborne]

Interesting development...

Hmm after an unfortunately timed system wide task scheduler service my annual backup job didn't run (testing was fine). So being left with no yearly backup job I am contemplating my options.

1. If I simply copy the vbks of the same VM's from a four week rotation job (synthetic fulls) that ran the same day (the others should have) into a separate folder and repository will they be effectively independent of the original jobs?

2. Or shall I upgrade my 9.5.0.1922 system to 4a (assuming there are no implications for a system with a W2K16 ReFS repository) and then export the restore point to an independent backup? Is it possible to export the backup without removing the restore point from the original retention (more of a copy export if you like)? And can this export be used as the import as a restore point for an existing job?

[sosborne]

That should have read: unfortunately timed system wide task scheduler service failure

[veremin]

1. If I simply copy the vbks of the same VM's from a four week rotation job (synthetic fulls) that ran the same day (the others should have) into a separate folder and repository will they be effectively independent of the original jobs?

Yes, they will.

2. Or shall I upgrade my 9.5.0.1922 system to 4a (assuming there are no implications for a system with a W2K16 ReFS repository) and then export the restore point to an independent backup?

Also a valid option.

Is it possible to export the backup without removing the restore point from the original retention (more of a copy export if you like)?

This is exactly how the said feature works.

And can this export be used as the import as a restore point for an existing job?

Can you elaborate on "import as a restore point for an existing job"? Can you inject the exported restore point into existing backup chain? No, you cannot.

Thanks!

[sosborne]

Can you elaborate on "import as a restore point for an existing job"? Can you inject the exported restore point into existing backup chain? No, you cannot.

Thanks for the response.

Does that apply even if the job has no existing backup chain (currently there are no restore points/backup chain)? Or can the independent backup be turned into a backup job as the start of a chain?

[sosborne]

I did the update to 9.5 4a which was straightforward (apart from a minor issue with the remote servers not initially updating their installer components).

I have since done some testing with both the export function and the copy method. At first I thought the copy method was going to be the way to go as the export doesn't give you any option to provide a meaningful name, as it uses the VM name and current date, which is slightly irritating if you are keeping it long term. But if you rename the job inside the vbm file, the vbm file itself and the folder too for consistency then the job can have a meaningful name at all levels. It's best not to rename the vbk but then the name is the VM and RP date so its just what you want.

I found that the copy didn't work well. If I only copied a vbk, and not the vbm it didn't seem to detect it after a rescan and place it under Disk (Encrypted) (I am working with encrypted backups). If i tried to import from the vbk directly even if I used valid credentials it doesn't import. I am guessing you need to have the vbm with an encrypted backup but then it has knowledge of the other VM's an restore points in the job which is messy to say the least.

FYI I fixed the update issue on the remote servers by removing the installer component on the servers concerned and then modifying the server properties in Backup Infrastructure > Managed Servers which then pushed out the latest installer to the remote servers. I don't know how critical it is but I do know that I had the same issue going to update 3a. Is there someone I should feed that back too?

[veremin]

Or can the independent backup be turned into a backup job as the start of a chain?

Yes, it can be used for backup seeding/mapping, if that's the question. Thanks!

[sosborne]

Thanks thats it

[sosborne]

A minor quibble with the export function is that it works on a per VM basis (which is good from the perspective that we backup per VM) but irritating given that running it on all my jobs (and all VM's in the jobs) for one given day generates a lot of separate backups under Import. And despite tweaking the vbm metadata so the job name is identical for each VM usually backed up by the same job (e.g. SQL Systems for all SQL Servers) it doesn't recognise that within the console and all of the backups still appear under individual albeit now identically named backups under Import. So this view will get very busy. I guess there must be some sort of id within the file, or perhaps the vbms need to be concatenated as opposed to individual, but I don't think I am comfortable with that level of tweaking especially given the backups are encrypted.

Any tips?

Its a shame I can't just copy the original vbks given they are encrypted and import them as its seems to require the vbm.

[Gostev]

I checked with the devs, and you should definitely be able to just copy the original VBKs and import them.

[sosborne]

Yes it is. And I have since done so (i was selecting the VBR server and not the repository server in the wizard). However no vbm seems to generated after the fact to give you metadata to tweak so short of going into the db I don't see a way to rename the job/backup name etc.