| 
Choix et mise en place d'une stratégie de sauvegarde/restauration Cette stratégie est bien évidemment fonction de: - vos unités de stockage + grande capacité ou non + haut débit ou non - absence ou présence d'un opérateur de nuit - Capacité disque (volume occupé, espace disponible) - fourchette d'heures de disponibilité souhaitée du système - est-il acceptable (pour la survie de l'entreprise) de perdre des informations (si oui combien de temps de saisie?) d'avoir un système informatique non disponible (là encore, combien de temps maxi) |
|
Plus le système est simple à mettre en place, moins il est coûteux, - plus la perte d'information est importante. - plus le temps de recouvrement en cas de défaillance peut être long. Il y a deux grands risques d'incidents: Arrêt du système sans disques endommagés (panne ou coupure de courant) = perte d'informations volatiles (transactions en cours) = perte d'informations systèmes (spools,...) = temps de reprise (IPL beaucoup plus long !!!!) Deux solutions: 1°/ onduleur (UPS) Peut envoyer un signal à l'AS lui indiquant le passage de l'alimentation en mode SECOURS. Couplé avec un traitement de ce qu'il faut faire au fur à mesure que le temps s'écoule, si le courant n'est pas rétabli. |
|
Pensez aux valeurs systèmes suivantes: - QABNORMWS indique si le dernier arrêt était normal. (permet de conditionner des traitements automatiques à l'IPL) - QPWRRSTIPL indique si vous désirez un IPL automatique lors de la remise sous tension. - QUPSMSGQ indique une file d'attente message recevant tous les messages UPS (elle doit être en délivrance *BREAK ou NOTIFY sur un travail actif). - QUPSDLYTIM indique le temps au bout duquel le système doit s'arrêter si le courant n'est pas rétabli. Ces deux dernières supposent un signal envoyé de l'onduleur vers l'AS/400. PENSEZ AUSSI AU RETABLISSEMENT DES CHEMINS D'ACCES. paramètre RECOVER() sur CRTxF et val-système QDBRCVYWT. |
|
2°/ Commit/Rollback. Un des risques en cas d'arrêt du système est la désynchronisation des fichiers B de D dépendants. La gestion des transactions par pgm (en s'appuyant sur la fonction journal) minimise les risques d'incohérences dans vos fichiers. 3°/ il n'y a pas de solution satisfaisante aujourd'hui en ce qui concerne la sauvegarde des spools. Regardez quand même l'outil dans QUSRTOOL Deuxième grand incident (MAJEUR) Le "plantage" disque ==> RISQUE de perte d'informations ==> TEMPS DE RECOUVREMENT. |
|
I/ Solution simple, vous avez des sauvegardes complètes (les plus récentes possibles) 1°/ de votre système SAVSYS 2°/ de vos données/systèmes SAVSECDTA et SAVCFG 3°/ des données entreprises. objets: SAVLIB *ALLUSR documents: SAVDLO *ALL Moins importants sont : les produits sous licence - il est toujours possible de recharger et d'appliquer la dernière cumulative. Les bibliothèques de développeur - souvent traitées par SAVCHGOBJ sur les fichiers source (perte de travail sur une journée ?) |
|
II/ Vous souhaitez réduire le temps d'indisponibilité des objets afin de pouvoir faire vos sauvegardes de jour. Utilisez le paramètre SAVACT a/ Le système établit un point de contrôle (Les objets sont indisponibles) b/ le point de contrôle établi, la disponibilté des objets est rendue c/ les pages de fichier modifiées pendant la sauvegarde sont dupliquées d/ en fin de sauvegarde, les modifications (enregistrées dans les pages dupliquées) sont répercutées. Gain: Temps d'indisponibilté réduit. Désavantages: Les modifications ne sont pas sauvegardées (fichiers désynchronisés ?) Le temps de traitement global est plus long. DANGER en cas d'arrêt du système, pendant la sauvegarde. |
|
III/ Vous mettez en place la fonction journal avec détachement et sauvegarde du récepteur toutes les demi-journées. Gains: un SAVLIB par semaine détachement du récepteur en activité (inutile d'arrêter les utilisateurs) sauvegarde rapide (volume faible) vous ne perdez plus qu'une demi-journée. (quand même !) la fonction journal peut être utilisée à des fins d'analyse. (DSPJRN) Désavantages: Légère dégradation des performances (E/S disques supplémentaires) Gestion des récepteurs (ménage) |
|
IV/ Vous associez à la fonction journal, la notion d'ASP Un ASP est un disque (ou un bras d'accès) "sorti" de la notion d'espace adressable unique. Historiquement il ne pouvait contenir que journal, récepteur et SAVF Cela reste (c'est une opinion arbitraire) son intérêt premier !!! Si vous perdez ce disque. ==> aucune perte de données, l'E.A.U est intacte.(mais le système est indisponible) Si vous perdez un autre disque (ASP système) ==> vous récupérez les éléments de l'ASP par RCLSTG. ==> Vous restaurez .votre journal et tous vos récepteurs .vos bibliothèques (SAVLIB hebdomadaire) ==> vous appliquez les modifs du journal (APYJRNCHG) Normalement vous ne devez perdre aucune transaction. |
|
Gains: - aucune perte de données (sur les fichiers) - Vos sauvegardes via SAVF sont plus sûres (SAVF dans l'ASP) - la manipulation d'ASP est devenue souple (principalement en cas de débordement) - vous avez toujours la possibilité d'utiliser Commit/Rollback Désavantages: Légère dégradation des performances (E/S disques supplémentaires, et sur un disque imposé !) Le temps de reprise est très long. (nous pouvons toujours atteindre, comme avec les solutions précédentes, 12 à 24 Heures, suivant votre config.) |
|
V / Toutes les solutions à venir impliquent des investissements supplémentaires conséquents : A: CHECKSUM le système établisait (IBM/38) une fonction XOR entre deux disques avec résultat sur un troisième. Il y A TOUJOURS arrêt de la machine (temps de réparation) Le disque remplacé est reconstruit automatiquement à l' IPL ! B: RAID-5 la fonction XOR est assurée par l'unité disque. (qui posséde son propre processeur et plusieurs disques 3,5') Un cas de problème sur un disque physique, l'unité est capable de fonctionner en mode dégradé. (reconstitution des infos manquantes à chaque lecture) C: MIRRORING les disques sont doublés (les écritures aussi) Aucun arrêt en cas de problème, ni pendant l'intervention. (MIRRORING possible au niveau Bus et Contrôleur) |
|
VI/ ET ENFIN le BACKUP complet. DEUX AS/400. - L'AS de backup peut être utilisé pour le développement. - les configurations doivent être dupliquées. (basculement rapide) - Vous pouvez dupliquer régulièrement vos modifs B de D. Avec la fonction journal (transfert du récepteur et APYJRNCHG) - OU quasi-temps réel (RCVJRNE et traitement APPC) La V3R10 propose un outil de réplication (DATA-PROPAGATOR) Vous devrez probablement vous acquiter des licences pour vos deux AS ? A VOUS de FAIRE le ratio - combien me coûterait une solution X ? - combien coûte aujourd'hui à l'entreprise un plantage avec ma solution Y ? |
