Ma question est simple, et je pense que je connais ma réponse - je suis vraiment après une confirmation des autres.
Évidemment, si mon serveur WSUS meurt, j'aurai des téléchargements lourds à faire une fois qu'il sera de sauvegarde, et ce n'est pas un problème. Je pensais davantage à la base de données derrière WSUS - cela devrait-il être sauvegardé?
Ce qui, je pense, se passerait, ce serait comme la configuration de WSUS pour la première fois - changez la stratégie de groupe et le serveur WSUS construira ensuite sa base de données d'ordinateurs et leurs mises à jour installées à partir de zéro.
Ai-je raison dans mes hypothèses, ou cela fera-t-il quelque chose d'inattendu?
Est-il préférable à long terme de simplement sauvegarder la base de données, disons une fois par mois et d'en finir?
Réponses:
Cela dépend en quelque sorte de la complexité de la disposition de votre groupe et du fait que vous ayez effectué de nombreuses approbations / refus personnalisés pour certains groupes. Cela dépend également si vous vous souciez de l'historique et de l'état actuel des ordinateurs dans la base de données.
Si vous avez une configuration très simple où vous approuvez simplement toutes les mises à jour et que vous ne vous souciez pas vraiment de l'historique des ordinateurs, il n'est pas nécessaire de sauvegarder la base de données ou les mises à jour. Il faudrait probablement moins de temps pour simplement reconstruire le service à partir de zéro (selon la vitesse à laquelle votre connexion réseau est établie avec Microsoft) que pour restaurer à partir d'une sauvegarde. Toutes vos machines existantes s'enregistreront simplement avec le nouveau serveur une fois qu'il sera opérationnel.
C'est une analyse des risques assez basique pour n'importe quel service. Si vous avez des données qui seraient coûteuses (temps ou argent) ou impossibles à recréer à partir de zéro, vous devez les sauvegarder. Sinon, ne vous embêtez pas.
la source
La sauvegarde de la base de données est une petite tâche, et la sauvegarde des mises à jour ne sert à rien car vous les re-téléchargez simplement si vous devez reconstruire votre serveur WSUS. La plupart des mises à jour sont déjà appliquées de toute façon.
Je sauvegarde ma base de données WSUS afin de ne pas avoir à écrire (ou à me souvenir) quelles mises à jour refuser (nous avons un plug-in de mot personnalisé qui se bloque avec un certain KB par exemple).
la source
J'ai examiné cela dans un travail précédent lorsque les sauvegardes approchaient de la capacité de la bande. Plutôt que de continuer à sauvegarder WSUS, je l'ai installé sur un autre serveur et configuré cela comme un serveur en aval, même s'il ne servait en fait aucun client. J'ai pensé que si nécessaire, je pouvais simplement modifier le paramètre GPO pointant vers le serveur et passer à des questions plus urgentes, comme la restauration du reste du système défaillant. L'espace disque utilisé n'était pas un problème, mais il libérait un espace précieux sur les bandes.
la source
Je le sauvegarderais de toute façon, juste pour le facteur de confort supplémentaire. Il me semble que WSUS n'est pas quelque chose qui doit absolument être inclus dans vos tâches de sauvegarde nocturnes régulières, et pourrait plutôt être exécuté pendant la journée, ce qui pourrait faciliter les choses si votre fenêtre de temps et / ou votre stockage sont serrés. Que vous souhaitiez ou non sauvegarder les mises à jour ainsi que la base de données et les autres configurations, cela dépend vraiment de vous; s'il est trivial de simplement les télécharger à nouveau, vous n'en aurez probablement pas besoin.
Si vous décidez de ne pas le sauvegarder, assurez-vous de bien documenter la configuration . La reconstruction du système d'exploitation et du logiciel d'application et de base de données peut être triviale, mais à moins que vous n'ayez récupéré la configuration, vous ne l'avez pas vraiment récupéré.
la source
Ce que vous dites re: la reconstruction du serveur WSUS est correcte (bien que si l'URL de mise à jour pour le serveur WSUS de remplacement est la même que le serveur WSUS en panne, aucune modification de la configuration client re: stratégie de groupe, paramètres de registre, etc., ne serait nécessaire).
La sauvegarde ou non de la base de données WSUS n'est en réalité qu'un compromis entre le temps de téléchargement et l'utilisation de vos ressources de sauvegarde (espace, temps dans la fenêtre de sauvegarde). Il est généralement assez petit, alors j'irais la tête et je la prendrais régulièrement.
la source
Quel serait le travail pour le réinstaller?
Combien d'efforts / de coûts sont impliqués dans la sauvegarde?
Si le travail de configuration va coûter moins cher que le coût de la sauvegarde, vous avez une réponse.
Je prends juste une image fantôme de la nôtre une fois par trimestre .. quelques mois de patchs sont de petites pommes de terre dans l'ordre des choses .. mais je le force également à utiliser le proxy de toute façon, donc en cas de mort, je peux toujours charger la plupart d'entre eux localement à travers cela .. (notre proxy a un grand cache, 100 Go)
Bravo de me le rappeler, j'ajoute une tâche programmée donc je n'oublie pas le prochain trimestre et je la sauvegarde maintenant!
la source
C'est toujours une bonne idée d'avoir une sauvegarde de n'importe quel serveur.
La douleur d'avoir à configurer wsus à nouveau puis à y broyer toutes les machines est bien plus grande que les 30 secondes nécessaires pour configurer une sorte de sauvegarde sur la machine.
Exécutez un vidage quotidien de la base de données / système vers un simple volume externe ou si vous disposez d'une infrastructure de sauvegarde interne, sauvegardez-le.
la source
IMO non, le temps / les tracas pour reconstruire un serveur WSUS est négligeable, et ce n'est pas un élément critique pour le temps qui vous tue lorsqu'il est en panne.
Si vous souhaitez atténuer les tracas autant que possible, configurez le ciblage côté client via une stratégie de groupe pour vos postes de travail / serveurs. Cela réduira vos frais généraux de gestion WSUS et rendra la reconstruction sans douleur.
Lorsque vous tenez compte du coût d'une CAL de sauvegarde SQL ou que vous la configurez / la maintenez via une méthode manuelle, je ne peux vraiment pas trouver d'argument solide pour la sauvegarder.
la source