Sélectionner une méthode de récupération après sinistre

Sauvegarde et restauration de volumes de blocs

Le but principal des sauvegardes est de soutenir la continuité des activités, la récupération après sinistre et l'archivage à long terme.

Voici des cas d'emploi courants pour les sauvegardes de volume de blocs :

Création de plusieurs copies du même volume. Les sauvegardes sont utiles lorsque vous avez besoin d'instances comportant de nombreux volumes qui doivent contenir les mêmes données.
Réalisation d'un cliché que vous pouvez restaurer ultérieurement vers un nouveau volume.
Garantir que vous disposez d'une copie fiable des données en cas de problème avec le volume principal.

Lorsque vous définissez votre plan et vos objectifs de sauvegarde, tenez compte des facteurs suivants :

fréquence : fréquence à laquelle vous voulez sauvegarder vos données.
Temps de récupération : durée d'attente avant qu'une sauvegarde ne soit restaurée et rendue accessible aux applications qui l'utilisent. La durée de création d'une sauvegarde dépend de plusieurs facteurs, tels que la taille des données sauvegardées et la quantité de données modifiées depuis la dernière sauvegarde.
Nombre de sauvegardes stockées : nombre de sauvegardes dont vous devez disposer et programmation de la suppression des sauvegardes dont vous n'avez plus besoin.

Lorsque vous créez des sauvegardes et effectuez une restauration à partir de ces sauvegardes, tenez compte des meilleures pratiques suivantes :

Avant de créer une sauvegarde, assurez-vous que les données sont cohérentes : synchronisez le système de fichiers, démontez ce dernier si possible et enregistrez les données d'application. Seules les données sur le disque sont sauvegardées. Lors de la création d'une sauvegarde, lorsque l'état de la sauvegarde passe de REQUEST_RECEIVED à CREATING, vous pouvez reprendre l'écriture des données sur le volume. Lorsqu'une sauvegarde est en cours, le volume sauvegardé ne peut pas être supprimé.
Si vous voulez attacher un volume restauré à l'instance de calcul à laquelle est attaché le volume d'origine, certains systèmes d'exploitation ne prennent pas en charge la restauration de volumes identiques. Pour surmonter cette contrainte, modifiez les ID de partition avant de restaurer le volume. La procédure de modification de l'ID de partition d'un système d'exploitation dépend du système d'exploitation. Reportez-vous à la documentation du système d'exploitation de votre instance de calcul.
Ne supprimez pas le volume d'origine tant que vous n'avez pas vérifié que la sauvegarde a été créée.

Si votre application utilise plusieurs volumes qui couvrent plusieurs instances de calcul, utilisez des sauvegardes de groupe de volumes. Les groupes de volumes simplifient le processus de création de sauvegardes et de clones pour les applications qui utilisent plusieurs volumes sur plusieurs instances. Vous pouvez restaurer l'intégralité d'un groupe de volumes à partir d'une sauvegarde de groupe de volumes, comme indiqué dans le diagramme suivant.

Description de l'image volume-backup-restore.png

Description de l'illustration volume-backup-restore.png ci-après

Créer un voyant de pilote

Le terme éclairage pilote désigne une petite flamme dans un réchauffeur à gaz traditionnel toujours allumé et pouvant être utilisé pour redémarrer rapidement le réchauffeur lorsqu'il est déclenché par des capteurs de température dans la maison. Dans le cadre de la récupération après sinistre, une lumière pilote se compose des principaux composants critiques de votre application, déployés sur le site de récupération après sinistre et contenant la dernière configuration d'application et les données critiques. Ces composants pilotes de base peuvent ensuite être utilisés pour restaurer un environnement de production en cas de sinistre.

Les composants critiques de la lumière pilote sur le site DR sont les suivants :

Niveau base de données
Le service Oracle Cloud Infrastructure Database vous permet de provisionner l'intégralité de votre base de données sur le site de récupération après sinistre (domaine de disponibilité, région ou les deux) sans activer les ressources de taille de production. Lorsque la récupération après sinistre est activée, vous pouvez activer davantage de ressources, avec un seul appel d'API REST vers le service sans redémarrer le serveur de base de données.
Niveau applications
Vous déployez un seul serveur d'applications sur votre site de récupération après sinistre (domaine de disponibilité, région ou les deux) contenant toutes vos dernières configurations. Vous pouvez utiliser la fonctionnalité d'images personnalisées dans Oracle Cloud Infrastructure pour sauvegarder périodiquement votre système d'exploitation et vos applications, puis utiliser ces images pour provisionner de nouveaux serveurs lorsque le site de récupération après sinistre est activé.

Par exemple, si un site de production contient huit serveurs d'applications, vous déployez un seul serveur d'applications sur le site de récupération après sinistre et maintenez-le synchronisé avec le site principal à l'aide de rsync ou d'un autre outil. Vous créez quotidiennement une image personnalisée à partir de ce serveur sur le site de récupération après sinistre qui peut être utilisée pour provisionner les sept serveurs restants lorsque la récupération après sinistre est activée.
Niveau de réseau
Utilisez les fonctionnalités et services Oracle Cloud Infrastructure suivants en mode pilote sur le site de récupération après sinistre
- Adresses IP (privées et publiques)
- Service DNS
- Service d'équilibrage de charge

Utiliser une base de données de secours active

Une base de données de secours active (vers une base de données de secours montée) est une base de données de secours ouverte en lecture seule lors de la récupération de la base de données. La base de données de secours active requiert la fonction et la licence Active Data Guard.

Avec Active Data Guard, la base de données de secours physique peut être utilisée pour des lectures et des rapports réduisant la charge globale potentielle sur la base de données principale. Active Data Guard fournit une protection complète des données grâce à la réparation automatique des corruptions de données physiques et à la vérification d'autres types d'altération de données, tels que les écritures perdues et les corruptions de blocs logiques. Avec la base de données de secours montée, vous bénéficierez également de nombreux avantages en matière de protection des données, à l'exception de la réparation automatique des blocs physiques endommagés. Le temps de récupération (RTO) et la perte de données (RPO) sont généralement très faibles lors du basculement vers une base de données de secours, qu'elle soit ouverte en lecture seule ou non.

Lors de la sélection d'une méthode de récupération après sinistre, déterminez si vous souhaitez des ressources symétriques ou asymétriques :

Ressources symétriques : il s'agit de l'architecture recommandée de sorte que la base de données de secours soit symétrique par rapport au système principal pour s'assurer que les performances de l'application et de la base de données sont similaires ou identiques au moment de la transition de rôle. Cela garantit également que la base de données de secours dispose de ressources suffisantes pour faire face à la charge de travail de production, de sorte que la perte de données est minime au moment du sinistre. Si elle est déployée en tant que base de données de secours active ou avec l'option Active Data Guard, la base de données de secours est ouverte en lecture seule tout en fournissant une protection de récupération après sinistre. Cela vous permet de décharger les rapports et les requêtes.
Ressources asymétriques : cette architecture est une configuration de réduction de l'environnement de secours. Avec Active Data Guard, la base de données de secours peut toujours être lue, offrant les mêmes avantages pour décharger le travail vers la base de données de secours. Toutefois, après le basculement, les performances peuvent être différentes, sauf si vous augmentez le système pour qu'il corresponde au système principal.

Les systèmes de secours asymétriques ou plus petits coûtent moins cher, mais ils peuvent réduire les coûts en matière de calcul, de CPU et de mémoire. Le compromis est effectué après la transition de rôle ou un événement de basculement. Vous devez soit augmenter (agrandir) pour correspondre à votre système principal précédent, soit accepter des performances inférieures ou des fonctionnalités réduites.

Utilisation d'une base de secours froide

Le terme de secours en froid est utilisé pour décrire un scénario de récupération après sinistre dans lequel une réplique redondante de l'environnement principal est déployée sur un site de récupération après sinistre. L'environnement de secours à froid est activé uniquement en cas de panne du système principal. Cette approche assure la continuité de la production avec un temps d'activation bien défini pour la permutation.

Oracle Cloud Infrastructure prend en charge le déploiement automatisé (programmé) d'un environnement de secours à froid qui réduit au minimum les coûts de maintenance d'un tel environnement. Vous n'êtes facturé que pour les ressources actives et tout stockage persistant que vous consommez sur le site de récupération après sinistre.