Discussion :

[JeanNoel53]

bonjour
comment faire un backup de le base?
Je souhaiterai un format de sortie de type Excel

[SergioMaster]

Bonjour,

réponse simple : Gbak , NBackup
et non le format de sortie ne seras pas Excel (mais là s'agit-il de la Base que tu veux sous format excel ou d'un Table ?)
à ce second sujet , il est assez facile avec Flamerobin , d'extraire tout ou partie d'une table (via SQL) , et de sauvegarder le résultat dans un fichier CSV (donc facile à importer dans Excel)

[JeanNoel53]

J'ai besoin de backuper la base. J'ai utilisé gback mais le format de sortie n'est pas transférable vers une autre base. J'ai besoin d'un backup qui me permet de reporter le contenu de la base dans un autre serveur. les formats xls ou csv conviennet

[Pierre GIRARD]

Il y a "IB Data Pump" qui fait ça il me semble. C'est avec cet outil que (si ma mémoire est bonne) j'ai converti des bases de données Paradox en Interbase. Et il me semble qu'il y a une option pour ressortir les données au format CSV.

Mais effectivement, ça sauvegarde les tables, mais pas la base dans sa totalité.

[makowski]

Allez voir ici :
http://ibphoenix.com/download/tools/migration

FBExport devrait convenir
mais je n'appellerai pas ça un backup, mais un export plutôt

il y a aussi
http://ibphoenix.com/products/software/dbfile

sinon, il y a la réplication :
http://ibphoenix.com/products/software/ibreplicator

[SergioMaster]

mais je n'appellerai pas ça un backup, mais un export plutôt

je plussoie , la question portait à confusion

[Pierre GIRARD]

Cela étant, je ne connais pas à fond "Flamerobin" cité par SergioMaster, mais il est peut-être possible d'extraire des tables au format CSV avec. A titre personnel, j'utilise IBExpert pour passer d'Excel à Firebird/Interbase et réciproquement couramment (en XLS comme en CSV) ... mais, IBExpert n'est pas gratuit.

Pour revenir aux "DataPump", en fait, ils permettent de transférer des Bases de données d'un format à un autre, mais via la création de scripts SQL. Donc pour créer des tables CSV ? finalement, j'ai des doutes.

Pour ce qui est de l'export, +1 aussi. A titre tersonnel, chez moi, le backup c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Copy <chemin source>/<fichier>.<extension>  <chemin sauvegarde>/<fichier>.<extension>

D'une simplicité enfantine ... mais ça ne change pas le format de la base.

[makowski]

A titre tersonnel, chez moi, le backup c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Copy <chemin source>/<fichier>.<extension>  <chemin sauvegarde>/<fichier>.<extension>

D'une simplicité enfantine ... mais ça ne change pas le format de la base.

à condition que personne ne soit connecté à la base à ce moment là et pendant la copie ...

[Pierre GIRARD]

Certes, mais ça peut être lancé en batch la nuit après arrêt des processus du serveur Firebird.

[SergioMaster]

Certes, mais ça peut être lancé en batch la nuit après arrêt des processus du serveur Firebird.

je préfère un petit GBAK (ou nbackup) en batch car
1- Cela évite le problème des personnes connectées (dans un environnement réseau on est jamais sur a 100% : pc mal éteint+programmes non quittés ces utilisateurs sont sans gêne )
2- Gbak fait un petit nettoyage (sweep) en même temps

[Pierre GIRARD]

...
1- Cela évite le problème des personnes connectées (dans un environnement réseau on est jamais sur a 100% : pc mal éteint+programmes non quittés ces utilisateurs sont sans gêne )...

Et ils restent connectés même si sous Linux je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/etc/init.d/firebird stop

ou si j'arrête les services FireBird sous Windows ?

Ça m'étonnerais un petit peu.

Après, tu n'as pas tord, il n'y a rien de mieux qu'un logiciel de backup adapté pour ce genre de chose ... mais ma méthode fonctionne, et elle permet même de copier une base de donnée directement d'un serveur Windows à un serveur Linux avec un minimum de compétences, de temps et sans avoir à installer d'outils particulier ni dans l'environnement de départ, ni dans celui de destination.

[SergioMaster]

ah mais , j'ai quand même un arrêt/backup/redémarrage dans mon batch

[makowski]

Certes, mais ça peut être lancé en batch la nuit après arrêt des processus du serveur Firebird.

pas besoin
il suffit d'utiliser nbackup ou son équivalent sql pour préparer le fichier de la base à la copie directe
http://www.firebirdsql.org/file/docu...ck-unlock.html

[Pierre GIRARD]

Je ne vois pas en quoi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nbackup [-U <user> -P <password>] -L <database>

Now copy/backup/zip the database file to your heart's content, with your own choice of tools. A simple file copy is also possible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nbackup [-U <user> -P <password>] -N <database>

est plus simple et plus efficace que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/etc/init.d/firebird stop

Copier la base (avec ou sans ZIP)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/etc/init.d/firebird start

Dans les deux cas, aucun risque de pertes de données, et les bases accédées par les utilisateurs 24h/24 7j/7 en FireBird ne doivent pas être très nombreuses. Mais bon, comme moi je suis le seul utilisateur de ma base ... je ne vois peut-être pas toutes les situations possibles.

[makowski]

les bases accédées par les utilisateurs 24h/24 7j/7 en FireBird ne doivent pas être très nombreuses

ben, il y en a et surement plus que tu ne sembles le croire
et il n'y a pas que ce cas là
car si tu as plusieurs bases, ton arrêt du serveur pour sauvegarder une base, coupe l'accès à toutes les bases, c'est un peu dommage non ?
bref le lock est utile, clairement.

[Pierre GIRARD]

ben, il y en a et surement plus que tu ne sembles le croire...

A 2h00 du matin ?

...car si tu as plusieurs bases, ton arrêt du serveur pour sauvegarder une base, coupe l'accès à toutes les bases, c'est un peu dommage non ?...

A 2h00 du matin ?

Bon, pour des usines Oracle, je suis d'accord avec toi. Mais, pour des bases de données de type FireBird ou Interbase, qui ne se composent la plupart du temps que d'un seul et unique fichier (ce qui n'est le cas ni de Oracle, ni de DB2, ni de ... la plupart des bases de données), les cas d'utilisation ne permettant pas un arrêt à heure fixe sont probablement assez marginales.

Après, on trouve de tout dans la nature, mais moi, je vais toujours au plus simple, au plus rapides et au plus pratiques. Mais encore une fois, je ne te donne par tort (je t'ai même ajouté un "+" pour lever tout doute), et dans certains cas, ta solution est absolument indispensable ... ce qui ne rend pas la mienne invalide dans un grand nombre de cas.

[SergioMaster]

A 2h00 du matin ?

tu sais , la sous-traitance et la délocalisation ça existe pour un peu qu'une SGBD soit utilisée dans divers pays ....

et ni dis pas "c'est exceptionnel" je travaille pour une petite entreprise et une des BDD est relié à ses sous-traitants (INDE, TUNISIE<- là y presque pas de décalage)
on en est pas encore à couvrir tous les fuseaux horaires
Maintenant un de nos objectifs est que nos clients puissent interroger les Stocks disponibles (ajoute alors USA,JAPON ....) on arrive vite a une utilisation 24h/24h