spen_lang
asked on
Veeam Backup (VSS Enabled) Snapshot Causes Server to go Offline
Hi,
We are running a Veeam backup of one of our most important VMware guests. This VM Guest must stay on-line 24/7 and therefore we do not have a designated backup window, we must do it on the "fly".
The VM Guest has Sysbase SQL Anywhere 11 installed with a 17+GB database. The VM Guest is backed up using Veeam with "Enable application-aware image processing" set as true.
The problem we have is that when the VM Guest is being snapshot or the snapshot is being released we will lose pings to the server (network connection drops for a second or so a few times), which then causes the ODBC connection from the client's PC to the database to error.
I have contacted VMware and they have responded by saying that this is a known problem for VM Guests that have heave I/O loads.VMWare KB Their solutions were not helpful... System downtime during backup windows is not an option and we need to find a solution.
Should I be using "application-aware" image processing (VSS) in Veeam? As far as I understand this is a must to get consistent backups (e.g. OS files that are not corrupted).
I have had a browse through the Veeam Task logs and noticed a line VSSControl: Frozen in 12sec, could this be causing a problem?
I would be grateful of any help on this issue or information from people who have also experienced this type of problem with VMWare and how it was worked around.
Thanks, Greg
We are running a Veeam backup of one of our most important VMware guests. This VM Guest must stay on-line 24/7 and therefore we do not have a designated backup window, we must do it on the "fly".
The VM Guest has Sysbase SQL Anywhere 11 installed with a 17+GB database. The VM Guest is backed up using Veeam with "Enable application-aware image processing" set as true.
The problem we have is that when the VM Guest is being snapshot or the snapshot is being released we will lose pings to the server (network connection drops for a second or so a few times), which then causes the ODBC connection from the client's PC to the database to error.
I have contacted VMware and they have responded by saying that this is a known problem for VM Guests that have heave I/O loads.VMWare KB Their solutions were not helpful... System downtime during backup windows is not an option and we need to find a solution.
Should I be using "application-aware" image processing (VSS) in Veeam? As far as I understand this is a must to get consistent backups (e.g. OS files that are not corrupted).
I have had a browse through the Veeam Task logs and noticed a line VSSControl: Frozen in 12sec, could this be causing a problem?
I would be grateful of any help on this issue or information from people who have also experienced this type of problem with VMWare and how it was worked around.
Thanks, Greg
1. Complete the backup at a quite time.
2. Your storage maybe too slow, for Veeam Backup (and Snapshot based backups).
So what is your storage?
2. Your storage maybe too slow, for Veeam Backup (and Snapshot based backups).
So what is your storage?
Have you contacted Veeam about this issue, Veeam support is excellent ask them to look at your backup job, they know exactly how to fine tune the job for optimal performance and reliability.
Send them the job logs and veaam server logs for them to analyze.
They disabled application aware processing on my backups to improve performance and replication reliability on my server not to long ago.
Something you can also consider is to take a snapshot of the VM and start that. Then you can at least play with the duplicate (snapshot) server and then it wont effect your production environment. Until you can get it fixed.
DirkMare
Send them the job logs and veaam server logs for them to analyze.
They disabled application aware processing on my backups to improve performance and replication reliability on my server not to long ago.
Something you can also consider is to take a snapshot of the VM and start that. Then you can at least play with the duplicate (snapshot) server and then it wont effect your production environment. Until you can get it fixed.
DirkMare
ASKER
I have contacted Veeam and I agree their support is excellent, however, I have been told that this is a problem with VMware and snapshotting heavy I/O guests.
I have now managed a work around. The guests main vmdk files (C and D) are located on very quick SAS disks (HP left SAN), there are 4 additional vmdk disks that I backup the database too and the vmdk files are located on SATA disks. I have converted the vmdk files that are on the SATA disks to independent persistent disks so that they are not affected by Snapshots. I have also changed the timing of the backup. THe combination of the two seem to have fixed the issue.
However, I am now stuck with the problem of, how can I backup an independent disk using Veeam when the disk is not in the snapshot of the server?
Thanks, Greg
I have now managed a work around. The guests main vmdk files (C and D) are located on very quick SAS disks (HP left SAN), there are 4 additional vmdk disks that I backup the database too and the vmdk files are located on SATA disks. I have converted the vmdk files that are on the SATA disks to independent persistent disks so that they are not affected by Snapshots. I have also changed the timing of the backup. THe combination of the two seem to have fixed the issue.
However, I am now stuck with the problem of, how can I backup an independent disk using Veeam when the disk is not in the snapshot of the server?
Thanks, Greg
However, I am now stuck with the problem of, how can I backup an independent disk using Veeam when the disk is not in the snapshot of the server?Veeam doesn't support independent-persistent disks for backup and replication jobs, because they were designed by VMware to provide an easy way of excluding a disk from a snapshot ("independent from shapshots").
This is to be expected as per @MaximVeeam post, http:#a39716073.
It's by design.
Why not move ALL the VMDKs to SAS disks, rather than SATA?
It's by design.
Why not move ALL the VMDKs to SAS disks, rather than SATA?
ASKER
The reason we have some vmdk files on SATA is because we have limited SAN\SAS storage. So the only approach to copy the database backup files on the SATA disk is by scripting a copy of the file?
You could use SQL Manager to copy the databases, or Stop DB, copy flat databases, and restart the DB.
Faster storage is recommended.
Faster storage is recommended.
ASKER
The problem I have with any tools is that it is a Sybase database. I am using Sybase Central to backup the database to the SATA disk, which is working fine. I now need a solution to copy the backup files to a remote location. I was hoping Veeam could do this, but I guess I may have to revert back to Symantec BackupExec...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Are you using the latest version of VEEAM?
Does the VM in question have adequate resources such as CPU, memory, and is it normally struggling with disk IOPs?
What are you trying to back up to? Is it fast enough to take care of the issue?
Can you move the backup to another time of the day when the DB may be less busy?
We back up a MS SQL VM that is way larger than your without issue. We did have some slowness issues with another very very busy VM and solved that by giving it more resources.