Déploiement automatisé de la sauvegarde Windows via Ansible

Rien ne change dans le fonctionnement interactif habituel : ce guide s'adresse aux équipes qui veulent déployer à l'échelle, sans ouvrir l'interface graphique sur chaque machine. Tout ce qui suit s'appuie sur les exemples fournis dans le dépôt, dossier examples/automation/.

Voie A — Ligne de commande (recommandée pour l'IaC)

Un seul fichier JSON porte tout ce qu'il faut pour une sauvegarde (adresse du serveur, token, empreinte SSL, datastore, namespace…) ; la planification est déléguée au Planificateur de tâches Windows. C'est l'approche la plus déterministe pour de l'infrastructure-as-code pure.

{
  "baseurl": "https://pbs.example.net:8007",
  "certfingerprint": "AA:BB:CC:...",
  "authid": "ansible@pbs!deploy",
  "secret": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "datastore": "myDatastore",
  "namespace": "clients/acme",
  "backup-id": "srv-files",
  "backupdir": "C:",
  "usevss": true
}

Lancement :

directorybackup.exe --config "C:\ProgramData\NimbusBackup\backup.json"

• Un fichier de config unique regroupe tous les champs (connexion PBS, dossiers, VSS, exclusions…).
• Chaque champ peut être surchargé par un flag CLI (le flag l'emporte sur le fichier) — pratique pour un template partagé avec des surcharges par machine.
• Les codes de retour sont fiables, votre orchestrateur détecte donc les échecs sans ambiguïté.

Codes de retour — le socle de l'automatisation

Le playbook d'exemple ansible/deploy-cli.yml (avec le template cli-single-config.json.j2) copie le binaire, rend la configuration et enregistre une tâche planifiée quotidienne (win_scheduled_task) exécutée en tant que SYSTEM au niveau highest — indispensable pour que VSS fonctionne.

- name: Sauvegarde quotidienne (Task Scheduler)
  community.windows.win_scheduled_task:
    name: NimbusBackup-Daily
    actions:
      - path: 'C:\Program Files\NimbusBackup\directorybackup.exe'
        arguments: '--config "C:\ProgramData\NimbusBackup\backup.json"'
    triggers:
      - type: daily
        start_boundary: '2026-01-01T02:30:00'
    username: SYSTEM
    run_level: highest   # requis pour VSS
    state: present
    enabled: true

Voie B — Service/GUI (MSI) : un fichier pour connexion et planification

Le MSI installe un service Windows. Depuis la 0.3, un unique config.json peut porter la connexion PBS, les paramètres de sauvegarde et la planification, via un tableau scheduled_jobs. Au (re)démarrage, le service réconcilie ces jobs dans son magasin et calcule automatiquement chaque nextRun : vous n'avez pas à produire d'horodatage dans votre template.

{
  "pbs_servers": {
    "default": {
      "id": "default",
      "baseurl": "https://pbs.example.net:8007",
      "certfingerprint": "AA:BB:CC:...",
      "authid": "ansible@pbs!deploy",
      "secret": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "datastore": "myDatastore",
      "namespace": "clients/acme"
    }
  },
  "default_pbs_id": "default",
  "usevss": true,
  "scheduled_jobs": [
    {
      "id": "nightly-c",
      "name": "Nightly C:",
      "scheduleTime": "02:30",
      "enabled": true,
      "backupType": "host",
      "backupDirs": ["C:"],
      "backupId": "srv-files",
      "useVSS": true,
      "compression": "fastest"
    }
  ]
}

Playbook d'exemple : ansible/deploy-gui-service.yml (avec le template ansible/gui-service-config.json.j2). Déposez le fichier, notifiez le redémarrage du service, c'est tout :

- name: Config unifiée (connexion + planification)
  ansible.windows.win_template:
    src: config.json.j2
    dest: 'C:\ProgramData\NimbusBackup\config.json'
  notify: Restart NimbusBackup

# handlers
- name: Restart NimbusBackup
  ansible.windows.win_service:
    name: NimbusBackup
    state: restarted

Idempotence : rejouer le playbook ne casse rien

Référence des champs

Connexion (pbs_servers[*])

Besoin de créer le token en amont ? Voir Gérer les tokens API d'un datastore PBS.

Job planifié (scheduled_jobs[*], voie service/GUI)

Quelle voie choisir ?