> Avec les REDO LOG (pour Oracle) par exemple, oui tu devrais arriver à une situation cohérente.
Tous les sgdb qui font des transactions ont toujours un état cohérent sur le disque. C'est définitivement le cas pour PostgreSQL. Après d'une coupure de courant ou d'un freeze système, le sgdb ignore (nettoye) simplement les transactions en cours (tout ce qui n'a pas été validé par le retour de "commit", un retour d'instruction type "insert into ..."). Et il ne va surtout pas les refaires puisqu'elles sont imcompletes !
Notes que c'est indispensable, sinon la base de donnée ne pourait pas redémarrer dans un état cohérent après une bête coupure de courrant.
> Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot.
Certe, mais ce n'est pas nécessaire avec un "vrai" snapshot.
Ton snapshot c'est l'état de ta bd comme si le moteur de base de donnée recevait un "kill -9". Or les sgbd doivent supporter un "kill -9" (ou une coupure de courant).
> Et certaines sociétés (les banques par exemple) ne veulent pas de situation où le snapshot peut être cohérent, elles veulent que ce soit cohérent, point.
C'est cohérent, point.
> Là ça passe par un agent intermédiare.
Nécessaire si tu n'as pas un "vrai" snapshot (ext3cow ou lvm font des "vrais" snapshots).
Autre chose, quand on parle de "rejouer un journal", on ne rejoue que les transactions validées (celles avec un commit/etc qui a aboutis ET qui est indiqué comme telle dans le journal).
> Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir.
Postgresql le fait aussi :-)
Ça été introduit dans PostgreSQL 8.0 je crois.
[^] # Re: rdiff-backup
Posté par IsNotGood . En réponse au journal Journalisation de fichier. Évalué à 2.
Tous les sgdb qui font des transactions ont toujours un état cohérent sur le disque. C'est définitivement le cas pour PostgreSQL. Après d'une coupure de courant ou d'un freeze système, le sgdb ignore (nettoye) simplement les transactions en cours (tout ce qui n'a pas été validé par le retour de "commit", un retour d'instruction type "insert into ..."). Et il ne va surtout pas les refaires puisqu'elles sont imcompletes !
Notes que c'est indispensable, sinon la base de donnée ne pourait pas redémarrer dans un état cohérent après une bête coupure de courrant.
> Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot.
Certe, mais ce n'est pas nécessaire avec un "vrai" snapshot.
Ton snapshot c'est l'état de ta bd comme si le moteur de base de donnée recevait un "kill -9". Or les sgbd doivent supporter un "kill -9" (ou une coupure de courant).
> Et certaines sociétés (les banques par exemple) ne veulent pas de situation où le snapshot peut être cohérent, elles veulent que ce soit cohérent, point.
C'est cohérent, point.
> Là ça passe par un agent intermédiare.
Nécessaire si tu n'as pas un "vrai" snapshot (ext3cow ou lvm font des "vrais" snapshots).
Autre chose, quand on parle de "rejouer un journal", on ne rejoue que les transactions validées (celles avec un commit/etc qui a aboutis ET qui est indiqué comme telle dans le journal).
> Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir.
Postgresql le fait aussi :-)
Ça été introduit dans PostgreSQL 8.0 je crois.