Mais si ce n'est pas cohérent, alors c'est codé avec les pieds. Tous les db doivent supporter une coupure de courant ou un freeze noyau. Lors d'une coupure de courant où d'un freeze noyau, on n'a bien un snapshot. Donc un snapshot marche parfaitement comme backup de base de donnée.
Avec les REDO LOG (pour Oracle) par exemple, oui tu devrais arriver à une situation cohérente. Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot. 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. Là ça passe par un agent intermédiare.
Pour la DB berkeley, je ne connais pas. Faut que j'aille sur Wikipedia si elle est mentionnée. Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir. Mais pourquoi pas ... Merci de l'info, je vais investiguer.
[^] # Re: rdiff-backup
Posté par tipmeabout . En réponse au journal Journalisation de fichier. Évalué à 1.
Avec les REDO LOG (pour Oracle) par exemple, oui tu devrais arriver à une situation cohérente. Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot. 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. Là ça passe par un agent intermédiare.
Pour la DB berkeley, je ne connais pas. Faut que j'aille sur Wikipedia si elle est mentionnée. Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir. Mais pourquoi pas ... Merci de l'info, je vais investiguer.