Komplett backup, inkl sql

[nessen]

Hei

Har satt opp ein server med Win2003 std, og Sql 2005 server.

Databasen inneholder masse data, frå bl.a Visma, Visma Lønn, Duett , etc.

 

Har installert Symantec Backup Exec som fulgte med Sony streameren.

 

Problem: Kvar gang den kjem til SQL filer så stopper backupen, pga at filene er låst/aktive.

 

Korleis skal eg klare å få tatt backup av SQL databasen når eg får denne meldinga?

 

Er det mulig å køyre eit script som "dumper" databasen til ei fil, som deretter kan kopieres?

 

Håper det er noen kloke(re) hoder her:)

[CrZy_T]

1. Kjøpe "Open file" add-on til Backup Exec

2. Dumpe databasen til fil og stoppe databaseservern mens backupen kjører.

[xcomiii]

Evt kan du jo sette opp en backupjobb inne i SQL 2005 Studio, kjør en Maintance Wizard og ta full backup lokalt på serveren. Så tar du backup av de filene SQL har laget (som da er ikke er bruk) og eksluderer de aktive SQL filene i backupen. Funker som et fly, kjapt er det og sammenligned med BE sin SQL agent.

[nessen]

Hei igjen:)

Har sett den funksjonen som er innebygd i MSSQL, men problemet der er då følgande:

 

Databasen ligger som \\server\visma

 

Inne i Visma igjen så ligger det 100vis av klient databaser som høyrer til Visma. Kvar gang ein ny kunde blir oppretta så legger det seg ein ny klient her. Eg finner ingen valg for å ta backup av HEILE visma delen, eg må i tilfelle klikke meg inn på kvar enkelt, og det tar uendelig lang tid..

Noen kloke hoder som klarer å løse det?

[xcomiii]

Bruker Visma på jobben sjøl og har aldri hørt om at Visma oppretter selv nye db når nye kunder kommer inn. Har du over 100 DB på en boks??? Det nekter jeg å tro

[nessen]

Hei igjen!

 

Eg vil helst ikkje tru det eg ser eg heller..Men slik er det:

 

Når eg går inn på MS SQL Server managment studio express, velger database, \\server\visma og åpner den.

På objekt explorer står det først \\server\visma

Under den står det "databases"

Når eg dobbelklikker på databases så kjem det opp 154 kataloger under databases.

Det som kjem opp ser ut til at det er ein katalog pr firma i visma...

 

Er det då ikkje mulig å få kopiert ut ALLE dei 154 i eit, istednefor å ta ei og ei mappe...?

[Leopal]

Hei,

 

Problemet med å bruke Maintainance-plan er at du må da stadig endre denne etter hvert som det kommer nye databaser (firma) i visma, det samme gjelder også for andre systemer av samme type (unimicro oppretter nye databaser for nye år pr klient f.eks)

 

Så derfor: siden dette er en backup job er det "lov" å bruke cursors i sql. cursorer er normalt sett et performance problem hvis de blir brukt hele tiden, men dette blir jo en jobb som skal gå en gang i døgnet, eller uken.. eller...så følgende Stored-Procedure fikser dette for deg.

 

den lager en cursor for alle databaser i serveren som ikke er system-databaser

looper igjennom den og tar backup til en fast mappe (som du må sette selv dit du vil ha det)

den lager en fil for hver database, med dato for backup som del av filnavnet.

 

--------------

 

CREATE PROC DoDatabaseBackup

AS

DECLARE @DBname VARCHAR(50)

DECLARE @Filepath VARCHAR(256)

DECLARE @FileName VARCHAR(256)

DECLARE @FileDate VARCHAR(20)

 

SET @FileDate =(SELECT CONVERT(VARCHAR(20),GETDATE(),112))

 

SET @Filepath = 'C:\SQLBACKUP\' --<- Bytte her for en katalog som finnes

 

DECLARE getDBName CURSOR FOR

SELECT name

FROM sys.databases

WHERE name NOT IN ('master','model','msdb','tempdb')

 

OPEN getDBName

FETCH NEXT FROM getDBName INTO @DBname

 

WHILE @@FETCH_STATUS = 0

BEGIN

SET @fileName = @Filepath + @DBname + '_' + @FileDate + '.BAK'

BACKUP DATABASE @DBname TO DISK = @fileName

FETCH NEXT FROM getDBName INTO @DBname

END

CLOSE getDBName

DEALLOCATE getDBName

 

------------------------

 

denne proceduren legger du så inn som en SCHEDULED-JOB under SQL-Server-Agent and viola..

 

nå kan du la backup-exec ta backup av C:\SQLBACKUP mappen, de filene er "detached" så de kan leses uten problem.

 

 

Skulle det være noe så spør

 

[email protected]

Endret 18. mars 2008 av Leopal

[Leopal]

Bare i tilfelle du / dere ikke vil bruke cursors, finnes det et par triks i 2005 som kan brukes i stedet for, nemlig row_number() funksjon og @table variabel og EXECUTE (@SqlCommand)

 

som i felleskap kan brukes på følgende måte:

(denne varianten oppretter in in-memory tabell som variabel, fyller den med databasenavn fra sys.databases og looper igjennom antallet for å bygge opp en SQL-Commando streng, som så eksekveres etterpå..Absolutt et godt alternativ til cursors)

 

CREATE PROC DoDatabaseBackup2

AS

SET NOCOUNT ON

declare @sqlstr varchar(MAX)

declare @userdbs int

declare @counter int

declare @fixedpath varchar(254)

 

declare @dbnames table (dbrow int,dbname varchar(254))

 

set @counter=1

set @sqlstr=''

set @fixedpath='C:\SQLBACKUP\'

 

insert into @dbnames

select row_number() over(order by name) as dbrow,name from sys.databases where name not in ('master','tempdb','model','msdb')

 

set @userdbs=@@rowcount

 

if @userdbs>0

begin

while @counter<=@userdbs

begin

select @sqlstr=@sqlstr+(select 'Backup database '+dbname+' to DISK = '''+@fixedpath+dbname+'_'+Convert(char(8),getdate(),112)+'.BAK'' ;'

from @dbnames where dbrow=@counter)

set @counter=@counter+1

end

end

 

EXECUTE (@sqlstr)

 

SET NOCOUNT OFF

 

Resultatet er det samme

[Fungus]

Har du sjekket med Visma leverandøren din hva de anbefaler av backup løsninger og rutiner ? Veldig mange software leverandører har egenutviklede små programmer for å ta backup av deres eget produkt, både med schedulering og truncing av baser.

[enden]

Bruker Visma på jobben sjøl og har aldri hørt om at Visma oppretter selv nye db når nye kunder kommer inn. Har du over 100 DB på en boks??? Det nekter jeg å tro

Det er da helt vanlig at man benytter en drøss med databaser i SQL-server. Alle Visma-installasjoner jeg har vært borti gjør i alle fall dette. Ikke bland det sammen med instanser eller installasjoner - det er noe helt annet

 

Ellers er det nok en god grunn til at Backup Exec feiler - det skal ikke være nødvendig med Open File add in for å ta backup av SQL 2005. Dette skal i alle fall nyere versjoner av BE klare fint av seg selv. Sjekk loggen til backupjobben og følg lenker til Symantec support (som egentlig er Vertas support, og derfor faktisk er hjelpsom i motsetning til Symantec...).

[harald_]

Jeg skulle veldig gjerne hatt et av scriptene til Leopal til å fungere - de ville gjort nøyaktig det jeg er ute etter (backup av en drøss databaser tilhørende UNI)

 

Men, når jeg har lagt til scriptet under Jobs i SQL server management studio og kjører det kommer det ingen filer til målmappen. Og andre gang jeg kjører scriptet avslutter det med feilmeldingen: "There is already an object named DoDatabaseBackup2 in the database"

 

Noen tips?

[kaffenils]

Jeg skulle veldig gjerne hatt et av scriptene til Leopal til å fungere - de ville gjort nøyaktig det jeg er ute etter (backup av en drøss databaser tilhørende UNI)

 

Men, når jeg har lagt til scriptet under Jobs i SQL server management studio og kjører det kommer det ingen filer til målmappen. Og andre gang jeg kjører scriptet avslutter det med feilmeldingen: "There is already an object named DoDatabaseBackup2 in the database"

 

Noen tips?

Du skal ikke kjøre CREATE PROCEDURE scriptet i jobben. CREATE PROCEDURE scriptet kjører du en gang. Opprett en egen database hvor du legger det.

 

Deretter oppretter du en sql agent job som kjører prosedyren: exec DoDatabaseBackup2.

 

I tillegg må bør du opprette en Maintenance Plan som sletter backupfiler som er eldre enn x dager.

 

Et problemer med dette scriptet er at det ikke tar backup av transaksjonloggene. Jeg regner med at databasene er satt til FULL RECOVERY, noe som gjør at transaksjonsloggene vil vokse i det "uendelige", dvs. inntil filene er fulle eller diskene er fulle. Du bør derfor lage en modifisert versjon av scriptet som tar backup av transaksjonsloggene og kjøre dette f.eks. en gang i timen.

 

Avhengig av størrelsen på databasene som det tas backup av bør du også vurdere differensiell backup. Dette kan redusere behovet for diskplass, spesielt hvis databasene er store. Du tar da f.eks. en ukentlig full backup, og daglig differensiell backup. I tillegg kommer selvfølgelig transaksjonslogbackupene.

Endret 11. desember 2009 av kaffenils

[kaffenils]

Hvis du ønsker enkelt overvåkning (disk, backup, sql agent jobber, filvekst etc) av serveren så kan du laste ned SQL H2 fra http://www.codeplex.com/sqlh2/.

[satheesh.net]

Hei!

Jeg bruker et program som heter SQLBackupAndFTP. Dette er gratis og kan dumpe SQL basen din til et nettverkshare, FTP eller annen mappe av eget ønske. På den måten kan du i hvert fall få kjørt en backup av basen på en enkel og grei måte.

 

Sjekk hjemmesiden deres eller her -> http://www.satheesh.net/?p=123

 

Lykke til...

[Lock-Aze]

Har ikke hatt problemer med å få kopiert SQL databaser med Backup Exec (kjører backup på en god del lokasjoner)men, hvis du ikke har kjøpt det, så må du nesten vurdere å kjøpe Advanced Open File til Backup Exec. Men, du kan høreklikke på jobben, gå inn på properties, ga under settings advanced. Der har du en opsjon som heter open file backup when advanced open file option is not in use. Klikk på with a lock. Men, det kan godt hende at en enkel måte å løse problemet ditt på rett og slett er å enten kjøpe advanced open file til symantec eller å stoppe databasen når du skal ta backup av den.

[Varj]

Advanced Open File Option har vært gratis i backup exec et par versjoner nå.

[LukasKasha]

Er det ikke mulig å bare bruke backup av rootmappa?

[Alte-to]

Tagger denne for å lese i morgen.. (via mobil sjø)

[conundrum]

Problem: Kvar gang den kjem til SQL filer så stopper backupen, pga at filene er låst/aktive.

 

Korleis skal eg klare å få tatt backup av SQL databasen når eg får denne meldinga?

Sånn jeg ser det, har du tre muligheter:

 

1. Gå til anskaffelse av Microsoft SQL Agent-opsjonen for Backup Exec (eller bruk et annet backupprogram)
   
2. Stopp SQL-tjenesten under backup
   
3. Bruk et SQL-script som tar SQL-backup av alle databasene i instansen (til filer)
   

Hver av disse løsningene har sine fordeler og ulemper.

 

Løsning 1 er den teknisk mest solide, da den gir mulighet for differensielle og inkrementelle backupjobber. Slike oppsett er ikke direkte vanlig å finne hos SMB-kunder (for å si det forsiktig), da backup typisk ikke tas oftere enn maksimalt 1 gang i døgnet og datamengdene vanligvis er små nok til at en full backup får plass på et enkelt backupmedie.

 

Løsning 2 er et overraskende godt alternativ for de som har enkle systemer (som Uni), anledning til å la databasen være utilgjengelig under backup, og ingen behov for delvis tilbakelegging av databasedata. Vær dog obs. på eventuelle brukerkontoer definert i SQL-instansen. De ligger ikke i applikasjonens databaser, men på selve instansen (f.eks. har Mamut og Visma slike). Ved restore til annen server/instans vil det være nødvendig å legge disse inn før du kobler opp databasefilene fra backupen.

 

Problemstillingen med løsning 3 og voksende/ukjent antall databaser, kan i MSSQL løses med den innebygde prosedyren sp_databases som lager en liste over alle databasene, eller man kan bruke sp_msForEachDB (men den er visst uoffisiell/udokumentert).

 

Som kaffenils nevnte vil løsning 2 og 3 ikke trunkere loggfilene for databasene, slik at de bare vil bli større og større hvis man ikke sletter manuelt. Dersom du ikke trenger denne funksjonen, kan du endre recovery-modus for databasene og omgå det problemet. Mange (om ikke de fleste) økonomi- og ordresystemer for SMB-markedet bruker ikke full recoverymodus som default.

 

NB: Det du for all del ikke må gjøre, er å anta at en alminnelig "open file option" kan brukes til å ta backup av databasefiler, enten det nå er SQL-databaser eller flatfil-løsninger. Dersom applikasjonen er i bruk mens backupjobben går, risikerer du at backupen er ubrukelig pga. inkonsistens mellom filene. Man bør alltid være nøye med å forsikre seg om at backupløsningen støtter det databasesystemet man bruker.

[enden]

Å ta backup i to etapper er et stygt hack jeg absolutt ikke liker. Backup Exec vil plukke opp backupfilene fra løsningen som tar SQL-backup uten å mukke. Hvis backup av SQL filer så driter BE i det, og fortsetter som før. Sørg for god overvåkning av SQL-backupen da, så dere ikke tror at alt er OK fordi BE sier det. Sett en del stygge tilfeller der.