bonjour
comment faire un backup de le base?
Je souhaiterai un format de sortie de type Excel
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
une question simple: comment faire un backup de le base?
bonjour
comment faire un backup de le base?
Je souhaiterai un format de sortie de type Excel
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)
précision sur mon besoin
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
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é.
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
je plussoieEnvoyé par makowski
, la question portait à confusion
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 :
D'une simplicité enfantine ... mais ça ne change pas le format de la base.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Copy <chemin source>/<fichier>.<extension> <chemin sauvegarde>/<fichier>.<extension>
à condition que personne ne soit connecté à la base à ce moment là et pendant la copie ...A titre tersonnel, chez moi, le backup c'est :
D'une simplicité enfantine ... mais ça ne change pas le format de la base.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Copy <chemin source>/<fichier>.<extension> <chemin sauvegarde>/<fichier>.<extension>
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 carCertes, mais ça peut être lancé en batch la nuit après arrêt des processus du serveur Firebird.
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
Et ils restent connectés même si sous Linux je fais...
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
ou si j'arrête les services FireBird sous Windows ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part /etc/init.d/firebird stop
Ç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
ah mais , j'ai quand même un arrêt/backup/redémarrage dans mon batch
pas besoinCertes, mais ça peut être lancé en batch la nuit après arrêt des processus du serveur Firebird.
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
Je ne vois pas en quoi :
est plus simple et plus efficace que :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>] -L <database>
Code : Sélectionner tout - Visualiser dans une fenêtre à part nbackup [-U <user> -P <password>] -N <database>
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.Copier la base (avec ou sans ZIP)
Code : Sélectionner tout - Visualiser dans une fenêtre à part /etc/init.d/firebird stop
Code : Sélectionner tout - Visualiser dans une fenêtre à part /etc/init.d/firebird start
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.
A 2h00 du matin ?
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.
tu sais , la sous-traitance et la délocalisation ça existepour 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
Répondre avec citation
Partager