Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
Un grand merci d'avance pour votre aide :-)
Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = '\serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
Un grand merci d'avance pour votre aide :-)
Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
Un grand merci d'avance pour votre aide :-)
Fred a écrit :
> Bonjour,
> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
> les backups.
> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
> qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.
> Là où tous les backups sont faits je vois chaque jour un fichier du type
> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
> censé faire ??
>
> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
> to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
> chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.
>
> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
> avant de faire un backup log et si oui de quelle manière car si je crée un
> fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !
>
> Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Fred a écrit :
> Bonjour,
> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
> les backups.
> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
> qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.
> Là où tous les backups sont faits je vois chaque jour un fichier du type
> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
> censé faire ??
>
> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
> to disk = '\serverbackupsqlsysaid_log.bak') sans arguments ... et là je
> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
> chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.
>
> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
> avant de faire un backup log et si oui de quelle manière car si je crée un
> fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !
>
> Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Fred a écrit :
> Bonjour,
> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
> les backups.
> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
> qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.
> Là où tous les backups sont faits je vois chaque jour un fichier du type
> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
> censé faire ??
>
> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
> to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
> chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.
>
> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
> avant de faire un backup log et si oui de quelle manière car si je crée un
> fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !
>
> Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Merci bcp. Voilà ce que j'ai donc fait :
1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
'serverbackupsqlSysAid_full.bak'
Completed successfully
2) backup database sysaid to SYSAID_BACKUPS
Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
MB/sec).
3) backup log sysaid to SYSAID_BACKUPS
Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
4) backup log sysaid to SYSAID_BACKUPS
Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
5) restore headeronly from SYSAID_BACKUPS
Je vois bien toutes les actions entreprises.
Est-ce que c'est normal que je voie au niveau de serverbackupsql
uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
le point 2) une fois par jour
et un autre job avec le point 3) toutes les heures ?
En cas de crash, on fait simplement ...
RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
Mille mercis pour votre aide en tout cas, elle m'a été très utile.
"Fred BROUARD" a écrit :Fred a écrit :Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Merci bcp. Voilà ce que j'ai donc fait :
1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
'\serverbackupsqlSysAid_full.bak'
Completed successfully
2) backup database sysaid to SYSAID_BACKUPS
Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
MB/sec).
3) backup log sysaid to SYSAID_BACKUPS
Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
4) backup log sysaid to SYSAID_BACKUPS
Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
5) restore headeronly from SYSAID_BACKUPS
Je vois bien toutes les actions entreprises.
Est-ce que c'est normal que je voie au niveau de \serverbackupsql
uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
le point 2) une fois par jour
et un autre job avec le point 3) toutes les heures ?
En cas de crash, on fait simplement ...
RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
Mille mercis pour votre aide en tout cas, elle m'a été très utile.
"Fred BROUARD" a écrit :
Fred a écrit :
Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.
Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = '\serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.
Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !
Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Merci bcp. Voilà ce que j'ai donc fait :
1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
'serverbackupsqlSysAid_full.bak'
Completed successfully
2) backup database sysaid to SYSAID_BACKUPS
Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
MB/sec).
3) backup log sysaid to SYSAID_BACKUPS
Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
4) backup log sysaid to SYSAID_BACKUPS
Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
5) restore headeronly from SYSAID_BACKUPS
Je vois bien toutes les actions entreprises.
Est-ce que c'est normal que je voie au niveau de serverbackupsql
uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
le point 2) une fois par jour
et un autre job avec le point 3) toutes les heures ?
En cas de crash, on fait simplement ...
RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
Mille mercis pour votre aide en tout cas, elle m'a été très utile.
"Fred BROUARD" a écrit :Fred a écrit :Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
re bonjour,
Fred a écrit :
> Merci bcp. Voilà ce que j'ai donc fait :
>
> 1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
> 'serverbackupsqlSysAid_full.bak'
>
> Completed successfully
>
> 2) backup database sysaid to SYSAID_BACKUPS
>
> Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
> Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
> BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
> MB/sec).
>
> 3) backup log sysaid to SYSAID_BACKUPS
>
> Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
> BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
>
> 4) backup log sysaid to SYSAID_BACKUPS
>
> Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
> BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
>
> 5) restore headeronly from SYSAID_BACKUPS
>
> Je vois bien toutes les actions entreprises.
DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
>
> Est-ce que c'est normal que je voie au niveau de serverbackupsql
> uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
oui ce fichier est un device, c'est à dire un super fichier contenant
vos différentes suavegardes
>
> Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
> le point 2) une fois par jour
oui
> et un autre job avec le point 3) toutes les heures ?
oui
>
> En cas de crash, on fait simplement ...
>
> RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
non, impossible. Je vous explique brièvement pourquoi (mais en général
on passe 3 heures en cours d'admin pour en développer toutes les
hypothèses).
Tout simplement parce que le système ne peut pas savoir à votre place
quel type de crash (logique, physique, fonctionnel...) vous avez eu.
Et comme il ne le peut pas, la logique de restauration sera différente
en fonction de votre problématique.
Maintenant pour savoir ce que contient votre super fichier, vous pouvez
faire les requêtes suivantes :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
ceci vous donnera la liste des sauvegardes empilées
Si vous regardez bien, dans les informations retournées il y a un N° de
séquence des différentes sauvegardes (colonne Position).
A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
jeu à l'aide de :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
WITH FILE = ?
Et remplacer ? par le n° de fichier souhaité
Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
c'est la dernière à passer
2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
mode NORECOVERY, sauf si c'est la dernière à passer
3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
NORECOVERY, sauf si c'est la dernière à passer
Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
production.
Vous devez comprendre donc que seule la dernière restauration de votre
stratégie doit être en RECOVERY, les autres non.
De plus respectez bien le séquencemment, car une sauvegarde de perdu et
c'est fini, vous ne pouvez plus restaurer.
Autrement dit : testez votre plan de sauvegarde en montant une maquette
de restauration.
Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
stratégie de sauvegarde par rapport aux problématique de restauration :
a) en combien de temps allez vous pouivoir restaurer la base ?
b) quel voulume de données pouvez vous sacrifier ?
Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
doivent aussi être sauvegardées) prenez celle que j'ai écrite :
http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
A +
>
> Mille mercis pour votre aide en tout cas, elle m'a été très utile.
>
> "Fred BROUARD" a écrit :
>
>> Fred a écrit :
>>> Bonjour,
>>> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
>>> les backups.
>>> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
>>> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
>>> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
>>> qui n'est pas le cas.
>> C'est parce que vous n'avez pas compris la notion de support.
>> Un support est une unité de sauvegarde comme une bande ou un fichier.
>> La commande INIT supprime le contenu du support, mais pas le support lui
>> même. Il faut comprendre que dans un device (unité de sauvegarde) vous
>> pouvez empiler plusieurs sauvegardes.
>> Lisez l'article que j'ai écrit à ce sujet :
>> http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
>> Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
>> INIT ne servira à rien. La commande INIT est une comande logique. Si
>> vous voulez de la suppression physique de fichier il faut agir avec une
>> commande OS comme DEL.
>>
>>> Là où tous les backups sont faits je vois chaque jour un fichier du type
>>> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
>>> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
>>> censé faire ??
>>>
>>> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
>>> to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
>>> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
>>> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
>>> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
>>> chaque fois un fichier unique et si oui, comment ?
>> même remarque que précédemment.
>>
>>> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
>>> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
>>> avant de faire un backup log et si oui de quelle manière car si je crée un
>>> fichier texte que je renomme en .bak, ça ne fct pas non plus.
>> non, et sans le texte de l'erreur, difficile de vous répondre !
>>
>>> Un grand merci d'avance pour votre aide :-)
>> A +
>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> *********************** http://www.sqlspot.com *************************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
re bonjour,
Fred a écrit :
> Merci bcp. Voilà ce que j'ai donc fait :
>
> 1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
> '\serverbackupsqlSysAid_full.bak'
>
> Completed successfully
>
> 2) backup database sysaid to SYSAID_BACKUPS
>
> Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
> Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
> BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
> MB/sec).
>
> 3) backup log sysaid to SYSAID_BACKUPS
>
> Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
> BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
>
> 4) backup log sysaid to SYSAID_BACKUPS
>
> Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
> BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
>
> 5) restore headeronly from SYSAID_BACKUPS
>
> Je vois bien toutes les actions entreprises.
DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
>
> Est-ce que c'est normal que je voie au niveau de \serverbackupsql
> uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
oui ce fichier est un device, c'est à dire un super fichier contenant
vos différentes suavegardes
>
> Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
> le point 2) une fois par jour
oui
> et un autre job avec le point 3) toutes les heures ?
oui
>
> En cas de crash, on fait simplement ...
>
> RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
non, impossible. Je vous explique brièvement pourquoi (mais en général
on passe 3 heures en cours d'admin pour en développer toutes les
hypothèses).
Tout simplement parce que le système ne peut pas savoir à votre place
quel type de crash (logique, physique, fonctionnel...) vous avez eu.
Et comme il ne le peut pas, la logique de restauration sera différente
en fonction de votre problématique.
Maintenant pour savoir ce que contient votre super fichier, vous pouvez
faire les requêtes suivantes :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
ceci vous donnera la liste des sauvegardes empilées
Si vous regardez bien, dans les informations retournées il y a un N° de
séquence des différentes sauvegardes (colonne Position).
A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
jeu à l'aide de :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
WITH FILE = ?
Et remplacer ? par le n° de fichier souhaité
Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
c'est la dernière à passer
2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
mode NORECOVERY, sauf si c'est la dernière à passer
3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
NORECOVERY, sauf si c'est la dernière à passer
Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
production.
Vous devez comprendre donc que seule la dernière restauration de votre
stratégie doit être en RECOVERY, les autres non.
De plus respectez bien le séquencemment, car une sauvegarde de perdu et
c'est fini, vous ne pouvez plus restaurer.
Autrement dit : testez votre plan de sauvegarde en montant une maquette
de restauration.
Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
stratégie de sauvegarde par rapport aux problématique de restauration :
a) en combien de temps allez vous pouivoir restaurer la base ?
b) quel voulume de données pouvez vous sacrifier ?
Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
doivent aussi être sauvegardées) prenez celle que j'ai écrite :
http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
A +
>
> Mille mercis pour votre aide en tout cas, elle m'a été très utile.
>
> "Fred BROUARD" a écrit :
>
>> Fred a écrit :
>>> Bonjour,
>>> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
>>> les backups.
>>> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
>>> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
>>> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
>>> qui n'est pas le cas.
>> C'est parce que vous n'avez pas compris la notion de support.
>> Un support est une unité de sauvegarde comme une bande ou un fichier.
>> La commande INIT supprime le contenu du support, mais pas le support lui
>> même. Il faut comprendre que dans un device (unité de sauvegarde) vous
>> pouvez empiler plusieurs sauvegardes.
>> Lisez l'article que j'ai écrit à ce sujet :
>> http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
>> Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
>> INIT ne servira à rien. La commande INIT est une comande logique. Si
>> vous voulez de la suppression physique de fichier il faut agir avec une
>> commande OS comme DEL.
>>
>>> Là où tous les backups sont faits je vois chaque jour un fichier du type
>>> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
>>> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
>>> censé faire ??
>>>
>>> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
>>> to disk = '\serverbackupsqlsysaid_log.bak') sans arguments ... et là je
>>> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
>>> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
>>> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
>>> chaque fois un fichier unique et si oui, comment ?
>> même remarque que précédemment.
>>
>>> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
>>> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
>>> avant de faire un backup log et si oui de quelle manière car si je crée un
>>> fichier texte que je renomme en .bak, ça ne fct pas non plus.
>> non, et sans le texte de l'erreur, difficile de vous répondre !
>>
>>> Un grand merci d'avance pour votre aide :-)
>> A +
>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> *********************** http://www.sqlspot.com *************************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
re bonjour,
Fred a écrit :
> Merci bcp. Voilà ce que j'ai donc fait :
>
> 1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
> 'serverbackupsqlSysAid_full.bak'
>
> Completed successfully
>
> 2) backup database sysaid to SYSAID_BACKUPS
>
> Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
> Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
> BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
> MB/sec).
>
> 3) backup log sysaid to SYSAID_BACKUPS
>
> Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
> BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
>
> 4) backup log sysaid to SYSAID_BACKUPS
>
> Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
> BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
>
> 5) restore headeronly from SYSAID_BACKUPS
>
> Je vois bien toutes les actions entreprises.
DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
>
> Est-ce que c'est normal que je voie au niveau de serverbackupsql
> uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
oui ce fichier est un device, c'est à dire un super fichier contenant
vos différentes suavegardes
>
> Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
> le point 2) une fois par jour
oui
> et un autre job avec le point 3) toutes les heures ?
oui
>
> En cas de crash, on fait simplement ...
>
> RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
non, impossible. Je vous explique brièvement pourquoi (mais en général
on passe 3 heures en cours d'admin pour en développer toutes les
hypothèses).
Tout simplement parce que le système ne peut pas savoir à votre place
quel type de crash (logique, physique, fonctionnel...) vous avez eu.
Et comme il ne le peut pas, la logique de restauration sera différente
en fonction de votre problématique.
Maintenant pour savoir ce que contient votre super fichier, vous pouvez
faire les requêtes suivantes :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
ceci vous donnera la liste des sauvegardes empilées
Si vous regardez bien, dans les informations retournées il y a un N° de
séquence des différentes sauvegardes (colonne Position).
A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
jeu à l'aide de :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
WITH FILE = ?
Et remplacer ? par le n° de fichier souhaité
Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
c'est la dernière à passer
2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
mode NORECOVERY, sauf si c'est la dernière à passer
3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
NORECOVERY, sauf si c'est la dernière à passer
Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
production.
Vous devez comprendre donc que seule la dernière restauration de votre
stratégie doit être en RECOVERY, les autres non.
De plus respectez bien le séquencemment, car une sauvegarde de perdu et
c'est fini, vous ne pouvez plus restaurer.
Autrement dit : testez votre plan de sauvegarde en montant une maquette
de restauration.
Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
stratégie de sauvegarde par rapport aux problématique de restauration :
a) en combien de temps allez vous pouivoir restaurer la base ?
b) quel voulume de données pouvez vous sacrifier ?
Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
doivent aussi être sauvegardées) prenez celle que j'ai écrite :
http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
A +
>
> Mille mercis pour votre aide en tout cas, elle m'a été très utile.
>
> "Fred BROUARD" a écrit :
>
>> Fred a écrit :
>>> Bonjour,
>>> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
>>> les backups.
>>> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
>>> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
>>> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
>>> qui n'est pas le cas.
>> C'est parce que vous n'avez pas compris la notion de support.
>> Un support est une unité de sauvegarde comme une bande ou un fichier.
>> La commande INIT supprime le contenu du support, mais pas le support lui
>> même. Il faut comprendre que dans un device (unité de sauvegarde) vous
>> pouvez empiler plusieurs sauvegardes.
>> Lisez l'article que j'ai écrit à ce sujet :
>> http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
>> Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
>> INIT ne servira à rien. La commande INIT est une comande logique. Si
>> vous voulez de la suppression physique de fichier il faut agir avec une
>> commande OS comme DEL.
>>
>>> Là où tous les backups sont faits je vois chaque jour un fichier du type
>>> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
>>> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
>>> censé faire ??
>>>
>>> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
>>> to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
>>> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
>>> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
>>> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
>>> chaque fois un fichier unique et si oui, comment ?
>> même remarque que précédemment.
>>
>>> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
>>> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
>>> avant de faire un backup log et si oui de quelle manière car si je crée un
>>> fichier texte que je renomme en .bak, ça ne fct pas non plus.
>> non, et sans le texte de l'erreur, difficile de vous répondre !
>>
>>> Un grand merci d'avance pour votre aide :-)
>> A +
>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> *********************** http://www.sqlspot.com *************************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Ok ... pas simple.
Juste une chose c'est que vu l'allure à laquelle mon super fichier grandit,
ça va être difficilement gérable. Je préférerais avoir un super fichier par
semaine par exemple. C'est possible ? Quel argument utiliser dans ce cas pour
que cela se fasse de manière automatique au niveau du job ?
Pour être sûre que j'ai bien compris les procédures de restore ...
Admettons que je fais un full à 23h tous les soirs et un backup log toutes
les 2 h.
Disons que la DB se plante un matin à 9h30.
Je regarde les headers et je vois que le dernier full a la position 8 et les
backups des logs de transactions respectivement les positions 9, 10, 11, 12 &
13.
Que devrais-je faire exactement ? Est-ce que le code suivant est bon ? Dans
la doc MSDN j'ai vu que la dernière cmd fait "un restore total" avec
recovery. C'est ce que je devrais faire ?
RESTORE DATABASE SysAid
FROM SYSAID_BACKUPS
WITH FILE = 8
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 9
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 10
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 11
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 12
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 13
NORECOVERY
GO
RESTORE DATABASE SysAid
WITH RECOVERY
Mais après tout je me demande quel est l'avantage de créer un device vu que
la procédure est aussi longue ... ?
Encore merci pour votre aide !
"Fred BROUARD" a écrit :re bonjour,
Fred a écrit :Merci bcp. Voilà ce que j'ai donc fait :
1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
'serverbackupsqlSysAid_full.bak'
Completed successfully
2) backup database sysaid to SYSAID_BACKUPS
Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
MB/sec).
3) backup log sysaid to SYSAID_BACKUPS
Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
4) backup log sysaid to SYSAID_BACKUPS
Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
5) restore headeronly from SYSAID_BACKUPS
Je vois bien toutes les actions entreprises.
DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OKEst-ce que c'est normal que je voie au niveau de serverbackupsql
uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
oui ce fichier est un device, c'est à dire un super fichier contenant
vos différentes suavegardesComme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
le point 2) une fois par jour
ouiet un autre job avec le point 3) toutes les heures ?
ouiEn cas de crash, on fait simplement ...
RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
non, impossible. Je vous explique brièvement pourquoi (mais en général
on passe 3 heures en cours d'admin pour en développer toutes les
hypothèses).
Tout simplement parce que le système ne peut pas savoir à votre place
quel type de crash (logique, physique, fonctionnel...) vous avez eu.
Et comme il ne le peut pas, la logique de restauration sera différente
en fonction de votre problématique.
Maintenant pour savoir ce que contient votre super fichier, vous pouvez
faire les requêtes suivantes :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
ceci vous donnera la liste des sauvegardes empilées
Si vous regardez bien, dans les informations retournées il y a un N° de
séquence des différentes sauvegardes (colonne Position).
A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
jeu à l'aide de :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
WITH FILE = ?
Et remplacer ? par le n° de fichier souhaité
Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
c'est la dernière à passer
2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
mode NORECOVERY, sauf si c'est la dernière à passer
3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
NORECOVERY, sauf si c'est la dernière à passer
Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
production.
Vous devez comprendre donc que seule la dernière restauration de votre
stratégie doit être en RECOVERY, les autres non.
De plus respectez bien le séquencemment, car une sauvegarde de perdu et
c'est fini, vous ne pouvez plus restaurer.
Autrement dit : testez votre plan de sauvegarde en montant une maquette
de restauration.
Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
stratégie de sauvegarde par rapport aux problématique de restauration :
a) en combien de temps allez vous pouivoir restaurer la base ?
b) quel voulume de données pouvez vous sacrifier ?
Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
doivent aussi être sauvegardées) prenez celle que j'ai écrite :
http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
A +Mille mercis pour votre aide en tout cas, elle m'a été très utile.
"Fred BROUARD" a écrit :Fred a écrit :Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Ok ... pas simple.
Juste une chose c'est que vu l'allure à laquelle mon super fichier grandit,
ça va être difficilement gérable. Je préférerais avoir un super fichier par
semaine par exemple. C'est possible ? Quel argument utiliser dans ce cas pour
que cela se fasse de manière automatique au niveau du job ?
Pour être sûre que j'ai bien compris les procédures de restore ...
Admettons que je fais un full à 23h tous les soirs et un backup log toutes
les 2 h.
Disons que la DB se plante un matin à 9h30.
Je regarde les headers et je vois que le dernier full a la position 8 et les
backups des logs de transactions respectivement les positions 9, 10, 11, 12 &
13.
Que devrais-je faire exactement ? Est-ce que le code suivant est bon ? Dans
la doc MSDN j'ai vu que la dernière cmd fait "un restore total" avec
recovery. C'est ce que je devrais faire ?
RESTORE DATABASE SysAid
FROM SYSAID_BACKUPS
WITH FILE = 8
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 9
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 10
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 11
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 12
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 13
NORECOVERY
GO
RESTORE DATABASE SysAid
WITH RECOVERY
Mais après tout je me demande quel est l'avantage de créer un device vu que
la procédure est aussi longue ... ?
Encore merci pour votre aide !
"Fred BROUARD" a écrit :
re bonjour,
Fred a écrit :
Merci bcp. Voilà ce que j'ai donc fait :
1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
'\serverbackupsqlSysAid_full.bak'
Completed successfully
2) backup database sysaid to SYSAID_BACKUPS
Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
MB/sec).
3) backup log sysaid to SYSAID_BACKUPS
Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
4) backup log sysaid to SYSAID_BACKUPS
Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
5) restore headeronly from SYSAID_BACKUPS
Je vois bien toutes les actions entreprises.
DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
Est-ce que c'est normal que je voie au niveau de \serverbackupsql
uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
oui ce fichier est un device, c'est à dire un super fichier contenant
vos différentes suavegardes
Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
le point 2) une fois par jour
oui
et un autre job avec le point 3) toutes les heures ?
oui
En cas de crash, on fait simplement ...
RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
non, impossible. Je vous explique brièvement pourquoi (mais en général
on passe 3 heures en cours d'admin pour en développer toutes les
hypothèses).
Tout simplement parce que le système ne peut pas savoir à votre place
quel type de crash (logique, physique, fonctionnel...) vous avez eu.
Et comme il ne le peut pas, la logique de restauration sera différente
en fonction de votre problématique.
Maintenant pour savoir ce que contient votre super fichier, vous pouvez
faire les requêtes suivantes :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
ceci vous donnera la liste des sauvegardes empilées
Si vous regardez bien, dans les informations retournées il y a un N° de
séquence des différentes sauvegardes (colonne Position).
A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
jeu à l'aide de :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
WITH FILE = ?
Et remplacer ? par le n° de fichier souhaité
Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
c'est la dernière à passer
2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
mode NORECOVERY, sauf si c'est la dernière à passer
3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
NORECOVERY, sauf si c'est la dernière à passer
Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
production.
Vous devez comprendre donc que seule la dernière restauration de votre
stratégie doit être en RECOVERY, les autres non.
De plus respectez bien le séquencemment, car une sauvegarde de perdu et
c'est fini, vous ne pouvez plus restaurer.
Autrement dit : testez votre plan de sauvegarde en montant une maquette
de restauration.
Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
stratégie de sauvegarde par rapport aux problématique de restauration :
a) en combien de temps allez vous pouivoir restaurer la base ?
b) quel voulume de données pouvez vous sacrifier ?
Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
doivent aussi être sauvegardées) prenez celle que j'ai écrite :
http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
A +
Mille mercis pour votre aide en tout cas, elle m'a été très utile.
"Fred BROUARD" a écrit :
Fred a écrit :
Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.
Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = '\serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.
Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !
Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Ok ... pas simple.
Juste une chose c'est que vu l'allure à laquelle mon super fichier grandit,
ça va être difficilement gérable. Je préférerais avoir un super fichier par
semaine par exemple. C'est possible ? Quel argument utiliser dans ce cas pour
que cela se fasse de manière automatique au niveau du job ?
Pour être sûre que j'ai bien compris les procédures de restore ...
Admettons que je fais un full à 23h tous les soirs et un backup log toutes
les 2 h.
Disons que la DB se plante un matin à 9h30.
Je regarde les headers et je vois que le dernier full a la position 8 et les
backups des logs de transactions respectivement les positions 9, 10, 11, 12 &
13.
Que devrais-je faire exactement ? Est-ce que le code suivant est bon ? Dans
la doc MSDN j'ai vu que la dernière cmd fait "un restore total" avec
recovery. C'est ce que je devrais faire ?
RESTORE DATABASE SysAid
FROM SYSAID_BACKUPS
WITH FILE = 8
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 9
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 10
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 11
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 12
NORECOVERY
GO
RESTORE LOG SysAid
FROM SYSAID_BACKUPS
WITH FILE = 13
NORECOVERY
GO
RESTORE DATABASE SysAid
WITH RECOVERY
Mais après tout je me demande quel est l'avantage de créer un device vu que
la procédure est aussi longue ... ?
Encore merci pour votre aide !
"Fred BROUARD" a écrit :re bonjour,
Fred a écrit :Merci bcp. Voilà ce que j'ai donc fait :
1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
'serverbackupsqlSysAid_full.bak'
Completed successfully
2) backup database sysaid to SYSAID_BACKUPS
Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
MB/sec).
3) backup log sysaid to SYSAID_BACKUPS
Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
4) backup log sysaid to SYSAID_BACKUPS
Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
5) restore headeronly from SYSAID_BACKUPS
Je vois bien toutes les actions entreprises.
DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OKEst-ce que c'est normal que je voie au niveau de serverbackupsql
uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
oui ce fichier est un device, c'est à dire un super fichier contenant
vos différentes suavegardesComme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
le point 2) une fois par jour
ouiet un autre job avec le point 3) toutes les heures ?
ouiEn cas de crash, on fait simplement ...
RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
non, impossible. Je vous explique brièvement pourquoi (mais en général
on passe 3 heures en cours d'admin pour en développer toutes les
hypothèses).
Tout simplement parce que le système ne peut pas savoir à votre place
quel type de crash (logique, physique, fonctionnel...) vous avez eu.
Et comme il ne le peut pas, la logique de restauration sera différente
en fonction de votre problématique.
Maintenant pour savoir ce que contient votre super fichier, vous pouvez
faire les requêtes suivantes :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
ceci vous donnera la liste des sauvegardes empilées
Si vous regardez bien, dans les informations retournées il y a un N° de
séquence des différentes sauvegardes (colonne Position).
A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
jeu à l'aide de :
RESTORE HEADERONLY
FROM SYSAID_BACKUPS
WITH FILE = ?
Et remplacer ? par le n° de fichier souhaité
Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
c'est la dernière à passer
2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
mode NORECOVERY, sauf si c'est la dernière à passer
3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
NORECOVERY, sauf si c'est la dernière à passer
Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
production.
Vous devez comprendre donc que seule la dernière restauration de votre
stratégie doit être en RECOVERY, les autres non.
De plus respectez bien le séquencemment, car une sauvegarde de perdu et
c'est fini, vous ne pouvez plus restaurer.
Autrement dit : testez votre plan de sauvegarde en montant une maquette
de restauration.
Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
stratégie de sauvegarde par rapport aux problématique de restauration :
a) en combien de temps allez vous pouivoir restaurer la base ?
b) quel voulume de données pouvez vous sacrifier ?
Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
doivent aussi être sauvegardées) prenez celle que j'ai écrite :
http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
A +Mille mercis pour votre aide en tout cas, elle m'a été très utile.
"Fred BROUARD" a écrit :Fred a écrit :Bonjour,
J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
les backups.
J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
qui n'est pas le cas.
C'est parce que vous n'avez pas compris la notion de support.
Un support est une unité de sauvegarde comme une bande ou un fichier.
La commande INIT supprime le contenu du support, mais pas le support lui
même. Il faut comprendre que dans un device (unité de sauvegarde) vous
pouvez empiler plusieurs sauvegardes.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
INIT ne servira à rien. La commande INIT est une comande logique. Si
vous voulez de la suppression physique de fichier il faut agir avec une
commande OS comme DEL.Là où tous les backups sont faits je vois chaque jour un fichier du type
SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
censé faire ??
Autre point : il y a un aute job qui fait un backup log (backup log sysaid
to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
chaque fois un fichier unique et si oui, comment ?
même remarque que précédemment.Dernier point : j'ai voulu créer un backup log chez un autre client mais il
me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
avant de faire un backup log et si oui de quelle manière car si je crée un
fichier texte que je renomme en .bak, ça ne fct pas non plus.
non, et sans le texte de l'erreur, difficile de vous répondre !Un grand merci d'avance pour votre aide :-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Fred a écrit :
> Ok ... pas simple.
>
> Juste une chose c'est que vu l'allure à laquelle mon super fichier grandit,
> ça va être difficilement gérable. Je préférerais avoir un super fichier par
> semaine par exemple. C'est possible ? Quel argument utiliser dans ce cas pour
> que cela se fasse de manière automatique au niveau du job ?
Dans la commande de backup rajouter un RETAIN DAYS. Il y a d'autres
options. Voir l'aide en ligne et faire des essais.
>
> Pour être sûre que j'ai bien compris les procédures de restore ...
> Admettons que je fais un full à 23h tous les soirs et un backup log toutes
> les 2 h.
> Disons que la DB se plante un matin à 9h30.
> Je regarde les headers et je vois que le dernier full a la position 8 et les
> backups des logs de transactions respectivement les positions 9, 10, 11, 12 &
> 13.
>
> Que devrais-je faire exactement ? Est-ce que le code suivant est bon ? Dans
> la doc MSDN j'ai vu que la dernière cmd fait "un restore total" avec
> recovery. C'est ce que je devrais faire ?
>
> RESTORE DATABASE SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 8
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 9
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 10
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 11
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 12
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 13
> NORECOVERY
> GO
> RESTORE DATABASE SysAid
> WITH RECOVERY
C'est exactement cela. Parfait !
>
> Mais après tout je me demande quel est l'avantage de créer un device vu que
> la procédure est aussi longue ... ?
Avec des fichiers diparatre le risque est grand d'en perdre un et donc
de ne pas pouvoir restaurer !
A +
>
> Encore merci pour votre aide !
>
>
>
>
>
> "Fred BROUARD" a écrit :
>
>> re bonjour,
>>
>> Fred a écrit :
>>> Merci bcp. Voilà ce que j'ai donc fait :
>>>
>>> 1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
>>> 'serverbackupsqlSysAid_full.bak'
>>>
>>> Completed successfully
>>>
>>> 2) backup database sysaid to SYSAID_BACKUPS
>>>
>>> Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
>>> Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
>>> BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
>>> MB/sec).
>>>
>>> 3) backup log sysaid to SYSAID_BACKUPS
>>>
>>> Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
>>> BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
>>>
>>> 4) backup log sysaid to SYSAID_BACKUPS
>>>
>>> Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
>>> BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
>>>
>>> 5) restore headeronly from SYSAID_BACKUPS
>>>
>>> Je vois bien toutes les actions entreprises.
>> DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
>>
>>> Est-ce que c'est normal que je voie au niveau de serverbackupsql
>>> uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
>> oui ce fichier est un device, c'est à dire un super fichier contenant
>> vos différentes suavegardes
>>
>>> Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
>>> le point 2) une fois par jour
>> oui
>>
>>> et un autre job avec le point 3) toutes les heures ?
>> oui
>>
>>> En cas de crash, on fait simplement ...
>>>
>>> RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
>> non, impossible. Je vous explique brièvement pourquoi (mais en général
>> on passe 3 heures en cours d'admin pour en développer toutes les
>> hypothèses).
>> Tout simplement parce que le système ne peut pas savoir à votre place
>> quel type de crash (logique, physique, fonctionnel...) vous avez eu.
>> Et comme il ne le peut pas, la logique de restauration sera différente
>> en fonction de votre problématique.
>>
>> Maintenant pour savoir ce que contient votre super fichier, vous pouvez
>> faire les requêtes suivantes :
>> RESTORE HEADERONLY
>> FROM SYSAID_BACKUPS
>> ceci vous donnera la liste des sauvegardes empilées
>> Si vous regardez bien, dans les informations retournées il y a un N° de
>> séquence des différentes sauvegardes (colonne Position).
>>
>> A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
>> jeu à l'aide de :
>> RESTORE HEADERONLY
>> FROM SYSAID_BACKUPS
>> WITH FILE = ?
>> Et remplacer ? par le n° de fichier souhaité
>>
>> Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
>> 1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
>> c'est la dernière à passer
>> 2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
>> mode NORECOVERY, sauf si c'est la dernière à passer
>> 3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
>> NORECOVERY, sauf si c'est la dernière à passer
>>
>> Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
>> faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
>> production.
>> Vous devez comprendre donc que seule la dernière restauration de votre
>> stratégie doit être en RECOVERY, les autres non.
>> De plus respectez bien le séquencemment, car une sauvegarde de perdu et
>> c'est fini, vous ne pouvez plus restaurer.
>>
>> Autrement dit : testez votre plan de sauvegarde en montant une maquette
>> de restauration.
>> Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
>> stratégie de sauvegarde par rapport aux problématique de restauration :
>> a) en combien de temps allez vous pouivoir restaurer la base ?
>> b) quel voulume de données pouvez vous sacrifier ?
>>
>> Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
>> doivent aussi être sauvegardées) prenez celle que j'ai écrite :
>> http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
>>
>> A +
>>
>>
>>> Mille mercis pour votre aide en tout cas, elle m'a été très utile.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Fred a écrit :
>>>>> Bonjour,
>>>>> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
>>>>> les backups.
>>>>> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
>>>>> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
>>>>> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
>>>>> qui n'est pas le cas.
>>>> C'est parce que vous n'avez pas compris la notion de support.
>>>> Un support est une unité de sauvegarde comme une bande ou un fichier.
>>>> La commande INIT supprime le contenu du support, mais pas le support lui
>>>> même. Il faut comprendre que dans un device (unité de sauvegarde) vous
>>>> pouvez empiler plusieurs sauvegardes.
>>>> Lisez l'article que j'ai écrit à ce sujet :
>>>> http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
>>>> Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
>>>> INIT ne servira à rien. La commande INIT est une comande logique. Si
>>>> vous voulez de la suppression physique de fichier il faut agir avec une
>>>> commande OS comme DEL.
>>>>
>>>>> Là où tous les backups sont faits je vois chaque jour un fichier du type
>>>>> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
>>>>> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
>>>>> censé faire ??
>>>>>
>>>>> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
>>>>> to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
>>>>> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
>>>>> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
>>>>> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
>>>>> chaque fois un fichier unique et si oui, comment ?
>>>> même remarque que précédemment.
>>>>
>>>>> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
>>>>> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
>>>>> avant de faire un backup log et si oui de quelle manière car si je crée un
>>>>> fichier texte que je renomme en .bak, ça ne fct pas non plus.
>>>> non, et sans le texte de l'erreur, difficile de vous répondre !
>>>>
>>>>> Un grand merci d'avance pour votre aide :-)
>>>> A +
>>>>
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> *********************** http://www.sqlspot.com *************************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> *********************** http://www.sqlspot.com *************************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Fred a écrit :
> Ok ... pas simple.
>
> Juste une chose c'est que vu l'allure à laquelle mon super fichier grandit,
> ça va être difficilement gérable. Je préférerais avoir un super fichier par
> semaine par exemple. C'est possible ? Quel argument utiliser dans ce cas pour
> que cela se fasse de manière automatique au niveau du job ?
Dans la commande de backup rajouter un RETAIN DAYS. Il y a d'autres
options. Voir l'aide en ligne et faire des essais.
>
> Pour être sûre que j'ai bien compris les procédures de restore ...
> Admettons que je fais un full à 23h tous les soirs et un backup log toutes
> les 2 h.
> Disons que la DB se plante un matin à 9h30.
> Je regarde les headers et je vois que le dernier full a la position 8 et les
> backups des logs de transactions respectivement les positions 9, 10, 11, 12 &
> 13.
>
> Que devrais-je faire exactement ? Est-ce que le code suivant est bon ? Dans
> la doc MSDN j'ai vu que la dernière cmd fait "un restore total" avec
> recovery. C'est ce que je devrais faire ?
>
> RESTORE DATABASE SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 8
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 9
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 10
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 11
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 12
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 13
> NORECOVERY
> GO
> RESTORE DATABASE SysAid
> WITH RECOVERY
C'est exactement cela. Parfait !
>
> Mais après tout je me demande quel est l'avantage de créer un device vu que
> la procédure est aussi longue ... ?
Avec des fichiers diparatre le risque est grand d'en perdre un et donc
de ne pas pouvoir restaurer !
A +
>
> Encore merci pour votre aide !
>
>
>
>
>
> "Fred BROUARD" a écrit :
>
>> re bonjour,
>>
>> Fred a écrit :
>>> Merci bcp. Voilà ce que j'ai donc fait :
>>>
>>> 1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
>>> '\serverbackupsqlSysAid_full.bak'
>>>
>>> Completed successfully
>>>
>>> 2) backup database sysaid to SYSAID_BACKUPS
>>>
>>> Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
>>> Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
>>> BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
>>> MB/sec).
>>>
>>> 3) backup log sysaid to SYSAID_BACKUPS
>>>
>>> Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
>>> BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
>>>
>>> 4) backup log sysaid to SYSAID_BACKUPS
>>>
>>> Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
>>> BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
>>>
>>> 5) restore headeronly from SYSAID_BACKUPS
>>>
>>> Je vois bien toutes les actions entreprises.
>> DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
>>
>>> Est-ce que c'est normal que je voie au niveau de \serverbackupsql
>>> uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
>> oui ce fichier est un device, c'est à dire un super fichier contenant
>> vos différentes suavegardes
>>
>>> Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
>>> le point 2) une fois par jour
>> oui
>>
>>> et un autre job avec le point 3) toutes les heures ?
>> oui
>>
>>> En cas de crash, on fait simplement ...
>>>
>>> RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
>> non, impossible. Je vous explique brièvement pourquoi (mais en général
>> on passe 3 heures en cours d'admin pour en développer toutes les
>> hypothèses).
>> Tout simplement parce que le système ne peut pas savoir à votre place
>> quel type de crash (logique, physique, fonctionnel...) vous avez eu.
>> Et comme il ne le peut pas, la logique de restauration sera différente
>> en fonction de votre problématique.
>>
>> Maintenant pour savoir ce que contient votre super fichier, vous pouvez
>> faire les requêtes suivantes :
>> RESTORE HEADERONLY
>> FROM SYSAID_BACKUPS
>> ceci vous donnera la liste des sauvegardes empilées
>> Si vous regardez bien, dans les informations retournées il y a un N° de
>> séquence des différentes sauvegardes (colonne Position).
>>
>> A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
>> jeu à l'aide de :
>> RESTORE HEADERONLY
>> FROM SYSAID_BACKUPS
>> WITH FILE = ?
>> Et remplacer ? par le n° de fichier souhaité
>>
>> Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
>> 1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
>> c'est la dernière à passer
>> 2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
>> mode NORECOVERY, sauf si c'est la dernière à passer
>> 3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
>> NORECOVERY, sauf si c'est la dernière à passer
>>
>> Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
>> faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
>> production.
>> Vous devez comprendre donc que seule la dernière restauration de votre
>> stratégie doit être en RECOVERY, les autres non.
>> De plus respectez bien le séquencemment, car une sauvegarde de perdu et
>> c'est fini, vous ne pouvez plus restaurer.
>>
>> Autrement dit : testez votre plan de sauvegarde en montant une maquette
>> de restauration.
>> Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
>> stratégie de sauvegarde par rapport aux problématique de restauration :
>> a) en combien de temps allez vous pouivoir restaurer la base ?
>> b) quel voulume de données pouvez vous sacrifier ?
>>
>> Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
>> doivent aussi être sauvegardées) prenez celle que j'ai écrite :
>> http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
>>
>> A +
>>
>>
>>> Mille mercis pour votre aide en tout cas, elle m'a été très utile.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Fred a écrit :
>>>>> Bonjour,
>>>>> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
>>>>> les backups.
>>>>> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
>>>>> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
>>>>> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
>>>>> qui n'est pas le cas.
>>>> C'est parce que vous n'avez pas compris la notion de support.
>>>> Un support est une unité de sauvegarde comme une bande ou un fichier.
>>>> La commande INIT supprime le contenu du support, mais pas le support lui
>>>> même. Il faut comprendre que dans un device (unité de sauvegarde) vous
>>>> pouvez empiler plusieurs sauvegardes.
>>>> Lisez l'article que j'ai écrit à ce sujet :
>>>> http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
>>>> Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
>>>> INIT ne servira à rien. La commande INIT est une comande logique. Si
>>>> vous voulez de la suppression physique de fichier il faut agir avec une
>>>> commande OS comme DEL.
>>>>
>>>>> Là où tous les backups sont faits je vois chaque jour un fichier du type
>>>>> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
>>>>> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
>>>>> censé faire ??
>>>>>
>>>>> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
>>>>> to disk = '\serverbackupsqlsysaid_log.bak') sans arguments ... et là je
>>>>> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
>>>>> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
>>>>> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
>>>>> chaque fois un fichier unique et si oui, comment ?
>>>> même remarque que précédemment.
>>>>
>>>>> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
>>>>> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
>>>>> avant de faire un backup log et si oui de quelle manière car si je crée un
>>>>> fichier texte que je renomme en .bak, ça ne fct pas non plus.
>>>> non, et sans le texte de l'erreur, difficile de vous répondre !
>>>>
>>>>> Un grand merci d'avance pour votre aide :-)
>>>> A +
>>>>
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> *********************** http://www.sqlspot.com *************************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> *********************** http://www.sqlspot.com *************************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Fred a écrit :
> Ok ... pas simple.
>
> Juste une chose c'est que vu l'allure à laquelle mon super fichier grandit,
> ça va être difficilement gérable. Je préférerais avoir un super fichier par
> semaine par exemple. C'est possible ? Quel argument utiliser dans ce cas pour
> que cela se fasse de manière automatique au niveau du job ?
Dans la commande de backup rajouter un RETAIN DAYS. Il y a d'autres
options. Voir l'aide en ligne et faire des essais.
>
> Pour être sûre que j'ai bien compris les procédures de restore ...
> Admettons que je fais un full à 23h tous les soirs et un backup log toutes
> les 2 h.
> Disons que la DB se plante un matin à 9h30.
> Je regarde les headers et je vois que le dernier full a la position 8 et les
> backups des logs de transactions respectivement les positions 9, 10, 11, 12 &
> 13.
>
> Que devrais-je faire exactement ? Est-ce que le code suivant est bon ? Dans
> la doc MSDN j'ai vu que la dernière cmd fait "un restore total" avec
> recovery. C'est ce que je devrais faire ?
>
> RESTORE DATABASE SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 8
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 9
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 10
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 11
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 12
> NORECOVERY
> GO
> RESTORE LOG SysAid
> FROM SYSAID_BACKUPS
> WITH FILE = 13
> NORECOVERY
> GO
> RESTORE DATABASE SysAid
> WITH RECOVERY
C'est exactement cela. Parfait !
>
> Mais après tout je me demande quel est l'avantage de créer un device vu que
> la procédure est aussi longue ... ?
Avec des fichiers diparatre le risque est grand d'en perdre un et donc
de ne pas pouvoir restaurer !
A +
>
> Encore merci pour votre aide !
>
>
>
>
>
> "Fred BROUARD" a écrit :
>
>> re bonjour,
>>
>> Fred a écrit :
>>> Merci bcp. Voilà ce que j'ai donc fait :
>>>
>>> 1) exec sp_addumpdevice 'disk', 'SYSAID_BACKUPS',
>>> 'serverbackupsqlSysAid_full.bak'
>>>
>>> Completed successfully
>>>
>>> 2) backup database sysaid to SYSAID_BACKUPS
>>>
>>> Processed 34920 pages for database 'sysaid', file 'sysaid' on file 1.
>>> Processed 6 pages for database 'sysaid', file 'sysaid_log' on file 1.
>>> BACKUP DATABASE successfully processed 34926 pages in 43.821 seconds (6.529
>>> MB/sec).
>>>
>>> 3) backup log sysaid to SYSAID_BACKUPS
>>>
>>> Processed 3227 pages for database 'sysaid', file 'sysaid_log' on file 2.
>>> BACKUP LOG successfully processed 3227 pages in 4.922 seconds (5.370 MB/sec).
>>>
>>> 4) backup log sysaid to SYSAID_BACKUPS
>>>
>>> Processed 0 pages for database 'sysaid', file 'sysaid_log' on file 3.
>>> BACKUP LOG successfully processed 0 pages in 0.414 seconds (0.000 MB/sec).
>>>
>>> 5) restore headeronly from SYSAID_BACKUPS
>>>
>>> Je vois bien toutes les actions entreprises.
>> DOnc vous avez empilé toutes vos sauvegardes dans un même device. On est OK
>>
>>> Est-ce que c'est normal que je voie au niveau de serverbackupsql
>>> uniquement le sysaid_full.bak et que je ne voie pas les fichiers logs ?
>> oui ce fichier est un device, c'est à dire un super fichier contenant
>> vos différentes suavegardes
>>
>>> Comme c'est une DB fort sollicitée, serait-il opportun de faire un job avec
>>> le point 2) une fois par jour
>> oui
>>
>>> et un autre job avec le point 3) toutes les heures ?
>> oui
>>
>>> En cas de crash, on fait simplement ...
>>>
>>> RESTORE DATABASE Sysaid FROM SYSAID_BACKUPS ???
>> non, impossible. Je vous explique brièvement pourquoi (mais en général
>> on passe 3 heures en cours d'admin pour en développer toutes les
>> hypothèses).
>> Tout simplement parce que le système ne peut pas savoir à votre place
>> quel type de crash (logique, physique, fonctionnel...) vous avez eu.
>> Et comme il ne le peut pas, la logique de restauration sera différente
>> en fonction de votre problématique.
>>
>> Maintenant pour savoir ce que contient votre super fichier, vous pouvez
>> faire les requêtes suivantes :
>> RESTORE HEADERONLY
>> FROM SYSAID_BACKUPS
>> ceci vous donnera la liste des sauvegardes empilées
>> Si vous regardez bien, dans les informations retournées il y a un N° de
>> séquence des différentes sauvegardes (colonne Position).
>>
>> A partir de ce n°, vous pouvez lire le contenu d'une des sauvegardes du
>> jeu à l'aide de :
>> RESTORE HEADERONLY
>> FROM SYSAID_BACKUPS
>> WITH FILE = ?
>> Et remplacer ? par le n° de fichier souhaité
>>
>> Maintenant, pour restaurer il faudra aussi tenir compte de ce n°
>> 1) Commencez toujours par une complète et en mode NORECOVERY, sauf si
>> c'est la dernière à passer
>> 2) Ajoutez la dernière sauvegarde différentielle s'il y en as une, en
>> mode NORECOVERY, sauf si c'est la dernière à passer
>> 3) Ajoutez toutes les sauvegardes de journaux, séquentiellement en mode
>> NORECOVERY, sauf si c'est la dernière à passer
>>
>> Le mode NORECOVERY dit à SQL Server : je te donne une restauration à
>> faire, mais comme ce n'est pas la dernière, ne met pas encore la base en
>> production.
>> Vous devez comprendre donc que seule la dernière restauration de votre
>> stratégie doit être en RECOVERY, les autres non.
>> De plus respectez bien le séquencemment, car une sauvegarde de perdu et
>> c'est fini, vous ne pouvez plus restaurer.
>>
>> Autrement dit : testez votre plan de sauvegarde en montant une maquette
>> de restauration.
>> Dans mes cours à Orsys (Admin) je dit toujours qu'il faut élaborer sa
>> stratégie de sauvegarde par rapport aux problématique de restauration :
>> a) en combien de temps allez vous pouivoir restaurer la base ?
>> b) quel voulume de données pouvez vous sacrifier ?
>>
>> Si vous voulez une procédure qui sauvegarde tout (les bases sytèmes
>> doivent aussi être sauvegardées) prenez celle que j'ai écrite :
>> http://blog.developpez.com/sqlpro?title=sauvegarder_toutes_les_bases_de_donnees
>>
>> A +
>>
>>
>>> Mille mercis pour votre aide en tout cas, elle m'a été très utile.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Fred a écrit :
>>>>> Bonjour,
>>>>> J'aurais 2-3 questions relatives aux arguments que l'on peut utiliser pour
>>>>> les backups.
>>>>> J'ai une DB (full recovery model) pour laquelle j'ai créé un job effectuant
>>>>> un full backup quotidien dans lequel j'ai mis comme argument WITH INIT. Dans
>>>>> la doc, je lis que dans ces circonstances le backup devrait être écrasé, ce
>>>>> qui n'est pas le cas.
>>>> C'est parce que vous n'avez pas compris la notion de support.
>>>> Un support est une unité de sauvegarde comme une bande ou un fichier.
>>>> La commande INIT supprime le contenu du support, mais pas le support lui
>>>> même. Il faut comprendre que dans un device (unité de sauvegarde) vous
>>>> pouvez empiler plusieurs sauvegardes.
>>>> Lisez l'article que j'ai écrit à ce sujet :
>>>> http://blog.developpez.com/sqlpro?titleÞ_l_interet_des_devices_pour_les_sauveg
>>>> Si pour chaque sauvegarde vous générez un nouveau fichier, la commande
>>>> INIT ne servira à rien. La commande INIT est une comande logique. Si
>>>> vous voulez de la suppression physique de fichier il faut agir avec une
>>>> commande OS comme DEL.
>>>>
>>>>> Là où tous les backups sont faits je vois chaque jour un fichier du type
>>>>> SysAid_backup_200812102125.bak ce qui n'est en soi pas une mauvais chose ...
>>>>> ce que je me demande c'est pourquoi le WITH INIT ne fait pas ce qu'il est
>>>>> censé faire ??
>>>>>
>>>>> Autre point : il y a un aute job qui fait un backup log (backup log sysaid
>>>>> to disk = 'serverbackupsqlsysaid_log.bak') sans arguments ... et là je
>>>>> vois que mon fichier est seul et qu'il fait pratiquement 20GB donc
>>>>> apparemment il y a un appennd chaque fois que la cmd est exécutée ... que se
>>>>> passerait-il en cas de restore ? Ne faudrait-il pas modifier la cmd pour voir
>>>>> chaque fois un fichier unique et si oui, comment ?
>>>> même remarque que précédemment.
>>>>
>>>>> Dernier point : j'ai voulu créer un backup log chez un autre client mais il
>>>>> me retourne chaque fois une erreur. Le fichier de backup doit-il être créé
>>>>> avant de faire un backup log et si oui de quelle manière car si je crée un
>>>>> fichier texte que je renomme en .bak, ça ne fct pas non plus.
>>>> non, et sans le texte de l'erreur, difficile de vous répondre !
>>>>
>>>>> Un grand merci d'avance pour votre aide :-)
>>>> A +
>>>>
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> *********************** http://www.sqlspot.com *************************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> *********************** http://www.sqlspot.com *************************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************