Forum Clubic

Droits d'utilisateur pour Opérateur de Sauvegarde - Dans le but d'utiliser SC.exe

Bonjour,

Je tente d’éviter l’achat d’un Remote Agent pour le logiciel de sauvegarde (Veritas Backup Exec) de ma société.

Veritas Backup Exec (VBE) est installé sur un serveur (machine nommée “serveurA”) Windows 2003 SP1 sur laquelle est également branché le lecteur de bande pour la sauvegarde quotidienne.
L’autre serveur (machine nommée “serveurB”) du réseau tourne sous Windows NT 4.0.

Sur les disques durs du serveurA se trouvent les données importantes à sauvegarder (fichiers utilisateurs, fichiers des travaux en cours, etc.). Les différents dossiers dans lesquelles elles se trouvent sont cochés pour la sauvegarde sous VBE.
Le serveurB fait office de serveur de comptabilité avec Microsoft SQL Server avec une base qu’il faudrait également sauvegarder au cours de la même sauvegarde VBE.

Normalement, il faudrait un Veritas Backup Exec Remote Agent car sans cela, VBE ne permet pas de choisir des dossiers distants (partage réseau et/ou lecteurs réseaux) à inclure dans la tâche de sauvegarde.
L’idée pour éviter d’acheter un Remote Agent est de rapatrier les données (les deux fichiers de la base SQL) du serveurB vers un dossier du serveurA et d’inclure ce dossier dans la tâche de sauvegarde VBE.

J’ai donc créé un partage (caché) sur serveurB du dossier contenant les deux fichiers de la base SQL. Ensuite un simple batch avec deux appels à XCOPY devrait faire l’affaire.

Le soucis c’est que les fichiers de la base SQL ne peuvent être lu si SQL Server tourne (sur serveurB).
J’ai découvert Service Controller Query Tool (sc.exe) qui permet de gérer les services (démarrer, arrêter, etc.) d’une machine distante.
Syntaxe : sc.exe \\serveurB start|stop mssqlserver
Ca me permet donc, dans mon Batch, de couper SQL Server, de copier (rapatrier sur serveurA) mes deux fichiers et de démarrer SQL Server.
Après je créer une tâche planifiée qui lance le batch dès que la Comptabilité ferme (vers 21h) pour que les fichiers soient rapatriés sur le serveur avant que la sauvegarde VBE ne se lance vers 02h.

J’ai fait quelques tests concluant et tout fonctionne bien (arrêt du service, copie, puis redémarrage).
Le truc qui me chiffone c’est que j’aimerais bien que la tâche planifiée se lance en tant qu’Opérateur de Sauvegarde (compte utilisateur Active Directory : “operateur_sauvegarde”, membre du groupe “Opérateurs de Sauvegarde”) et non pas en tant qu’Administrateur (du domaine) comme c’est le cas actuellement.
J’ai bien essayé de la lancer (la tâche planifiée) sous le compte “operateur_sauvegarde” mais l’appel à sc.exe retourne une erreur (“Echec”) qui est liée, selon moi au droits du compte “operateur_sauvegarde”. J’aurai cru qu’étant membre du groupe spécial “Opérateurs de Sauvegarde” (qui est un Groupe Domaine Local de sécurité définit dans BuiltIn) il aurait eu les droits suffisants :neutre:

Salut,

As tu juste vérifié si les droits NTFS de ton SC.EXE incluaient les Opérateurs de sauvegarde ?

Ce n’est pas l’appel à SC.exe qui est refusé, je pense que c’est plutôt le serveurB et/ou SQL Server qui ne m’autorise pas à arrêter le service.
Pour en être sûr, j’ai fait un test en me loggant sur le serveurA sous le compte “operateur_sauvegarde” et j’ai tapé la commande suivante :

sc \\serveurB query

J’ai ainsi obtenu la liste des services enregistrés sur le serveurB ainsi que leur état respectif : “operateur_sauvegarde” a bien pût exécuter SC.exe sans problèmes de droit et de plus, pour interroger le serveurB.

Est ce que SQL installe un compte de service ? Si oui, as tu tenté d’inclure ton Opérateur de sauvegardes dans ce groupe SQL ?

PS : désolé, j’ai pas testé SQL :smiley: