Databasadministratörer är indelade i de som gör säkerhetskopior och de som ska säkerhetskopiera.
Den här artikeln beskriver den vanligaste säkerhetskopieringen av IB 1C med hjälp av MS-verktyg SQL Server 2008 R2, förklarar varför det ska göras på det här sättet och inte på annat sätt, och avlivade flera myter. Artikeln har många länkar till MS SQL-dokumentationen, den här artikeln är mer en översikt över säkerhetskopieringsmekanismer än en omfattande guide. Men för den som ställs inför denna uppgift för första gången ges enkla och steg-för-steg instruktioner som gäller enkla situationer. Artikeln är inte avsedd för administrationsguruer, gurus vet redan allt detta, men det antas att läsaren kan installera MS SQL Server själv och tvinga detta mirakel av fientlig teknologi att skapa en databas i hans tarmar, vilket han i sin tur är kunna tvinga att lagra 1C-data.
Jag anser att kommandot TSQL BACKUP DATABASE (och dess bror BACKUP LOG) är i princip det enda säkerhetskopieringsverktyget för 1C-databaser som använder MS SQL Server som DBMS. Varför? Låt oss titta på vilka metoder vi generellt har:
| Hur | Bra | Dåligt | Total |
| Ladda upp till dt | Mycket kompakt format. | Det tar lång tid att bilda, det kräver exklusiv åtkomst, det sparar inte obetydlig data (som användarinställningar i tidigare versioner), det tar lång tid att distribuera. | Detta är inte så mycket en säkerhetskopieringsmetod, utan ett sätt att överföra data från en miljö till en annan. Idealisk för smala kanaler. |
| Kopiera mdf- och ldf-filer | Ett mycket tydligt sätt för nybörjare. | Kräver frigivning av databasfiler från låset, och detta är möjligt om databasen är inaktiverad (take offline-kommandot innehållsmeny), kopplade från (koppla bort) eller bara stoppade servern. Uppenbarligen kommer användare inte att kunna arbeta just nu. | Det är vettigt att tillämpa den här metoden om och bara om ett fel redan har inträffat, så att när du försöker återställa åtminstone kunna återgå till det alternativ från vilket återställningen började. |
| Säkerhetskopiera med OS eller hypervisor | Ett bekvämt sätt för utvecklings- och testmiljöer. | Inte alltid vänlig med dataintegritet. resurskrävande sätt. | Kan ha begränsad applikation för utveckling. Det har ingen praktisk betydelse i matmiljön. |
| Säkerhetskopiering med MS SQL | Kräver inte stillestånd. Låter dig återställa ett konsekvent tillstånd till ett godtyckligt ögonblick, om du tar hand om det i förväg. Perfekt automatiserad. Sparar tid och andra resurser. | Inte särskilt kompakt. Inte alla vet hur man använder denna metod i den utsträckning som behövs. | För produktionsmiljöer - huvudverktyget. |
De största svårigheterna vid användning av säkerhetskopiering med hjälp av de inbyggda MS SQL-verktygen uppstår på grund av ett elementärt missförstånd av arbetsprinciperna. Detta förklaras dels av stor lättja, dels av avsaknaden av en enkel och begriplig förklaring på nivån "färdiga recept" (hmm, låt oss säga, jag har inte sett det), och situationen förvärras till och med av det mytologiska råd från "under-guru" på forumen. Jag vet inte vad jag ska göra med lathet, men jag ska försöka förklara grunderna för säkerhetskopiering.
För länge sedan, i en avlägsen galax, fanns en sådan produkt av ingenjörs- och redovisningstänkande som 1C: Enterprise 7.7. Tydligen på grund av det faktum att de första versionerna av 1C:Enterprise utvecklades för att använda det populära dbf-filformatet, lagrade dess SQL-version inte tillräckligt med information i databasen för att överväga MS SQL-säkerhetskopieringen som komplett, och även med varje förändring i strukturen, driftsförhållanden för den fullständiga återställningsmodellen, så du var tvungen att gå till olika knep för att få backupsystemet att utföra sin huvudfunktion. Men sedan version 8 kom ut har DBA:er äntligen kunnat slappna av. Med regelbundna säkerhetskopieringsverktyg kan du skapa ett komplett och komplett system av säkerhetskopior. Endast registreringsloggen och några småsaker som att ställa in positionen för formulär (i äldre versioner) ingår inte i säkerhetskopian, men denna förlust av dessa data påverkar inte systemets funktionalitet, även om det verkligen är korrekt och användbart för att göra säkerhetskopior av registreringsloggen.
Varför behöver vi en backup överhuvudtaget? Hm. Vid första anblicken är detta en konstig fråga. Tja, förmodligen för det första för att kunna distribuera en kopia av systemet och för det andra för att återställa systemet i händelse av fel? Jag håller med om det första, men det andra mötet är den första backupmyten.
Backup är den sista försvarslinjen för systemintegritet. Om databasadministratören måste återställa produktsystemet från säkerhetskopior betyder det att en hel del misstag i organisationen av arbetet har gjorts med stor sannolikhet. Du kan inte behandla säkerhetskopiering som det huvudsakliga sättet att säkerställa dataintegritet, nej, det är mer som ett brandsläckningssystem. Ett brandsläckningssystem krävs. Den måste vara konfigurerad, testad och fungerande. Men om det fungerade så är detta i sig en allvarlig nödsituation med många negativa konsekvenser.
För att säkerhetskopiering endast ska användas för "fredliga" ändamål, använd andra metoder för att säkerställa prestanda:
Beroende på systemtillgänglighetskrav och budgeten som tilldelats för dessa ändamål är det fullt möjligt att välja lösningar som minskar driftstopp och katastrofåterställning med 1-2 storleksordningar. Det finns ingen anledning att vara rädd för tillgänglighetsteknologier: de är enkla nog att lära sig på några dagar med grundläggande kunskaper om MS SQL.
Men trots allt är backup fortfarande nödvändig. Detta är samma reservfallskärm som du kan använda när alla andra flyktmetoder misslyckas. Men, som en riktig reservfallskärm, för detta:
Data i MS SQL lagras vanligtvis i datafiler (hädanefter är FD inte en vanlig förkortning, det kommer att finnas några fler inte särskilt vanliga förkortningar i denna artikel) med mdf- eller ndf-tillägg. Utöver dessa filer finns det även transaktionsloggar (LT), som lagras i filer med filtillägget ldf. Det är inte ovanligt att nybörjare administratörer är oansvariga och flippiga om VT, både när det gäller prestanda och lagringssäkerhet. Detta är ett mycket grovt misstag. Faktum är att tvärtom, om det finns ett pålitligt fungerande säkerhetskopieringssystem och mycket tid kan tilldelas för systemåterställning, kan du lagra data på en snabb, men extremt opålitlig RAID-0, men då bör VT lagras på en separat pålitlig och produktiv resurs (även om det skulle vara på RAID-1). Varför är det så? Låt oss ta en närmare titt. Reservera omedelbart att presentationen är något förenklad, men tillräckligt för en första förståelse.
FD lagrar data på sidor om 8 kilobyte (som kombineras till omfattningar på 64 kilobyte, men detta är inte nödvändigt). MS SQL garanterar inte att omedelbart efter att ha utfört kommandot för att ändra data, kommer dessa ändringar att falla in i FD. Nej, det är bara att sidan i minnet är markerad som "kräver att sparas". Om servern har tillräckligt med resurser kommer dessa data snart att finnas på disken. Dessutom fungerar servern "optimistiskt" och om dessa förändringar sker i en transaktion kan de mycket väl komma till disken innan transaktionen genomförs. Det vill säga i det allmänna fallet, aktivt arbete FD innehåller spridda bitar av oavslutade data och ofullständiga transaktioner för vilka det inte är känt om de kommer att annulleras eller begås. Det finns ett speciellt " CHECKPOINT "-kommando som säger åt servern att "just nu" spola all osparad data till disken, men omfattningen av detta kommando är ganska specifik. Det räcker med att säga att 1C inte använder det (jag har inte stött på det) och förstå att under drift är FD vanligtvis inte i ett konsekvent tillstånd.
För att hantera detta kaos behöver vi bara VT. Följande händelser skrivs till den:
All denna information är skriven som indikerar identifieraren för transaktionen där den inträffade och i tillräcklig volym för att förstå hur man går från tillståndet före denna operation till tillståndet efter denna operation och vice versa (undantaget är den bulkloggade återställningsmodellen) .
Det är viktigt att denna information skrivs till disken omedelbart. Tills informationen har registrerats i VT, anses kommandot inte vara utfört. I en normal situation, när storleken på VT är tillräcklig och när den inte är särskilt fragmenterad, skrivs poster till den sekventiellt i små poster (inte nödvändigtvis multiplar på 8 kb). Endast den data som verkligen behövs för återställning kommer in i transaktionsloggen. Särskilt Inte information om vilken begärantext som ledde till ändringar, vilken exekveringsplan denna begäran hade, vilken användare som startade den och annan information som är onödig för återställning tas emot. En uppfattning om transaktionsloggens datastruktur kan ges av frågan
Välj * från::fn_dblog(null,null)
På grund av det faktum att hårddiskar fungerar mycket mer effektivt med sekventiell skrivning än med en kaotisk ström av läs- och skrivkommandon, och på grund av att SQL-kommandon väntar till slutet av skrivningen till VT:n, uppstår följande rekommendation:
Om det finns ens den minsta möjlighet, bör VT:er i produktionsmiljön placeras på separata (från allt annat) fysiska medier, helst med en minimal åtkomsttid för sekventiell skrivning och med maximal tillförlitlighet. För enkla system RAID-1 är bra.
Om transaktionen avbryts kommer servern att returnera alla ändringar som redan gjorts till det tidigare tillståndet. Det är därför
Annullering av en transaktion i MS SQL Server varar vanligtvis jämförbar med den totala varaktigheten av datamodifieringsoperationer för själva transaktionen. Försök att inte avbryta transaktioner eller besluta att avbryta så tidigt som möjligt.
Om servern oväntat slutar fungera av någon anledning, kommer den, när den startas om, att analysera vilka data i FD som inte motsvarar ett konsekvent tillstånd (oinspelade men begångna transaktioner och inspelade men avbrutna transaktioner) och dessa data kommer att korrigeras. Därför, om du till exempel började bygga om indexen för en stor tabell och startade om servern, kommer det att ta lång tid att återställa denna transaktion när du startar om den, och det finns inget sätt att avbryta denna process.
Vad händer när JT har nått slutet av filen? Det är enkelt - om det finns ledigt utrymme i början, så börjar det skriva till det lediga utrymmet i början av filen tills ockuperad plats. Som ett ögla magnetband. Om det inte finns något utrymme i början, kommer servern vanligtvis att försöka expandera transaktionsloggfilen, medan den nya delen som tilldelas för servern är en ny virtuell transaktionsloggfil, som kan vara många i den fysiska transaktionsfilen, men detta räcker inte för säkerhetskopiering. Om servern misslyckas med att expandera filen (den tar slut på diskutrymme eller det är förbjudet att expandera VT i inställningarna), kommer den aktuella transaktionen att avbrytas med fel 9002.
Hoppsan. Och vad behöver göras så att det alltid finns en plats i ZhT? Det är här vi kommer till backupsystemet och återställningsmodellerna. För att avbryta transaktioner och för att återställa det korrekta tillståndet för servern i händelse av en plötslig avstängning, är det nödvändigt att lagra poster i LT, från början av den tidigaste öppna transaktionen. Detta minimum skrivs och lagras i JT Nödvändigtvis. Oavsett väder, serverinställningar och administratörens önskemål. Servern kan inte tillåta att denna information saknas. Därför, om du öppnar en transaktion i en session och utför olika åtgärder i andra, kan transaktionsloggen avslutas oväntat. Den tidigaste transaktionen kan identifieras med kommandot DBCC OPENTRAN. Men detta är bara det nödvändiga minimum av information. Vad som händer härnäst beror på återhämtningsmodeller. Det finns tre i SQL Server:
Det finns flera myter förknippade med återhämtningsmodeller.
Den bulkloggade modellen för 1C-databaser är nästan meningslös att använda, så vi kommer inte att överväga den vidare. Men valet mellan Full och Simple kommer att övervägas mer i detalj i nästa del.
Det finns tre typer av säkerhetskopior beroende på typen av formation:
Bli inte förvirrad här: en fullständig återställningsmodell och en fullständig säkerhetskopia är väsentligt olika saker. För att inte förväxla dem kommer jag nedan att använda engelska termer för återställningsmodellen och ryska termer för typer av säkerhetskopior.
Fullständig och differentiell kopia fungerar på samma sätt för Simple och Full. Säkerhetskopiering av transaktionslogg saknas helt i Simple.
Låter dig återställa tillståndet för databasen till en viss tidpunkt (till den då säkerhetskopieringen startades). Den består av en sökt kopia av den använda delen av datafilerna och den aktiva delen av transaktionsloggen för tiden medan säkerhetskopian skapades.
Lagrar sidor med data som har ändrats sedan den senaste fullständiga säkerhetskopieringen. När du återställer måste du först återställa en fullständig säkerhetskopia (i NORECOVERY-läge, exempel kommer att ges nedan), sedan kan du använda vilken som helst av de efterföljande differentiella kopiorna på den resulterande "tomma", men naturligtvis bara de som gjordes före nästa fullständig backup. Detta kan minska volymen avsevärt disk utrymme för att lagra säkerhetskopian.
Viktiga punkter:
Innehåller en kopia av VT för en viss period. Vanligtvis från ögonblicket av den sista RKZHT till bildandet av den nuvarande RKZHT. RCRT låter dig återställa tillståndet vid vilken som helst efterföljande tidpunkt, inkluderad i intervallet för den återställda säkerhetskopian, från en kopia som återställts i NORECOVERY-läge till vilken tidpunkt som helst som ingår i perioden för den återställda kopian av RT. När du skapar en säkerhetskopia med standardparametrar frigörs utrymmet i transaktionsloggfilen (fram till ögonblicket för den senaste öppna transaktionen).
Det är uppenbart att RKZhT inte är vettigt i Simple-modellen (då innehåller VT endast information från ögonblicket för den senaste oavslutade transaktionen).
När du använder RKZHT uppstår ett viktigt koncept - kontinuerlig kedja av RKZhT. Denna kedja kan avbrytas antingen genom att några av säkerhetskopiorna av denna kedja går förlorade, eller genom att byta databasen till Simple och vice versa.
Varning: En uppsättning RCST:er är i princip värdelös om det inte är en sammanhängande kedja, och starttiden för den senaste framgångsrika fullständiga eller differentiella säkerhetskopieringen måste vara inuti period av denna kedja.
Vanliga missuppfattningar och myter:
Låt det finnas en databas på 1000 GB. Varje dag växer databasen med 2 GB, samtidigt som den ändrar 10 GB gamla data. Gjorde följande säkerhetskopior
Med den här uppsättningen kan vi återställa data klockan 0:00 någon av dagarna från 1 februari till 14 februari. För att göra detta måste vi ta en fullständig kopia av F1 för veckan 1-7 februari eller en fullständig kopia av F2 för 8-14 februari, återställa den i NORECOVERY-läge och sedan använda en differentiell kopia av önskad dag.
Låt oss säga att vi har samma uppsättning fullständiga och differentiella säkerhetskopior som i föregående exempel. Utöver detta finns det följande RKZHT:
Notera:
I det enklaste fallet måste vi återställa:
Först kommer F2 att återställas, sedan D2.2, sedan RKZHT 6 till 13:13:13 den 10 februari. Men en betydande fördel med Full-modellen är att vi har ett val - att använda den senaste fullständiga eller differentiella kopian, eller INTE den senaste. Till exempel, om det upptäcktes att kopian av D2.2 var skadad och vi behöver återställa till ett ögonblick före 13:13:13 den 10 februari, då för Simple-modellen skulle detta innebära att vi bara kan återställa data till ögonblicket D2.1. Med Full - "DON" T PANIC" har vi följande alternativ:
Som du kan se ger den fullständiga modellen oss fler valmöjligheter.
Föreställ dig nu att vi är väldigt listiga. Och ett par dagar innan misslyckandet (13:13:13 10 februari) vet vi att det kommer att bli ett misslyckande. Vi återställer databasen från en fullständig säkerhetskopia på den angränsande servern, vilket lämnar möjligheten att rulla ut efterföljande tillstånd med differentiella kopior eller RKZHT, d.v.s. kvar i NORECOVERY-läge. Och varje gång omedelbart efter bildandet av RKZhT applicerar vi den på denna reservbas och lämnar den i NORECOVERY-läget. Wow! Varför, det kommer nu att ta oss bara 10-15 minuter att återställa databasen, istället för att återställa en enorm databas! Grattis, vi har återuppfunnit stocktransportmekanismen, ett av sätten att minska stilleståndstiden. Om du överför data på detta sätt inte en gång i en period, utan hela tiden, kommer spegling att visa sig, och om källbasen väntar tills spegelbasen uppdateras, är detta synkron spegling, om den inte väntar, då asynkron.
Du kan läsa mer om verktyg för hög tillgänglighet i hjälpen:
Du kan säkert hoppa över det här avsnittet om du är uttråkad av teori och längtar efter att testa säkerhetskopieringsinställningarna.
1C:Enterprise vet faktiskt inte hur man arbetar med filgrupper. Det finns en enda filgrupp och det är allt. Faktum är att en programmerare eller MS SQL-databasadministratör kan placera vissa tabeller, index eller till och med bitar av tabeller och index i separata filgrupper (i den enklaste versionen, i enskilda filer). Detta är nödvändigt antingen för att snabba upp åtkomsten till vissa data (att lägga dem på mycket snabba medier), eller vice versa, för att offra hastigheten för att lägga den på billigare media (till exempel lite använd men omfattande data). När du arbetar med filgrupper är det möjligt att göra säkerhetskopior av dem separat, och du kan också återställa dem separat, men du måste ta hänsyn till att alla filgrupper måste "fångas ikapp" till ett ögonblick genom att rulla RKZHT.
Om en person kontrollerar placeringen av data i olika filgrupper, när det finns flera filer i filgruppen, skjuter MS SQL Server data på dem oberoende av varandra (med en lika stor mängd filer kommer den att försöka jämnt). Ur tillämpningssynpunkt används detta för att parallellisera I/O-operationer. Och när det gäller säkerhetskopiering finns det en annan poäng. För mycket stora databaser i "pre-SQL 2008"-eran var det ett typiskt problem att tilldela ett kontinuerligt fönster för en fullständig säkerhetskopiering, och måldisken för denna säkerhetskopia kanske helt enkelt inte passade den. av de flesta på ett enkelt sätt i det här fallet var det att göra en säkerhetskopia av varje fil (eller filgrupp) i sitt eget fönster. Nu, med den aktiva spridningen av backup-komprimering, har detta problem blivit mindre, men fortfarande kan denna teknik komma ihåg.
MS SQL Server 2008 har en super-mega-ultra-funktion. Från och med nu kan säkerhetskopior komprimeras i farten. Detta minskar storleken på 1C-databassäkerhetskopieringen med 5-10 gånger. Och med tanke på att oftast prestanda diskundersystemär en flaskhals i DBMS, minskar detta inte bara kostnaden för lagring, utan också en kraftfull backupacceleration (även om belastningen på processorerna ökar, men vanligtvis är processorkraften ganska tillräcklig på DBMS-servern).
Om den här funktionen i version 2008 endast var för Enterprise-utgåvan (vilket är mycket dyr), så gavs denna funktion 2008 R2 till standardversionen, vilket är mycket glädjande.
Kompressionsinställningar täcks inte av exemplen nedan, men jag rekommenderar starkt att du använder säkerhetskopieringskomprimering om det inte finns en särskild anledning att stänga av den.
Faktum är att en säkerhetskopia inte bara är en fil, det är en ganska komplex behållare som kan lagra många säkerhetskopior. Detta tillvägagångssätt har en mycket gammal historia (jag har personligen observerat det sedan version 6.5), men för närvarande finns det inga allvarliga skäl för administratörer av "vanliga" databaser, särskilt 1C-databaser, att inte använda "en säkerhetskopia - en fil" tillvägagångssätt . För allmän utveckling är det användbart att studera möjligheten att lägga flera säkerhetskopior i en fil, men troligtvis behöver du inte använda den (eller om du måste, sedan sortera igenom blockeringarna för en blivande administratör som använde denna möjlighet okvalificerad).
SQL Server har en annan bra funktion. Det är möjligt att göra en säkerhetskopia parallellt med flera mottagare. Som ett enkelt exempel kan du dumpa en kopia till en lokal disk och samtidigt dumpa till nätverksresurs. Den lokala kopian är bekväm, eftersom återställning från den är mycket snabbare, medan fjärrkopian mycket bättre kan överleva den fysiska förstörelsen av huvuddatabasservern.
Nog med teori. Det är dags att bevisa med övning att hela det här köket fungerar.
Denna sektion är uppbyggd i form av färdiga recept med förklaringar. Det här avsnittet är väldigt tråkigt och långt på grund av bilderna, så du kan hoppa över det.
Frågan uppstår genast, vad mer behövs? Det verkar som att allt precis har ställts in och allt fungerar som en klocka? Varför slita med alla möjliga manus? Serviceplaner tillåter inte:
Följande är typiska backup-kommandon
Fullständig säkerhetskopiering med överskrivning av befintlig fil (om någon) och verifiering av sidkontrollsummor före skrivning. När du skapar en säkerhetskopia räknas varje procent av framstegen
BACKUP DATABAS TILL DISK = N"C:\Backup\mydb.bak" MED INIT, FORMAT, STATISTIK = 1, CHECKSUMMA
Likaså - differentiell kopia
BACKUP DATABAS TILL DISK = N"C:\Backup\mydb.diff" MED DIFFERENTIELL, INIT, FORMAT, STATISTIK = 1, KONTROLLSUMMA
Säkerhetskopiering av transaktionslogg
BACKUP LOGG TILL DISK = N"C:\Backup\mydb.trn" MED INIT, FORMAT
Det är ofta bekvämt att inte göra en säkerhetskopia på en gång utan två. Till exempel kan man ligga lokalt på servern (så att den är till hands), och den andra formas omedelbart till en fysiskt avlägsen och skyddad från negativ lagringslagring:
BACKUP DATABAS TILL DISK = N"C:\Backup\mydb.bak", SPEGEL TILL DISK = N"\\safe-server\backup\mydb.bak" MED INIT, FORMAT
En viktig punkt som ofta förbises: användaren under vilken MSSQL Server-processen startas måste ha tillgång till resursen "\\safe-server\backup\", annars misslyckas kopian. Om MSSQL Server körs på uppdrag av systemet, måste åtkomst ges till domänanvändaren "server_name$", men det är fortfarande bättre att korrekt konfigurera MS SQL för att köras på uppdrag av en speciellt skapad användare.
Om du inte anger SPEGLING TILL så blir det inte 2 spegelkopior, utan en kopia, uppdelad i 2 filer, enligt stripingprincipen. Och var och en av dem individuellt kommer att vara värdelösa.
Databasservrar är en av de viktigaste i alla organisationer. Det är de som lagrar information och ger utdata på begäran, och det är oerhört viktigt att spara databasen i alla situationer. Den grundläggande distributionen innehåller vanligtvis de nödvändiga verktygen, men en administratör som inte tidigare har stött på en databas kommer att behöva ta itu med arbetets egenheter under en tid för att säkerställa automatisering.
Till att börja med, låt oss ta reda på vad säkerhetskopior är i allmänhet. Databasservern är inte en vanlig skrivbordsapplikation, och för att säkerställa implementeringen av alla ACID-egenskaper (Atomic, Consistency, Isolated, Durable) används ett antal teknologier, och därför har det att skapa och återställa en databas från ett arkiv egna egenskaper. Det finns tre olika sätt att säkerhetskopiera data, var och en med sina egna för- och nackdelar.
Med en logisk, eller SQL, säkerhetskopia (pg_dump, mysqldump, SQLCMD), skapas en ögonblicksbild av innehållet i databasen, med hänsyn till transaktionsintegritet och sparas som en fil med SQL-kommandon (du kan välja hela databasen eller enskilda tabeller), med vilka du kan återskapa databasen på en annan server. Det tar tid (särskilt för stora databaser) att spara och återställa, så mycket ofta kan denna operation inte utföras och utförs under minimal belastning (till exempel på natten). Vid återställning måste administratören köra flera kommandon för att förbereda allt som behövs (skapa en tom databas, konton Och så vidare).
Fysisk backup (nivå filsystem) - kopiera filer som DBMS använder för att lagra data i databasen. Men enkel kopiering ignorerar lås och transaktioner, som sannolikt kommer att vara felaktigt lagrade och trasiga. Om du försöker bifoga den här filen kommer den att vara i ett inkonsekvent tillstånd och kommer att resultera i fel. För att få en uppdaterad säkerhetskopia måste databasen stoppas (du kan minska stilleståndstiden genom att använda rsync två gånger - först på en körande, sedan på en stoppad). Nackdelen med denna metod är uppenbar - du kan inte återställa vissa data, bara hela databasen. När du startar en databas som återställts från ett filsystemarkiv måste du kontrollera integriteten. Här används olika hjälpmedel. Till exempel i PostgreSQL, WAL (Write Ahead Logs) loggar och speciell funktion(Point in Time Recovery - PITR), som låter dig återgå till ett specifikt tillstånd i databasen. Med deras hjälp är det tredje scenariot enkelt implementerat, när en säkerhetskopia på filsystemnivå kombineras med en WAL-filsäkerhetskopiering. Först återställer vi filsystemets säkerhetskopior, och sedan, med hjälp av WAL, uppdateras databasen. Detta är ett lite mer komplicerat tillvägagångssätt för administration, men det finns inga problem med databasens integritet och att återställa databaser till en viss tid.
En logisk säkerhetskopia används i de fall då det är nödvändigt att göra en engångskopia av databasen eller i vardagsbruk det inte tar mycket tid eller utrymme att skapa en kopia. När avlastning av databaser tar lång tid bör du vara uppmärksam på fysisk arkivering.
Licens: GNU GPL
DBMS som stöds: PostgreSQL
PostgreSQL stöder fysiska och logiska säkerhetskopieringsmöjligheter genom att lägga till ytterligare ett lager av WAL (se sidofältet) som kan kallas kontinuerlig säkerhetskopiering. Men att hantera flera servrar med standardverktyg är inte särskilt bekvämt även för en erfaren administratör, och i händelse av ett fel går räkningen till sekunder.
Barman (backup and recovery manager) är en intern utveckling av 2ndQuadrant, ett företag som tillhandahåller tjänster baserade på PostgreSQL. Designad för fysisk PostgreSQL-säkerhetskopiering (logisk stöder inte), WAL-arkivering och snabb återhämtning efter krascher. Stöder fjärrsäkerhetskopiering och återställning av flera servrar, punkt-i-tid-återställning (PITR), WAL-hantering. SSH används för att kopiera och utfärda kommandon till en fjärrvärd, synkronisering och säkerhetskopiering med rsync gör att du kan minska trafiken. Barman integrerar också med standardverktyg bzip2, gzip, tar och liknande. I princip kan du använda vilket komprimerings- och arkiveringsprogram som helst, integrationen tar inte mycket tid. Implementerat olika service- och diagnostiska funktioner som låter dig övervaka tjänsters status och justera bandbredden. Pre/Post-skript stöds.
Barman är skrivet i Python, och säkerhetskopieringspolicyer hanteras med den vänliga INI-filen barman.conf, som kan finnas i /etc eller användarens hemkatalog. I leveransen ingår en färdig mall med detaljerade kommentarer inuti. Fungerar endast på *nix-system. För installation på RHEL, CentOS och Scientific Linux måste du ansluta EPEL - ett arkiv som innehåller ytterligare paket. Debian/Ubuntu-användare har det officiella arkivet till sitt förfogande:
$ sudo apt-get install barman
Inte alltid i förvaret senaste versionen, för att installera det måste du hänvisa till källtexterna. Det finns få beroenden, och processen är lätt att ta reda på.
Licens: BSD
DBMS som stöds: MySQL
Tillsammans med MySQL levereras verktygen mysqldump och mysqlhotcopy, som gör att du enkelt kan skapa en databasdump, de är väldokumenterade och du kan hitta ett stort antal färdiga exempel och frontends på Internet. De senare gör det möjligt för nybörjaren att snabbt komma till jobbet. Sypex Dumper är ett PHP-skript som låter dig enkelt skapa och återställa en kopia av databasen MySQL-data. Designad för att fungera med stora databaser är den mycket snabb, tydlig och enkel att använda. Vet hur man arbetar med MySQL-objekt - vyer, procedurer, funktioner, triggers och händelser.
Ett annat plus, till skillnad från andra verktyg som konverterar till UTF-8 vid export, är att Dumper exporterar i inbyggd kodning. Den resulterande filen tar mindre utrymme och själva processen är snabbare. En dump kan innehålla objekt med olika kodningar. Dessutom är det lätt att importera / exportera i flera steg, vilket stoppar processen under laddningen. Vid omstart startar proceduren där den slutade. Det finns fyra alternativ för återställning:
Den stöder kopieringskomprimering (gzip eller bzip2), automatisk radering av gamla säkerhetskopior, visning av innehållet i dumpfilen, återställer endast strukturen för tabeller. Det finns även servicefunktioner för att hantera databasen (skapa, ta bort, kontrollera, återställa databasen, optimera, rensa tabeller, arbeta med index etc.), samt en filhanterare som låter dig kopiera filer till servern.
Hanteringen utförs med hjälp av en webbläsare, AJAX-gränssnittet är lokaliserat ur lådan och ger intrycket av att arbeta med en skrivbordsapplikation. Det är också möjligt att köra jobb från konsolen och enligt schema (via cron).
För att Dumper ska fungera behöver du en klassisk L|WAMP-server, installationen är gemensam för alla applikationer skrivna i PHP (kopiera filer och ange behörigheter), och det kommer inte att vara svårt även för en nybörjare. Projektet tillhandahåller detaljerad dokumentation och videohandledningar som visar hur man arbetar med Sypex Dumper.
Det finns två utgåvor: Sypex Dumper (gratis) och Pro ($10). Den andra har fler funktioner, alla skillnader listas på webbplatsen.
Licens:
DBMS som stöds: MS SQL Server
MS SQL Server är en av de populära lösningarna, och därför är det ganska vanligt. Säkerhetskopieringsjobbet skapas med SQL Server Management Studio, själva Transact-SQL och SQL PowerShell-modulens cmdlets (Backup-SqlDatabase). På MS-webbplatsen kan du bara hitta en enorm mängd dokumentation som låter dig förstå processen. Dokumentationen, även om den är komplett, är mycket specifik och information på Internet motsäger ofta varandra. En nybörjare kommer verkligen att behöva öva först, "fylla sin hand", därför, trots allt som har sagts, har tredjepartsutvecklare utrymme att vända sig om. Förutom gratis version SQL Server Express har inte inbyggda säkerhetskopieringsverktyg. För mer tidiga versioner MS SQL (före 2008) kan du hitta gratis verktyg, såsom SQL Server backup, men de flesta av dessa projekt har redan kommersialiserats, även om de ofta erbjuder all funktionalitet för en symbolisk summa.
Till exempel, utvecklingen av SQL Backup And FTP och One-Click SQL Restore följer set-and-forget-principen. Med ett mycket enkelt och intuitivt gränssnitt låter de dig skapa kopior av MS SQL Server (inklusive Express) och Azure-databaser, spara krypterade och komprimerade filer till FTP och molntjänster(Dropbox, Box, Google Drive, MS SkyDrive eller Amazon S3), kan resultatet ses omedelbart. Det är möjligt att starta processen både manuellt och enligt schemat, skicka ett meddelande om resultatet av uppgiften via e-post, starta användarskript.
Alla alternativ för säkerhetskopiering stöds: fullständig, differentiell, transaktionslogg, kopiering av en mapp med filer och mycket mer. Gamla säkerhetskopior raderas automatiskt. För att ansluta till den virtuella värden används SQL Management Studio, även om detta kan nyanseras och inte fungerar i alla sådana konfigurationer. Fem versioner erbjuds för nedladdning - från Fri till den tjusiga Prof Lifetime (endast $149 när detta skrivs). Gratis funktionalitet räcker för små nätverk, där en eller två SQL-servrar är installerade, är alla grundläggande funktioner aktiva. Antalet backupdatabaser, möjligheten att skicka filer till Google Drive och SkyDrive och filkryptering är begränsade. Gränssnittet, även om det inte är lokaliserat, är väldigt enkelt och förståeligt även för en nybörjare. Du behöver bara ansluta till SQL-servern, varefter en lista över databaser kommer att visas, du bör markera de du behöver, konfigurera åtkomst till fjärrresurser och ange tiden för uppgiften att slutföra. Och allt detta i ett fönster.
Men det finns ett "men". Programmet i sig är inte utformat för att återställa arkiv. För att göra detta erbjuds ett separat gratis One-Click SQL Restore-verktyg, som också förstår formatet som skapas av kommandot BACKUP DATABASE. Administratören behöver bara ange arkivet och servern som data ska återställas till och trycka på en knapp. Men i mer komplexa scenarier måste du använda RESTORE.
Att skapa en säkerhetskopia och återställa ett DBMS har sina egna skillnader som måste beaktas, särskilt när man överför ett arkiv till en annan server. Låt oss till exempel analysera några av nyanserna i MS SQL Server. För att arkivera med Transact-SQL, använd kommandot BACKUP DATABASE (det finns också ett delta DIFFERENTIAL-kommando) och BACKUP LOG transaktionsloggen.
Om säkerhetskopian distribueras på en annan server måste du se till att samma logiska enheter finns. Alternativt kan du manuellt ställa in rätt sökvägar för databasfilerna med alternativet MED FLYTTA i kommandot RESTORE DATABASE.
En enkel situation är säkerhetskopiering och överföring av databaser till andra versioner av SQL Server. Den här operationen stöds, men i fallet med SQL Server kommer den att fungera om versionen av servern som kopian distribueras på är densamma eller nyare än den som den skapades på. Och det finns en begränsning: inte mer än två nyare versioner. Efter återställning kommer databasen att vara i kompatibilitetsläge med versionen från vilken övergången gjordes, det vill säga nya funktioner kommer inte att vara tillgängliga. Detta är lätt att fixa genom att ändra COMPATIBILITY_LEVEL. Kan detta göras med GUI-hjälp eller SQL.
ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;
Du kan avgöra på vilken version kopian skapades genom att titta på arkivfilens rubrik. För att inte experimentera, när du byter till ny version SQL Server bör köra det kostnadsfria verktyget Microsoft Upgrade Advisor.
Licens: kommersiell, det finns en gratisversion
DBMS som stöds: Oracle 9-11, XE, MySQL, MariaDB, PostgreSQL och MS SQL Server
När du ska hantera flera typer av DBMS är skördetröskor oumbärliga. Valet är stort. Till exempel är Iperius ett lätt, mycket lättanvänt men ändå kraftfullt program för säkerhetskopiering av filer som har förmågan att säkerhetskopiera databaser utan avbrott eller blockering. Ger fullständig eller inkrementell backup. Kan skapa hela diskavbildningar för automatisk ominstallation av hela systemet. Stöder säkerhetskopiering till NAS, USB-enheter, streamer, FTP/FTPS, Google Drive, Dropbox och SkyDrive. Stöder zip-komprimering utan filstorleksbegränsning och AES256-kryptering, kör externa skript och program. Den innehåller en mycket funktionell uppgiftsschemaläggare, det är möjligt att utföra flera uppgifter parallellt eller sekventiellt, resultatet skickas till e-post. Många filter, variabler för att anpassa sökvägar och inställningar stöds.
FTP-uppladdningskapacitet gör det enkelt att uppdatera information på flera webbplatser. Öppna filer säkerhetskopieras med VSS-teknik (Volume Shadow Copy), som låter dig göra en het säkerhetskopiering av inte bara DBMS-filer utan även andra applikationer. För Oracle används även verktyget för säkerhetskopiering och återställning RMAN (Recovery Manager). För att inte överbelasta kanalen är det möjligt att justera bandbredden. Säkerhetskopiering och återställningshantering utförs med hjälp av den lokala konsolen och webbkonsolen. Alla funktioner är synliga, så för att ställa in en uppgift behöver du bara en förståelse för processen, du behöver inte ens titta i dokumentationen. Följ bara guidens instruktioner. Du kan också notera kontoansvarig, vilket är väldigt bekvämt med ett stort antal system.
Grundfunktioner erbjuds kostnadsfritt, men möjligheten till databasredundans ingår endast i Advanced DB- och Full-versionerna. Stöder installation från XP till Windows Server 2012.
Licens: en reklamfilm
DBMS som stöds: Oracle, MySQL, IBM DB2 (7–9.5) och MS SQL Server
Ett av de mest kraftfulla reär IBM DB2, som har unika skalbarhetsfunktioner och stöder många plattformar. Den levereras i flera upplagor, som är byggda på samma bas och skiljer sig funktionellt. Med DB2-databasarkitekturen kan du hantera nästan alla typer av data: dokument, XML, mediefiler och så vidare. Gratis DB2 Express-C är särskilt populärt. Säkerhetskopieringen är väldigt enkel:
db2 backup db exempel
Eller en ögonblicksbild med funktionen Advanced Copy Services (ACS):
db2 backup db exempel använd ögonblicksbild
Men vi måste komma ihåg att när det gäller ögonblicksbilder kan vi inte återställa (db2 recover db) enskilda tabeller. Det finns möjligheter till automatisk säkerhetskopiering, och mycket mer. Produkterna är väldokumenterade, även om manualer är sällsynta på det ryskspråkiga Internet. Dessutom kan inte alla speciallösningar hitta stöd för DB2.
Till exempel, Praktisk säkerhetskopiering låter dig säkerhetskopiera flera typer av databasservrar och spara filer på nästan alla media ( HDD, CD/DVD, moln och nätverkslagring, FTP/S, WebDAV och andra). Det är möjligt att säkerhetskopiera databaser via ODBC (endast tabeller). Det är en av få lösningar som stöder DB2 och har även logotypen "Ready for IBM DB2 Data Server Software". Hela proceduren utförs med en konventionell guide, där du bara behöver välja önskat objekt och skapa en uppgift. Själva installationsprocessen är så enkel att även en nybörjare kan lista ut det. Du kan skapa flera jobb som körs enligt ett schema. Resultatet loggas och skickas via e-post. Det är inte nödvändigt att stoppa tjänsten medan jobbet pågår. Arkivet komprimeras och krypteras automatiskt, vilket garanterar dess säkerhet.
Att arbeta med DB2 stöds av två versioner av Handy Backup - Office Expert (lokal) och Server Network (nätverk). Fungerar på datorer som kör Win8/7/Vista/XP eller 2012/2008/2003. Själva distributionsprocessen är inte svår för någon administratör.
Vi fortsätter att prata om backup och idag ska vi lära oss skapa ett arkiv Microsofts baser SQL Server 2008. Vi kommer att överväga allt som vanligt med exempel med både det grafiska gränssnittet och SQL-frågan, och vi kommer också att ställa in automatisk skapa en säkerhetskopia med hjälp av en batchfil.
Vi kommer inte att återkomma till frågan om vikten av säkerhetskopiering av databas, eftersom vi redan har tagit upp detta ämne mer än en gång, till exempel i materialet:
Och i den förra artikeln sa jag att vi kommer att överväga möjligheten att skapa ett arkiv på MS SQL Server 2008 DBMS, så nu ska vi göra just det.
Och eftersom det redan fanns mycket teori, låt oss omedelbart gå vidare till praktiken, nämligen att skapa en backupbas.
Notera! Som framgår av rubriken på artikeln kommer vi att göra arkivet på Microsoft SQL 2008 DBMS med Management Studio. Servern är lokaliserad. OS Windows 7.
Låt oss bestämma att vi ska göra ett arkiv av en testdatabas som heter "test". Från början till och med GUI, och i processen med detta kommer vi att skriva ett skript så att vi i framtiden helt enkelt kan köra det och inte längre distraheras av att ange alla typer av parametrar.
Öppna Management Studio, expandera « Databas» , välj önskad bas, klicka Högerklicka för musen över den, välj Uppgifter-> Säkerhetskopiering
Du kommer att se fönstret " Databas backup”, där du kan ställa in arkiveringsparametrar. Jag gav bara ett namn Säkerhetskopiering set", och ändrade även namnet på arkivet och sökvägen, eftersom det som standard kommer att skapas i mappen Programfiler, till exempel hade jag standardsökvägen
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\
Till exempel ändrade jag det till C:\temp\ och döpte arkivet test_arh.bak
Även om du går till fliken « alternativ», sedan kan du ställa in inställningen för att skriva över alla datamängder, nu ska jag förklara vad det är. Om du lämnar allt som det är, d.v.s. lägg till en befintlig datauppsättning, så kommer du att ha en backupfil, men med flera instanser av datauppsättningar, d.v.s. vid återställning väljer du helt enkelt den uppsättning du behöver. Och om du sätter " Skriv över alla befintliga säkerhetskopior”, då kommer uppsättningen alltid att vara densamma, då måste du i det här fallet skapa arkiv (låt oss säga dagliga) med olika namn. Jag ställer in den på att skriva över, för låt oss säga att jag i framtiden planerar att skapa arkiv för varje dag med datumet i namnet på dessa arkiv, för att snabbt kopiera säkerhetskopian jag behöver för ett visst datum till vilken plats som helst om det behövs .
Och förresten, vid det här laget, efter att ha angett alla parametrar, kan du skapa ett skript för att spela in det och använda det senare. För att göra detta klickar du bara på toppen Scenario».
Och som ett resultat av denna åtgärd kommer du att öppna ett frågefönster, där det kommer att finnas en kod för detta skript. Vi återkommer till det lite senare, men för nu klickar du på "OK" och efter att operationen är klar ser du ett fönster där resultatet av säkerhetskopieringen kommer att indikeras, om allt är bra kommer följande meddelande dyka upp
Om du har gjort allt enligt ovan de där. klickade på "Script"), då har du öppnat ett frågefönster, som faktiskt innehåller själva arkiveringsbegäran, men vi kommer att göra om det lite, eftersom jag sa att vi planerar att köra det varje dag, så att namnet är lämpligt, kommer vi att skriva detta SQL-sats.
DECLARE @path AS VARCHAR(200) SET @path = N"C:\temp\test_arh_" + CONVERT(varchar(10), getdate(), 104) + ".bak" BACKUP DATABAS TILL DISK = @sökväg MED NOFORMAT, INIT, NAME = N"Databastest", SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO
Och nu om vi kör det, då kommer vi att skapa en databassäkerhetskopiering med namnet test_arh_ Det aktuella datumet.bak
För dessa ändamål har MS SQL 2008 speciell möjlighet berättigad " Serviceplaner”, där du bara kan ställa in ett schema för att skapa en databassäkerhetskopiering, men jag föreslår att du använder en bat-fil för dessa ändamål för att ställa in den i schemaläggaren och få den att köras varje dag och säkerhetskopiera databasen.
För att göra detta, kopiera SQL-sats, som vi granskade ovan, och klistra in den i anteckningsblocket ( Jag rekommenderar Notepad++), spara sedan med förlängning .sql de där. detta skript kommer att köras på MS SQL 2008. Sedan måste vi skriva en batchfil så att den ansluter till SQL-servern och kör vårt skript. Skriv även i anteckningsblocket:
SET cur_date=%date:~6,4%%date:~3,2%%date:~0,2% osql -S localhost -i C:\temp\test.sql -o C:\temp\%cur_date %_log_sql.log -E
där jag skapade en cur_date-variabel för att lagra det aktuella datumet i den, sedan ansluter jag till lokal server, genom verktyget osql, som använder ODBC och kör vårt skript ( Jag kallade det test.sql), och även skriva en logg, var och precis vi behövde vår variabel, det är allt, spara med tillägget .fladdermus, vi skapar en uppgift i schemaläggaren och vi kan säga att vi glömmer processen att arkivera databasen, ja, vi kontrollerar bara regelbundet om arkivet har skapats eller inte.
För grunderna räcker detta, nu vet du hur du kan säkerhetskopiera databaser på en 2008 SQL-server, i nästa artikel kommer vi att titta på hur du kan återställa en databas på MS SQL Server 2008. Under tiden är det allt ! Lycka till!
Och även: SQL backup, 1C backup.
Server 1C innehåller data i databasen, som finns på SQL-servern. Idag överväger vi MS SQL 2005/2008.
För att säkerställa att data inte går förlorade i händelse av en bränd serverdisk eller andra force majeure-situationer är det nödvändigt att göra säkerhetskopior redan från början.
Naturligtvis vill ingen göra pennor varje dag Backup SQL-databas 1C. Det finns automatiska verktyg för detta. Låt oss lära känna dem.
Konfigurera BackupSQL
Att ställa in backup SQL för en 1C-databas skiljer sig inte från att ställa in en backup för någon annan databas.
För att konfigurera, kör MS SQL Management Studio. Detta program finns i MS SQL-programgruppen.
Lägga till ett 1C SQL databas backup jobb
Uppgifter för automatisk säkerhetskopiering av SQL-databaser finns i grenen Management/Maintenance Plans.
För att lägga till en ny säkerhetskopieringsuppgift högerklickar du på gruppen Underhållsplaner och väljer Ny underhållsplan.
Ange namnet på uppgiften. Namnet betyder bara för dig. För säkerhets skull är det bättre att använda engelska tecken.
Konfigurera en säkerhetskopieringsuppgift för 1C SQL-databas
Jobbredigeraren öppnas. Observera att jobb kan göra olika operationer med databasen, och inte bara säkerhetskopior.
Listan med alternativ för operationer visas längst ner till vänster. Välj Säkerhetskopiera databasuppgift genom att dubbelklicka eller helt enkelt dra åt höger.
Lägg märke till pilen. Du kan dra och släppa flera olika eller identiska operationer och länka dem med pilar. Sedan kommer flera uppgifter att utföras på en gång i den ordning du angett.
I inställningsfönstret väljer du de SQL 1C-databaser som krävs (du kan ha flera eller en åt gången).
Välj platsen för att spara säkerhetskopian av SQL 1C-databasen. Du måste välja en fysiskt annan hårddisk. Organisatoriskt kan du markera rutan "Skapa undermappar".
Låt oss nu ställa in säkerhetskopieringsschemat. Standardsäkerhetskopieringsschemat lades till av sig självt. Men du kan lägga till flera scheman (till exempel ett dagligt, ett varje vecka, etc.). Klicka på knappen för säkerhetskopieringsschemainställningar.
Skärmdumpen visar ett exempel på en daglig säkerhetskopiering av SQL-databas 1C kl. 03.00.
För att göra säkerhetskopieringsschemat i listan snyggt och begripligt kan du ändra det.
Sparar ett 1C SQL databas backup jobb
Klicka på bränna. Uppgiften kommer att visas till vänster i listan.
Det är viktigt! Kontrollera att backup SQL-databasuppgiften skapades korrekt. För att göra detta, högerklicka på uppgiften och välj Utför.
Som ett resultat bör en säkerhetskopia visas på den angivna sökvägen. Om något är fel, ta bort uppgiften (Del) och börja från början.
Låt oss överväga en oönskad situation. Nämligen: av någon anledning misslyckades databasen. Vad har vi? En fullständig kopia, en differentiell kopia för igår, men det finns också data för idag, var det verkligen nödvändigt att göra en differentiell kopia varje timme? - Nej! Äta Transaktionsloggen.
Transaktionsloggen är en logg som registrerar alla transaktioner och alla databasändringar som görs av varje transaktion. De där. alla åtgärder med databasen registreras steg för steg i loggen. Varje post markeras av DBMS för slutförandet av transaktionen, genomförd eller inte. Med dess hjälp kan du återställa tillståndet för databasen inte bara efter ett misslyckande, utan också vid oförutsedda åtgärder med data. Återställ till en viss tidpunkt. Liksom med databasen måste transaktionsloggen säkerhetskopieras, fullständig, differentiell, inkrementell. För att återställa en del av transaktionsloggen efter ett fel mellan säkerhetskopieringarna måste du säkerhetskopiera den sista delen av loggen, som i själva verket är slutpunkten för säkerhetskopieringen. Utförs efter en krasch, som en nedräkningspunkt.
Så för att återställa databasen efter en krasch behöver vi en uppdaterad fullständig kopia av databasen, en differentiell kopia av databasen och en kopia av transaktionsloggen.
För själva databasen finns det 3 återställningsmodeller - enkla, fullständiga och bulkloggade. Överväga:
Låt oss överväga den mest relevanta backupkedjan: Full backup - en gång i veckan, Differential backup - en gång om dagen, Transaktionslogg backup - en gång i timmen.
Det finns flera alternativ för att skapa säkerhetskopior:
Betrakta det första alternativet som det mest användbara. För detta används Windows Server 2008 R2 Enterprise och MS SQL Server 2008 Eng.
Så låt oss säga att vi har en TECH-databas:
Låt oss gå vidare till verktyget för att skapa jobb:
Tre höger musknappar och ring Master Job:
Vi markerar kryssrutan "Separat utförande av varje uppgift", vi utför bara en åtgärd
Mästaren är utan turban, men det viktigaste är inte storleken på turban)) Vi väljer önskad typ, i vårt fall - full reservation:
Mäster Joba, som det visade sig, är lite judisk, så han frågar igen:
"Det är värt att välja ytterligare alternativ, åh unge paddawan!":
här väljer vi databasen, backuplagringsperioden, adressen (band eller disk), sparsökvägen och, viktigast av allt, uppgiftsschemaläggaren!
"Glöm inte databasen när du väljer din. Koncentrera din makt och välj databasen":
"För snabbt du har bråttom att skapa en uppgift, klicka på knappen nedan med namnet Schema - Definiera".
Sobsno, uppgiftsschemaläggare, där vi väljer typ (upprepning, en gång, etc.), dag, tid, starttyp:
Det är allt, skapat. Mästare Joba är cool och grön. Vi tittar på tillståndet i underhållsplaner:
För den paranoida, var inte rädd för att erkänna det för spegeln, det är värt att titta in i själen hos SQL Server Agent - Job Activity Monitor, Job Master kommer att visa allt i detalj:
Nu, om de givna villkoren är uppfyllda, bör det skapa fullständig backup DB. Enligt samma princip skapas en differentiell backup och en transaktionslogg backup (dessa underpunkter finns under "Fullständig backup" i jobbvalslistan).
Vrid öronen med MSSQL som du vill, skruva inte loss
Nästa artikel tar upp skapandet med Transact-SQL och ett par exempel.
