Remote Backup er kompliceret. Vi vil forklare hvorfor og vise alle de tilgængelige muligheder for at lave sikkerhedskopierne alligevel.

ekstern server er en server, hvor du har begrænset adgang til serverens filsystem som i et delt hostingmiljø.
lokal server er en server, hvor du har fuld adgang til filsystemet som en lokal server, du fysisk kan få adgang til eller en dedikeret/virtuel server, som du har fuld kontrol over.

hvad er problemet med backup af eksterne servere?

hovedproblemet med eksterne servere er, at du kan køre scripts, herunder BACKUP DATABASE kommando, men adgang til den resulterende *.bak-filen er problematisk. Den *.bak-filen er placeret et sted på drevet lokalt til den pågældende server. Og hvis du ikke har adgang til denne placering, kan du ikke kopiere sikkerhedskopifilen til videre behandling som komprimering, kryptering, opbevaring osv. (flere detaljer om, hvad backup automation betyder) så er dine muligheder begrænset til at oprette en scriptfil.

BAK (*.bak) fil vs Script ( * .7168 >

BAK-filer er sikkerhedskopier oprettet ved hjælp af Microsofts standard BACKUP DATABASE kommando (eller via SSMS eller ). De får normalt *.bak udvidelse. Hvis du har mulighed for at oprette *.bak-filer-foretrækker det altid frem for alternativerne, fordi det giver dig mulighed for at gemme ikke kun fulde, men også differentielle og Transaktionslogbackups. Og formatet er det mest almindelige og ikke proprietært til nogen 3.part. Du kan gendanne fra ( * .bak) fil ved hjælp af standard Gendan DATABASE kommando og mange 3.parts værktøjer.

Script (*.filen er dybest set et sæt kommandoer, der genskaber databaseobjekterne og indsætter dataene i tabellerne. Fordelen ved at bruge en scriptfil er, at de fleste hostingmiljøer giver dig mulighed for at uploade scriptfiler og køre dem ved hjælp af et hosting administration Kontrolpanel. Derefter kan du gendanne en database uden at kræve, at noget installeres eller konfigureres af hosteren.

Dog Script (*.metode har følgende begrænsninger:

1. det tager meget længere tid at generere et script end at oprette en standard BAK type Server backup
2. et sådant script tager mere plads, da det er en tekstlig (ikke binær) repræsentation af din database, selvom det er meget mere komprimerbart end en binær backup.
3. det tager længere tid at gendanne en database fra et script, der fra en almindelig sikkerhedskopi
4. i modsætning til standardbackups indeholder scripts ikke transaktionslogoplysninger, så du ikke kan anvende point-in-time recovery
5. Scripting tager ikke altid hensyn til afhængigheder, så du kan få problemer under databasens rekreation

lokale SERVERBACKUPS

lokal server backup er veldokumenteret, og vi vil ikke komme ind i detaljerne i det her. Grundlæggende kører du BACKUP-DATABASEKOMMANDO, bruger Server Management Studio eller 3. parts værktøjer. Dette skaber en *.bak-fil på serverens lokale filsystem. Derefter komprimerer du normalt filen, krypterer den, uploader til et netværksdrev, FTP eller en sky osv. Du kan bygge dine brugerdefinerede scripts til at gøre det eller få det hele i et produkt som f.eks.

sikkerhedskopier af eksterne servere til en *.bak-fil på netværksdeling

hvis din eksterne server er på det samme netværk som dig og begge servere, og du har adgang til den samme netværksandel (som \ \ servername \ path), kan du på serveren sikkerhedskopiere til denne placering med kommandoen som:

BACKUP DATABASE dbname til DISK = N’\\servername\path\dbname.BAK ‘

og fra din egen computer ville du kunne få adgang til den samme placering, tage *.bak fil og gøre hvad du vil med det.

du kan skrive dine egne scripts for at automatisere det eller sikkerhedskopiere din netværksserver.

fordelen ved sikkerhedskopier til UNC sti er, at du får backup i samme eftertragtede *.bak format. Ulempen er dybest set relateret til behovet for at konfigurere adgangsrettigheder korrekt. Besøg linket ovenfor for detaljer om tilladelser.

sikkerhedskopier af eksterne servere til et script (*.fil

et genereret SERVERSCRIPT (*.backup-filen indeholder de oplysninger, der er nødvendige for at genskabe databasen på en fjerncomputer. Scriptet indeholder kommandoer til at genskabe databaseskemaet (tabeller, visninger, lagrede procedurer, udløsere, fuldtekstkataloger, roller, regler osv.) og dataene. Du har flere muligheder for at generere et script (*.

Scripting database med

dette er langt den enkleste metode til at sikkerhedskopiere dine eksterne databaser. Vælg blot “Remote server” som en servertype sæt loginoplysninger:

konfigurer derefter komprimering, kryptering, hvor du skal sende sikkerhedskopier, og hvor du skal sende e-mail-meddelelser. Se flere detaljer i Sådan sikkerhedskopieres ekstern SERVERDATABASE ved hjælp af SDK

Scripting database med SDK Server Management Studio (SSMS)

Bemærk, at dette fungerer som en ad hoc “backup”, men du kan ikke planlægge SSMS scripting. Sådan genererer du et databasescript med SSMS:

1. Åbn dine SSMS
2. Opret forbindelse til din eksterne server
3. Højreklik på den database, du vil sikkerhedskopiere, og vælg opgaver- > Generer Scripts. Dette åbner en guide
4. Hit Næste på Introduktionsskærmen
5. lad standard “Script hele databasen og databaseobjekter” være valgt og tryk Næste
6. Klik på knappen Avanceret og skift “typer af data til script” fra “kun skema” til “skema og data”. Tryk på OK
7. Vælg indstillingen “Gem i et nyt forespørgselsvindue” og tryk på Næste, Næste og afslut

Kopier scriptet til din lokale fil, og gem eller kør, hvor det er nødvendigt.

andre muligheder for ekstern backup af servere

hvis brug af ordet “backup” med hensyn til scripting var en ganske strækning, er de muligheder, der diskuteres i dette afsnit, endnu længere fra det, der anses for at være en “database backup”. Alligevel giver det dig mulighed for at få en kopi af dine data, derfor gennemgår vi også disse indstillinger

flytning af data med guiden Import og eksport af servere i SSMS

du kan bruge guiden Import og eksport af servere til at kopiere dataene fra den eksterne server til en lokal server. Bemærk, at det ikke kopierer alle databaseobjekter, men kun dataene. Vi kan ikke forestille os at bruge det som en hoved backup metode. Alligevel her instruktionerne:

1. åbn din SSMS
2. Opret forbindelse til din lokale server
3. Højreklik på den database, hvor sikkerhedskopierne skal gendannes, og vælg opgaver- > Importer data. Dette åbner en guide
4. Vælg “Native Client” som en datakilde og din eksterne server som et servernavn.
5. Vælg den database, du vil kopiere dataene fra. Næste.
6. Vælg “Native Client” som datakilde og din lokale server som servernavn.
7. Vælg den database, som dataene skal kopieres til. Næste.
8. Vælg de tabeller, der skal kopieres. Næste, Næste, Afslut