j'ai plusieures question sur les sauvegardes sous FreeBSD:
1. mksnap_ffs: - qu'y a t'il dans le fichier snapshot? des liens?
- que ce passe-t-il si j'ajoute/modifie des fichiers?
rien du pt de vue de dump, mais où est mon nouveau
fichier?
- est-ce valable pour sauvegarder une db (postgres) en activité?
(j'en doute)
2. Dump: qu'elle sont les pour et les contre entre dump via nfs et ssh en
terme de perf/securité sachant que c'est "à la maison".
j'utilise une ligne de commande du genre:
#mksnap_ffs /usr /usr/monsnap
#dump -0uanC 32 -f - /usr/monsnap | gzip -6 |\
dd of=/nfs/big/snap/tetsuo-usr-fulldump-080505.gz
le snapshot pour /usr pèse près de 40Gb, que se passe-t-il si le pipe
"casse"? (ex: perte réseau pour une raison X ou Y)
3. sur quels répertoire peut on sans crainte appliquer le flag "nodump"?
/usr/src; /usr/ports; /usr/obj; ??? dans la mesure ou cvsup va les
recréer, juste histoire d'alléger le bazar...
Bon on va dire que c'est assez...
Merci d'avance...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Masson
MaXX writes:
'Lut,
1. mksnap_ffs: - qu'y a t'il dans le fichier snapshot? des liens?
Voir à partir de la page 15 du document suivant : http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf
- est-ce valable pour sauvegarder une db (postgres) en activité ? (j'en doute)
Non, par contre, il est possible d'arrêter la base juste le temps de poser le snapshot et de sauvegarder les fichiers dudit snapshot après que la base ait repris une activité normale.
Éric Masson
-- Admirez les photos de notre superbe boutre mahorais. Cliquez ici: -+- PB in <http://www.le-gnu.net> : L'e-mail, kes t'en a à boutre -+-
MaXX <bs139412@skynet.be> writes:
'Lut,
1. mksnap_ffs:
- qu'y a t'il dans le fichier snapshot? des liens?
Voir à partir de la page 15 du document suivant :
http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf
- est-ce valable pour sauvegarder une db (postgres) en activité ?
(j'en doute)
Non, par contre, il est possible d'arrêter la base juste le temps de
poser le snapshot et de sauvegarder les fichiers dudit snapshot après
que la base ait repris une activité normale.
Éric Masson
--
Admirez les photos de notre superbe boutre mahorais. Cliquez ici:
-+- PB in <http://www.le-gnu.net> : L'e-mail, kes t'en a à boutre -+-
1. mksnap_ffs: - qu'y a t'il dans le fichier snapshot? des liens?
Voir à partir de la page 15 du document suivant : http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf
- est-ce valable pour sauvegarder une db (postgres) en activité ? (j'en doute)
Non, par contre, il est possible d'arrêter la base juste le temps de poser le snapshot et de sauvegarder les fichiers dudit snapshot après que la base ait repris une activité normale.
Éric Masson
-- Admirez les photos de notre superbe boutre mahorais. Cliquez ici: -+- PB in <http://www.le-gnu.net> : L'e-mail, kes t'en a à boutre -+-
MaXX
Eric Masson wrote:
MaXX writes: 'Lut,
1. mksnap_ffs: Voir à partir de la page 15 du document suivant :
Merci, je vais aller lire ça tranquile devant un petit verre...
- est-ce valable pour sauvegarder une db (postgres) en activité ? (j'en doute) Non, par contre, il est possible d'arrêter la base juste le temps de
poser le snapshot et de sauvegarder les fichiers dudit snapshot après que la base ait repris une activité normale.
C'est bien ce que je pensait, bien que dans le document en page 16 il est dit: "Once the snapshot file is in place, activity on the file system resumes."... (lecture en diagonale) Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
Éric Masson
Merci en tout cas...
-- MaXX
Eric Masson wrote:
MaXX <bs139412@skynet.be> writes:
'Lut,
1. mksnap_ffs:
Voir à partir de la page 15 du document suivant :
Merci, je vais aller lire ça tranquile devant un petit verre...
- est-ce valable pour sauvegarder une db (postgres) en activité ?
(j'en doute)
Non, par contre, il est possible d'arrêter la base juste le temps de
poser le snapshot et de sauvegarder les fichiers dudit snapshot après
que la base ait repris une activité normale.
C'est bien ce que je pensait, bien que dans le document en page 16 il est
dit:
"Once the snapshot file is in place, activity on the file system
resumes."... (lecture en diagonale)
Le système doit placer un lock exclusif sur le FS et pendant ce temps les
autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le
feu...
Merci, je vais aller lire ça tranquile devant un petit verre...
- est-ce valable pour sauvegarder une db (postgres) en activité ? (j'en doute) Non, par contre, il est possible d'arrêter la base juste le temps de
poser le snapshot et de sauvegarder les fichiers dudit snapshot après que la base ait repris une activité normale.
C'est bien ce que je pensait, bien que dans le document en page 16 il est dit: "Once the snapshot file is in place, activity on the file system resumes."... (lecture en diagonale) Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
Éric Masson
Merci en tout cas...
-- MaXX
Eric Masson
MaXX writes:
Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est quasi nulle.
Donc, tomber la base, poser le snap et remonter la base me semble être la seule solution fiable en l'absence de mécanismes de sauvegarde en ligne propres à la base. (en plus sur un fs pas trop monstrueux, tu dois arriver à un temps d'indisponibilité inférieur à 3/4 minutes)
Éric Masson
-- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://www.le-gnu.net : Les oiseaux sont des cons.
MaXX <bs139412@skynet.be> writes:
Le système doit placer un lock exclusif sur le FS et pendant ce temps les
autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le
feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est
quasi nulle.
Donc, tomber la base, poser le snap et remonter la base me semble être
la seule solution fiable en l'absence de mécanismes de sauvegarde en
ligne propres à la base. (en plus sur un fs pas trop monstrueux, tu dois
arriver à un temps d'indisponibilité inférieur à 3/4 minutes)
Éric Masson
--
manquerait plus que les groupes soient pollués. c'est beaucoup plus
grave que des plages bretonnes à deux francs qui étaient déjà polluées
par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus
-+- tilt in http://www.le-gnu.net : Les oiseaux sont des cons.
Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est quasi nulle.
Donc, tomber la base, poser le snap et remonter la base me semble être la seule solution fiable en l'absence de mécanismes de sauvegarde en ligne propres à la base. (en plus sur un fs pas trop monstrueux, tu dois arriver à un temps d'indisponibilité inférieur à 3/4 minutes)
Éric Masson
-- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://www.le-gnu.net : Les oiseaux sont des cons.
F. Senault
MaXX writes:
Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est quasi nulle.
Donc, tomber la base, poser le snap et remonter la base me semble être la seule solution fiable en l'absence de mécanismes de sauvegarde en ligne propres à la base.
A moins qu'il n'y ait moyen de passer la base en read-only le temps de la sauvegarde (je ne sais plus si ça existe en postgres ; avec Oracle, c'est un moyen classique pour les backups, IIRC).
Fred -- A glance over your own shoulder A vow that today will stand out Caged in a routine Intent unknown The element Of surprise Impact undetermined but vast Mark me... Brandishing a cold loaded smile Simplicity, subtlety, discordance fate and allegory (Kittie, Oracle)
MaXX <bs139412@skynet.be> writes:
Le système doit placer un lock exclusif sur le FS et pendant ce temps les
autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le
feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est
quasi nulle.
Donc, tomber la base, poser le snap et remonter la base me semble être
la seule solution fiable en l'absence de mécanismes de sauvegarde en
ligne propres à la base.
A moins qu'il n'y ait moyen de passer la base en read-only le temps de
la sauvegarde (je ne sais plus si ça existe en postgres ; avec Oracle,
c'est un moyen classique pour les backups, IIRC).
Fred
--
A glance over your own shoulder A vow that today will stand out Caged
in a routine Intent unknown The element Of surprise Impact
undetermined but vast Mark me... Brandishing a cold loaded smile
Simplicity, subtlety, discordance fate and allegory (Kittie, Oracle)
Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est quasi nulle.
Donc, tomber la base, poser le snap et remonter la base me semble être la seule solution fiable en l'absence de mécanismes de sauvegarde en ligne propres à la base.
A moins qu'il n'y ait moyen de passer la base en read-only le temps de la sauvegarde (je ne sais plus si ça existe en postgres ; avec Oracle, c'est un moyen classique pour les backups, IIRC).
Fred -- A glance over your own shoulder A vow that today will stand out Caged in a routine Intent unknown The element Of surprise Impact undetermined but vast Mark me... Brandishing a cold loaded smile Simplicity, subtlety, discordance fate and allegory (Kittie, Oracle)
MaXX
Eric Masson wrote:
MaXX writes:
Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est quasi nulle.
je fais confiance à pg_dump, même dans l'hypothèse où le snap serait
correct, une db sauvegardée vaut mieux qu'un "j'espère que ma db est sauvegardée"...
Enfin, je me demande ce que ça donne PostgreSQL WAL + FFS + Cache ATA/ou cache controleur RAID (sans NVRAM), comment l'intégrité des données peut-elle être assurées alors qu'il y a trois systèmes mis en jeux, même si ils sont indépendament "safe", je vois mal comment ils peuvent resister à une coupure de courrant... En tout cas j'ai du mal à croire que c'est plus sur que de sauvgarder ma db en faisant confiance aux snapshots... (ex: Si postgres attend FFS et que FFS attend ATA ou le controleur RAID ça laisse pas mal de temps pour faire de la casse).
Ce qui me fait très peur vu qu'il vont complètement détruire la rue pour rénover, j'ai peur du coup de pelleteuse dans les cables électrique... -- MaXX
Eric Masson wrote:
MaXX <bs139412@skynet.be> writes:
Le système doit placer un lock exclusif sur le FS et pendant ce temps les
autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec
le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est
quasi nulle.
je fais confiance à pg_dump, même dans l'hypothèse où le snap serait
correct, une db sauvegardée vaut mieux qu'un "j'espère que ma db est
sauvegardée"...
Enfin, je me demande ce que ça donne PostgreSQL WAL + FFS + Cache ATA/ou
cache controleur RAID (sans NVRAM), comment l'intégrité des données
peut-elle être assurées alors qu'il y a trois systèmes mis en jeux, même si
ils sont indépendament "safe", je vois mal comment ils peuvent resister à
une coupure de courrant... En tout cas j'ai du mal à croire que c'est plus
sur que de sauvgarder ma db en faisant confiance aux snapshots...
(ex: Si postgres attend FFS et que FFS attend ATA ou le controleur RAID ça
laisse pas mal de temps pour faire de la casse).
Ce qui me fait très peur vu qu'il vont complètement détruire la rue pour
rénover, j'ai peur du coup de pelleteuse dans les cables électrique...
--
MaXX
Le système doit placer un lock exclusif sur le FS et pendant ce temps les autres softs sont forcés d'attendre... Mais pour une db c'est jouer avec le feu...
La probabilité de tomber sur un état correct des fichiers du rdbms est quasi nulle.
je fais confiance à pg_dump, même dans l'hypothèse où le snap serait
correct, une db sauvegardée vaut mieux qu'un "j'espère que ma db est sauvegardée"...
Enfin, je me demande ce que ça donne PostgreSQL WAL + FFS + Cache ATA/ou cache controleur RAID (sans NVRAM), comment l'intégrité des données peut-elle être assurées alors qu'il y a trois systèmes mis en jeux, même si ils sont indépendament "safe", je vois mal comment ils peuvent resister à une coupure de courrant... En tout cas j'ai du mal à croire que c'est plus sur que de sauvgarder ma db en faisant confiance aux snapshots... (ex: Si postgres attend FFS et que FFS attend ATA ou le controleur RAID ça laisse pas mal de temps pour faire de la casse).
Ce qui me fait très peur vu qu'il vont complètement détruire la rue pour rénover, j'ai peur du coup de pelleteuse dans les cables électrique... -- MaXX
MaXX
F. Senault wrote:
A moins qu'il n'y ait moyen de passer la base en read-only le temps de la sauvegarde (je ne sais plus si ça existe en postgres ; avec Oracle, c'est un moyen classique pour les backups, IIRC).
Je n'ai pa l'impression que ça existe autrement que par les outils de sauvegarde de postgres. pg_dump utilise un système "proche" du snapshot FFS+S pour les sauvegardes en plaçant un lock exclusif sur les tuples à sauvegarder si je ne me trompe pas, les modifs en cours étant déléguées dans une sorte de cache...
un extrait de la doc de postgres dit ceci (WAL = Write Ahead Logging qui est utilisé sur ma base): "Finally, WAL makes it possible to support on-line backup and point-in-time recovery, as described in Section 22.3. By archiving the WAL data we can support reverting to any time instant covered by the available WAL data: we simply install a prior physical backup of the database, and replay the WAL log just as far as the desired time. What's more, the physical backup doesn't have to be an instantaneous snapshot of the database state ? if it is made over some period of time, then replaying the WAL log for that period will fix any internal inconsistencies." http://www.postgresql.org/docs/8.0/static/wal.html
le tout étant de créer une procédure de sauvegarde/restauration qui prend tout en compte, et plus le temps passe plus je me dis que la mienne n'est pas au point. J'ai la méchante impression de mélanger plusieures notions...
Fred
-- MaXX
F. Senault wrote:
A moins qu'il n'y ait moyen de passer la base en read-only le temps de
la sauvegarde (je ne sais plus si ça existe en postgres ; avec Oracle,
c'est un moyen classique pour les backups, IIRC).
Je n'ai pa l'impression que ça existe autrement que par les outils de
sauvegarde de postgres.
pg_dump utilise un système "proche" du snapshot FFS+S pour les sauvegardes
en plaçant un lock exclusif sur les tuples à sauvegarder si je ne me
trompe pas, les modifs en cours étant déléguées dans une sorte de cache...
un extrait de la doc de postgres dit ceci (WAL = Write Ahead Logging qui est
utilisé sur ma base):
"Finally, WAL makes it possible to support on-line backup and point-in-time
recovery, as described in Section 22.3. By archiving the WAL data we can
support reverting to any time instant covered by the available WAL data: we
simply install a prior physical backup of the database, and replay the WAL
log just as far as the desired time. What's more, the physical backup
doesn't have to be an instantaneous snapshot of the database state ? if it
is made over some period of time, then replaying the WAL log for that
period will fix any internal inconsistencies."
http://www.postgresql.org/docs/8.0/static/wal.html
le tout étant de créer une procédure de sauvegarde/restauration qui prend
tout en compte, et plus le temps passe plus je me dis que la mienne n'est
pas au point.
J'ai la méchante impression de mélanger plusieures notions...
A moins qu'il n'y ait moyen de passer la base en read-only le temps de la sauvegarde (je ne sais plus si ça existe en postgres ; avec Oracle, c'est un moyen classique pour les backups, IIRC).
Je n'ai pa l'impression que ça existe autrement que par les outils de sauvegarde de postgres. pg_dump utilise un système "proche" du snapshot FFS+S pour les sauvegardes en plaçant un lock exclusif sur les tuples à sauvegarder si je ne me trompe pas, les modifs en cours étant déléguées dans une sorte de cache...
un extrait de la doc de postgres dit ceci (WAL = Write Ahead Logging qui est utilisé sur ma base): "Finally, WAL makes it possible to support on-line backup and point-in-time recovery, as described in Section 22.3. By archiving the WAL data we can support reverting to any time instant covered by the available WAL data: we simply install a prior physical backup of the database, and replay the WAL log just as far as the desired time. What's more, the physical backup doesn't have to be an instantaneous snapshot of the database state ? if it is made over some period of time, then replaying the WAL log for that period will fix any internal inconsistencies." http://www.postgresql.org/docs/8.0/static/wal.html
le tout étant de créer une procédure de sauvegarde/restauration qui prend tout en compte, et plus le temps passe plus je me dis que la mienne n'est pas au point. J'ai la méchante impression de mélanger plusieures notions...
Fred
-- MaXX
Amon
In article <d5m0oo$1v7p$, MaXX wrote:
Eric Masson wrote:
Enfin, je me demande ce que ça donne PostgreSQL WAL + FFS + Cache ATA/ou cache controleur RAID (sans NVRAM), comment l'intégrité des données peut-elle être assurées alors qu'il y a trois systèmes mis en jeux, même si ils sont indépendament "safe", je vois mal comment ils peuvent resister à une coupure de courrant... En tout cas j'ai du mal à croire que c'est plus
Tout l'ensemble est sur car quand le WAL ecrit son journal il fait des appels periodique a fsync() pour synchroniser immediatement les donnees sur disque sans passer par le buffer cache de l'os. Si le controlleur disque sous jacent a un cache, alors une batterie est indispensable pour garantir la coherence des donnees ecrites en cas de coupure electrique.
Dans tous les cas il est amha mieux de sauver une base avec pg_dump car ca permet de disposer des donnees en format texte, ce qui est largement plus utile que des dumps du fs (par exemple s'il faut restaurer une seule table ou une partie d'une table).
-- Herve Boulouis
In article <d5m0oo$1v7p$1@talisker.lacave.net>, MaXX wrote:
Eric Masson wrote:
Enfin, je me demande ce que ça donne PostgreSQL WAL + FFS + Cache ATA/ou
cache controleur RAID (sans NVRAM), comment l'intégrité des données
peut-elle être assurées alors qu'il y a trois systèmes mis en jeux, même si
ils sont indépendament "safe", je vois mal comment ils peuvent resister à
une coupure de courrant... En tout cas j'ai du mal à croire que c'est plus
Tout l'ensemble est sur car quand le WAL ecrit son journal il fait des appels
periodique a fsync() pour synchroniser immediatement les donnees sur disque sans
passer par le buffer cache de l'os. Si le controlleur disque sous jacent a un
cache, alors une batterie est indispensable pour garantir la coherence des
donnees ecrites en cas de coupure electrique.
Dans tous les cas il est amha mieux de sauver une base avec pg_dump car ca
permet de disposer des donnees en format texte, ce qui est largement plus
utile que des dumps du fs (par exemple s'il faut restaurer une seule table
ou une partie d'une table).
Enfin, je me demande ce que ça donne PostgreSQL WAL + FFS + Cache ATA/ou cache controleur RAID (sans NVRAM), comment l'intégrité des données peut-elle être assurées alors qu'il y a trois systèmes mis en jeux, même si ils sont indépendament "safe", je vois mal comment ils peuvent resister à une coupure de courrant... En tout cas j'ai du mal à croire que c'est plus
Tout l'ensemble est sur car quand le WAL ecrit son journal il fait des appels periodique a fsync() pour synchroniser immediatement les donnees sur disque sans passer par le buffer cache de l'os. Si le controlleur disque sous jacent a un cache, alors une batterie est indispensable pour garantir la coherence des donnees ecrites en cas de coupure electrique.
Dans tous les cas il est amha mieux de sauver une base avec pg_dump car ca permet de disposer des donnees en format texte, ce qui est largement plus utile que des dumps du fs (par exemple s'il faut restaurer une seule table ou une partie d'une table).
