PI Services

Le blog des collaborateurs de PI Services

Powershell & Windows Server Backup

 

Windows Server Backup, le successeur de NT Backup est intéressant mais un peu déroutant, et en tout cas plus facile a administrer avec Powershell donc voici un script Powershell qui:

1/ Vérifie la présence de la feature Windows Server Backup et l’installe si ce n’est pas le cas

2/ Si le feature est présent il crée une Policy (au sens Windows server backup) qui effectuera un backup SystemState tout les jours a 1:00 AM.

Avant d’exécuter ce script il est nécessaire de permettre l’exécution de script avec la commande suivante dans une console powershell:

Set-executionpolicy –executionpolicy unrestricted

 

Import-Module servermanager

$module=Get-Module servermanager

$backfeat=Get-WindowsFeature backup-features

$backtools=Get-WindowsFeature backup-tools

if ($backfeat.Installed -eq $TRUE -AND $backtools.installed -eq $TRUE)

{

write-host "les features WINDOWS SERVER BACKUP sont déja installé - Le script va continuer"

}

else

{

add-WindowsFeature backup-features,backup-tools

write-host "Merci de redemarrer le serveur pour prendre en compte l'ajout du feature Windows Server Backup"

exit

}

####verification de la presence du snapin Windows.serverbackup####

Add-Pssnapin Windows.serverbackup -ErrorAction:SilentlyContinue

if ($errSnapin.count -eq 0)

{

Write-host "`No Windows.serverbackup PSSnapin initialized!";

Write-host "Windows.serverbackup PSSnapin failed initialize! Verifiez que le role Windows Server Backup est bien installé dans la console Server Manager";

}

elseif (Get-PSSnapin | where-object {$_.Name -eq "Windows.serverbackup"})

{

write-host "le snapin Windows.serverbackup est deja chargé - le script va continuer"

}

{

}

$SystemStatepolicy = New-WBPolicy

set-wbschedule -Policy $SystemStatepolicy -Schedule 1:00

Add-WBSystemState -Policy $SystemStatepolicy

$diskBackupLocation = New-WBBackupTarget -VolumePath D:

Add-WBBackupTarget -Policy $SystemStatepolicy -Target $diskBackupLocation

Set-WBPolicy -Policy $SystemStatepolicy -force

write-host "Une sauvegarde System State aura lieu tout les jours a 1:00 AM"

SQL Server 2008 : Types de sauvegardes et choix du mode de récupération d’une base de données

Introduction

Lors de la création d’une base de données SQL Server 2008 on peut choisir le mode de récupération à appliquer pour cette base de données. Ce choix ne doit pas être fait au hasard mais il doit répondre aux besoins de l’entreprise en termes de stratégie de sauvegarde et de récupération.

Types de sauvegardes

SQL Server 2008 offre une multitude de types de sauvegarde pour une base de données sauf que ces types de sauvegarde dépendent du mode de récupération choisi pour celle-ci.

Les types de sauvegarde qu’on peut réaliser sur une base de données sont :

  1. Sauvegarde de données
  2. Sauvegarde des journaux de transactions
  3. Sauvegarde de type copie seule

 

L’étendu d’une sauvegarde peut être soit une base de données complète, une base de données partielle ou un ensemble de fichiers ou groupes de fichiers. Pour chacun de ces étendues on peut faire soit des sauvegardes complètes soit des sauvegardes différentielles.

Une sauvegarde différentielle dépend de la dernière sauvegarde complète réalisée avant celle-ci, la perte de la sauvegarde complète implique la perte de toutes les sauvegardes différentielles réalisées après.

Chaque sauvegarde de base de données contient la portion du journal de transaction qui permet de remettre la base de données à la fin de l’opération de sauvegarde.

Une sauvegarde de type copie seule (Copy Only) nous permet de réaliser des sauvegardes sans affecter la stratégie de sauvegarde mise en place, ce qui veut dire qu’une sauvegarde en copie seule même si c’est une sauvegarde complète n’affecte pas le chainage entre les sauvegardes différentielles réalisées après celle-ci et la sauvegarde complète normale réalisée avant elle.

Mode de récupération

Si le mode de récupération d’une base de données est Simple, la sauvegarde des journaux de transaction est désactivée pour celle-ci, en effet SQL Server prendra en charge la gestion des fichiers journaux et à chaque point de contrôle les parties inactives du journal seront tronquées.

clip_image002

Le mode de récupération Journalisé en bloc est un mode complémentaire au mode complet qui permet d’optimiser les opérations en bloc mais n’offre pas le même niveau de protection que le mode complet, en effet ce mode ne prend pas en charge la récupération de la base de données à une date et heure précise.

Meilleures pratiques

  • Choisir le mode de récupération Simple pour les bases de données de développement et de test
  • Si votre base de données est configurée avec un mode de récupération complet ou journalisé en bloc il ne faut pas oublier de réaliser des sauvegardes des journaux de transaction.
  • Une sauvegarde différentielle d’une base de données contient toutes les pages de données modifiées depuis la dernière sauvegarde complète, sans la sauvegarde complète de référence une sauvegarde différentielle ne peut pas être restaurée ; dans le cas où on met en place une stratégie de sauvegarde à base de sauvegarde complète et différentielles il faut bien faire attention à ne pas perdre la sauvegarde complète.
  • L’application d’une mise à jour ou d’un patch de sécurité qui change le numéro de version de votre serveur SQL doit être suivi immédiatement d’une sauvegarde des bases de données système, en fait les anciennes sauvegardes seront obsolètes dans ce cas.

SQL Server 2008 : Automatisation de la sauvegarde des journaux de transactions

Si une base de données est configurée en mode de récupération complet, son journal de transaction ne sera tronqué que suite à la sauvegarde de celui-ci. La réalisation d’un grand nombre de transactions volumineuse peut augmenter indéfiniment la taille du journal des transactions ce qui impliquera un suivi permanent et une charge administratif en plus.

Avec les alertes et les travaux SQL Server on peut automatiser les tâches de sauvegarde du journal de transactions afin d’éviter que le disque hébergeant le journal ne soit rempli.

Pour cela il faudra procéder comme suit :

Créer une unité de sauvegarde

Depuis l’explorateur des objets, développer Server Objects puis cliquer avec le bouton droit de la souris sur Backup Devices et cliquer sur New Backup Device.image

Donnez un nom et préciser le chemin du fichier à utiliser pour votre unité de sauvegarde

image

Cliquer sur Ok

Créer un opérateur pour recevoir les notifications

Créez un opérateur en cliquant sur New Operator

image

Précisez le nom de l’opérateur, son adresse email si vous voulez utiliser la notification par messagerie électronique et le nom de sa machine en cas de notification par message console.

image

Cliquer sur Ok

Créer un travail de sauvegarde du journal de transaction

Créer un nouveau Travail en cliquant sur New Job…

image

Au niveau de l’onglet Général tapez le nom du travail et ensuite passez à l’onglet Etapes.

image

Créer une étape de Type Script Transact-SQL (T-SQL) avec le script BACKUP LOG NomBase TO BackupDevice avec BackupDevice le nom de l’unité de sauvegarde crée auparavant.

image

Au niveau de l’onglet Notification choisissez l’opérateur qui doit recevoir une notification et quand.

image

Créer une alerte relative au compteur de performance (Pourcentage du journal utilisé)

Créez une alerte en cliquant sur New Alerte

image

Au niveau de l’onglet Général donner un nom à votre alerte de type Alerte de condition de performance SQL Server et configurez la comme illustré au niveau de l’image

image

Au niveau de l’onglet Réponse choisissez l’exécution du Job de sauvegarde comme réponse et cochez le mode de notification à utiliser.

image

La configuration de cette alerte qui déclenche le travail de sauvegarde permettra d’éviter que les disques soient remplis et que les journaux de transactions ne grandissent indéfiniment.