HP StoreOnce shares to catalyst stores

[andriktr]

Hello,
I have question about HP StoreOnce catalyst. At this moment we use HP StoreOnce shares as backup repositories in Veeam B&R 8. Planning to upgrade to version 9 soon.
But it’s still unclear for me how to migrate our existing data from share to catalyst stores and configure existing jobs to use catalyst.
The only note that i have found about in the new user guide was:
"If you have added HP StoreOnce shares and stores as backup repositories in Veeam Backup & Replication 8.0, after upgrade to 9.0 these stores and shares will be presented as shared folder backup repositories. To use the HP StoreOnce Catalyst technology, remove these shares and stores and add them once again to the backup infrastructure"
Thank you.

[foggy]

Andrej, the recommended way to migrate between CIFS and Catalyst Store is as follows:

1. Add the StoreOnce device as new Catalyst repository.
2. Clone existing jobs that point to CIFS share.
3. Change target repository in the cloned jobs settings, pointing them to the newly added repository.

This will trigger active fulls on all these jobs and create completely new backup chains, however this is still required for the new per-VM backup chain feature (which is mandatory for StoreOnce Catalyst repositories due to its current inability to provide concurrent reads) to take effect.

[andriktr]

Thank you for the quick response.

[kte]

how do you clone the data? filecopy job?

[andriktr]

What do you mean when saying "clone the data" you should clone only jobs change target repository in the cloned jobs settings, pointing them to the newly added repository.
You can't use old jobs (backup data) point them to catalyst stores and copy old data.
You should create new job that means new backup chain.
In some cases, for example if your old jobs have long retention policy, this scenario sounds not very good because you will need to manually manage/delete backup files which are out of backup retention policy

[foggy]

Right, you do not need to copy existing data to the new Catalyst repository. Though, there are workarounds to do that, we still recommend to start chains anew, to enable per-VM chains. Existing backup data can be left aside in old repository until it reaches the retention and then be deleted manually.

[andriktr]

How about backup copy jobs with GFS retentions? Your recommendation to create new jobs also valid here?

[foggy]

Yes, this is a global recommendation for StoreOnce repository.

[DaveWatkins]

Is there any process for moving existing backup data from, for example a windows repository to a StoreOnce dedupe device when using it in Catalyst mode?

There doesn't appear to be any way to copy to the StoreOnce manually, and Veeam doesn't seem to have any way to automate the process.

On that note, it would be _really_ useful for Veeam to be able to migrate existing backup data from one repo to another (including the custom dedupe devices) without having to go to the repos and manually move the data then map it into the backup job

[nielsengelen]

On that note, it would be _really_ useful for Veeam to be able to migrate existing backup data from one repo to another (including the custom dedupe devices) without having to go to the repos and manually move the data then map it into the backup job

Don't really have an answer about the StoreOnce part but for this you can use Scale-Out Backup Repositories and put repositories in maintenance mode and evacuate backups so we move everything for you around.

[nefes]

You could find several creative workarounds (including Evacuate) to move backup chain to StoreOnce Catalyst.
However it is highly recommended to use completely new chain.
Main reason for this is Storage Per VM option. It is not accidental decision to make this option mandatory for StoreOnce Catalyst:
This store supports exclusive read only. So If you have large vbk with tens/hundreds of VMs you can't restore two of them simultaneously. And even some Backup/Backup Copy activities will fail due to inability of concurrent read.

Try it, and you will be surprised by active full speed with necessary paralleling in place.

[veremin]

Dave, your post has been merged into existing discussion. Take a look at the answer provided by Foggy for the description of recommended approach. Thanks.

[millardjk]

To start with, the ScaleOut migration doesn't work. No explanation why, but it doesn't (in practice). And while I totally understand the desire to get things migrated by using a new per-VM chain, this does NO GOOD when trying to seed a remote copy.
There is a copy/paste function in the UI (look under Files and you'll see the StoreOnce repos and be able to do some minimal file manipulation on them). They are no, however, valid targets for a File Copy job, and I've found hit-and-miss results (mostly miss) with trying to copy large files over to the Catalyst store: horrible errors thrown when trying to rescan the repository or open the backup for recovery or adding a new incremental to the chain.

[Gostev]

Hi, Jim. Do you have support case ID for these two issues you mentioned? This is something I'd certainly like the corresponding QC to take a look at. I am even curios because these migration scenarios were ready in advance and very well tested (in other words, it was not an afterthought use case). Thanks!

[millardjk]

I'm planning on opening a case for the latter (the copy+paste for seeding a copy job) but haven't yet due to other constraints. I wasn't going to worry about the former because it's a sub-optimal option: it really does have a positive impact on performance & dedupe/compression on the StoreOnce to leverage per-VM storage, and simply migrating a monolithic VBK+VIB chain will never get you there...

[Gostev]

Thanks! And you are right about per-VM with deduplicating storage.

[millardjk]

Case re: unusable seed copy job on Catalyst store after copying from portable media to StoreOnce using "COPY+PASTE" method in Files panel. 01707863. Additional information about environment & logs in 01704762; in this second case, the same symptoms apply, but were presumed to be the result of a bad copyjob source (there were some errors in the original copy job that created the VBM/VBK on the removable media).

I suspect that there's some Catalyst-related information that isn't set properly in the file copy process; Veeam seems to be able to read the VBM (it does create a database entry for the job in the "Imported Backups" area), but dipping further into the VBK just throws a fatal error (OSCLT_ERR_INVALID_OBJECT_KEY_FILTER) and the entire repository rescan fails.

Although the rescan fails, the presence of the job in the "imported backups" node allows the original job to have the target moved to the StoreOnce, and the job can be saved, but as soon as it tries to execute, repository errors get thrown out like candy at a parade (more of the aforementioned errors). Client has multi-terabyte backups that we need to seed in this fashion, and it can't even handle a ~150GB VBK...

[SyNtAxx]

To start with, the ScaleOut migration doesn't work. No explanation why, but it doesn't (in practice). And while I totally understand the desire to get things migrated by using a new per-VM chain, this does NO GOOD when trying to seed a remote copy.
There is a copy/paste function in the UI (look under Files and you'll see the StoreOnce repos and be able to do some minimal file manipulation on them). They are no, however, valid targets for a File Copy job, and I've found hit-and-miss results (mostly miss) with trying to copy large files over to the Catalyst store: horrible errors thrown when trying to rescan the repository or open the backup for recovery or adding a new incremental to the chain.

I have found scale out repo migrations/evacuation to not work correctly either.

[Gostev]

There are currently no known issues with scale out repository evacuation functionality, so I tend to suspect a storage-specific issue here.

[millardjk]

Steps to reproduce migration issue:
1) copy or create (new) a backup chain on a StoreOnce-based share.
2) create a scale-out repo using the SO share and a SO Catalyst Store
3) evacuate the SO share repo.
4) die of old age before it actually accomplishes anything

Steps to reproduce the seeding issue:
1) target a removable NTFS-formatted drive with a copy job
2) using the File tool in the Veeam console, copy to folder from the removable media to the ShareOnce Catalyst store
3) rescan catalyst store.

*if possible, the source for the copy job should be a different StoreOnce store on a different StoreOnce using a different mount server.

[foggy]

While there are no known issues with scale-out repository evacuation functionality itself, it is not supported for the "migration to Catalyst" scenario. There's some specifics in how metadata is stored in the backup file on Catalyst Store and attempts to write backups stored on a regular repository to Catalyst will fail.

[Markus.K1985]

Ist there something on the Roadmap to close the gap?

[foggy]

Markus, the recommended way of migration is described in the beginning of this thread. Seeding is not an option here, since for the per-VM backup chain setting to take effect, you need to perform an active full anyway.

[Markus.K1985]

I'm aware of this.

I was thinking about an option to Import a existing Backup (*.vib) on NAS or local Disk to a Catalyst store.

[foggy]

No plans in this regard at the moment.

[Markus.K1985]

Is an enhancement request for that possible?

Should work for DDB an Catalyst... An ist good Step in to the Enterprise Market!

[foggy]

Thanks, your request is accepted.

[gdavid16]

anyone using catalyst shares, how many VMs are going at once? we are constantly seeing COFC errors when we do to many jobs/tasks at the same time.

[Gostev]

Hi George, you want to avoid pointing too many tasks to the same StoreOnce unit, because its limit of concurrently open files is very low comparing to other storage devices. I voiced my concern about this to HP back when we started working on the integration, and was assured this is something they will address in close future. But for now, from reliability perspective it is best not to run too many simultaneous tasks against StoreOnce, or you will keep hitting the limit. Thanks!

[gdavid16]

felt bad for thread hijacking.
vmware-vsphere-f24/hp-storeonce-catalys ... ml#p192649