Mesaventure

Soit un serveur Mac avec une sauvegarde TimeMachine d’activée; celle-ci ne sauvegarde PAS ? le fichier de data .4DD courant ? est-ce dû au fait que la date du fichier de data tant que le serveur est ouvert ne varie pas ? :?: :!:

De plus, sur ce serveur, le backup était paramètré pour se réaliser tous les jours sauf que pour une raison qu’on ignore il s’est arrêté. En relançant l’application serveur, le backup c’est tout de suite relancé…

N’y aurait-il pas quelquechose à mettre en place pour mieux alerter les utilisateurs que la sauvegarde ne s’effectue pas correctement ? Un message d’alerte au démarrage d’un poste client par exemple ? :idea:

C’est un cas particulier, mais ces 2 problèmes cumulés font perdre des données qu’on aurait pu éviter si tout fonctionnait comme il le devrait…

: Manuel PIQUET

N’y aurait-il pas quelquechose à mettre en place pour mieux alerter
les utilisateurs que la sauvegarde ne s’effectue pas correctement ?

J’ai fait ça et ça roule bien

<code 4D>
If (Application type=4D Local mode) | (Application type=4D Volume desktop) | (Application type=4D Server)

C_LONGINT($L_MyError)
Case of 
	: (BK_NoBackup )
		$L_MyError:=-1
	: (BK_BackupDelayed (0))
		$L_MyError:=-2
	Else 
		$L_MyError:=1
End case 

C_TEXT($T_Body)
Case of 
	: ($L_MyError=-1)
		$T_Body:="Vous devriez configurer une sauvegarde de vos données"
	: ($L_MyError=-2)
		$T_Body:="Aucune une sauvegarde n'a été réalisée récemment.\r"+BK_Get_Textinfo (1)
	Else 
		$T_Body:="OK"
End case 

If ($L_MyError#1)
	Send Mail Admin ($T_Body;"Avertissement sur la sauvegarde de vos contrats de maintenance")
End if 

End if

// EOM
</code 4D>

Mouai, mais cela n’explique pas ce que tu testes réellement ? Elles font quoi tes méthodes BK exactement ?

Ça:
<code 4D>
C_BOOLEAN($0)

C_DATE($D_Date)
C_TIME($H_Time)
GET BACKUP INFORMATION(Last backup date;$D_Date;$H_Time)

$0:=($D_Date=!00-00-00!) & ($H_Time=?00:00:00?)
</code 4D>

<code 4D>
C_BOOLEAN($0)
C_LONGINT($1;$L_Delay)
$L_Delay:=$1

ASSERT($L_Delay>=0)

C_DATE($D_Date)
C_TIME($H_Time)
GET BACKUP INFORMATION(Last backup date;$D_Date;$H_Time)

$0:=((Current date-$D_Date)>$L_Delay)

// EOM
</code 4D>

Et ces infos sont fiables :?: Je demande, parce que le backup était bien paramètré sauf qu’il s’est arrêté de fonctionner ?! :-?
Si la date est à jour, on est sûr que le fichier .4BK est bien sauvegardé sur le disque :?:

TimeMachine n’est pas une solution de sauvegarde pour des fichiers de données qui sont par définition toujours ouverts et en activités.

La première règle que j’applique lorsque j’ai à mettre en place un serveur 4D sur un Mac avec TimeMachine activé c’est de mettre en exception tous les dossiers contenant des fichiers actifs (Data, log, etc.)

C’est valable pour tout système de sauvegarde automatisé !

Une bonne pratique c’est de mettre en place un système qui consiste à informer l’administrateur de la réussite ou pas des backup réalisés par 4D. C’est en fait très simple à mettre en oeuvre. Pour cela on dispose de la méthode de base :

  • On Backup Startup database method
  • On Backup Shutdown database method


Le comble de l’optimisme, c’est de rentrer dans un grand restaurant et
compter sur la perle qu’on trouvera dans une huître pour payer la note.
–Tristan Bernard

Apparemment, c’est inutile de s’embêter à mettre une exception, car dans mon cas le Time Machine n’a simplement jamais backupé le fichier .4DD :twisted: :?: :!:

Je me demande bien pourquoi ? et si c’est le comportement attendu de cette commande ?

NB: Je sais que le fichier risque de ne pas être exploitable. Mais on aurait au moins eu quelque chose.

L’envoi par mail n’est pas vraiment une solution fiable à 100% non plus…

Je pense que pour un serveur (avec des clients) l’alerte comme le fait Bertrand me paraît être une bonne solution.

Je ne m’explique pas le pourquoi de l’arrêt du backup coté 4D alors que le serveur était toujours lancé et que le parametrage était correct…

J’espère que les infos récupérées via la commande GET BACKUP INFORMATION soient suffisamment fiable pour se baser dessus.

À moins de ne pas comprendre le système, l’utilisation de vos méthodes base requiert que l’on active le backup :!:

Donc, si pour une raison ou une autre le fichier de paramétrage de backup est mauvais ou PAS paramétré, vous ne recevrez jamais aucune alerte avec votre façon de faire… :razz:

La doc 4D commet la même erreur car rien ne se passe si aucune sauvegarde n’est déclenchée !
Et comme dans mon cas c’est justement le déclenchement de la sauvegarde qui ne se faisait plus… :roll:

Peut-être fonctionnez-vous à l’inverse et de vous alerter quand vous ne recevez pas de message :?:

Le fait d’inonder d’alerte m’a toujours posé problème mais ce n’est peut-être que moi… et de toute façon, on retombera sur le problème d’envoi de mail qui n’est pas fiable à 100 %.

: Manuel PIQUET

Je ne m’explique pas le pourquoi de l’arrêt du backup coté 4D alors
que le serveur était toujours lancé et que le parametrage était
correct…
Probablement la combinaison d’un administrateur mal éduqué et d’un développeur inconscient. Presque à chaque fois que j’ai trouvé une base avec un backup qui ne se faisait plus depuis X temps, l’explication était que le développeur a autorisé des utilisateurs à se connecter avec le droit design ou admin, et qu’un de ces braves gens que l’attente pendant le backup insupportait a trouvé très pratique que le dialogue de progression propose un bouton “Arrêter”. Si ça n’a (pour eux) pas de conséquence de cliquer ce bouton, ils ont zéro raison de te le signaler. Sauf que, suite à ce clic, plus aucun backup n’aura lieu tant qu’on n’ira pas le relancer sur le serveur…

Autres possibilités : erreur ou une malveillance de la part de quelqu’un qui a accès au serveur, disque de sauvegarde externe qui part en sucette…

Je ne pige pas l’absence du 4DD sur ton timeMachine, chez moi il est là (étant entendu que c’est la dernière des roues de secours) ; tu as regardé s’il était exclu ?

: Manuel PIQUET

Le fait d’inonder d’alerte m’a toujours posé problème mais ce n’est
peut-être que moi…et de toute façon, on retombera sur le problème
d’envoi de mail qui n’est pas fiable à 100 %.
Si on envoie un mail pour dire que tout va bien, oui, on peut être inondé, mais pas si on l’envoie pour signaler un problème exceptionnel. Qui plus est, un mail dont on est l’émetteur est facile à caractériser de façon à être classé à la réception.

C’est une mauvaise raison d’invoquer le 100% : à ce compte, laisse tomber la ceinture de sécurité en bagnole, le casque en vélo, les couches du bébé, etc.

Je peux t’assurer qu’en ce qui me concerne le mail est largement plus fiable que les utilisateurs : en supposant qu’ils lisent l’alerte avant de faire OK, toute alerte qui se répète devient une non alerte (principe de l’inondation, énoncé par Manuel Piquet au début du XXIème). Ou alors tu les obliges à être fiables :
si(pas de sauvegarde)
alerte(“Pas de sauvegarde, programme inutilisable, prévenez X”)
quitter 4D
fin de si

Concernant le mail, même s’il n’est pas fiable ce n’est pas le problème.
En effet c’est l’absence de mail qui est une information…
Si tu as reçu le mail tu le lis
Si tu n’as pas reçu le mail tu vérifies le serveur

Sur les clients gérés par BlueCompany, on vérifie de plus la fragmentation et l’état du fichier de données avant d’envoyer un mail de ce type :

Date : 06/07/2019 - 00:31:29
La sauvegarde c’est bien déroulée
La sauvegarde a eu lieu le 06/07/2019 à 00:30:01 et c’est terminée le 06/07/2019 à 00:31:04
Erreur : (0 - Aucune erreur détectée.)

La prochaine sauvegarde aura eu lieu le 06/07/2019 à 00:30:00

Fragmentation : Le fichier ne nécessite pas de défragmentation

Contrôle du fichier de données : Controle effectué
Le fichier de donnée est endommagé (VerifFailed)

Ce mail est envoyé automatiquement par le système de sauvegarde, merci de ne pas répondre

Ce n’est pas très compliqué à développer

Concernant TimeMachine c’est un très bon système pour…; sauvegarder les fichier BK

Hélas, non; le problème ne viens pas d’un admin malheureusement, d’où mon étonnement.
En relançant le serveur le paramètrage du backup était toujours juste et c’est bien lancé directement au démarrage; donc, non, le paramètrage du backup était en place et non arrêté par quelqu’un ! le serveur était en service tout le temps donc le backup c’est arrêté pour une raison inexpliqué. Et le fait qui me trouble le plus c’est effectivement le .4DD qui n’apparait sur aucun backup TImeMachine c’est vraiment fou. (Est-ce le fait du non changement de date du data qui fait que macOS pense que le fichier n’évolue pas ? et du coup ne le resauvegarderait pas ?)

Je vais mettre en place l’alerte au démarrage d’un client admin qui me paraît être le plus sûr pour au moins prévenir quelqu’un du problème et de plus cela permet de dire au client qu’il est au courant du problème…

Bonjour Paul,

: Paul KUHN

Concernant le mail, même s’il n’est pas fiable ce n’est pas le
problème.
En effet c’est l’absence de mail qui est une information…
Si tu as reçu le mail tu le lis
Si tu n’as pas reçu le mail tu vérifies le serveur

Tout est là ! Rien à ajouter … sauf si l’on veux faire de la littérature.

Quand à la discussion autour de TimeMachine cela me laisse dans un abîme de perplexité !
TimeMachine est un super produit, mais qui n’est pas destiné à remplacer 4D Backup, une administration du serveur, la relève de la garde et la 6ème semaine de congès payés.

Cordialement,

Avec votre stratégie de mail journalier, j’espère que vous avez une base qui vous alerte de vos serveurs clients défaillant :roll: Parce qu’heureusement, je n’ai pas qu’un seul client/serveur à gérer… :twisted:

Donc, si c’est pour passer la matinée à vérifier les retours de mail…

Qui a parlé de remplacer 4D Backup par Time Machine ?
Time machine est un complément et permet de conserver les fichiers .4BK dans le temps.
Mais, il devrait conserver le fichier courant également ce qui n’a pas fonctionné ici.
Et ce qui n’a plus fonctionné malheureusement c’est la création des fichiers .4BK… :evil:

: Manuel PIQUET

Hélas, non; le problème ne viens pas d’un admin malheureusement, d’où
mon étonnement.
Disque de backup : externe ou interne ?
Autre possibilité, quand il fait chaud j’ai toujours une recrudescence de pannes “inexplicables”.

: Manuel PIQUET

Je vais mettre en place l’alerte au démarrage d’un client admin qui
me paraît être le plus sûr pour au moins prévenir quelqu’un du
problème et de plus cela permet de dire au client qu’il est au
courant du problème…
C’est mieux que rien, mais pour quelque chose d’aussi critique qu’une absence de sauvegarde, on n’a jamais trop de cordes à son arc. À ta place, je ne ferais pas fi du mail. Que se passe-t-il si ton admin est à la plage ?

Non, la création des 4BK était sur le disque interne mais backupé par le Time machine + un autre backup sur un disque externe

Mais loi de Murphy :

Le backup externe était arrêté :frowning: (pour le coup une négligence de l’admin chez eux ! Mais cela n’aurait rien changé car la création des 4BK ne se faisait plus…)
LeTimemachine a fonctionné à moitié puisqu’il backupait tout le disque interne (sauf qu’on ne retrouve pas le 4DD ?!!!) et que comme la création des 4BK sur le disque interne était stoppée pour une raison inconnue car le paramétrage était juste (c’est certain car au relancement du serveur la sauvegarde s’est refaite immédiatement au démarrage !) du coup il backupait toujours les mêmes 4BK depuis le moment où le backup s’est stoppé…

Le mail me pose réellement problème ; je ne fais pas/plus confiance entre les firewalls, les antivirus, les antispams, et les aléas de l’envoi SMTP…

Ce qui m’importe c’est que si la sauvegarde n’est pas en place (ET PAS SIMPLEMENT qu’elle ne se lance pas) Une personne chez le client soit au courant de ce fait. C’est de leur responsabilité de faire le nécessaire pour sauvegarder les données. (les moyens mis en œuvre peuvent varier, l’important c’est qu’ils soient fonctionnels et en place).

On est dans un cas extrême : rien n’a fonctionné correctement…
Mais ce qui m’embête c’est de ne pas comprendre ce qui s’est passé alors que normalement le nécessaire (minimum) avait été fait.

Ça va finir pas un process qui test la présence du fichier 4BK sur le disque ce truc… :-?

Bonjour Manuel

la gestion de la sauvegarde doit être une priorité pour ton client. Qui dit sauvegarde dit procédure de monitoring de la sauvegarde et cela inclut :

  • vérification journalière de la bonne exécution de la sauvegarde sur chacun des supports sur lesquelles elle est réalisée,
  • vérification des logs pour détecter les erreurs éventuelles et assigner les éventuelles actions à mener aux personnes intéressées (admin de la base, problème réseau, …)
  • la messagerie (si le système envoi un mail)
  • un test régulier (en règle général annuel) de “remonter” d’une sauvegarde de manière à ne pas découvrir comment faire le jour où cela arrive.

Dans les “grosses entreprises”, c’est généralement une TMA qui s’occupe de cette gestion de vérification.

Outre le fait que la sauvegarde ne se fasse pas pour x raisons (arrêt par une administrateur), la vérification du jour suivant aurait dû permettre de remontrer le problème => ton client ne gère pas la sauvegarde suffisamment sérieusement et n’a pas de procédure pour cela => tu peux leur proposer une formation poussée sur les risques/tenant et aboutissant de la gestion de la sauvegarde :slight_smile:

Je confirme que seul le 4BK est LE fichier à récupérer. La fréquence de la sauvegarde étant liée dans ce cas à la criticité des données qu’il contient, et là encore, c’est au client de la définir sur la base de ton conseil.
De plus, avec les options de réplication, il est aussi possible d’utiliser ce fichier 4BK pour alimenter une plateforme qui te permettra de remonter l’application super rapidement.

Je vois cela trop souvent : les utilisateurs se basent sur les automatismes des systèmes sans prendre en compte la dimension de la panne sournoise qui est découverte souvent bien trop tardivement car pas de vérification que cela se passe bien.

Bon courage

Patrick

Bonjour,

: Patrick EMANUEL
  • un test régulier (en règle général annuel) de “remonter” d’une
    sauvegarde de manière à ne pas découvrir comment faire le jour où
    cela arrive.

Tu as parfaitement raison.
En fait personne n’a réellement besoin de la fonction sauvegarde. La seule chose dont on peu avoir besoin est la fonction Restituer. Et tous les efforts doivent être fait pour que la restitution puisse être entreprise. Il faut donc :

  • une procédure écrite claire de restitution qui doit être accessible a des personnes formées. S’il n’y a qu’une seule personne formée, alors le besoin arrivera pendant qu’il sera dans un avion en partance pour ses vacances et donc injoignable …
  • une verification régulière et aléatoire de la procédure de restitution : une fois par an n’est clairement pas suffisant
  • une rélecture de la procédure à chaque mise à jour majeure de 4D et correction éventuelle
  • une surveillance des éléments nécessaires à la restitution.
  • une prise en compte du facteur matériel : cela sert à rien d’avoir une baie de disque en raid 5 (par exemple) si on n’a pas en stock le disque vierge permettant le fameux remplacement à chaud. Quand un disque flanche, il faut pas avoir à attendre l’aval du comptable pour permettre de passer la commande qui arrivera dans 5 jours. Une baie de disques sans disque de secours prêt à être mis en oeuvre n’est pas une baie sécurisée.
  • … liste non exhaustive, je vous laisse compléter

Ne parlez pas de Murphy car c’est un incorrigible optimiste.

Cordialement,

Je vous remercie de tous vos conseils, mais je ne découvre pas ce problème aujourd’hui :wink: Simplement, si on ne peut pas se fier au résultat de la creation effective des 4BK cela devient compliqué…

Comment faire si on paramètre correctement 4D mais que la creation des 4BK s’arrête quand il veut :?:

Donc, on va renforcer la verification de la présence de ces fichiers, mais bon…

: Manuel PIQUET

C’est de leur responsabilité de faire le nécessaire pour sauvegarder
les données.
Perso, j’ai eu tellement de mauvaises expériences avec ça que je considère que la surveillance de la sauvegarde doit faire partie du “package” 4D. Demander à quelqu’un de gérer ce qu’il ne comprend pas et/ou dont il se fiche est une perte de temps. Un backup externe arrêté à cause d’un administrateur que tu qualifies de négligent : tu veux quand même t’appuyer sur lui ?

La question est une question de responsabilité :

  • tu mets en place les moyens de la sauvegarde et que es capable d’apporter la preuve que la solution de sauvegarde fonctionne (via 4D backup)
  • si tu as vendu la mise en oeuvre de la sauvegarde chez le client, alors c’est à toi de démontrer qu’il y a eu modification de la mise en oeuvre et que dans ce cas, c 'est la responsabilité du client
  • Ensuite, si c’est au client qui est en charge de la sauvegarde, tout est dit

Un cahier des charges (contrat) doit décrire cela afin de clarifier les rôles et responsabilité.
Comme je l’ai écrit et qu’Olivier à repris: la finalité d’une sauvegarde est la restitution, sinon cela ne sert à rien. Sans procédure pour gérer les 2 (sauvegardes et restitution), cela revient à aller dans le mur pour N raisons.

Patrick