We have the standard version of Veeam. We are just backing up the C drive of our SQL server. Our environment has the need for in guest ISCSI attached database LUNs. With application Processing enabled Veeam does an API call on all VSS writers on this server which causes our SAN to take a SNAP of all attached LUNs. We wanted to still use application processing to get an application consistent backup of the C drive but we did not want the SAN to take SNAPs every time we run a backup of LUNS that we are not trying to backup. Is there a way to prevent Veeam from calling to the VSS writer for our SAN? Unfortunately Standard does not have the option to exclude volumes from application processing like the Enterprise version. I don not want to have to buy Enterprise to fix unwanted behavior caused by the backup process.
We're using VMware 6.0
-
- Novice
- Posts: 5
- Liked: 1 time
- Joined: Feb 23, 2017 3:31 pm
- Full Name: Brian Squillace
- Contact:
-
- Product Manager
- Posts: 6408
- Liked: 724 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: Veeam causing an uninteneded SAN SNAP
Hi,
May I ask you to provide the list of VSS writers that are available on the host?
Thank you
May I ask you to provide the list of VSS writers that are available on the host?
Code: Select all
vssadmin list writers
-
- Novice
- Posts: 5
- Liked: 1 time
- Joined: Feb 23, 2017 3:31 pm
- Full Name: Brian Squillace
- Contact:
Re: Veeam causing an uninteneded SAN SNAP
Below are the writers from the server in question:
Code: Select all
C:\Windows\System32>vssadmin list writers
vssadmin 1.1 - Volume Shadow Copy Service administrative command
(C) Copyright 2001-2013 Microsoft Corp.
Writer name: 'Task Scheduler Writer'
Writer Id: {d61d61c8-d73a-4eee-8cdd-f6f9786b7124}
Writer Instance Id: {1bddd48e-5052-49db-9b07-b96f96727e6b}
State: [1] Stable
Last error: No error
Writer name: 'VSS Metadata Store Writer'
Writer Id: {75dfb225-e2e4-4d39-9ac9-ffaff65ddf06}
Writer Instance Id: {088e7a7d-09a8-4cc6-a609-ad90e75ddc93}
State: [1] Stable
Last error: No error
Writer name: 'Performance Counters Writer'
Writer Id: {0bada1de-01a9-4625-8278-69e735f39dd2}
Writer Instance Id: {f0086dda-9efc-47c5-8eb6-a944c3d09381}
State: [1] Stable
Last error: No error
Writer name: 'System Writer'
Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Instance Id: {0e2de42e-8c73-41e8-bd49-7b9f5c383d3e}
State: [1] Stable
Last error: No error
Writer name: 'Cluster Shared Volume VSS Writer'
Writer Id: {1072ae1c-e5a7-4ea1-9e4a-6f7964656570}
Writer Instance Id: {fd2214a1-b70d-4108-9de9-ec9378dc3292}
State: [1] Stable
Last error: No error
Writer name: 'ASR Writer'
Writer Id: {be000cbe-11fe-4426-9c58-531aa6355fc4}
Writer Instance Id: {8f9f1d82-7b38-4e50-b923-160a72b0d7dd}
State: [1] Stable
Last error: No error
Writer name: 'SqlServerWriter'
Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
Writer Instance Id: {64da2b39-68f9-43a5-84c6-82328d78e820}
State: [1] Stable
Last error: No error
Writer name: 'Shadow Copy Optimization Writer'
Writer Id: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}
Writer Instance Id: {594b1a86-6bc5-407e-a097-216fe1b53d51}
State: [1] Stable
Last error: No error
Writer name: 'Registry Writer'
Writer Id: {afbab4a2-367d-4d15-a586-71dbb18f8485}
Writer Instance Id: {570b5878-2047-490a-a02b-57e135a64d45}
State: [1] Stable
Last error: No error
Writer name: 'Cluster Database'
Writer Id: {41e12264-35d8-479b-8e5c-9b23d1dad37e}
Writer Instance Id: {79ab614a-8796-4f25-8861-733705579d40}
State: [1] Stable
Last error: No error
Writer name: 'COM+ REGDB Writer'
Writer Id: {542da469-d3e1-473c-9f4f-7847f01fc64f}
Writer Instance Id: {0d15b14b-730b-4d62-b879-e4d994a0c41c}
State: [1] Stable
Last error: No error
Writer name: 'WMI Writer'
Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
Writer Instance Id: {fd1b4b51-bbcb-4f7a-8d4e-2d0cd7f8ecfa}
State: [1] Stable
Last error: No error
Writer name: 'BITS Writer'
Writer Id: {4969d978-be47-48b0-b100-f328f07ac1e0}
Writer Instance Id: {8f1f6d82-145b-4aaf-b4e1-bba6e3fd0a9d}
State: [1] Stable
Last error: No error
-
- Product Manager
- Posts: 6408
- Liked: 724 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: Veeam causing an uninteneded SAN SNAP
A possible workaround would be to use a pre-freeze and post-thaw scripts to stop VSS writer's service before taking a snapshot and start it again after the snapshot has been taken.
Thanks
Thanks
Who is online
Users browsing this forum: GregorS and 99 guests