Veeam (dépôt de sauvegarde durci)¶

Rôle¶

Ce dépôt IaC (/root/veeam) est conçu pour provisionner un Veeam Hardened Repository (cible de stockage immuable pour Veeam Backup & Replication) — pas le serveur Veeam B&R lui-même. Objectif : cible de sauvegarde pour l'infrastructure, avec protection anti-ransomware par immuabilité.

Architecture¶

Ce que le code Terraform déclare (non appliqué actuellement)¶

• VM unique veeam-repo01 (nom historique, pas encore migré vers la convention IND<SEGMENT><NNN>), zone sauvegarde (seg-sauvegarde), 4 vCPU / 8 Go, clone du template Rocky 9.6 durci.
• IP fixe 10.100.3.17/28 (var.vm_ip) — pas de lookup NetBox, contrairement au reste de la flotte applicative récente (k8s/glpi/ocs/postfix).
• Disque data dédié de 1 To (disk1-backup), XFS avec l'option reflink=1 (support du « fast clone » Veeam), monté sur /mnt/veeam-repo.
• Compte Linux dédié veeamrepo, sudo temporaire pour le déploiement initial du Data Mover Veeam.
• Ports firewalld 2500-3300/tcp (transport Veeam), zone drop.

Ce qui existe réellement sur vCenter (constaté le 2026-07-19)¶

Les 4 VM sont raccordées au portgroup seg-sauvegarde (dvportgroup-2006, le même réseau que le projet Terraform cible) mais l'adaptateur réseau est déconnecté (Connected: false). Les noms de fichiers .vmdk (veeam.vmdk, veeam-proxy.vmdk) trahissent une création initiale sous les anciens noms manuels (veeam, veaam-proxy01/02, veea-repo — avec coquilles, cf. mémoire de convention de nommage), renommés depuis vers le schéma INDSAUV00x sans recréation du disque sous-jacent.

Interprétation prudente à partir des seuls éléments observables (OS + ISO monté, aucune inspection console faite) : INDSAUV001 (Windows + ISO Windows Server) est vraisemblablement destinée à devenir le serveur Veeam Backup & Replication ; INDSAUV002/003/004 (Rocky + ISO VeeamJeOS, l'image d'appliance "Just enough OS" officielle de Veeam pour déployer des rôles hardened repository/proxy) sont vraisemblablement destinées à des rôles de repository/proxy. Aucune des 4 VM n'a d'OS confirmé installé (pas d'IP remontée, ISO non connecté activement) — préparation en cours ou en pause, pas un service opérationnel.

État constaté¶

flowchart TB
    subgraph IaC["Terraform /root/veeam — declare, PAS applique"]
        T1["vsphere_virtual_machine.veeam_repo (absent du state)<br/>nom cible : veeam-repo01 - 4 vCPU/8 Go<br/>disque data 1 To XFS reflink<br/>IP fixe 10.100.3.17"]
    end

    subgraph Real["vCenter /Datacenter/vm/veeam - hors Terraform, constate le 2026-07-19"]
        direction TB
        V1["INDSAUV001<br/>Windows Server 2025 - 4 vCPU/32 Go<br/>poweredOff, pas d'IP"]
        V2["INDSAUV002<br/>Rocky Linux - 4 vCPU/16 Go<br/>poweredOff, pas d'IP"]
        V3["INDSAUV003<br/>Rocky Linux - 4 vCPU/16 Go<br/>poweredOff, pas d'IP"]
        V4["INDSAUV004<br/>Rocky Linux - 4 vCPU/16 Go<br/>poweredOff, pas d'IP"]
    end

    Seg(["Segment seg-sauvegarde<br/>10.100.3.16/28"])
    V1 -.-> Seg
    V2 -.-> Seg
    V3 -.-> Seg
    V4 -.-> Seg
    T1 -.->|"jamais applique"| Seg

Structure du dépôt¶

Provisioning Terraform¶

• main.tf : ressource vsphere_virtual_machine.veeam_repo, avec un second disque (disk1-backup, unit_number = 1, 1 To par défaut via var.data_disk_mb).
• Variables clés (variables.tf) : vsphere_network = seg-sauvegarde, vm_gateway = 10.100.3.30, vm_name = veeam-repo01, vm_cpu = 4, vm_ram = 8192.
• Pas de provider NetBox dans ce projet : IP statique (var.vm_ip) — seul projet applicatif récent de la flotte qui n'a pas basculé vers l'allocation dynamique NetBox.
• Vérifié le 2026-07-19 (terraform state list dans /root/veeam) : le state contient uniquement data.vsphere_compute_cluster.cluster, data.vsphere_datacenter.dc, data.vsphere_datastore.ds, data.vsphere_network.net, data.vsphere_virtual_machine.template — aucune instance de vsphere_virtual_machine.veeam_repo. L'historique git (5 commits) montre une préparation continue du code après la suppression manuelle de la VM d'origine le 2026-07-04 (élargissement du netmask /28, correction du gateway .30, bascule du compte de service svc-terraform) mais aucune trace d'un ré-apply réussi depuis.
• Si ce code était appliqué tel quel aujourd'hui, il créerait une 5ᵉ VM sur seg-sauvegarde, nommée veeam-repo01 — nom qui ne suit pas la convention IND<SEGMENT><NNN> déjà en usage sur les 4 VM manuelles du même segment (INDSAUV001-004). Un renommage (INDSAUV005, le segment étant partiellement occupé — jamais reprendre un numéro déjà utilisé) serait nécessaire avant tout apply, en plus de clarifier si ce 5ᵉ rôle (repository Terraform/Ansible) fait doublon avec l'un des 4 déjà présents.

Configuration Ansible¶

• ansible/site.yml applique le rôle veeam_repo sur l'hôte veeam_repo (inventory.ini). Non exécuté contre une cible vivante depuis le 2026-07-04 (aucune VM gérée par ce projet n'existe actuellement — voir ci-dessus) ; le code ci-dessous décrit ce que ferait un futur apply, pas un état en cours.
• Rôle veeam_repo (roles/veeam_repo/tasks/main.yml) : crée le système de fichiers XFS (opts: -m reflink=1) sur le disque data, récupère son UUID (blkid) et le monte de façon persistante (ansible.posix.mount, noatime), crée le compte veeamrepo (mot de passe géré via ansible-vault, groupe wheel temporaire), active chronyd, crée backups/ (mode 0700, propriété du compte dépôt), ouvre les ports de transport Veeam (2500-3300/tcp, zone drop).
• Playbook séparé ansible/post-hardening.yml, à exécuter une seule fois, après avoir ajouté le dépôt dans la console Veeam : retire le compte dépôt du groupe wheel, supprime son éventuel sudoers dédié, vérifie la synchronisation horaire (chronyc tracking), puis désactive et arrête définitivement SSH (async/poll: 0 pour survivre à la coupure de la connexion Ansible elle-même), ferme le port SSH en firewalld.

Procédure manuelle¶

1. Ajout du dépôt dans la console Veeam Backup & Replication (hors périmètre de ce dépôt IaC, produit tiers non provisionné ici) → déploiement du Data Mover par Veeam via SSH et le compte veeamrepo.
2. Constat à traiter avant toute reprise : les 4 VM INDSAUV001-004 observées sur vCenter (voir Architecture) suggèrent qu'un déploiement manuel plus large (serveur B&R Windows + appliance(s) repository/proxy via l'ISO officiel VeeamJeOS) a été entamé en dehors de tout IaC, indépendamment de ce projet Terraform/Ansible. Les 4 VM sont actuellement hors tension et sans réseau actif — état de préparation, pas de service rendu. Avant de relancer un travail sur Veeam, clarifier avec le user lequel des deux chemins est la cible réelle (le repository Terraform/Ansible de ce dépôt, ou la construction manuelle déjà entamée) pour éviter un doublon.
3. Si le chemin Terraform/Ansible de ce dépôt est confirmé : renommer veeam-repo01 → INDSAUV005 dans variables.tf/terraform.tfvars avant l'apply (voir Provisioning Terraform).

Procédure de déploiement¶

terraform apply                                       # provisionne la VM et son disque data
cd ansible && ansible-playbook site.yml                # FS, compte dépôt, accès réseau
# --- ajout manuel du dépôt dans la console Veeam (hors IaC) ---
ansible-playbook post-hardening.yml -e @/root/.hap_secrets.yml   # IRRÉVERSIBLE : coupe SSH

Contrôle de santé / Vérification¶

Aucune VM opérationnelle actuellement (ni via ce projet Terraform — state vide —, ni les 4 VM manuelles constatées — toutes hors tension) : rien à vérifier en fonctionnement au 2026-07-19. Pour un futur déploiement via ce dépôt :

ssh veeamrepo@<ip> 'df -h /mnt/veeam-repo && xfs_info /mnt/veeam-repo | grep reflink'
ssh veeamrepo@<ip> 'chronyc tracking'

Points d'attention¶

• Divergence état réel / IaC : cette page décrit un projet Terraform/Ansible cohérent et prêt à appliquer, mais qui ne reflète pas ce qui existe réellement sur vCenter au 2026-07-19 (4 VM manuelles, éteintes, jamais provisionnées par ce code). Ne pas supposer qu'un service Veeam est opérationnel sur la seule base de ce dépôt.
• Nom de VM cible (veeam-repo01) pas encore aligné sur la convention IND<SEGMENT><NNN>, contrairement aux VM manuelles déjà présentes sur le même segment (INDSAUV001-004).
• IP encore statique (pas de lookup NetBox) — à harmoniser avec le reste de la flotte si ce projet est un jour réappliqué.
• Ce dépôt ne configure, dans tous les cas, que la cible de stockage (repository) ; la définition des jobs de sauvegarde (quelles VM, planification, rétention) se ferait entièrement dans la console Veeam B&R, hors de ce dépôt IaC.
• Le serveur Veeam Backup & Replication lui-même (Windows) n'apparaît dans aucun fichier Terraform/Ansible de ce dépôt — cohérent avec le constat qu'INDSAUV001 (Windows Server 2025) a été créée manuellement, hors IaC, comme les contrôleurs de domaine AD.
• Compte dépôt délibérément retiré des droits sudo après le déploiement initial (principe du moindre privilège une fois le Data Mover en place) — s'applique si/quand ce projet est effectivement déployé.