|
|
fr.comp.os.ms-windows.programmation
Discussion complète de l'article :
mécanisme_de_sauvegarde_de_données
|
Article :
25236
Date :
04-08-2005
From :
AG
Sujet :
mécanisme_de_sauvegarde_de_données
Bonjour,
j'ai une petite application de calcul en C, qui peut tourner plusieurs
jours de suite. Pour ne pas avoir à recalculer tout depuis le début
lorsque l'application plante (soit parce que je décide de l'arrêter,
soit parce que la machine sur laquelle elle tourne, plante, soit pour
n'importe quelle autre raison), je sauvegarde les résultats
intermédiaires dans un fichier texte. Mes sauvegardes sont périodiques.
Mais il peut arriver que le système plante au moment ou la sauvegarde
est en train d'être effectuée, et là, pour le coup, je perds toutes mes
données.
Quels sont les mécanismes classiques qui permettent un sauvegarde sûre ?
J'ai pensé à :
1°) Utilisation d'outils de synchronisation (des cadenas (locks) ) mais
j'ai comme l'impression que contre un reboot intempestif, même le
meilleurs des cadenas ne sera pas d'une grande utilité.
2°) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
sauvegarder alternativement les données. Si le système plante lors de la
sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet une
restauration du système.
Quelles sont les mécanismes classiques pour résoudre ce problème ?
Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?
Merci d'avance pour vos conseils.
AG.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25237
Date :
04-08-2005
From :
Thierry
Sujet :
Re: mécanisme de sauvegarde de données
Bonjour,
AG a écrit :
> 1°) Utilisation d'outils de synchronisation (des cadenas (locks) ) mais
> j'ai comme l'impression que contre un reboot intempestif, même le
> meilleurs des cadenas ne sera pas d'une grande utilité.
>
> 2°) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
> sauvegarder alternativement les données. Si le système plante lors de la
> sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet une
> restauration du système.
Un truc comme ça, avec le fichier nommé en fonction du jour et de l'heure.
Et pour être sur que le fichier est valide, placer un flag en debut de
fichier une fois toutes les données ecrites:
En gros :
fopen
fwrite(0)
fflush
fwrite(data) ..
fseek 0, CUR_SET
fwrite(1)
fclose (flush implicite)
--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
>> Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25238
Date :
04-08-2005
From :
adebaene@club-internet.fr
Sujet :
Re:_mécanisme_de_sauvegarde_de_données
AG a =E9crit :
> Bonjour,
>
> j'ai une petite application de calcul en C, qui peut tourner plusieurs
> jours de suite. Pour ne pas avoir =E0 recalculer tout depuis le d=E9but
> lorsque l'application plante (soit parce que je d=E9cide de l'arr=EAter,
> soit parce que la machine sur laquelle elle tourne, plante, soit pour
> n'importe quelle autre raison), je sauvegarde les r=E9sultats
> interm=E9diaires dans un fichier texte. Mes sauvegardes sont p=E9riodique=
s=2E
>
> Mais il peut arriver que le syst=E8me plante au moment ou la sauvegarde
> est en train d'=EAtre effectu=E9e, et l=E0, pour le coup, je perds toutes=
mes
> donn=E9es.
>
> Quels sont les m=E9canismes classiques qui permettent un sauvegarde s=FBr=
e ?
>
> J'ai pens=E9 =E0 :
>
> 1=B0) Utilisation d'outils de synchronisation (des cadenas (locks) ) mais
> j'ai comme l'impression que contre un reboot intempestif, m=EAme le
> meilleurs des cadenas ne sera pas d'une grande utilit=E9.
>
> 2=B0) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
> sauvegarder alternativement les donn=E9es. Si le syst=E8me plante lors de=
la
> sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet une
> restauration du syst=E8me.
>
> Quelles sont les m=E9canismes classiques pour r=E9soudre ce probl=E8me ?
Un m=E9canisme de journalisation, avec des op=E9rations transactionnelles
pour la sauvegarde (commit/rollback).
> Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?
Le plus simple, c'est d'utiliser pour ton stockage une base de donn=E9e
transactionnelle (MSDE par exemple), ou bien un syst=E8me transactionnel
tout fait (=E9crire soi-m=EAme un moteuer transactionnel me semble
illusoire pour la plupart des genrs).
Arnaud
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25239
Date :
04-08-2005
From :
AG
Sujet :
Re: mécanisme_de_sauvegarde_de_donnée
adebaene@club-internet.fr wrote:
> Un mécanisme de journalisation, avec des opérations transactionnelles
> pour la sauvegarde (commit/rollback).
Un mécanisme de journalisation, je crois que je vois :
On sauve l'état de départ, puis on ajoute un ligne pour chaque
différence depuis le dernier état sauvegardé. ça permet de remonter dans
le temps les états de sauvegarde (ça doit être le rollback ?)
>
>
>>Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?
>
> Le plus simple, c'est d'utiliser pour ton stockage une base de donnée
> transactionnelle (MSDE par exemple), ou bien un système transactionnel
> tout fait (écrire soi-même un moteuer transactionnel me semble
> illusoire pour la plupart des genrs).
Une base de donnée, je vois bien, transactionnelle, je vois moins déjà.
mais j'imagine que c'est pour décrire la manière dont les échanges de
données sont faits (les transactions), et pour dire que c'est fait par
des opérations transactionnelles (?) dont on a parlé plus haut (genre,
le nouvel état du système est sauvegardé uniquement si la transaction
c'est bien passée, sinon on revient à l'état d'avant ?)
Bon, de toute façon, je ne m'en servirait pas, c'était pour ma culture.
Mon code n'est pas destiné à aller en production, c'est juste pour mes
besoins personnels. Un système de deux fichiers suffira je pense.
Merci.
Alexandre.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25240
Date :
04-08-2005
From :
adebaene@club-internet.fr
Sujet :
Re:_mécanisme_de_sauvegarde_de_données
AG a =E9crit :
> adebaene@club-internet.fr wrote:
>
> > Un m=E9canisme de journalisation, avec des op=E9rations transactionnell=
es
> > pour la sauvegarde (commit/rollback).
> Un m=E9canisme de journalisation, je crois que je vois :
>
> On sauve l'=E9tat de d=E9part, puis on ajoute un ligne pour chaque
> diff=E9rence depuis le dernier =E9tat sauvegard=E9. =E7a permet de remont=
er dans
> le temps les =E9tats de sauvegarde (=E7a doit =EAtre le rollback ?)
Plus pr=E9cisemment:
- lorsque l'op=E9ration est r=E9alis=E9e elle est =E9crite dans un journal
de transaction (et pas sur le support final).
- plus tard, lorsque la transaction est valid=E9e ("commit") ou m=EAme
apr=E8s, l'op=E9ration est r=E9alis=E9e sur le support final.
- Seulement une fois que l'op=E9ration est effectivement effectu=E9e sur
le support final, le journal de transaction est effac=E9 (et encore, sur
de nombreux syst=E8me, SQL Server par exemple, le journal de transaction
est effac=E9 beaucoup plus tard, typiquement quand un backup du syst=E8me
est effectu=E9, de fa=E7on =E0 pouvoir restaurer n'importe quel =E9tat
coh=E9rent de la base avant la derni=E8re sauvegarde).
> >
> >>Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?
> >
> > Le plus simple, c'est d'utiliser pour ton stockage une base de donn=E9e
> > transactionnelle (MSDE par exemple), ou bien un syst=E8me transactionnel
> > tout fait (=E9crire soi-m=EAme un moteuer transactionnel me semble
> > illusoire pour la plupart des genrs).
> Une base de donn=E9e, je vois bien, transactionnelle, je vois moins d=E9j=
=E0.
Les bases "s=E9rieuses" (MSDE, Oracle, SQL Server, ...) offrent un
m=E9canisme transactionnel. Ce n'est pas le cas d'Access. Pour MySql, si
mes souvenirs sont bons, c'est un peu plus compliqu=E9 : ca d=E9pend du
type de base utilis=E9e.
> mais j'imagine que c'est pour d=E9crire la mani=E8re dont les =E9changes =
de
> donn=E9es sont faits (les transactions), et pour dire que c'est fait par
> des op=E9rations transactionnelles (?) dont on a parl=E9 plus haut (genre,
> le nouvel =E9tat du syst=E8me est sauvegard=E9 uniquement si la transacti=
on
> c'est bien pass=E9e, sinon on revient =E0 l'=E9tat d'avant ?)
Oui : un syst=E8me journalis=E9 et transactionnel garantit que, m=EAme en
cas de coupure de courant, l'=E9tat de la base sera coh=E9rent (soit la
transaction compl=E8te sera enregistr=E9e, soit aucune op=E9ration faisant
partie de la transaction ne sera enregistr=E9e).
Pour info, NTFS utilise un m=E9canisme transactionnel pour ses
structures internes, pour garantir qu'une partition ne sera jamais
foutue en l'air par une panne de courant. Par contre, le contenu des
fichiers lui-m=EAme n'est pas journalis=E9 (ce serait trop lourd en
espace disque pris par le journal et en temps de r=E9ponse).
>
> Bon, de toute fa=E7on, je ne m'en servirait pas, c'=E9tait pour ma cultur=
e=2E
> Mon code n'est pas destin=E9 =E0 aller en production, c'est juste pour mes
> besoins personnels.=20
MSDE irait bien dans ce cas l=E0.
Arnaud
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25241
Date :
04-08-2005
From :
Cyrille Szymanski
Sujet :
Re: mécanisme de sauvegarde de données
adebaene@club-internet.fr wrote in
news:1123171717.390528.209360@g43g2000cwa.googlegroups.com:
> - lorsque l'opération est réalisée elle est écrite dans un journal
> de transaction (et pas sur le support final).
> - plus tard, lorsque la transaction est validée ("commit") ou même
> après, l'opération est réalisée sur le support final.
> - Seulement une fois que l'opération est effectivement effectuée sur
> le support final, le journal de transaction est effacé (et encore, sur
> de nombreux système, SQL Server par exemple, le journal de transaction
> est effacé beaucoup plus tard, typiquement quand un backup du système
> est effectué, de façon à pouvoir restaurer n'importe quel état
> cohérent de la base avant la dernière sauvegarde).
- La journalisation peut aussi être une optimisation :
1. il est possible de laisser le journal un moment en mémoire ce
qui évite les accès disque inutiles (par ex si une ligne est changée
deux fois au cours de la transaction) 2. lorsqu'on écrit sur le
disque, on le fait dans un ordre cohérent (moins d'allers-retours
des têtes d'écriture).
>> Bon, de toute façon, je ne m'en servirait pas, c'était pour ma
>> culture. Mon code n'est pas destiné à aller en production, c'est
>> juste pour mes besoins personnels.
> MSDE irait bien dans ce cas là.
S'il peut se payer le luxe de créer des fichiers distincts, c'est aussi
beaucoup plus simple.
En fait, la méthode des deux fichiers est une forme de "journalisation
du pauvre", le journal étant le second fichier et l'opération de commit
est le renommage.
--
Cyrille Szymanski
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25242
Date :
05-08-2005
From :
AG
Sujet :
Re: mécanisme_de_sauvegarde_de_donnée
Cyrille Szymanski wrote:
>>MSDE irait bien dans ce cas là.
J'ai regardé, ça à l'air pas mal. C'est surement bien plus propre et sûr
que ce que je fais à la main, mais d'un autre coté, si j'intègre ça dans
mon soft, ça va en devenir la plus grosse partie. Hors c'est pas le plus
important quand même.
Un inconvénient, c'est que c'est sous windows, et j'ai besoin d'un truc
qui fonctionne sous Windows et sous linux.
Je la garde sous la main, pour d'autres occasions.
> S'il peut se payer le luxe de créer des fichiers distincts, c'est aussi
> beaucoup plus simple.
>
> En fait, la méthode des deux fichiers est une forme de "journalisation
> du pauvre", le journal étant le second fichier et l'opération de commit
> est le renommage.
Ok.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25245
Date :
06-08-2005
From :
Patrick 'Zener' Brunet
Sujet :
Re: mécanisme de sauvegarde de données
Bonjour.
Je réponds à AG qui a écrit :
> Bonjour,
>
> j'ai une petite application de calcul en C, qui peut tourner plusieurs
> jours de suite. Pour ne pas avoir à recalculer tout depuis le début
> lorsque l'application plante (soit parce que je décide de l'arrêter,
> soit parce que la machine sur laquelle elle tourne, plante, soit pour
> n'importe quelle autre raison), je sauvegarde les résultats
> intermédiaires dans un fichier texte. Mes sauvegardes sont
> périodiques.
>
> Mais il peut arriver que le système plante au moment ou la sauvegarde
> est en train d'être effectuée, et là, pour le coup, je perds toutes
> mes données.
>
> Quels sont les mécanismes classiques qui permettent un sauvegarde
> sûre ?
>
> J'ai pensé à :
>
> 1°) Utilisation d'outils de synchronisation (des cadenas (locks) )
> mais j'ai comme l'impression que contre un reboot intempestif, même le
> meilleurs des cadenas ne sera pas d'une grande utilité.
>
> 2°) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
> sauvegarder alternativement les données. Si le système plante lors de
> la sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet
> une restauration du système.
>
> Quelles sont les mécanismes classiques pour résoudre ce problème ?
> Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?
>
>
> Merci d'avance pour vos conseils.
>
Si on ne tient pas compte des éventualités du style crash disque, le
problème se limite à conserver un fichier dans un état valide en permanence,
même en supposant que le logiciel qui le manipule plante en cours
d'opération.
J'ai une expérience positive en ce sens, utilisant les fichiers mappés en
mémoire et des opérations dessus qui sont conçues pour ne pas provoquer de
réallocation du fichier, ainsi que des règles particulières de gestion des
buffers.
Bref c'est pas simple, et sans doute pas sûr à 100%.
Sans aller jusqu'à gérer deux fichiers alternatifs, vous pouvez très bien
(sauf coût parasite en cours de calcul) faire une sauvegarde temporaire du
fichier précédent, puis la mise à jour, puis la suppression du fichier de
sauvegarde.
Une logique simple, en cas de reprise après crash, peut permettre de
restaurer le fichier principal à partir de la sauvegarde s'il est corrompu.
Si les volumes de données ou la vitesse de calcul ne permettent pas de faire
ça, vous aurez sans doute intérêt à découper votre fichier en plusieurs
segments, et à utiliser cette procédure segment par segment.
Ca a de bonnes chances de rester simple et fiable.
Cordialement,
--
/***************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\***************************************/
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25246
Date :
06-08-2005
From :
GG
Sujet :
Re: mécanisme de sauvegarde de données
Bonjour,
si Windows XP ou Windows 2003 utiliser ntbackup avec clichés
instantanés pour la sauvegarde et rien ne plantera et rien ne sera
perdu.
Autrement l'utilisation d'un utilitaire de backup ce n'est pas de
la programmation mais bon .. :-)
--
Cordialement.
GG.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25247
Date :
08-08-2005
From :
AG
Sujet :
Re: mécanisme_de_sauvegarde_de_donnée
Patrick 'Zener' Brunet wrote:
> Bonjour.
> Sans aller jusqu'à gérer deux fichiers alternatifs, vous pouvez très bien
> (sauf coût parasite en cours de calcul) faire une sauvegarde temporaire du
> fichier précédent, puis la mise à jour, puis la suppression du fichier de
> sauvegarde.
Cela ne revient il pas à gérer deux fichiers ? (de manière différente,
certes, mais deux fichiers quand même).
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
25248
Date :
08-08-2005
From :
Patrick 'Zener' Brunet
Sujet :
Re: mécanisme de sauvegarde de données
Bonjour.
Je réponds à AG qui a écrit :
> Patrick 'Zener' Brunet wrote:
>> Bonjour.
>> Sans aller jusqu'à gérer deux fichiers alternatifs, vous pouvez très
>> bien (sauf coût parasite en cours de calcul) faire une sauvegarde
>> temporaire du fichier précédent, puis la mise à jour, puis la
>> suppression du fichier de sauvegarde.
>
> Cela ne revient il pas à gérer deux fichiers ? (de manière différente,
> certes, mais deux fichiers quand même).
En fonctionnement niominal, non, parce que le fichier de sauvegarde n'est
que temporaire, et donc détenu par la fonction d'écriture, puis "oublié".
Seule la fonction de reprise après crash doit être capable de régénérer son
nom pour le retrouver et restaurer le fichier nominal, ensuite idem.
C'est très différent du principe consistant à gérer deux fichiers en
alternance; et il faudrait encore gérer en parallèle l'information
spécifiant où on en est dans cette alternance : un simple booléen, mais
faites en la clé de votre reprise après crash et vous allez voir comme il
devient lourd à gérer !
Cordialement,
--
/***************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\***************************************/
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
|