Restaurer et supprimer la récupération

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 4 minutes de lecture

    • Les contextes de restauration vous permettent d’annuler certaines actions telles qu’une mise à niveau de correctif, l’activation d’un module d’extension et des exécutions de script en arrière-plan, et vous pouvez récupérer des suppressions d’enregistrements et tous les changements associés.

    Les fonctionnalités de restauration et de suppression de la récupération sont disponibles sur les instances qui utilisent des bases de données MySQL et MariaDB. Les instances qui utilisent des bases de données Oracle prennent uniquement en charge la restauration. Les instances qui utilisent SQL Server ne prennent pas en charge la restauration ou la suppression de la récupération.
    Tableau 1. Restaurer et supprimer la prise en charge de la base de données de récupération
    Type de base de données Restaurer Supprimer la récupération
    MySQL yes yes
    MariaDB yes yes
    Oracle yes no

    Module d’enregistrements supprimés

    Ce module fonctionne sur les enregistrements dans les tables auditées. La récupération des enregistrements supprimés en cascade doit être effectuée dans les sept jours suivant la suppression de l’enregistrement. Au bout de sept jours, seuls les enregistrements de données et les références sur les tables dont les suppressions d’audit peuvent être récupérés, ce qui est la même fonctionnalité que les versions précédentes.

    Pour rechercher ce module, accédez à Définition du système > Enregistrements supprimés.

    Supprimer le module de récupération

    Ce module fonctionne pour tout enregistrement supprimé. Cette récupération doit être effectuée dans les sept jours suivant la suppression de l’enregistrement.

    Pour rechercher ce module, accédez à Restauration et reprise > Supprimer la détection.

    Module d’historique des exécutions de script

    Ce module fonctionne sur les scripts exécutés à l’aide du module Scripts - Arrière-plan . Cet historique ne comprend que sept jours d’exécutions de scripts.

    Pour rechercher ce module, accédez à Restauration et reprise > Historique des exécutions de script.

    Contextes de restauration

    Les contextes de restauration contiennent tout ce qui est nécessaire pour restaurer une mise à niveau logicielle ou l’activation d’un module d’extension. Il s’agit notamment des enregistrements supprimés, des mises à jour de correctifs, des exécutions de scripts en arrière-plan, des actions de base de données et des activations de modules d’extension. Un contexte de restauration est créé pour chaque mise à niveau de correctif au sein d’une famille et chaque activation de module d’extension, à condition que le module d’extension prenne en charge les contextes de restauration.

    Pour utiliser des contextes de restauration, activez les modules d’extension Restaurer les enregistrements supprimés (com.snc.undelete) et Supprimer la récupération (com.glide.delete_recovery).

    Les restaurations sont généralement effectuées sur les instances de pré-production où les fonctionnalités doivent être restaurées avant de pouvoir trouver la cause première d’un problème dans la mise à niveau. La restauration supprime des données, ce qui peut souvent rendre difficile, voire impossible, la découverte du problème qui a rendu la restauration nécessaire.

    Un contexte de restauration est créé lorsque :
    • GlideRecord.delete() ou GlideRecord.deleteMultiple() suppriment des enregistrements.
    • Il y a une mise à jour du correctif.
    • Vous activez un module d’extension qui prend en charge les contextes de restauration.
    • Un script s’exécute à l’aide du module Scripts-Background (Arrière-plan ) et la restauration a été activée en sélectionnant la case à cocher Enregistrement pour la restauration ? .

    Les restaurations n’ont pas d’impact sur les autres activités de la base de données. Si une activité de base de données modifie un enregistrement qui fait partie d’un contexte de restauration, la restauration n’affecte pas cet enregistrement.

    Étant donné que les contextes de restauration contiennent une quantité importante de données, les contextes de restauration sont supprimés au bout de 10 jours. Par conséquent, les restaurations doivent avoir lieu dans les 10 jours suivant la dernière mise à niveau ou activation du module d’extension. Si vous devez conserver un contexte de restauration pendant plus de 10 jours, vous pouvez le faire en ajoutant une propriété système. Consultez Propriétés du contexte de restauration.

    Remarque :
    Ne restaurez pas de contexte de restauration avant d’avoir vérifié avec Service et assistance client. Une restauration supprime les données et peut supprimer la preuve du problème de mise à niveau ou d’activation, empêchant le débogage du problème.

    Pour rechercher ce module, accédez à Restauration et reprise > Contextes de restauration.

    Si l’une des opérations suivantes se produit pendant une restauration, aucun contexte de restauration n’est créé :

    • Les tables ou les colonnes sont supprimées du schéma.
      Remarque :
      Les baisses d’index sont acceptables.
    • Une table est tronquée.
    • Une table ou une colonne est renommée.
    • Une colonne est reparentée ou promue.
    • Un type de colonne change.
    • La largeur d’une colonne est diminuée.
    Le processus Now Support de restauration effectue les opérations suivantes :
    • Met à jour le WAR signalé vers la version restaurée et le WAR affecté reste défini sur la version antérieure à la restauration.
    • Définit la propriété glide.war.no_upgrade sur l’instance est défini sur la version antérieure à la restauration.
    • Affiche le message « La guerre souhaitée correspond à la guerre annulée spécifiée par la propriété [glide.war.no_upgrade]. Le script de mise à niveau ne s’exécutera PAS ».
    • Passe l’état à Expiré et la restauration purge toutes les données stockées.