top of page

Life Coaching with M Group

Public·57 members

SSB Backup Script WORK

To configure a backup schedule, you must be a member of the Administrators group. To perform all other tasks with this command, you must be a member of the Backup Operators or the Administrators group, or you must have been delegated the appropriate permissions.

SSB backup script

Creates a backup using specified parameters. If no parameters are specified and you have created a scheduled daily backup, this command creates the backup by using the settings for the scheduled backup. If parameters are specified, it creates a Volume Shadow Copy Service (VSS) copy backup and won't update the history of the files that are being backed up.

To create a one-time backup using this command, you must be a member of the Backup Operators group or the Administrators group, or you must have been delegated the appropriate permissions. In addition, you must run wbadmin from an elevated command prompt, by right-clicking Command Prompt, and then selecting Run as administrator.

Tip: The target volume for a critical-volume backup can be a local drive, but it Can't be any of the volumes that are included in the backup.-systemStateCreates a backup that includes the system state in addition to any other items that you specified with the -include parameter. The system state contains boot files (Boot.ini, NDTLDR,, the Windows Registry including COM settings, the SYSVOL (Group Policies and Logon Scripts), the Active Directory and NTDS.DIT on Domain Controllers and, if the certificates service is installed, the Certificate Store. If your server has the Web server role installed, the IIS Metadirectory will be included. If the server is part of a cluster, Cluster Service information will also be included.-noVerifySpecifies that backups saved to removable media (such as a DVD) are not verified for errors. If you do not use this parameter, backups saved to removable media are verified for errors.-userIf the backup is saved to a remote shared folder, specifies the user name with write permission to the folder.-passwordSpecifies the password for the user name that is provided by the parameter -user.-noInheritAclApplies the access control list (ACL) permissions that correspond to the credentials provided by the -user and -password parameters to \\\\WindowsImageBackup\\ (the folder that contains the backup). To access the backup later, you must use these credentials or be a member of the Administrators group or the Backup Operators group on the computer with the shared folder. If -noInheritAcl is not used, the ACL permissions from the remote shared folder are applied to the \ folder by default so that anyone with access to the remote shared folder can access the backup.-vssFullPerforms a full back up using the Volume Shadow Copy Service (VSS). All files are backed up, each file's history is updated to reflect that it was backed up, and the logs of previous backups may be truncated. If this parameter isn't used, wbadmin start backup makes a copy backup, but the history of files being backed up is not updated.Caution: Don't use this parameter if you are using a product other than Windows Server Backup to back up apps that are on the volumes included in the current backup. Doing so can potentially break the incremental, differential, or other type of backups that the other backup product is creating because the history that they are relying on to determine how much data to backup might be missing and they might perform a full backup unnecessarily.-vssCopyPerforms a copy backup using VSS. All files are backed up but the history of the files being backup up is not updated so you preserve the all the information on which files where changed, deleted, and so on, as well as any application log files. Using this type of backup does not affect the sequence of incremental and differential backups that might happen independent of this copy backup. This is the default value.Warning: A copy backup can't be used for incremental or differential backups or restores.-quietRuns the command without prompts to the user.RemarksIf you save your backup to a remote shared folder, and then perform another backup to the same computer and the same remote shared folder, you will overwrite your previous backup.

If your backup operation fails, you can end up without a backup because the older backup is overwritten, but the newer backup isn't usable. To avoid this, we recommend creating subfolders in the remote shared folder to organize your backups. However, because of this organization, you must have twice the space available as the parent folder.

To perform a one-time, non-recursive backup of d:\folder1 to the \\backupshare\backup1* network location, and to restrict access to members of the Administrators or Backup Operators group, type:

A not-uncommon requirement for Powershell is monitoring and reporting backups created via Windows Server Backup. The Get-WBSummary and Get-WBJob cmdlets can be leveraged to obtain a great deal of information and in most cases will get the job done. However there is one bit of data that is a bit tougher to retrieve: the size of the SystemState backup (not to be confused with the System Reserved backup).

For some reason the Get-WBJob cmdlet reports the size of the SystemState backup as zero, at least when multiple volumes are involved. This can be a little frustrating as the Windows Server Backup application reports the size correctly in the items and as part of Data transferred, but only the most recent 7 backups can be viewed in that application and it requires logging into the target server directly.

Fortunately WSB records the data in the Event Log and it can be viewed in Applications and Services Logs -> Microsoft -> Backup -> Operational. Powershell is able to retrieve this via the Get-WinEvent cmdlet using the microsoft-windows-backup Provider. Even so, the SSB backup size is buried deep in an XML hierarchy. To really complicate matters, SSB is reported for each Volume, whether or not that volume actually contains system state data.

It's a pretty bare-bones script which can certainly be improved and/or customized to suit a particular need. The data is gathered into an array of custom objects ($backups) which cold be piped to ConvertTo-Html or other cmdlets as desired.

You should be able to better catch an error if you stay away from specific Event IDs and focus on the backup providers (the Source that is listed in the Event Viewer). There is one that reads 'Backup' that is actually called Microsoft-Windows-Backup, and one called 'Windows Backup.'

Thanks. I checked the Microsoft-Windows-Backup logs on my domain controllers and I see a consistent use of Event 5 for failed system state backups, as well as Event 4 for successful system state backups.

Thanks for the information and script. Your advice about focusing on the Application log and events 49, 4, and 19 sounds good. I can incorporate them into the script you provided and get the results sent to email.

I would confirm those event IDs...I was playing around with this and the error event ID for me was 517. Unless you test every iteration of every possible failure, you might miss certain event IDs. Some background research would be advisable. Or identify exactly what makes for a 'successful' backup, and if any computer doesn't have that event, mark it as a failure.

While working with a number of databases, creating a recovery plan can be challenging, especially if we want a foolproof design. Automated backup and restore strategies ensure the recovery plan is successful. However, strategies relying on frequent backups, although part of a sound strategy, can start causing issues when available storage space becomes limited. Old database backups are in many cases unnecessary, and it is often prudent to delete those backups to increase available storage. This can be done manually or automatically. There are several options to delete old backup files automatically in SQL Server:

For this option, the SQL Server Agent service must be installed and running. It requires basic knowledge and understanding of Transact-SQL (T-SQL) scripting, but the process is then entirely automated, so there is no further input from the user needed. It is necessary to create a stored procedure first upon which the SQL Server Agent job we make would call to execution. The advantage of this is the ability to use the same stored procedure across different jobs with different input parameters. To create a SQL Server Agent scheduled to delete old backup files, we must do the following steps:

Create a user stored procedure which will use the input from the SQL Server Agent scheduled job to delete old backup files. Right click on the database upon which we want to act and select New Query:

In the New Job Step window, under General tab, enter a descriptive job name, under Database select the database which we want the job to work on and under Command: insert the following line:


Welcome to the group! You can connect with other members, ge...
Group Page: Groups_SingleGroup
bottom of page