me revoilà à l'attaque!
Aujourd'hui nous voyons un élément essentiel et incontournable d'un système d'information, la sauvegarde.
/!\
Je précise en préambule que cet article a pour but de contourner des limitations de l'interface d'un Windows Backup classique, et donc une analyse fine du système devra toujours être réalisée par des experts.
En effet certains éléments, comme des bases de données, peuvent nécessiter des procédures, et logiciels spécifiques, pour mettre en œuvre un plan de sauvegarde adapté. Le périmètre spécifique à l'entreprise devra également être pris en compte.
Je ferme la parenthèse, et en rouvre une autre, pour parler des limitations de l'outil Windows Backup.
Il est aujourd'hui performant, et peut très bien convenir pour des utilisations basiques, ou en complément d'autres systèmes professionnels.
Cependant, il comporte des limitations qui sont incompréhensibles, mais qui pourtant existent:
- Lorsqu'on sauvegarde sur un partage réseau, la sauvegarde est toujours complète, il n'est pas possible de réaliser de l'incrémentiel, et donc limiter le temps de sauvegarde, ainsi que le retour en arrière dans le temps grâce aux versions précédentes de ces sauvegardes.
- Lorsqu'on utilise l'interface graphique, il n'est pas possible de programmer plusieurs jobs de sauvegardes différents.
J'ose espérer que ces limitations seront levées avec le temps, mais rien n'est moins sûr.
Mais nous sommes pragmatiques, donc nous allons faire avec!
Nous allons contourner partiellement ces limitations, en utilisant des tâches planifiées de sauvegarde! Nous aurons donc bel et bien plusieurs jobs de sauvegarde. Par contre le fait que les jobs soient "complets" fait que in fine la volumétrie de l'espace de stockage sera plus volumineuse!
Un coup pour rien :
La première action à effectuer est de créer un dossier que je vais appeler "backup" sur mon NAS ou sur mon serveur distant.
Pas besoin de mapper un lecteur réseau, ceci n'est pas pris en charge par Windows Backup.
Je vérifie tout de même que j'ai bien accès à ce dossier depuis mon serveur:
 |
| J'accède à mon partage réseau |
Ensuite, et cela peut sembler paradoxal, mais je lance un backup complet de mon serveur. Ceci afin de vérifier ce qui est sauvegardé, et donc vérifier que mon script sauvegardera bien tous les éléments.
Je créé une "sauvegarde unique":
 |
| Je lance la console Sauvegarde Windows et je sélectionne sauvegarde unique. |
 |
Je rentre mon chemin, dans mon cas "\\NAS\backup":
Je visualise les éléments qui seront sauvegardés, et j'aurai un point de comparaison une fois mes jobs mis en place:
 |
| Tout est sauvegardé, même mon état du système et mes volumes de démarrage et de récupération. |
Les mains dans le cambouis :
Maintenant les choses sérieuses commencent...on va créer un plan de sauvegarde professionnel, avec des sauvegardes "grand-père, père, fils".Nous allons donc créer un job par jour de la semaine, du lundi au vendredi, puisque nous ne travaillons pas le weekend.
Chaque fois la sauvegarde précédente étant écrasée, dans ce cas de figure nous ne pouvons remonter qu'une semaine en arrière.
Nous mettons donc en place une sauvegarde bi-hebdomadaire, par exemple le 1 et le 15 de chaque mois (il faut toujours être vigilent sur les jobs de fin de mois, certains mois finissent à 30 jours, voir à 28 pour février, ou 29 pour les années bissextiles).
Nous mettons en place une sauvegarde mensuelle, qui permettra de remonter 1 mois en arrière, et enfin une sauvegarde trimestrielle, en janvier, avril, juillet et octobre.
Nous serons donc à même de remonter loin de le temps, au détriment de l'espace disque disponible.
Cependant il est important de conserver des sauvegardes sur une longue durée, ceci afin de pouvoir récupérer une version de document différente de celle actuelle, ou si un fichier a disparu et qu'on s'en rend compte un long moment après.
Je vais créer l'arborescence qui va recevoir ces jobs sur mon NAS de destination:
 |
| Ils sont dans l'ordre car je viens de les créer, je vais les organiser pour que cela soit plus pro. |
Là tout est à la racine, pour bien faire je vous laisse le soin d'organiser les dossiers en séparant les jours, des quinzaines, des trimestres.
Œuvrer dans la lumière :
Me voilà prêt à œuvrer, et à vous éclairer (petit clin d’œil à mes étudiants) sur la manière de configurer concrètement mes jobs.
Je vais utiliser l'utilitaire en ligne de commande de Windows, wbadmin.
Pour valider les options et paramètres, je tape mes commandes dans une invite de commande DOS.
Je pourrais le faire dans une invite de commande PowerShell, mais il faudrait que je modifie les paramètres, en rajoutant des guillemets, que je devrais ensuite supprimer pour mon job, je reste efficient et tape directement dans ma fenêtre cmd.
La commande wbadmin est bien faîte, et permet de réaliser plus d'actions que l'interface graphique le permet, et notamment créer plusieurs jobs distincts!
Nous souhaitons sauvegarder l'ensemble du serveur, en incluant les partitions de boot et de récupération, qui n'ont pas de lettre de lecteur attribué. Je vais donc identifier ma partition grâce à son numéro de volume, en tapant la commande mountvol:
 |
| Je vois bien l'ID de mon volume sans point de montage... |
Je sélectionne et copie l'ID de volume.
Maintenant je tape la commande suivante, qui va me permettre de sauvegarder tous mes volumes, avec des points de montage ou non, mais surtout l'état du système et tous les paramètres:
wbadmin.exe start backup -backuptarget:\\nas\backup\lundi\ -include:c:,d:,\\?\Volume{e847a19f-2f6d-4e74-a8bb-aa1c2bfd35e2}\ -allcritical -systemstate -quiet
Voici le lien Technet avec toutes les options possibles de cette commande:
https://technet.microsoft.com/fr-fr/library/cc742083%28v=ws.10%29.aspx
Je démarre un job de sauvegarde, avec comme destination le dossier lundi de mon NAS, j'inclue dans la sauvegarde mes volumes C: et D:, ainsi que le volume de boot EFI, en incluant tous les éléments critiques pour le système, ainsi que son état.
Je vois l'avancement de mon job, et que tout se déroule correctement:
L'avantage de ce système c'est que non seulement je vois le job en cours, chose qui ne sera plus vraie lorsque j'automatiserai les sauvegardes, mais surtout je visualise l'état du job depuis la console Windows Backup.
Je vérifie donc que j'ai bien les bons arguments, et que le périmètre de sauvegarde est identique à celui que j'ai créé au tout début:
Me voilà rassuré, je sauvegarde bien l'intégralité de mes données!
Je vais maintenant créer une tâche planifiée pour automatiser cela, en utilisant le planificateur de tâches :
Je crée une tâche avec pour nom "backup lundi", qui s'exécute même si l'utilisateur n'est pas connecté.
L'action réalisée par cette tâche est de démarrer un programme, je rentre simplement wbadmin.exe, et je copie/colle le reste de la commande dans les arguments:
Je crée un déclencheur, qui se lance à l'heure programmée chaque lundi à 22h, j'aurai adapté cet horaire en fonction des autres tâches qui tourneront la nuit, en prenant en compte que la durée peut être assez longue du fait que la sauvegarde sera complète :
Je valide ma tâche planifiée, et pour contrôle je la lance manuellement:
Voilà, tout est Ok, je répète l'opération pour chaque jour de la semaine, et pour tous mes autres jobs.
La cerise sur le gâteau :
Nous voilà avec un plan de sauvegarde correct, ne restera qu'à mettre en place le suivi de ces sauvegardes.
Pour ce faire nous allons recevoir à chaque sauvegarde réussie un mail qui m'indiquera que tout s'est bien déroulé!
Ne faîtes surtout pas l'inverse, à savoir recevoir un mail quand ça ne fonctionne pas, car si n'importe quel autre événement se produit entre temps qui empêcherait la réception de mail, vous pourriez vous retrouver avec des données non sauvegardées, et ne pas vous en rendre compte juste parce que le serveur de mail n'a pas transmis le message.
Pour envoyer ce message, la méthode sera différente si nous nous trouvons sous Windows 2012 ou sous Windows 2008.
En effet une sécurité empêche d'envoyer un mail directement depuis Windows 2012, nous passerons donc par un script.
De même, si nous avons besoin d'une authentification SMTP, nous procéderons également via un script.
Je retourne simplement dans le planificateur de tâches, et créé une tâche de base que je nomme "réussite sauvegarde" :
Je sélectionne en déclencheur, un événement spécifique:
Je sélectionne "Microsoft-Windows-Backup/Operational", "backup" comme source, et renseigne 4 en "ID de l'événement":
 |
| Cet événement correspond à une réussite du Windows Backup. |
En tâche je sélectionne "démarrer un programme", et je renseigne mon script:
Si je suis sous 2008, je peux sélectionner directement "envoyer un courrier électronique", en renseignant les informations qui vont bien.
Voici un script PowerShell à adapter en fonction de son cas de figure, et notamment en fonction du besoin d'authentification SMTP ou non :
function EmailNotification()
{
#Sender email
$Sender = "sender.at.corpnet.net"
#Receipt email
$Receipt = "receipt.at.contoso.com"
#SMTP Server
$Server = "smtp.corpnet.net"
#Mail subject
$Object = $env:computername+": Backup report of "+(Get-Date)
#Mail content
$Content = Get-WBJob -Previous 1 | ConvertTo-Html -As List | Out-String
$SMTPclient = new-object System.Net.Mail.SmtpClient $Server
#Specify SMTP port if needed
#$SMTPClient.port = 587
#Activate SSL if needed
#$SMTPclient.EnableSsl = $true
#Specify email account credentials if needed
#$SMTPAuthUsername = "login"
#$SMTPAuthPassword = "password"
#$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($SMTPAuthUsername, $SMTPAuthPassword)
$Message = new-object System.Net.Mail.MailMessage $Sender, $Receipt, $Object, $Content
$Message.IsBodyHtml = $true;
$SMTPclient.Send($Message)
}
EmailNotification
Et maintenant?
Et bien rien! (enfin presque)Nous avons réalisé un plan de sauvegarde qui tient la route.
Je précise tout de même que dans notre cas de figure le NAS en question serait dans un autre bâtiment, la règle étant de ne pas avoir la sauvegarde au même endroit que le serveur, en cas d'incendie, de vol, de dégât dû à une inondation...
Ce plan devra être complété par une sauvegarde complémentaire, et surtout par des tests réguliers de remise en production, afin de valider que tout se déroule comme on l’espérait.
Cette nuit on va pouvoir
Je vous dis à très bientôt, pour un autre article qui traitera des règles concernant les ACL lors de la copie de fichiers/dossiers.
Bonne
