plan de sauvegarde.

Version imprimable

05/07/2007, 12h55
ylarvor

plan de sauvegarde.

bonjour,

ci joint un article où l'on crée un plan de sauvegarde.

http://www.lmgharba.net/modules/smartsection/item.php?itemid=4

ma question, au bout de 2 semaines, les unites vont contenir 2 semaines de données ? les unites vont gonfle à l'infini avec un plan automatise par sql agent ? comment remettre à zéro les unités ?

merci de vos reponses.

je te joins un script que j'utilise pour mes backups que j'ai mis dans une PS
lancée par un travail

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
use Master
go
--drop table #BckDatabases
Create Table #BckDatabases (
  databasename sysname
)
Set nocount on 
declare @BckPath varchar(255)
declare @Prefix varchar(50)
declare @Extension varchar(10)
/****************************/
/*       Paramétrage        */
/****************************/
Set @BckPath = 'chemin_backup'
Set @Prefix  = cast(year(getdate() as varchar)+cast(month(getdate() as varchar)+cast(day(getdate() as varchar)
Set @Extension = '.bak'
 
  insert into #BckDatabases values('base1')
  insert into #BckDatabases values('base2')
  etc...  
/****************************/
PRINT ''
PRINT 'Liste des bases à Backuper :'
Select * from #BckDatabases
 
declare @CurrentDB sysname
declare @sql varchar(2000)
declare @fileName varchar(255)
 
Set nocount off
 
Declare curDB Cursor for
  Select databasename from #BckDatabases
 
open curDB
Fetch next from CurDB into @CurrentDB
while @@fetch_status = 0
begin
  Set @FileName = @bckPath +@Prefix +@CurrentDB + @Extension
  PRINT '===================================================================='
  PRINT '** '+@CurrentDB + ' Backup Started on '+Cast(GetDate() as Varchar)
  Set @sql = 'BACKUP DATABASE '+@CurrentDB + ' TO DISK=N'''+@filename+''''
  print @sql
  exec (@sql)
  PRINT '** '+@CurrentDB + ' Backup Ended on '+Cast(GetDate() as Varchar)
  PRINT '===================================================================='
  PRINT ''
  Fetch next from CurDB into @CurrentDB
end
deallocate CurDB
drop table #BckDatabases

tes sauvegardes s'appelleront
20070704_base1.bak
20070704_base2.bak
20070705_base1.bak
20070705_base2.bak
etc..
ensuite j'ai un travail qui supprime les fichiers dont la date est inférieure a 8 jours de la date du jour.

05/07/2007, 15h12
ylarvor

complement.

merci serge.

La sauvegarde est ma hantise dans mon futur metier de dba.

est ce que tu verifies l'existence de tes sauvegardes par une methode quelconque pour t'assurer que le travail s'est bien effectue? existe t'il une méthode pour être sûr de sa sauvegarde ?
05/07/2007, 15h22
serge0934

tu peux le faire en faisant un "restore verifyonly" après ta sauvegarde. En fait ce n'est pas une restauration mais juste une verif.

regardes
http://technet.microsoft.com/fr-fr/l.../ms188902.aspx
05/07/2007, 15h42
serge0934

etant dba depuis 1998 SYBASE au USA je te donnes quelques conseils de "vieux" (qui sont personnels et n'engagent que moi)

dans ton plan fais:

-reindexations des tables les plus usitées => DBCC DBREINDEX ...
-sauvegarde du journal de transaction ( et que lui !) après
-test place dispo sur tes devices
-test des jobs qui pourraient se lancer pendant ta sauvegarde
-compactage SANS replacement en tête de fichier
-sauvegarde de tes bases COMPLETES (les differentielles plantent toujours a la restauration sauf chez oracle :mouarf: )
-test avec VERIFYONLY
-zip des .bak
-archivages des bak d'un coté et des zip d'un autre (sur un disque DIFFERENT)

PS: attention si tu es sous RAID5, ne garde que le dernier journal de transaction, supprime (del) les anciens.
05/07/2007, 15h54
ylarvor

quelques questions ?

Citation:

dans ton plan fais:

-reindexations des tables les plus usitées => DBCC DBREINDEX ...
-sauvegarde du journal de transaction ( et que lui !) après
-test place dispo sur tes devices
-test des jobs qui pourraient se lancer pendant ta sauvegarde
-compactage SANS replacement en tête de fichier
-sauvegarde de tes bases COMPLETES (les differentielles plantent toujours a la restauration sauf chez oracle :mouarf: )
-test avec VERIFYONLY
-zip des .bak
-archivages des bak d'un coté et des zip d'un autre (sur un disque DIFFERENT)

compactage sans replacement en tete de fichier : que cela signifie t'il ?
05/07/2007, 17h37
rudib

Bonjour,

Juste pour insérer une info : quand tu crées un plan de sauvegarde avec l'assistant du même nom, tu peux indiquer une suppression des anciens jeux de sauvegarde après un certain délai.
06/07/2007, 08h36
serge0934

lorsque SQLserveur compacte, il "défragmente" ses fichiers (il rassemble tous les bouts qui traine par ci par là); mais tu peux lui dire aussi qu'il les range tous les uns après les autres. ex:

fichier1 de l'adresse 0x11111111 a 0x12111111
fichier2 de l'adresse 0x18011111 a 0x18111111
...

si tu lui dis de replacer en tête de fichier, il va faire des fichiers contigus

fichier1 de l'adresse 0x01111111 a 0x02111111
fichier2 de l'adresse 0x02111112 a 0x02811112
...

ce qui veut dire que si ton fichier1 augmente (requete d'insertion), SQLserveur ne pourra pas ranger les données a la suite, il sera obligé de fragmenter ;)

C'est pour cela que souvent lorsque l'on compacte comme je dis, on ne voit pas trop la taille de la base diminuer, mais par contre, elle est mieux "organisée".

j'espère être assez clair :oops:
06/07/2007, 11h29
ylarvor

Dbcc Shrinkdatabase

Lorsque tu parles de compacter, tu parles bien de l'instruction DBCC SHRINKDATABASE et DBCC SHRINKFILE ?