Reprise après sinistre

AccessPoint s'exécute entièrement dans votre abonnement Azure. La planification de la reprise après sinistre s'appuie sur les capacités intégrées de redondance et de récupération d'Azure. L'éditeur ne détient aucune donnée client, la récupération est donc entièrement sous votre contrôle.

Objectifs de récupération

Sauvegarde et récupération

Base de données

• Restauration à un point dans le temps (PITR) : Automatique, jusqu'à 35 jours. Aucune configuration manuelle requise.
• Rétention à long terme (LTR) : Configurez des sauvegardes hebdomadaires, mensuelles ou annuelles pour la conformité. Configuration via Portail Azure > SQL Database > Sauvegardes > Stratégies de rétention.
• Sauvegarde géo-redondante : Activée par défaut sur les niveaux Standard et Premium. Permet la restauration vers une région Azure appariée en cas de panne régionale.

Blob Storage

• Suppression réversible : Activez la suppression réversible pour les blobs et les conteneurs afin de récupérer les documents supprimés accidentellement. Rétention recommandée : 30 jours.
• Gestion des versions : Activez la gestion des versions des blobs pour conserver les versions précédentes des documents écrasés.

Configuration

Exportez ou documentez vos packs de configuration avant d'effectuer des modifications majeures. Si un changement de configuration doit être annulé, la seule option est de restaurer à partir d'une sauvegarde de la base de données.

Procédures de restauration

Restauration de l'API

L'API est déployée sous forme de package zip dans Azure App Service. Pour revenir à un déploiement précédent :

1. Ouvrez le Portail Azure et accédez à votre App Service
2. Allez dans Centre de déploiement > Historique de déploiement
3. Localisez le déploiement réussi précédent
4. Sélectionnez-le et cliquez sur Redéployer
5. Vérifiez que l'application fonctionne correctement

Si vous utilisez des emplacements de déploiement, permutez vers l'emplacement précédent via Emplacements de déploiement > Permuter.

Restauration de la base de données

Les déploiements DacPac sont additifs par défaut — de nouvelles colonnes et tables sont ajoutées, mais les objets existants ne sont pas supprimés. Cela offre un filet de sécurité pour la plupart des modifications de schéma.

Pour les problèmes de données (données corrompues ou incorrectes), utilisez la restauration à un point dans le temps d'Azure SQL :

1. Restaurez la base de données à un moment précédant le problème
2. Vérifiez le contenu de la base de données restaurée
3. Mettez à jour la chaîne de connexion de l'App Service pour pointer vers la base de données restaurée, ou renommez les bases de données pour les permuter

Restauration SPFx

Pour revenir à une version précédente du composant web SPFx :

1. Téléchargez le package .sppkg de la version précédente depuis le portail Realizer
2. Ouvrez le Catalogue d'applications SharePoint
3. Téléversez le package précédent en remplaçant la version actuelle
4. Cliquez sur Déployer

Restauration de la configuration

Les packs de configuration sont additifs — l'importation d'un pack ajoute ou met à jour des éléments, mais ne supprime pas les éléments existants. Pour annuler des modifications de configuration, restaurez la base de données à partir d'une sauvegarde à un point dans le temps effectuée avant la modification.

Scénarios de reprise après sinistre

Scénario 1 : Suppression accidentelle de données

1. Documents supprimés du Blob Storage : Si la suppression réversible est activée, récupérez les blobs dans la fenêtre de rétention configurée
2. Enregistrements de base de données supprimés : Utilisez la restauration à un point dans le temps d'Azure SQL au moment précédant la suppression. Copiez les enregistrements nécessaires de la base de données restaurée vers la production.

Scénario 2 : Panne de région Azure

Si la région Azure hébergeant votre déploiement devient indisponible :

1. Azure SQL : Restaurez à partir des sauvegardes géo-redondantes vers un nouveau SQL Server dans une région différente
2. Blob Storage : Si vous utilisez un stockage géo-redondant (GRS ou RA-GRS), initiez un basculement de compte. Si vous utilisez un stockage localement redondant (LRS), les données doivent être restaurées à partir d'une sauvegarde externe.
3. App Service : Redéployez à l'aide du modèle Bicep dans la région de récupération
4. DNS et URL de l'API : Mettez à jour l'entité de stockage de l'URL de l'API AccessPoint dans SharePoint pour pointer vers la nouvelle URL de l'App Service

Scénario 3 : Reconstruction complète de l'environnement

L'ensemble de l'environnement AccessPoint peut être reconstruit à partir de zéro en utilisant les artefacts de déploiement publiés :

1. Exécutez le modèle Bicep pour provisionner toutes les ressources Azure
2. Déployez le zip de l'API dans l'App Service (inclus dans le déploiement ARM)
3. Le schéma de base de données se déploie automatiquement au premier démarrage de l'API
4. Téléversez le .sppkg SPFx dans le catalogue d'applications SharePoint
5. Exécutez Deploy-AccessPoint.ps1 pour configurer l'authentification Entra uniquement pour SQL et les autorisations Graph
6. Restaurez la base de données à partir de la sauvegarde la plus récente pour récupérer les données
7. Restaurez les documents du Blob Storage à partir des sauvegardes géo-redondantes

L'infrastructure en tant que code (modèles Bicep) et le script de déploiement garantissent que l'environnement est entièrement reproductible.

Recommandations de planification

• Activez le stockage géo-redondant (GRS) sur le compte Blob Storage pour la redondance documentaire inter-régions
• Activez la rétention à long terme (LTR) sur Azure SQL pour les sauvegardes hebdomadaires, mensuelles et annuelles au-delà de la fenêtre PITR par défaut
• Activez la suppression réversible sur le Blob Storage avec une période de rétention de 30 jours
• Activez la gestion des versions des blobs pour récupérer les documents écrasés
• Documentez vos paramètres de déploiement — conservez un enregistrement de votre nom de locataire, groupe de ressources, adresse courriel d'alerte et tout paramètre personnalisé de l'App Service afin de pouvoir redéployer rapidement
• Testez la récupération annuellement — restaurez la base de données et le Blob Storage dans un environnement de test pour vérifier le bon fonctionnement de vos sauvegardes
• Envisagez Azure Front Door ou Traffic Manager si votre organisation nécessite un basculement automatique avec un temps d'arrêt minimal

Surveillance de la santé

AccessPoint expose deux points de terminaison de vérification de santé :

Métriques clés à surveiller

Mise à l'échelle

Mise à l'échelle verticale (montée en puissance)

Modifiez le niveau du plan App Service dans Portail Azure > App Service > Montée en puissance (plan App Service). Aucun redéploiement requis.

Mise à l'échelle horizontale (augmentation du nombre d'instances)

L'API AccessPoint est sans état et prend en charge plusieurs instances. Configurez la mise à l'échelle manuelle ou automatique dans Portail Azure > App Service > Augmenter le nombre d'instances (plan App Service).

Mise à l'échelle SQL

Ajustez le niveau de la base de données en fonction de la charge de travail. Objectifs de service courants : Basic, S0, S1, S2, S3, P1, P2.

Rotation des certificats et des secrets