none
Can vss shadowstorage volume size be calculated? RRS feed

  • Question

  • Simply put, my DPM 2010 jobs for a specific PS is failing due to the vss shadowstorage running out of space. It is not an ideal backup scenario. I'll give the details below - but what I need to figure out, is if the size of the vss shadowstorage volume can be predicted based on total data size, and data churn of two different VSS operations.

    I of course have extremely limited SAN space space left and can either expand the e:\ by a specific amount. Or - attach another SAN volume, move the DPM shadowStorage from e:\ to new volume, and leave as UNBOUNDED. What can I do to figure out these numbers for size expansion or new volume size?

    SQL VSS jobs are dealing with ~400GB of SQL data to make full backups from E:\ to D:\ -- how much space would it need for this?

    DPM VSS jobs are dealing with the consistency check of 2.1TB of .bkf files / transaction log Data on D:\ with a daily churn of ~420GB. --

    ~10% of the volume data totals? So - maybe 260GB of free space?

    As mention, my situation and details.

    At this point, DPM needs to run a consistency check of 2.1TB of file data - with a daily churn of 415GB. Should take my environment about 72 Hours +/- 12 Hours. In the meantime, the same volume that houses the DPM shadowstorage volume runs out of space every day when the SQL VSS Writer runs its own jobs to do full backups of each DB... thats where the 415GB of churn is from - not SQL data changes, but I'm backing up full backups of the SQL databases.

    DPM 2010 running on a 2008 R2 SP1 DPM server - protecting a clustered 2008 R2 SP1 SQL server - 

    D:\ = 2.5TB (50GB Free) SAN Volume

    E:\ = 600GB (140GB Free) SQL Databases  -- also home to the shadowStorage Volumes - the volume that is running out of space.

    Due to infrastructure, and old procedures - SQL databases are not being backed up directly via DPM, but rather the SQL server is running its own backup jobs of the Databases on E:\ to its D:\  (both are Fiber SAN Attached) - reason being that our SQL DBA can then restore to the minute with the transaction logs all at the speed of our SAN.

    DPM is protecting the 2.5TB of .bkf and log files. The shadowstorage volume of D:\ is set to E:\ -- and until recently has not been a problem. 

    Wednesday, March 6, 2013 7:33 PM

All replies

  • Hey Kyle,

    Space is always something to consider with backups.

    How are you backing up SQL? Actually using DPM to backup the DB's or backing up a folder which have .BAK files being dumped too?

    The reason this is very important is because every new .BAK is seen as a BRAND new file so DPM will backup the full size everytime.

    To give you an example, I hold 15TB of SQL backups on my disk with DPM.  2TB each day, 7 days of recovery points.

    Thursday, April 4, 2013 1:56 PM