Author name: Managecast Technologies

Veeam Backup for Salesforce provides complete access and control of Salesforce data and metadata, as well as providing powerful, rapid-recovery capabilities for IT departments and Salesforce administrators. Veeam recently announced the launch of its newest product offering – Veeam Backup for Salesforce. Salesforce is one of the most utilized CRMs in the world because of its advanced features, but many don’t realize the importance of backing up Salesforce data. Do I need to back up Salesforce? Some users think Salesforce is responsible for backing up the data. Still, it clearly states, “It is important for Salesforce customers to develop a routine data backup strategy as part of their overall data management and security model.” We often talk about the Microsoft shared responsibility model, and Salesforce follows the same rule. Even though Salesforce manages the infrastructure, this doesn’t replace YOUR responsibility to protect Salesforce from data loss and data corruption. Key Capabilities Veeam Backup for Salesforce eliminates the risk of losing your Salesforce data and metadata — so that your business is reliably protected, giving you complete control. Key capabilities include: Salesforce native: Purpose-built to create backups and restore Salesforce data and metadata Fast and flexible recovery: Restore Salesforce records, hierarchies, fields, files and metadata Secure data: Run a backup environment anywhere, on-premises or in the cloud (AWS, Microsoft Azure, etc.) Custom scheduling: Set granular backup schedules and retention settings at the object level Simplified management: Manage several Salesforce instances from one console Incremental changes: With incremental sync and flexibility scheduling, you can back up your Salesforce data and metadata almost continuously Simple and easy-to-use UI: Run backup policies and restore jobs in minutes See and compare: See versions of records and metadata and quickly compare them with production Restore hierarchy: Granularly restore linked objects to any record, including parent/child records Ready to start? Getting started is simple! Veeam provides a licensing structure that aligns with your Salesforce usage. From now until December 31, 2022, Veeam has special pricing on backup for Salesforce: 50 users or less – FREE! Up to 300 users – $2,000 USD for the first year Unlimited users – $10,000 USD for the first year At Managecast, we fully manage and monitor your backups so that you can focus on more strategic initiatives. Interested in learning how Managecast can help your business with its cloud backup and disaster recovery solutions? Fill out this form for more information!

We recently ran into an issue where a Veeam Cloud Connect replication job started to fail with the error: Restore point is corrupted We noticed that the source for the replication job was set as the offsite backup copy job, but the source backup copy job was also failing with the following error: Looking into the error message, this can happen when the backup server is rebooted or loses connection during the offsite backup, and it causes things to go out of sync. It is possible this can be resolved by just rescanning the repository and re-enabling the backup copy job. We tried this, but the rescan on the repository came back with an error “XYZ Cloud repository: Failed to synchronize 1 backups.” After a bit more investigation, we determined that the VBM file in the customers’ repository had a size of 0 MB. This indicated that the metadata file had been corrupted and needed to be recreated. Veeam can typically recreate the VBM file as long as the job and remaining backup files are intact. In this case, the solution for this issue was to: Disable the backup copy job. From the Cloud Connect provider side, access the customers’ backup repository. Rename the backup metadata file to “XYZ.vbm.bak” Then rescan the repository from the customer’s backup server. Re-enable the backup copy job. This time, the rescan completed successfully. The backup copy and replication jobs were re-enabled and the next run for each completed successfully.

This is an error that occurs when an instant VM recovery has started. Then, the backup copy job runs while the instant VM recovery is running and has not migrated to production. The original VM is deleted and replaced by the one that is in the instant VM recovery mode. The local job can pick up on this change and backup the new VM that is running on the backup storage. However, the copy job begins to have a bug that causes the whole job to fail. Even if you remove the data from the offsite location and remove the VM from the local job, the job continues to fail. The error also will not list out the VM that is causing the issue, but we have only seen this error occur after one of the VMs in the job has gone through an instant VM recovery. The first thing that needs to be done is to migrate the new VM from the backup storage to production. The new VM should already be in the local job, and it can be left in there. The issue is fixing it on the offsite location. Doing a rescan on the service provider or removing the data for that VM does not work. For this to work, the backups also need to be set to Per VM backup chain. If they are not set to Per VM Backups, then this solution will not work. Next, you need to remove the Per VM chain of the VM that is causing the issue. It cannot be removed from the Veeam Console or else it will display this error: The VM needs to be removed from the service provider side in the repository. Once this is deleted the issue will still be there. Even though all the past data is gone, it will still show the same error for the whole job, and none of the other VMs in the job can be backed up. The final step is taking all the data from the job and moving it outside of the tenant directory on the service provider side. It needs to be moved outside of the tenant directory and rescanned from the tenant side in Veeam. After the rescan, the job data should no longer show up under the backups section. You will then want to move that job data back into the tenant directory from the service provider side in the same way that you moved it out. Next, you will want to do another rescan on the tenant side in Veeam. The job should show back up in the backups section. You will want to ensure that the Copy Job that was getting this error is mapped to the job correctly. After that has been completed, the job should be able to transfer data for the other VMs in the job. I have seen where the VM that was causing the issue fails after this but the other VMs have been able to run. My solution to that was to make a separate local job and offsite job just for that VM and get all new data for it.

In the Azure portal, you will select the storage account that your file share is currently being stored in. Select the File share that you want to backup with Veeam. Click Connect up in the left corner of the screen. Next, you will want to open up Veeam Backup and Replication. Go to Inventory, then under Inventory select File Shares. Select Add File Share. You will want to select SMB Share. When it asks you what shared folder to use, you will have to use the path of \\URL\fileshare In our case, it would be \\teststoragefileshare.file.core.windows.net\blogfileshare. You will then want to check the box next to “This share requires access credentials:” Click Add next to the credentials. Go to the text file that you saved with the connection configuration. In that file you will want to look for the /user: after that will be the username you will use. Then look for the /pass: and after that will be the password. Click Next and it will take you to the processing page. Adjust as you need to then click Apply. Click Finish and your SMB Share will be saved to Veeam. You will Then want to back up the SMB share. Right-click the file share and select Add to backup job, then New Job. Specify a name for the Job, then click next. The Fileshare should already be in there, click next again. Pick the backup repository that you would want the Fileshare backed up to. There are also other settings you can specify here as well. Click next on secondary target and then you will be in schedule. Schedule the backup for whatever time works best for you and click Apply. Finally, check the box for “Run the job when I click Finish” then click finish.

Overview Generally, it is good to be informed of low backup storage situations on Veeam repositories. Running out of disk storage during backup operations can result in corrupted backups. By default, Veeam is configured to trigger a warning notification when backup storage space is 10% or less free space. For example, if you have 1TB of storage and the notification is set to warning at 10% left then it would trigger when there is 100GB or less space.  It is good to be aware of low disk space situations so we can proactively address the issue before it leads to a problem. However, in some scenarios, 10% can trigger nuisance warnings that make all affected jobs turn yellow (warning). For example, if there is 50TB of storage then warnings are going to be issued with 5TB left on the disk. In this situation, it may not be justified to resolve the issue as there is still a lot of free space Solution We recommend changing the notification settings when 10% of free space is still more than adequate for current needs. Changing these settings will return the backup jobs to green instead of showing up as warnings. Our goal is to keep all jobs green so we do not have to investigate why they are not. Green is good!  Do not change these settings if you do not feel comfortable that you will not run out of space!  Changing the value from 10% to 1% may not be wise. We recommend decreasing the threshold to only that which will resolve the issue, for example, changing from 10% to 7%. Note: This guide will work for Hyper-V hosts and VSphere hosts. Changing Veeam repository low-disk notifications First, log into your Veeam appliance. In the top left corner click the drop-down and select General Options. Next, click the notification tab. Then you will see an option for backup storage, there will be a checkbox next to it that says “Warn me when free disk space is below:”. You want to leave this box checked. Next to that will be a percentage. You are going to want to change the percentage from 10% to what fits best for your storage. We recommend cutting it in half to around 5%. You will then want to change the option “Skip VM processing when free disk space is below:”. You will want to lower that percentage to ensure that the VMs are not skipped from processing when there is plenty of storage. Summary Once the notification settings are made to verify future backup jobs return green status.  Take care to leave the threshold at a reasonable percentage as to notify you in the future if disk space gets dangerously low.