If they ARE, then this will inhibit you, the backup admin, from being able to handle your domain responsibly and reliably (and isn’t that really what you want? Reliable restoration of important data?).

In addition, there are so many features beyond backup and restores that may not be taken full advantage of if these backups are run outside of CV. Kicking off 10 full DB backups on your own will potentially require more space than you have at the moment (and will that impact non-DB backups from running?). You need to be able to predict and plan out storage needs based on continuous cycles/schedules. Looking for methods, thoughts, arguments, positions and when they run these WAC backups, are they sending a command to Commvault to initiate the backups or are these going to outside-CV resources?Įither way, from a logistics perspective (and an audit/compliance perspective as you wisely mentioned), this doesn’t sound like a wise idea in the long run. Oh the DBAs don’t want any change.Īny thoughts out there in CV land? I wish to remain impartial, but the security aspect is worrisome. I have two camps, one that wants to remove this unapproved use the backup infra for SQL production purposes and another that wants to secure these procedures. Not even going to go into regulatory and audit implications. However this causes problems over time with unanticipated storage requirements, retention of nonproduction DBs, failed scheduled backups, etc. In the scheme of things it goes unnoticed when you have ten thousand plus backups running daily.

They developed these procedures without consulting data protection team, storage team, security team. WAC launches scripts from the client server with a generic account, for anyone with access to the client. outside of the control of backup environment. I have a client who has SQL admins using WAC to launch backups/restores for their day to day changes, db refresh, devops, pre/post-change backups, etc.

Wac windows