hi Veeam community
I want to buy new storage for the repository and I got acquainted with the option “Backup direct from Primary Storage Snapshot”
My question is where is the best way to use this option?For what server and services it is better to use?It also has disadvantages?And finally, if you have the experience of using this feature, I would appreciate it if you could share and what kind of storage you used.
thanks
Best answer by coolsport00
Hi
You use this feature for Backup Jobs. It is best to use for Jobs which contain highly transactional VMs such as DBs because Veeam first snaps the VMs which run on a given datastore, which will then snap the datastore, to back up a Job's VMs. The advantage of this is the Snapshot taken is real quick vs the Snapshot taken using another backup methods (hotadd or directsan) can be retained a bit long.
Another advantage of using BFSS is the ability to use Veeam to orchestrate your SAN snapshots and even replicate them to a partner array. This helps you achieve the 3-2-1-1-0 rule.
One disadvantage of using BFSS is sometimes the initial processing phase of the job can take 3-5mins before backups of the VMs begin.
I do use this feature myself, and have for several years. I use Nimble storage, now called Alletra, as my backend storage for this.
Hope this helps.
+4To use this option you must have a Storage that supports Snapshots and it’s supported by Veeam.
The biggest advatange is the short time the snapshot lives on vSphere side during the backup. We explain better in the User Guide: https://helpcenter.veeam.com/docs/backup/storage/vm_processing.html?ver=120
Also, this KB shows the Storages that supports Snapshot integration with VBR: https://www.veeam.com/kb4206
+20Hi
You use this feature for Backup Jobs. It is best to use for Jobs which contain highly transactional VMs such as DBs because Veeam first snaps the VMs which run on a given datastore, which will then snap the datastore, to back up a Job's VMs. The advantage of this is the Snapshot taken is real quick vs the Snapshot taken using another backup methods (hotadd or directsan) can be retained a bit long.
Another advantage of using BFSS is the ability to use Veeam to orchestrate your SAN snapshots and even replicate them to a partner array. This helps you achieve the 3-2-1-1-0 rule.
One disadvantage of using BFSS is sometimes the initial processing phase of the job can take 3-5mins before backups of the VMs begin.
I do use this feature myself, and have for several years. I use Nimble storage, now called Alletra, as my backend storage for this.
Hope this helps.
+21Check out the links that Wesley posted as there is good information there.
When I did some testing, we were using both the Hitachi Plugin as we are a Hitachi Partner and also, I was able to thoroughly test the Pure Storage plugin with the iSCSI implementation. Worked extremely well with backups and used the storage snapshots from the array to make things much faster. Great storage for sure.
Hi
You use this feature for Backup Jobs. It is best to use for Jobs which contain highly transactional VMs such as DBs because Veeam first snaps the VMs which run on a given datastore, which will then snap the datastore, to back up a Job's VMs. The advantage of this is the Snapshot taken is real quick vs the Snapshot taken using another backup methods (hotadd or directsan) can be retained a bit long.
Another advantage of using BFSS is the ability to use Veeam to orchestrate your SAN snapshots and even replicate them to a partner array. This helps you achieve the 3-2-1-1-0 rule.
One disadvantage of using BFSS is sometimes the initial processing phase of the job can take 3-5mins before backups of the VMs begin.
I do use this feature myself, and have for several years. I use Nimble storage, now called Alletra, as my backend storage for this.
Hope this helps.
Thank you for sharing your experience, it is very helpful for me
Check out the links that Wesley posted as there is good information there.
When I did some testing, we were using both the Hitachi Plugin as we are a Hitachi Partner and also, I was able to thoroughly test the Pure Storage plugin with the iSCSI implementation. Worked extremely well with backups and used the storage snapshots from the array to make things much faster. Great storage for sure.
It was great, thank you, I will also check about hitachi, I am currently researching two brands, Hpe and Datacore.
+21Check out the links that Wesley posted as there is good information there.
When I did some testing, we were using both the Hitachi Plugin as we are a Hitachi Partner and also, I was able to thoroughly test the Pure Storage plugin with the iSCSI implementation. Worked extremely well with backups and used the storage snapshots from the array to make things much faster. Great storage for sure.
It was great, thank you, I will also check about hitachi, I am currently researching two brands, Hpe and Datacore.
If you do look into Hitachi keep this in mind - you need double the amount of storage for it to work properly for the snapshots, etc. I found this out while testing and investigating.
Hi
You use this feature for Backup Jobs. It is best to use for Jobs which contain highly transactional VMs such as DBs because Veeam first snaps the VMs which run on a given datastore, which will then snap the datastore, to back up a Job's VMs. The advantage of this is the Snapshot taken is real quick vs the Snapshot taken using another backup methods (hotadd or directsan) can be retained a bit long.
Another advantage of using BFSS is the ability to use Veeam to orchestrate your SAN snapshots and even replicate them to a partner array. This helps you achieve the 3-2-1-1-0 rule.
One disadvantage of using BFSS is sometimes the initial processing phase of the job can take 3-5mins before backups of the VMs begin.
I do use this feature myself, and have for several years. I use Nimble storage, now called Alletra, as my backend storage for this.
Hope this helps.
A question about using this method for sql database Is this method suitable for transaction logs?
+21Hi
You use this feature for Backup Jobs. It is best to use for Jobs which contain highly transactional VMs such as DBs because Veeam first snaps the VMs which run on a given datastore, which will then snap the datastore, to back up a Job's VMs. The advantage of this is the Snapshot taken is real quick vs the Snapshot taken using another backup methods (hotadd or directsan) can be retained a bit long.
Another advantage of using BFSS is the ability to use Veeam to orchestrate your SAN snapshots and even replicate them to a partner array. This helps you achieve the 3-2-1-1-0 rule.
One disadvantage of using BFSS is sometimes the initial processing phase of the job can take 3-5mins before backups of the VMs begin.
I do use this feature myself, and have for several years. I use Nimble storage, now called Alletra, as my backend storage for this.
Hope this helps.
A question about using this method for sql database Is this method suitable for transaction logs?
Not sure I would look at storage snapshots for transaction logs with SQL. You may want to look at another backup method like using the agent or CDP.
+20Hi
You use this feature for Backup Jobs. It is best to use for Jobs which contain highly transactional VMs such as DBs because Veeam first snaps the VMs which run on a given datastore, which will then snap the datastore, to back up a Job's VMs. The advantage of this is the Snapshot taken is real quick vs the Snapshot taken using another backup methods (hotadd or directsan) can be retained a bit long.
Another advantage of using BFSS is the ability to use Veeam to orchestrate your SAN snapshots and even replicate them to a partner array. This helps you achieve the 3-2-1-1-0 rule.
One disadvantage of using BFSS is sometimes the initial processing phase of the job can take 3-5mins before backups of the VMs begin.
I do use this feature myself, and have for several years. I use Nimble storage, now called Alletra, as my backend storage for this.
Hope this helps.
A question about using this method for sql database Is this method suitable for transaction logs?
Hi
Hope this helps.
+9Almost all jobs will start after a few minutes as CoolSport said. I use BFSS for all my jobs however.
It removes the stun if you have large VM’s. I have very large servers and databases that are sensitive to VM stun.
It has VMware take a snapshot, the SAN will take a snapshot, then the VM snapshot is removed immediately. Veeam continues to get the data from the storage snapshot not effecting production.
You can also do storage snapshot only jobs, or tell Veeam to leave the storage snapshots behind for a set amount of time after completion. These can be set to immutable at SAN level as well.
I have storage snapshots on almost all my SAN volumes with Veeam allowing for very frequent rolling restore points, with backups going to other storage. If you have a second SAN at an additional location, you can run a storage snapshot job to a global mirror or secondary site as well using a secondary job which is incredible.
One thing to take note of, if you have small VM’s with minimal change, sometimes using a different transport mode will complete faster. It’s good to test multiple methods and see what works best for what workload. Veeam has done a great job of improving this over the years and not leaving snapshots behind to manually delete.
Look at the Storage limitations for the following products here. My IBM equipment has worked fantastic.
https://helpcenter.veeam.com/docs/backup/storage/storage_specific_reqs.html?ver=120
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
