Le versionnement est utile tant que la bibliothèque SharePoint reste accessible. Si la base de contenu ou la ferme entière ne répond plus, la version précédente est enfermée au même endroit que l’actuelle. Il faut distinguer les couches de protection par le scénario qu’elles corrigent.

Le versionnement conserve des états d’un même élément dans la base de contenu. La corbeille marque certaines suppressions et permet une récupération pendant sa période de rétention. La sauvegarde copie les bases et les composantes nécessaires vers un autre support. Ces mécanismes ne couvrent pas la même portée.

mauvaise modification -> historique des versions
suppression            -> corbeille utilisateur / administrateur
base perdue            -> restauration de la base de contenu
ferme perdue           -> reconstruction + configuration + contenu + solutions

Une ferme SharePoint dépend généralement d’une base de configuration, de bases de contenu, d’IIS, de comptes de service et de solutions installées sur les serveurs Web. Restaurer seulement la base de contenu peut rendre les documents présents mais les pages cassées si une Web Part maison manque.

Définir la perte et le délai acceptables

Pour un contrat signé, je donnerais un RPO de quatre heures et un RTO de huit heures. Le RPO indique la quantité maximale de changements perdus; il fixe la fréquence des copies. Le RTO indique le délai de retour; il inclut le temps pour obtenir le backup, restaurer SQL Server, rattacher la base et valider les accès.

Un exercice progressif vérifierait :

1. restaurer la version précédente d’un document modifié;
2. récupérer un élément de la corbeille avec ses propriétés;
3. restaurer une base de contenu sous un autre nom dans un environnement isolé;
4. rattacher le site et installer les solutions requises;
5. ouvrir le document avec un compte autorisé;
6. confirmer qu’un autre compte reçoit encore un refus;
7. comparer versions, métadonnées et heure de la dernière donnée récupérée.

Le test isolé évite de lancer une vieille ferme avec les mêmes URL, comptes ou tâches planifiées que la production. Les secrets et comptes de service doivent être disponibles par une procédure protégée, pas dans un document ouvert à tous.

Le backup peut réussir tout en étant inutilisable. Un fichier tronqué, une version de SQL incompatible, un chiffrement sans clé ou une solution introuvable bloque le retour. Je conserverais donc les logs de restauration et un document témoin connu, puis je répéterais l’exercice après une modification majeure de la ferme.

Pendant l’exercice, le service de restauration lit le jeu de sauvegarde, vérifie ses en-têtes, écrit la base sur un stockage isolé puis SQL Server rejoue son journal pour obtenir une transaction cohérente. SharePoint rattache ensuite cette base et reçoit les requêtes des comptes de test. Décrire ce flux évite de traiter la copie du fichier .bak comme la fin du travail.

La rétention doit correspondre au besoin. Garder cent versions de chaque gros fichier gonfle la base et le temps de sauvegarde. Garder sept jours de backups ne permet pas de récupérer une suppression découverte après un mois. Les contrats, brouillons et fichiers temporaires n’ont pas besoin de la même classe.

Je ne me contenterais plus de backup completed. Pour un document critique, je veux connaître sa base, sa classe de rétention, son RPO, son RTO et la date de la dernière restauration réussie. L’exercice paraît plate jusqu’au jour où il évite d’apprendre la procédure pendant que quelqu’un attend déjà le contrat.