Annexe B, Redémarrage rapide

4D - Documentation   Français   English   German   4D Backup, Commandes par thème   4D Backup, Liste alphabétique des commandes   Retour   Précédent   Suivant

version 6.0


Cette annexe résume les opérations à effectuer pour redémarrer l'exploitation de votre base après un incident, en fonction du type d'incident et du mode de sauvegarde choisi.

Pour plus de détails, reportez-vous au Guide d'utilisation de 4D Backup.

En cas d'arrêt accidentel de l'exploitation


L'arrêt inopiné de l'exploitation d'une base de données peut avoir plusieurs causes : coupure de courant, panne d'un élément du système, etc.

Trois cas peuvent alors se présenter, en fonction de l'état du cache de données de 4D :

L'incident se produit alors que le cache de données est vide (aucune modification n'a été apportée sur la base depuis la dernière écriture du cache sur le disque).

L'incident se produit alors que le cache contient des modifications de la base n'ayant pas été reportées dans le fichier de données.

L'incident se produit pendant l'écriture sur disque du cache de 4D.

Dans tous les cas, relancez votre base avec 4D et identifiez votre situation. Les symptômes correspondant à chaque cas et les opérations de récupération sont décrits dans les paragraphes suivants.

Note : Pour plus d'informations sur le cache de données, reportez-vous à la documentation de 4D.

Cache vide

Symptômes : Aucun, la base s'ouvre normalement

Procédures de redémarrage : Toutes les modifications apportées à la base ont été enregistrées. Ce cas ne nécessite aucune opération particulière.

Cache contenant des opérations

Symptômes : Les dernières opérations effectuées dans la base manquent. De plus, si votre base travaillait avec un fichier d'historique, 4D affiche à l'ouverture de la base les messages "Le fichier d'historique contient plus d'opérations qu'il n'en a été effectué sur la base." et "Utilisez 4D Backup pour intégrer ces opérations dans la base."

Procédures de redémarrage :

1. Intégrez le fichier d'historique courant dans votre base pour récupérer les opérations manquantes.

Si vous travailliez sans fichier d'historique, ces opérations sont perdues.

2. Relancez votre base avec votre application 4D.

Cache en écriture

Symptômes : Il est impossible d'ouvrir la base avec 4D. Le programme affiche un message d'alerte vous signalant des erreurs physiques dans le fichier de données.

Procédures de redémarrage :

Repartez de la dernière sauvegarde de la base :

1. Restituez votre dernière sauvegarde intégrale ou, dans le cas de sauvegardes par miroir logique, recopiez la base miroir sur le poste en exploitation.

2. Si votre base exploitait un fichier d'historique, intégrez l'historique courant dans cette base pour retrouver l'intégralité de vos données.

En cas de perte d'un fichier de la base


La perte d'un ou plusieurs fichier(s) de votre base peut avoir de nombreuses causes : secteurs défectueux sur le disque contenant la base, virus, ou encore effacement par erreur.

Bien entendu, si le problème est d'ordre technique, commencez par le rechercher et l'éliminer, par exemple en lançant un utilitaire de détection des blocs abîmés sur votre disque, un détecteur de virus, etc.

Les opérations de redémarrage de l'exploitation diffèrent suivant votre mode d'utilisation de 4D Backup (sauvegardes régulières — avec ou sans fichier d'historique — ou miroir logique).

Utilisation de sauvegardes intégrales

1. Restituez, à partir de la dernière sauvegarde intégrale de votre base, le ou les fichier(s) perdu(s).

Lorsqu'un fichier de données segmenté est endommagé, vous devez toujours restituer l'ensemble des segments (même si seul un segment a été perdu).

2. Si le fichier de données a été perdu et restitué, il se peut que 4D affiche les messages suivants à l'ouverture de la base :

Message 1 : "Le fichier d'historique contient plus d'opérations qu'il n'en a été effectué dans la base."

Message 2 : "Utilisez 4D Backup pour incorporer ces opérations dans la base."

Dans ce cas, intégrez le fichier d'historique courant dans la base que vous venez de restituer.

3. Si, depuis la dernière sauvegarde intégrale, vous aviez sauvegardé uniquement l'historique (sans le fichier de données), il vous faudra intégrer dans l'ordre les différentes sauvegardes de l'historique (comportant les suffixes "-a", "-b", etc).

Utilisation d'un miroir logique

Les opérations de redémarrage d'une base sauvegardée à l'aide d'un miroir logique sont simples :

1. Recopiez le fichier de la base miroir sur le poste en exploitation.

2. Intégrez l'historique courant dans la base recopiée.

En cas d'incident lors de la mise à jour du miroir


Si votre base est sauvegardée à l'aide d'un miroir logique, il peut arriver qu'un incident se produise pendant la mise à jour du miroir. L'incident peut avoir pour origine une coupure de courant, un mauvais fonctionnement du réseau, un secteur défectueux sur le disque du poste miroir, etc.

Cet incident, relativement rare, nécessite des procédures de remise en route particulières, suivant la phase de mise à jour dans laquelle se trouvait le miroir.

Au moment du redémarrage du poste miroir, 4D Backup vous signale par des messages d'alerte toute anomalie rencontrée et vous donne des indications sur les opérations à effectuer.

Analyse de la situation

Vous devez connaître deux informations :

l'état de vos deux bases (la base en exploitation et la base miroir),

le stade de l'intégration du fichier d'historique au moment de l'incident.

Etat des bases

Vous devez savoir si vos bases sont utilisables ou non. Si l'incident a eu lieu pendant l'écriture sur disque du cache de données de la base en exploitation, la base sera endommagée. De même, si l'incident a eu lieu pendant que la base miroir intégrait le fichier d'historique, la base miroir sera également inutilisable.

Pour vérifier l'état de ces deux bases, ouvrez-les avec votre application 4D, qui vous signalera si la base est ou non en état.

Note : Si, sous MacOS, un fichier "Historique en intégration" se trouve dans le dossier "MaBase", ou si, sous Windows, un fichier "Restore.4DL" se trouve dans le répertoire "MaBase.MIR", condidérez que votre base miroir est endommagée, même si elle semble s'ouvrir correctement avec 4D.

Quatre hypothèses peuvent donc se présenter :

Les deux bases sont intactes (mais des fichiers d'historique intermédiaires non détruits empêchent le redémarrage de l'exploitation).

Seule la base en exploitation est endommagée.

Seule la base miroir est endommagée.

Les deux bases sont endommagées.

Stade d'intégration du fichier d'historique

Lors du processus interne de mise à jour du miroir, le fichier d'historique est renommé à chaque étape (pour plus d'informations sur ce processus, reportez-vous au chapitre "Exploitation d'un miroir logique" du Guide d'utilisation de 4D Backup).

En conséquence, suivant l'instant de l'incident, un fichier d'historique initalement intitulé "MaBase.log" sous MacOS et "MABASE.4DL" sous Windows pourra avoir les noms suivants :

Sur le poste en exploitation (dans le répertoire contenant l'historique) :

MacOSWindows
MaBase.logMABASE.4DL
MaBase.log.2MABASE.4L2
Historique à envoyerSENDING.4DL

Sur le poste miroir (dans le dossier "MaBase" sous MacOS, dans le répertoire "Mabase.MIR" sous Windows) :

MacOSWindows
Historique en réceptionRECEIVE.4DL
Historique en analyseANALYZE.4DL
Historique en intégrationRESTORE.4DL
Historique miroirMIRROR.4DL

Hypothèse n°1 : les deux bases sont intactes

L'incident a eu lieu en-dehors de toute phase d'écriture du cache des données. Cependant, la mise à jour du miroir peut avoir échoué et la présence de fichiers d'historique intermédiaires peut entraîner l'impossibilité de redémarrer. Plusieurs cas sont à distinguer, en fonction du stade d'intégration de l'historique et des fichiers présents sur les postes.

Premier cas

Fichiers sur le poste en exploitationFichiers sur le poste miroir
MacOSWindowsMacOSWindows
MaBase.logMABASE.4DLAucunAucun

Malgré l'incident, la mise à jour s'est déroulée correctement.

Redémarrez l'exploitation.

Deuxième cas

Fichiers sur le poste en exploitationFichiers sur le poste miroir
MacOSWindowsMacOSWindows
MaBase.log +MABASE.4DL +AucunAucun ou
Historique à SENDING.4DLou HistoriqueRECEIVE.4DL
envoyerou MABASE.4L2en réception
ou MaBase.log.2

Le fichier d'historique n'a pas été envoyé au miroir (ou pas en totalité).

1. Sur le poste miroir, effacez, s'il s'y trouve, le fichier Historique en réception ou RECEIVE.4DL.

2. Relancez le poste miroir.

3. Relancez la base en exploitation.

4. Effectuez une mise à jour du miroir.

Note : Si le fichier MaBase.log.2 (MacOS) ou MABASE.4L2 (Windows) se trouve sur le poste en exploitation, renommez-le Historique à envoyer (MacOS) ou SENDING.4DL (Windows).

Troisième cas

Fichiers sur le poste en exploitationFichiers sur le poste miroir
MacOSWindowsMacOSWindows
MaBase.logMABASE.4DLHistorique en analyseANALYZE.4DL

Le fichier d'historique a été envoyé au miroir mais n'a pas été intégré dans la base miroir.

1. Sur le poste miroir, intégrez Historique en analyse ou ANALYZE.4DL dans la base miroir.

2. Effacez le fichier que vous venez d'intégrer.

3. Relancez le poste miroir.

Quatrième cas

Fichiers sur le poste en exploitationFichiers sur le poste miroir
MacOSWindowsMacOSWindows
MaBase.logMABASE.4DLHistorique miroirMIRROR.4DL

La base miroir a été mise à jour mais sa sauvegarde intégrale a été interrompue.

1. Sur le poste miroir, effectuez une sauvegarde intégrale de la base miroir.

Placez l'archive dans le dossier "MaBase" (MacOS) ou "MABASE.MIR" (Windows).

2. Effacez le fichier Historique miroir ou MIRROR.4DL.

3. Relancez le poste miroir.

Hypothèse n° 2 : seule la base en exploitation est endommagée

Lorsque la base en exploitation est inutilisable, le principe de remise en route consiste à recopier la base miroir sur le poste en exploitation. Plusieurs cas sont à distinguer, en fonction du stade d'intégration de l'historique et des fichiers présents sur les postes.

Premier cas

Fichiers sur le poste en exploitationFichiers sur le poste miroir
MacOSWindowsMacOSWindows
MaBase.log +MABASE.4DL +AucunAucun
Historique àSENDING.4DLou Historiqueou
envoyer ouou MABASE.4L2en réceptionRECEIVE.4DL
MaBase.log.2

Le fichier d'historique n'a pas été envoyé au miroir (ou pas en totalité).

1. Sur le poste miroir, effacez, s'il s'y trouve, le fichier Historique en réception ou RECEIVE.4DL

2. Recopiez le fichier de données de la base miroir sur le poste en exploitation.

3. Intégrez successivement les fichiers Historique à envoyer puis MaBase.log (MacOS) ou SENDING.4DL puis MABASE.4DL (Windows) dans la base que vous venez de recopier.

4. Ouvrez cette base avec votre application 4D et sélectionnez MaBase.log ou MABASE.4DL comme fichier d'historique courant.

5. Relancez le poste miroir.

Note : Si le fichier MaBase.log.2 (MacOS) ou MABASE.4L2 (Windows) se trouve sur le poste en exploitation, renommez-le Historique à envoyer (MacOS) ou SENDING.4DL (Windows).

Deuxième cas

Fichiers sur le poste en exploitationFichiers sur le poste miroir
MacOSWindowsMacOSWindows
MaBase.logMABASE.4DLHistorique en analyseANALYZE.4DL

Le fichier d'historique a été envoyé au miroir mais la base miroir n'a pas été mise à jour.

1. Intégrez le fichier Historique en analyse ou ANALYZE.4DL dans la base miroir.

2. Effacez le fichier Historique en analyse ou ANALYZE.4DL.

3. Recopiez le fichier de données de la base miroir sur le poste en exploitation.

4. Intégrez le fichier MaBase.log ou MABASE.4DL dans la base que vous venez de recopier sur le poste en exploitation.

5. Ouvrez cette base avec votre application 4D et sélectionnez MaBase.log ou MABASE.4DL comme fichier d'historique courant.

6. Relancez le poste miroir

Hypothèse n° 3 : seule la base miroir est endommagée

Vous devez réinstaller le miroir.

1. Détruisez la base miroir inutilisable.

2. Sur le poste en exploitation, détruisez (le cas échéant) les fichiers MaBase.log.2 (MacOS) ou MABASE.4LD (Windows), ainsi que, éventuellement Historique à envoyer (MacOS) ou SENDING.4DL (Windows) désormais inutiles.

3. Recopiez le fichier de données de la base en exploitation sur le poste miroir.

4. Relancez le poste miroir en utilisant le fichier de données que vous venez de recopier.

Hypothèse n°4 : la base en exploitation et le miroir sont endommagés

Cette situation extrême peut se présenter par exemple en cas de panne de courant alors que la base en exploitation écrit sur disque son cache de données et qu'au même moment la base miroir procède à l'intégration de l'historique

Les fichiers présents sont alors :

MaBase.log (MacOS) ou MABASE.4DL (Windows) sur le poste en exploitation,

Historique en intégration (MacOS) ou RESTORE.4DL (Windows) sur le poste miroir.

Le principe de remise en route de l'exploitation consiste à restituer la base à partir de la sauvegarde du miroir, puis d'y intégrer le fichier d'historique.

1. Effacez du miroir le fichier de données endommagé.

2. Restituez la base à partir de la dernière sauvegarde des données de la base miroir et placez-la dans le dossier de la base miroir.

La sauvegarde du miroir se trouve dans le dossier "MaBase" sous MacOS ou "MABASE.MIR" sous Windows, au premier niveau du disque de sauvegarde du poste miroir.

3. Intégrez dans la base restituée le fichier Historique en intégration (MacOS) ou Restore.4DL (Windows) puis effacez ce fichier.

4. Copiez le fichier de données de la base sur le poste en exploitation.

5. Intégrez le fichier MaBase.log (MacOS) ou MABASE.4DL (Windows) sur le poste en exploitation.

6. Relancez le poste miroir et le poste en exploitation. Sur ce dernier, choisissez le fichier MaBase.log (MacOS) ou MABASE.4DL (Windows) comme historique courant.

L'exploitation peut redémarrer.


4D - Documentation   Français   English   German   4D Backup, Commandes par thème   4D Backup, Liste alphabétique des commandes   Retour   Précédent   Suivant