Hi @Priyanka 

With VBO365 V5.0 , I‘m not a fan of using Object Storage as a primary Backup target for the product. You can‘t do Backup Copy Jobs.

This may change with the next version 6.0. Backup Copy Jobs for Object Storage is coming in 2022. But still no immutability for vbo365 data.

So, my recommendation would be:

1. Create a Vm (or physical machine) with local disks
2. Install vbo365 on this Vm
3. Backup the O365 Data to the local disks
4. Create a vm backup job for this vm (or machine) on your vbr server
5. Use a SOBR to offload the back-ed up VBO365 machine to an object storage with Object Lock (immutability)

https://bp.veeam.com/vbo/guide/design/3-2-1.html

I need to create VBO server on Prem and data store in disk and secondary copy save on cloud. however if first time backup will be complete and data moving from disk to cloud then what is network bandwidth.

With the vbo365 product, you can‘t move data from disk to cloud. This feature do not exist. You need a VBR server as recommend by me, or you have to create a second backup job inside vbo365 with the object storage as a backup repo.

With my approach, only changed data will be offloaded to the object storage. Necessary network bandwidth can be calculated by the amount of changed data and required time to get the upload done.

If you want to have disk and cloud inside a single vbo installation, you need to create two backup jobs and backup the data always twice. Data will be downloaded twice from O365 (first full, then only changes) and again uploaded to the cloud storage for the one job. I don‘t recommend this, because with Microsofts throttling policy, your backups will not perform correctly. To many issues with a single backup job already, a second would make the issue much worse. :)

Hi @Priyanka , as @Mildur already has mentioned : a copy-job on VBO365 is not yet possible. It will be possible on version 6, but probably only to archive object storage (AWS Glacier or Azure Archive storage).

There are in fact 2 options to implement VBO365 : on-premises or in the public cloud.

If using on-premises : be aware the extra load on your internet-connection. Also if you store the backups on regular (use only local disks or iSCSI disks - no shares) storage the data will be twice as big then if you use object storage. So, if you are having on-premises an object storage appliance : use that as the repository (offload, you first need local cache drive). If not, don’t use public object storage : you have to download everything and upload again : not a good idea!

If using public cloud : use only cache drives and offload the data to public object storage.

A shortcome at the moment is the copy-job.

A workarround : if using VBO365 on the public cloud : create 2 jobs referring to 2 different repositories (for example : one in Azure and one in AWS), then you have the data on 2 different locations.

Hope this helps you.

If you need both local and cloud then you need two jobs set up for VBO.  One will go to local storage and does not have to be on the same server as VBO and then the second job will be sent to Object Storage offsite.  Right now this is the only way to get two copies directly from VBO. As Mildur mentioned you can back up the VBO server to a SOBR and then offload it but depending on the size of the server it can take time.  It is all in how you want to handle it. The link above to the BP site is a good one.

One scenrio - if I will create create VBO on AWS cloud and data store in AWS glacier. 

                   what are the pros and cons?

2nd scenrio - if I will create VBO on prem and data directly store in AWS glacier- object storage on cloud (primary copy).

One scenrio - if I will create create VBO on AWS cloud and data store in AWS glacier. 

                   what are the pros and cons?

2nd scenrio - if I will create VBO on prem and data directly store in AWS glacier- object storage on cloud (primary copy).