Нека разберем помощните програми за архивиране на база данни. SQL. Настройка на архивиране на Sql настройка на архивиране

Администраторите на бази данни се делят на такива, които правят архиви и такива, които ще правят архиви.

Въведение

Тази статия описва най-често срещаното IB 1C архивиране с помощта на MS инструменти SQL сървър 2008 R2, обяснява защо трябва да го направите по този начин, а не по друг начин, и разсейва няколко мита. Статията съдържа доста препратки към MS SQL документация; тази статия е по-скоро общ преглед на механизмите Резервно копиеотколкото изчерпателно ръководство. Но за тези, които се сблъскват с тази задача за първи път, просто и инструкции стъпка по стъпка, които се отнасят за прости ситуации. Статията не е предназначена за административни гурута, гурутата вече знаят всичко това, но се предполага, че читателят е в състояние сам да инсталира MS SQL Server и да принуди това чудо на враждебната технология да създаде база данни в нейните дълбини, което от своя страна е способен да принуди да съхранява 1C данни.

Смятам, че командата TSQL BACKUP DATABASE (и нейния брат BACKUP LOG) е по същество единственото средство за архивиране на 1C бази данни с помощта на MS SQL Server като СУБД. Защо? Нека да разгледаме какви методи обикновено имаме:

Основните трудности при използване на архивиране с помощта на вградени MS SQL инструменти възникват от основно неразбиране на принципите на работа. Това отчасти се обяснява с голям мързел, отчасти с липсата на просто и разбираемо обяснение на ниво „готови рецепти“ (хм, да кажем, че не съм срещал), а и ситуацията се утежнява по митологичните съвети на „underguru“ във форумите. Не знам какво да правя с мързела, но ще се опитам да обясня основите на архивирането.

Какво и защо спестяваме?

Преди много време, в далечна галактика, имаше такъв продукт на инженерната и счетоводна мисъл като 1C: Enterprise 7.7. Очевидно поради факта, че първите версии на 1C:Enterprise бяха разработени да използват популярния файлов формат dbf, неговата SQL версия не съхраняваше достатъчно информация в базата данни, за да се счита, че архивирането на MS SQL е завършено и дори при всяка промяна в структурата бяха нарушени условията на работа на модела за пълно възстановяване, така че беше необходимо да се положат различни усилия, за да се принуди системата за архивиране да изпълнява основната си функция. Но откакто излезе версия 8, администраторите на бази данни най-накрая успяха да се отпуснат. Създадени фондовеархивирането ви позволява да създадете цялостна и холистична система за архивиране. Само дневникът и някои малки неща като настройки за позицията на формулярите (в по-старите версии) не са включени в архива, но загубата на тези данни не засяга функционалността на системата, въпреки че със сигурност е правилно и полезно да направете резервни копия на бордовия дневник.

Защо изобщо имаме нужда от резервно копие? хм На пръв поглед странен въпрос. Е, вероятно, първо, за да можете да разположите копие на системата и второ, да възстановите системата в случай на повреда? Съгласен съм за първото, но втората цел е първият резервен мит.

Архивирането е последната линия на сигурността на системата.Ако администратор на база данни трябва да възстанови продуктова система от резервни копия, вероятно са направени много сериозни грешки в организацията на работата. Не можете да разглеждате резервното копие като основен начин за гарантиране на целостта на данните; не, по-скоро е по-близо до пожарогасителна система. Необходима е пожарогасителна система. Той трябва да бъде конфигуриран, тестван и работещ. Но ако е проработило, това само по себе си е сериозна авария с много негативни последици.

За да сте сигурни, че архивирането се използва само за „мирни“ цели, използвайте други средства, за да гарантирате производителност:

• Осигурете физическата безопасност на вашите сървъри: пожари, наводнения, лошо захранване, чистачи, строителни работници, метеорити и диви животни чакат зад ъгъла, за да унищожат вашата сървърна стая.
• Отнасяйте се отговорно към заплахите за информационната сигурност.
• Правете промени в системата умело и се уверете предварително, че тези промени няма да доведат до влошаване. Освен план за извършване на промени, препоръчително е да имате план „какво да правите, ако всичко се обърка“.
• Активно използвайте технологии за увеличаване на достъпността и надеждността на системата, вместо по-късно да се справяте с последствията от аварии. За MS SQL трябва да обърнете внимание на следните характеристики:
  • Използване на MS SQL клъстери (въпреки че, честно казано, мисля, че това е един от най-скъпите и безполезни начини да заемете администратор на база данни за системи, които не изискват 24x7)
  • Дублиране на база данни (синхронно и асинхронно в зависимост от изискванията за наличност, производителност и цена)
  • Доставка на регистър на транзакциите
  • Репликация с помощта на 1C инструменти (разпределени бази данни)

В зависимост от изискванията за наличност на системата и бюджета, разпределен за тези цели, е напълно възможно да се изберат решения, които ще намалят времето за престой и времето за възстановяване при повреда с 1-2 порядъка. Няма нужда да се страхувате от технологиите за достъпност; те са достатъчно прости, за да ги научите за няколко дни. основни познания MS SQL.

Но независимо от всичко, архивирането все още е необходимо. Това е същият резервен парашут, който можете да използвате, когато всички други средства за спасяване се провалят. Но, като истински резервен парашут, за това:

• тази система трябва да бъде правилно и професионално конфигурирана предварително,
• специалистът, използващ системата, трябва да има теоретични и практически умения за нейното използване (редовно подсилвани),
• системата трябва да се състои от най-надеждните и прости компоненти (това е последната ни надежда).

Основна информация за съхранение и обработка на MS SQL данни

Данните в MS SQL обикновено се съхраняват във файлове с данни (наричани по-долу FD - съкращение, което не се използва често; в тази статия ще има още няколко не много често срещани съкращения) с разширения mdf или ndf. В допълнение към тези файлове има и регистрационни файлове за транзакции (TL), които се съхраняват във файлове с разширение .ldf. Често начинаещите администратори са безотговорни и несериозни, когато става въпрос за VT, както по отношение на производителността, така и по отношение на надеждността на съхранението. Това е много сериозна грешка. Всъщност е по-скоро обратното, ако има надеждно функционираща система за архивиране и може да се отдели много време за възстановяване на системата, тогава можете да съхранявате данни на бърз, но изключително ненадежден RAID-0, но тогава данните трябва да се съхранява на отделен надежден и продуктивен ресурс (въпреки че ще бъде на RAID-1). Защо така? Нека да разгледаме по-отблизо. Нека веднага направя уговорка, че представянето е донякъде опростено, но достатъчно за първоначално разбиране.

FD съхранява данни в страници от 8 килобайта (които се комбинират в екстенти от 64 килобайта, но това не е значително). MS SQL не гарантираче веднага след изпълнение на команда за промяна на данни, тези промени ще отидат във FD. Не, просто страницата в паметта е маркирана като „изискваща записване“. Ако сървърът има достатъчно ресурси, тогава тези данни скоро ще бъдат на диска. Освен това сървърът работи „оптимистично“ и ако тези промени се появят в транзакция, тогава те могат да се окажат на диска, преди транзакцията да бъде извършена. Тоест в общ случай, по време на активна работа, FD съдържа разпръснати части от незавършени данни и незавършени транзакции, за които не е известно дали ще бъдат анулирани или ангажирани. Има специална команда "CHECKPOINT", която казва на сървъра, че трябва да изчисти всички незапазени данни на диска "точно сега", но обхватът на тази команда е доста специфичен. Достатъчно е да кажа, че 1C не го използва (не съм го срещал) и да разбера, че по време на работа FD обикновено не е в непокътнато състояние.

За да се справим с този хаос, ние просто се нуждаем от VT. В него са записани следните събития:

• Информация за началото на транзакцията и нейния идентификатор.
• Информация за факта на извършване или отмяна на транзакция.
• Информация за всички промени в данните във FD (грубо казано какво се е случило и какво се е случило).
• Информация за промени в самия FD или структурата на базата данни (увеличаване на файлове, намаляване на файлове, разпределяне и освобождаване на страници, създаване и изтриване на таблици и индекси)

Цялата тази информация е написана, като посочва идентификатора на транзакцията, в която е възникнала, и в достатъчен обем, за да разберете как да преминете от състоянието преди тази операция към състоянието след тази операция и обратно (изключение е моделът за възстановяване с частично регистриране) .

Важно е тази информация да бъде записана на диска веднага. Докато информацията не бъде записана във VT, командата не се счита за изпълнена. В нормална ситуация, когато размерът на VT е достатъчен и когато не е много фрагментиран, записите се записват в него последователно в малки записи (не непременно кратни на 8 kb). В регистъра на транзакциите се включват само данни, които действително са необходими за възстановяване. В частност Неполучава се информация за това кой текст на заявка е довел до модификациите, какъв план за изпълнение е имала тази заявка, кой потребител я е стартирал и друга информация, ненужна за възстановяване. Заявката може да предостави известна представа за структурата на данните в регистъра на транзакциите

Изберете * от::fn_dblog(null,null)

Защото твърди дисковеработят много по-ефективно с последователно писане, отколкото с хаотичен поток от команди за четене и запис и поради факта, че SQL командище изчака края на регистрацията във VT, възниква следната препоръка:

Ако има дори и най-малка възможност, тогава в продуктова среда VT трябва да бъдат разположени на отделен (от всичко останало) физически носител, за предпочитане с минимално време за достъп за последователен записи с максимална надеждност. За прости системи RAID-1 е доста подходящ.

Ако транзакцията бъде анулирана, тогава сървърът ще върне всички вече направени промени в предишното състояние. Защото

Анулирането на транзакция в MS SQL Server обикновено продължава сравнимо с общата продължителност на операциите по промяна на данните на самата транзакция. Опитайте се да не анулирате транзакции или вземете решение за анулиране възможно най-рано.

Ако сървърът неочаквано спре да работи по някаква причина, тогава при рестартирането му ще се анализира кои данни във FD не съответстват на интегралното състояние (незаписани, но извършени транзакции и записани, но анулирани транзакции) и тези данни ще бъдат коригирани. Ето защо, ако например сте започнали да възстановявате индексите на голяма таблица и сте рестартирали сървъра, тогава, когато го рестартирате, ще отнеме значително време, за да върнете тази транзакция и няма начин да прекъснете този процес .

Какво се случва, когато VT достигне края на файла? Просто е - ако има свободно място в началото, то ще започне да пише на свободното място в началото на файла преди заетото място. Като примка на магнитна лента. Ако няма място в началото, тогава сървърът обикновено ще се опита да разшири регистрационния файл на транзакциите, докато за сървъра разпределената нова част е нов виртуален регистрационен файл на транзакции, от който може да има много във физическия файл на транзакция , но това няма много общо с архивирането. Ако сървърът не успее да разшири файла (дисковото пространство е свършило или настройките забраняват разширяването на файла), тогава текущата транзакция ще бъде анулирана с грешка 9002.

опа Какво трябва да се направи, за да има винаги място в ж.п. Тук стигаме до системата за архивиране и моделите за възстановяване. За да анулирате транзакции и да възстановите правилното състояние на сървъра в случай на внезапно изключване, е необходимо да съхранявате записи в JT, като се започне от началото на най-ранната отворена транзакция. Този минимум се записва и съхранява в ЖТ Задължително. Независимо от времето, настройките на сървъра и желанията на администратора. Сървърът не може да позволи тази информация да не съществува. Следователно, ако отворите транзакция в една сесия и извършите различни действия в други, регистърът на транзакциите може да приключи неочаквано. Най-старата транзакция може да бъде идентифицирана с командата DBCC OPENTRAN. Но това е само необходимият минимум информация. Какво ще се случи след това зависи от модели за възстановяване. Има три от тях в SQL Server:

• просто— съхранява се само остатъкът от VT, необходим за живота.
• Пълна— целият VT се съхранява от последното архивиране регистър на транзакциите. Моля, обърнете внимание, не от момента на пълно архивиране!
• Групово регистриране— част (обикновено много малка част) от операциите се записват в много компактен формат (по същество само запис, че такава и такава страница от файла с данни е променена). Иначе идентичен с Full.

Има няколко мита, свързани с моделите за възстановяване.

• Simple ви позволява да намалите натоварването на дисковата подсистема. Това е грешно. записва се точно същата сума като при Bulk logged, само че се счита за безплатна много по-рано.
• Груповото регистриране ви позволява да намалите натоварването на дисковата подсистема. За 1C това почти не е така. Всъщност една от малкото операции, които могат да попаднат под минимално регистриране без допълнителни танци с тамбура, е зареждането на данни от качване в dt формат и преструктуриране на таблици.
• Когато използвате модела за групово регистриране, някои транзакции не са включени в резервното копие на регистъра на транзакциите и това не ви позволява да възстановите състоянието към момента на това резервно копие. Това не е съвсем вярно. Ако операцията е регистрирана минимално, тогава текущите страници с данни ще бъдат включени в резервното копие и ще бъде възможно да се „пусне“ регистърът на транзакциите до края (въпреки че това не е възможно в произволен момент от време, ако има минимално регистрирани операции).

Почти безсмислено е да се използва моделът Bulk logged за 1C бази данни, така че не го разглеждаме по-нататък. Но ще разгледаме по-подробно избора между Full и Simple в следващата част.

• Структура на дневника на транзакциите
• • Модели за възстановяване и управление на регистъра на транзакциите
  • Управление на регистъра на транзакциите
• Използване на резервни копия на регистъра на транзакциите

Как работи архивирането в моделите Simple и Full recovery

В зависимост от вида на образуването, резервните копия са три вида:

• Пълна(Пълен)
• Диференциал(Диференциал, разлика)
• Дневник(Резервно копие на регистрационните файлове на транзакциите, като се има предвид колко често се използва този термин, ще го съкратим на RKZhT)

Не се обърквайте тук: моделът на пълно възстановяване и пълното архивиране са значително различни неща. За да не ги обърквам, по-долу ще използвам английски термини за модела на възстановяване и руски термини за видовете архивиране.

Пълното и диференциалното копиране работят еднакво за Simple и Full. Архивирането на регистъра на транзакциите напълно липсва в Simple.

Пълно архивиране

Позволява ви да възстановите състоянието на базата данни до определен момент от време (до този, в който е стартирано архивирането). Състои се от копие страница по страница на използваната част от файловете с данни и активна част от регистъра на транзакциите по време на създаването на архива.

Диференциално архивиране

Съхранява страници с данни, които са се променили след последното пълно архивиране. Когато възстановявате, първо трябва да възстановите пълно резервно копие (в режим NORECOVERY, примерите ще бъдат дадени по-долу), след което можете да приложите всяко от следващите диференциални копия към полученото „празно“, но, разбира се, само от тези, направени преди следващото пълно архивиране. Благодарение на това можете значително да намалите силата на звука дисково пространствоза съхраняване на резервно копие.

Важни точки:

• Без предишно пълно архивиране диференциалното копие е безполезно. Затова е препоръчително да ги съхранявате някъде близо един до друг.
• Всяко следващо диференциално архивиране ще запази всички страници, включени в предишното диференциално архивиране, направено след предишното пълно архивиране (макар и може би с различно съдържание). Следователно всяко следващо диференциално копие е по-голямо от предишните, докато не бъде направено пълно копие отново (ако това е нарушено, то се дължи само на алгоритми за компресия)
• За възстановяване в даден момент е достатъчно последнопълно архивиране в този момент и последнодиференциално копие в този момент. Междинните копия не са необходими за възстановяване (въпреки че може да са необходими за избор на момента на възстановяване)

РКЖТ

Съдържа копие от ВТ за определен период. Обикновено от момента на последния РКЖТ до образуването на настоящия РКЖТ. RKZHT ви позволява да възстановите състоянието от копие, възстановено в режим NORECOVERY във всеки момент от времето, включен в периода на възстановеното копие на ZHT, във всеки следващ момент от време, включен в интервала на възстановеното резервно копие. При създаване на резервно копие със стандартни параметри се освобождава място в регистрационния файл на транзакциите (до момента на последната отворена транзакция).

Очевидно RKZhT няма смисъл в Simple модела (тогава ZhT съдържа само информация от момента на последната незатворена транзакция).

Когато използвате RKZhT, възниква важна концепция - непрекъсната верига на RKZhT. Тази верига може да бъде прекъсната или от загубата на някои резервни копия на тази верига, или от преобразуване на базата данни в проста и обратно.

Внимание: набор от RKZhT е по същество безполезен, ако не е непрекъсната верига и началната точка на последното успешно пълно или диференциално архивиране трябва да бъде вътрепериод от тази верига.

Често срещани погрешни схващания и митове:

• „RKZhT съдържа данни от регистъра на транзакциите от момента на предишното пълно или диференциално архивиране.“Не, това не е вярно. RKZhT също съдържа на пръв поглед безполезни данни между предишния RKZhT и последващото пълно архивиране.
• „Пълно или диференциално архивиране трябва да освободи място в регистъра на транзакциите.“Не, това не е вярно. Пълните и диференциалните архиви не засягат веригата RKZhT.
• VT трябва периодично да се почиства ръчно, намалява и настъргва.Не, не е необходимо и напротив, не е желателно. Ако освободите VT между RCVT, веригата RCVT, необходима за възстановяване, ще бъде прекъсната. И постоянното намаляване/разширяване на файла ще доведе до неговата физическа и логическа фрагментация.

Как работи на прост

Нека има база данни от 1000 GB. Всеки ден базата данни нараства с 2 GB, докато 10 GB стари данни се променят. Направени са следните резервни копия

• Пълно копие на F1 от 0:00 1 февруари (обем 1000 GB, компресията не се взема предвид за простота на картината)
  • Диференциално копие на D1.1 от 0:00 2 февруари (обем 12 GB)
  • Диференциално копие на D1.2 от 0:00 3 февруари (обем 19 GB)
  • Диференциално копие на D1.3 от 0:00 4 февруари (обем 25 GB)
  • Диференциално копие на D1.4 от 0:00 5 февруари (обем 31 GB)
  • Разлика копие D1.5 от 0:00 6 февруари (обем 36 GB)
  • Диференциално копие на D1.6 от 0:00 7 февруари (обем 40 GB)
• Пълно копие на F2 от 0:00 8 февруари (обем 1014 GB)
  • Диференциално копие на D2.1 от 0:00 9 февруари (обем 12 GB)
  • Диференциално копие на D2.2 от 0:00 10 февруари (обем 19 GB)
  • Диференциално копие на D2.3 от 0:00 11 февруари (обем 25 GB)
  • Диференциално копие на D2.4 от 0:00 12 февруари (обем 31 GB)
  • Разлика копие D2.5 от 0:00 13 февруари (обем 36 GB)
  • Диференциално копие на D2.6 от 0:00 14 февруари (обем 40 GB)

Използвайки този набор, можем да възстановим данни в 0:00 часа всеки ден от 1 февруари до 14 февруари. За да направим това, трябва да вземем пълно копие на F1 за седмицата 1-7 февруари или пълно копие на F2 за 8-14 февруари, да го възстановим в режим NORECOVERY и след това да приложим диференциално копие на желания ден.

Как работи изцяло

Нека имаме същия набор от пълни и диференциални резервни копия, както в предишния пример. В допълнение към това има следните RKZhT:

• RKZhT 1 за периода от 12:00 31 януари до 12:00 2 февруари (около 30 GB)
• RKZhT 2 за периода от 12:00 2 февруари до 12:00 4 февруари (около 30 GB)
• RKZhT 3 за периода от 12:00 4 февруари до 12:00 6 февруари (около 30 GB)
• RKZhT 4 за периода от 12:00 6 февруари до 12:00 7 февруари (около 30 GB)
• RKZhT 5 за периода от 12:00 8 февруари до 12:00 10 февруари (около 30 GB)
• RKZhT 6 за периода от 12:00 10 февруари до 12:00 12 февруари (около 30 GB)
• RKZhT 7 за периода от 12:00 12 февруари до 12:00 14 февруари (около 30 GB)
• RKZhT 8 за периода от 12:00 14 февруари до 12:00 16 февруари (около 30 GB)

Забележка:

1. Размерът на RKZhT ще бъде приблизително постоянен.
2. Можем да правим резервни копия по-рядко от диференциалните или пълните, или можем да ги правим по-често, тогава те ще бъдат по-малки по размер.
3. Сега можем да възстановим състоянието на системата до всяка точка от 0:00 на 1 февруари, когато имаме най-ранното пълно копие, до 12:00 на 16 февруари.

В най-простия случай трябва да възстановим:

1. Последно пълно копие преди възстановяване
2. Последно диференциално копие преди възстановяване
3. Всички RKZhT, от момента на последното различно копие до момента на възстановяване

• Пълно копие на F2 от 0:00 8 февруари
• Разлика копие D2.2 от 0:00 10 февруари
• РКЖТ 6 за времето от 12:00 ч. 10 януари до 12:00 ч. 12 февруари

Първо ще се възстанови Ф2, след това Д2.2, след това РКЖТ 6 до 13:13:13 на 10 февруари. Но значително предимство на Full модела е, че имаме избор - да използваме последното пълно или диференциално копие или НЕ последното. Например, ако се установи, че копието на D2.2 е повредено и трябва да го възстановим до момента преди 13:13:13 на 10 февруари, тогава за модела Simple това би означавало, че можем да възстановим само данни към момента D2.1. С Full - "DON"T PANIC" имаме следните опции:

1. Възстановете F2, след това D2.1, след това RKZHT 5, след това RKZHT 6 до 13:13:13 на 10 февруари.
2. Възстановете F2, след това RKZHT 4, след това RKZHT 5, след това RKZHT 6 до 13:13:13 на 10 февруари.
3. Или дори възстановете F1 и стартирайте всички RKZhT до RKZhT 6 до 13:13:13 на 10 февруари.

Както можете да видите, пълният модел ни дава по-голям избор.

Сега нека си представим, че сме много хитри. И няколко дни преди провала (13:13:13 10 февруари) знаем, че ще има провал. Възстановяваме базата данни от пълно архивиране на съседен сървър, оставяйки възможността да навиваме следващите състояния с диференциални копия или RKZhT, т.е. оставихме я в режим NORECOVERY. И всеки път, веднага след формирането на RKZhT, ние го прилагаме към тази резервна база, оставяйки я в режим NORECOVERY. Еха! Защо, сега ще ни отнеме само 10-15 минути, за да възстановим базата данни, вместо да възстановяваме огромна база данни! Поздравления, преоткрихме доставката на трупи, един от начините за намаляване на времето за престой. Ако прехвърляте данни по този начин не веднъж на период, а постоянно, тогава ще получите дублиране и ако изходната база чака огледалната база да се актуализира, тогава това е синхронно дублиране, ако не чака, тогава е асинхронен.

Можете да прочетете повече за инструментите за висока наличност в помощта:

• Висока наличност (Database Engine)
  • Разбиране на решенията за висока наличност
  • Високо ниво на достъпност. Взаимодействие и сътрудничество

Други съображения за архивиране

Можете спокойно да пропуснете този раздел, ако сте отегчени от теорията и ви се иска да изпробвате настройките за архивиране.

Файлови групи

1C:Enterprise по същество не знае как да работи с файлови групи. Има една група файлове и това е. Всъщност програмист или администратор на MS SQL база данни може да постави някои таблици, индекси или дори части от таблици и индекси в отделни файлови групи (в най-простата версия - в отделни файлове). Това е необходимо или за ускоряване на достъпа до някои данни (като ги поставите на много бърз носител), или обратното, като пожертвате скоростта и ги поставите на по-евтини носители (например малко използвани, но обемни данни). Когато работите с файлови групи, е възможно да правите резервни копия на тях поотделно, както и да ги възстановявате поотделно, но трябва да имате предвид, че всички файлови групи ще трябва да бъдат „догонени“ до една точка чрез превъртане на РКЖТ.

Файлове с данни

Ако човек управлява разполагането на данни в различни файлови групи, тогава, когато има няколко файла във файловата група, тогава MS SQL Server избутва данните в тях независимо (ако обемът на файловете е равен, той ще се опита равномерно). От гледна точка на приложението това се използва за паралелизиране на I/O операции. Но от гледна точка на резервните копия има и друг момент. За много големи бази данни в ерата преди SQL 2008 беше типичен проблем да се разпредели непрекъснат прозорец за пълно архивиране и целевият диск за това архивиране може просто да не го побере. Повечето по прост начинв този случай беше да се архивира всеки файл (или файлова група) в негов собствен прозорец. Сега, с активното разпространение на компресията на архивиране, този проблем е намалял, но тази техника все още може да се има предвид.

Резервно компресиране

MS SQL Server 2008 въведе супер-мега-ултра функция. Отсега нататък и завинаги архивите могат да бъдат компресирани, когато се генерират в движение. Това намалява размера на архива на 1C база данни с 5-10 пъти. И като се има предвид, че изпълнението обикновено е дискова подсистемае тясното място на СУБД, това не само намалява разходите за съхранение, но също така значително ускорява архивирането (въпреки че натоварването на процесорите се увеличава, но обикновено мощността на процесора е напълно достатъчна на СУБД сървъра).

Ако във версията от 2008 г. тази функция беше достъпна само за изданието Enterprise (което е много скъпо), то през 2008 R2 тази функция беше предоставена на стандартната версия, което е много приятно.

Настройките за компресиране не са обхванати в примерите по-долу, но силно препоръчвам да използвате резервно компресиране, освен ако няма конкретна причина да го деактивирате.

Един архивен файл - много вътрешни

Всъщност архивът не е просто файл, той е доста сложен контейнер, в който могат да се съхраняват много архиви. Този подход има много древна история (аз лично го наблюдавам от версия 6.5), но в момента за администраторите на „обикновени“ бази данни, особено бази данни 1C, няма сериозни причини да не използват „едно резервно копие - едно файл” подход. За общо развитие е полезно да проучите възможността да поставите няколко резервни копия в един файл, но най-вероятно няма да ви се налага да го използвате (или ако трябва, това ще бъде подреждане на развалините на бъдещ администратор които неправомерно са използвали тази възможност).

Множество огледални копия

SQL Server има още една страхотна функция. Можете да създадете резервно копие паралелно в няколко приемника. как най-прост пример, можете да изхвърлите едно копие на локален диск и в същото време да го поставите мрежов ресурс. Локалното копие е удобно, тъй като възстановяването от него е много по-бързо; отдалеченото копие ще издържи много по-добре на физическото унищожаване на основния сървър на база данни.

Примери за резервни системи

Стига теория. Време е да докажете с практика, че цялата тази кухня работи.

Настройване на типична сървърна резервация чрез планове за поддръжка

Този раздел е структуриран под формата на готови рецепти с обяснения. Този раздел е много скучен и дълъг поради снимките, така че можете да го пропуснете.

Използване на съветника за създаване на план за обслужване

Настройка на архивиране на сървъра с помощта на TSQL скриптове, примери за някои функции

Веднага възниква въпросът какво още е необходимо? Изглежда, че просто сте настроили всичко и всичко работи като часовник? Защо да се занимавате с всякакви скриптове? Сервизните планове не позволяват:

• Използвайте огледално архивиране
• Използвайте настройки за компресиране, различни от настройките на сървъра
• Не позволява гъвкава реакция при възникващи ситуации (няма възможности за обработка на грешки)
• Не позволява гъвкаво използване на настройките за сигурност
• Плановете за услуги са много неудобни за внедряване (и поддържане на същото) на голям брой сървъри (дори може би вече на 3-4)

По-долу са типичните команди за архивиране

Пълно архивиране

Пълно архивиране с презаписване на съществуващия файл (ако има такъв) и проверка на контролните суми на страницата преди запис. При създаване на резервно копие се отчита всеки процент напредък

РЕЗЕРВНО КОПИРАНЕ НА БАЗА ДАННИ НА ДИСК = N"C:\Backup\mydb.bak" С INIT, ФОРМАТ, СТАТИСТИКА = 1, КОНТРОЛНА СУМА

Диференциално архивиране

Аналогично - разлика копие

РЕЗЕРВНО КОПИРАНЕ НА БАЗА ДАННИ НА ДИСК = N"C:\Backup\mydb.diff" С ДИФЕРЕНЦИАЛ, INIT, FORMAT, STATS = 1, CHECKSUMA

РКЖТ

Архивиране на регистъра на транзакциите

РЕЗЕРВЕН РЕГИСТРАТОР НА ДИСК = N"C:\Backup\mydb.trn" С INIT, ФОРМАТ

Огледално архивиране

Често е удобно да направите не едно резервно копие наведнъж, а две. Например, единият може да се съхранява локално на сървъра (така че да е под ръка), а вторият веднага се оформя във физически отдалечено и защитено от неблагоприятни влияния хранилище:

РЕЗЕРВНО КОПИРАНЕ НА БАЗА ДАННИ НА ДИСК = N"C:\Backup\mydb.bak", ОГЛЕДАЛО КЪМДИСК = N"\\safe-server\backup\mydb.bak" С INIT, ФОРМАТ

Важен момент, който често се пропуска: потребителят, от чието име се стартира процесът на MSSQL Server, трябва да има достъп до ресурса "\\safe-server\backup\", в противен случай копирането ще бъде неуспешно. Ако MSSQL Server се стартира от името на системата, тогава трябва да се даде достъп на потребителя на домейна "server_name$", но все пак е по-добре правилно да конфигурирате MS SQL да работи от името на специално създаден потребител.

Ако не укажете MIRROR TO , то няма да са 2 огледални копия, а едно копие, разделено на 2 файла, според принципа на interleave. И всеки от тях поотделно ще бъде безполезен.

„Този, който притежава информация, притежава света“ – Майер Амшел Ротшилд

Най-ценният актив във всеки бизнес е информацията. Загубата на информация може да доведе до непредвидими последици, най-вече финансови. Ето защо една от основните задачи на ИТ специалистите е архивиране на цялата ИТ инфраструктура. Това важи и за базите данни на MS SQL Server.

За да се гарантира безопасността на информацията в използваните бази данни, както и да се намали времето за възстановяване на функционалността, е необходимо да се извършва периодично архивиране на SQL сървърите.

Нека да разгледаме един прост пример: трябва да конфигурирате архивиране на база данни на отделен диск.

Решение:

1. Отваряне Microsoft SQLСтудио за управление на сървъри. В навигационното меню вдясно отворете раздела "Контрол". Там виждаме раздел „Сервизни планове“. Щракнете с десен бутон -> „Създайте план за обслужване“и дайте име на нашия план (фиг. 1):

Фиг.1 Създаване на нов сервизен план.

2. Добавете задача в лентата с инструменти „Архивиране на база данни“(фиг.2):

Фиг.2 Добавяне на задачата "Архивиране на база данни".

3. Върху създадената задача щракнете с десния бутон -> "Промяна"(фиг.3):

4. В прозореца със свойства на задачата изберете типа архивиране (в моя случай пълно), изберете желаната база данни (имам ka_cons), директорията за архивиране, възможността за проверка на резервните копия за целостта и опциите за компресиране за тях (фиг. 4-6):

Фиг.4 Тип архивиране - пълно.

Фиг.5 Избор на база данни за архивиране.

Фиг.6 Определяне на директорията за архивиране, проверка на целостта и степента на компресия.

5. В панела с настройки на плана за услуги вдясно. Натисни бутона "График"(фиг.7):

6. Настройте необходимия график и щракнете "ДОБРЕ"(фиг.8):

Фиг.8 Настройка на график за архивиране.

7. Запазете нашия сервизен план (фиг. 9):

Фиг.9 Запазване на план за поддръжка.

Конфигурирано е планирано пълно архивиране на база данни.

Сървърите за бази данни са едни от ключовите сървъри във всяка организация. Те са тези, които съхраняват информация и предоставят изход при поискване и е изключително важно да се запази базата данни във всяка ситуация. Основният пакет обикновено включва необходимите помощни програми, но администратор, който преди това не е срещал база данни, ще трябва да отдели известно време за разбиране на особеностите на работата, за да осигури автоматизация.

Видове резервни копия на бази данни

Първо, нека да разберем какъв вид архивиране има. Сървърът на база данни не е обикновено приложение за настолни компютри и за да се гарантира, че са изпълнени всички свойства на ACID (Atomic, Consistency, Isolated, Durable), се използват редица технологии и следователно създаването и възстановяването на база данни от архив има свои собствени характеристики . Има три различни подхода за архивиране на данни, всеки със своите предимства и недостатъци.

С логическо или SQL архивиране (pg_dump, mysqldump, SQLCMD) се създава моментна снимка на съдържанието на базата данни, като се взема предвид целостта на транзакцията и се записва като файл с SQL команди (можете да изберете цялата база данни или отделни таблици ), с който можете да пресъздадете базата данни на друг сървър. Това отнема време (особено за големи бази данни) за запазване и възстановяване, така че много често тази операция не може да бъде изпълнена и се извършва при минимално натоварване (например през нощта). По време на възстановяването администраторът ще трябва да изпълни няколко команди, за да подготви всичко необходимо (създаване на празна база данни, акаунти и т.н.).

Физическо архивиране (ниво файлова система) - копиране на файлове, които СУБД използва за съхраняване на данни в базата данни. Но едно просто копие игнорира заключвания и транзакции, които има вероятност да бъдат неправилно запазени и разбити. Ако се опитате да прикачите този файл, той ще бъде в непоследователно състояние и ще доведе до грешки. Придобивам текущо архивиране, базата данни трябва да бъде спряна (можете да намалите времето за престой, като използвате rsync два пъти - първо на работеща, след това на спряна). Недостатъкът на този метод е очевиден - не можете да възстановите конкретни данни, а само цялата база данни. Когато стартирате база данни, възстановена от архив на файлова система, ще трябва да проверите нейната цялост. Тук се използват различни помощни технологии. Например в PostgreSQL, WAL (предварително записване на регистрационни файлове) и специална функция(Point in Time Recovery - PITR), което ви позволява да се върнете към определено състояние на базата данни. С тяхна помощ лесно се изпълнява третият сценарий, когато архивиране на ниво файлова система се комбинира с резервно копие на WAL файлове. Първо възстановяваме архивните файлове на файловата система и след това, използвайки WAL, базата данни се довежда до текущото състояние. Това е малко по-сложен подход за администриране, но няма проблеми с целостта на базата данни и възстановяването на бази данни до определено време.

Логическото архивиране се използва в случаите, когато е необходимо да се направи еднократно пълно копие на базата данни или при ежедневна употреба, създаването на копие не изисква много време или място. Когато разтоварването на бази данни отнема много време, трябва да обърнете внимание на физическото архивиране.

барман

Разрешително: GNU GPL

Поддържани СУБД: PostgreSQL

PostgreSQL поддържа физически и логически възможности за архивиране, добавяйки друг WAL слой към тях (вижте страничната лента), което може да се нарече непрекъснато копиране. Но управлението на множество сървъри с помощта на стандартни инструменти не е много удобно дори за опитен администратор и в случай на повреда се броят секунди.

Barman (мениджър за архивиране и възстановяване) е вътрешна разработка на компанията 2ndQuadrant, която предоставя услуги, базирани на PostgreSQL. Проектиран за физическо архивиране на PostgreSQL (логически не поддържа), WAL архивиране и бързо възстановяванеслед провали. Поддържа отдалечено архивиране и възстановяване на множество сървъри, функции за възстановяване в момента (PITR) и управление на WAL. SSH се използва за копиране и изпращане на команди до отдалечен хост; синхронизирането и архивирането с помощта на rsync ви позволява да намалите трафика. Barman също се интегрира със стандартни помощни програми bzip2, gzip, tar и други подобни. По принцип можете да използвате всяка програма за компресиране и архивиране, интеграцията няма да отнеме много време. Бяха внедрени различни сервизни и диагностични функции за наблюдение на състоянието на услугите и регулиране на честотната лента. Поддържат се скриптове преди/след.

Barman е написан на Python и политиките за архивиране се управляват с помощта на удобния за потребителя INI файл barman.conf, който може да се намира в /etc или в домашната директория на потребителя. Включено в доставката готов шаблонс подробни коментари вътре. Работи само на *nix системи. За да инсталирате на RHEL, CentOS и Scientific Linux, трябва да свържете EPEL - хранилище, което съдържа допълнителни пакети. Официалното хранилище е достъпно за потребителите на Debian/Ubuntu:

$ sudo apt-get инсталирайте барман

Не винаги в хранилището последна версия, за да го инсталирате, ще трябва да се обърнете към изходните текстове. Има малко зависимости и процесът е лесен за разбиране.

Sypex Самосвал

Разрешително: BSD

Поддържани СУБД: MySQL

MySQL идва с помощните програми mysqldump и mysqlhotcopy, които ви позволяват лесно да създадете дъмп на база данни; те са добре документирани и можете да намерите голям брой в Интернет. готови примерии интерфейси. Последните позволяват на начинаещия бързо да започне. Sypex Dumper е PHP скрипт, който ви позволява лесно да създавате и възстановявате копие на MySQL база данни. Създаден за работа с големи бази данни, той работи много бързо, разбираем е и лесен за използване. Знае как да работи с MySQL обекти - изгледи, процедури, функции, тригери и събития.

Друг плюс, за разлика от други инструменти, които извършват транскодиране в UTF-8 при експортиране, в Dumper експортирането се извършва в естественото кодиране. Полученият файл заема по-малко място и самият процес е по-бърз. Един дъмп може да съдържа обекти с различни кодировки. Освен това е лесно да импортирате/експортирате на няколко етапа, спирайки процеса по време на зареждане. При подновяване процедурата ще започне от мястото, където е спряла. Има четири опции за възстановяване:

• CREATE + INSERT - стандартен режим на възстановяване;
• TRUNCATE + INSERT - по-малко време за създаване на таблици;
• REPLACE - възстановяваме стари данни в работещата база данни, без да презаписваме нови;
• INSERT IGNORE - добавяме изтрити или нови данни към базата данни, без да докосваме съществуващите.

Поддържа компресиране на копие (gzip или bzip2), автоматично изтриване на стари архиви, преглед на съдържанието на дъмп файл и възстановяване само на структурата на таблицата. Има и сервизни функции за управление на базата данни (създаване, изтриване, проверка, възстановяване на базата данни, оптимизация, почистване на таблици, работа с индекси и др.), Както и файлов мениджър, който ви позволява да копирате файлове на сървъра.

Управлението се извършва с помощта на уеб браузър, интерфейс с използвайки AJAXлокализиран от кутията и създава впечатление за работа с десктоп приложение. Също така е възможно да се изпълняват задачи от конзолата и по график (чрез cron).

За да работи Dumper, ще ви е необходим класически L|WAMP сървър; инсталацията е стандартна за всички приложения, написани на PHP (копиране на файлове и задаване на разрешения) и няма да бъде трудно дори за начинаещ. Проектът предоставя подробна документация и видео уроци, демонстриращи как да използвате Sypex Dumper.

Има две издания: Sypex Dumper (безплатно) и Pro ($10). Вторият има повече функции, всички разлики са изброени на уебсайта.

SQL архивиране и FTP

Разрешително:

Поддържани СУБД: MS SQL сървър

MS SQL Server е едно от популярните решения и затова се среща доста често. Задание за архивиране се създава с помощта на SQL Server Management Studio, самия Transact-SQL и кратките команди на модула SQL PowerShell (Backup-SqlDatabase). На уебсайта на MS можете да намерите огромно количество документация, която ви позволява да разберете процеса. Документацията, макар и пълна, е много специфична, а информацията в интернет често си противоречи. Начинаещият всъщност ще трябва първо да практикува, „да навлезе в главата си“, така че въпреки всичко казано, разработчиците на трети страни имат място за разширяване. Освен това безплатната версия на SQL Server Express няма вградени инструменти за архивиране. За още по-ранни версии MS SQL (до 2008 г.) можете да намерите безплатни помощни програми, например архивиране на SQL Server, но в повечето такива проекти вече са комерсиализирани, въпреки че предлагат цялата функционалност често за символична сума.

Например разработката на SQL Backup And FTP и One-Click SQL Restore следва принципа „настройте и забравете“. Имайки много прост и интуитивен интерфейс, те ви позволяват да създавате копия на бази данни MS SQL Server (включително Express) и Azure, да запазвате криптирани и компресирани файловекъм FTP и облачни услуги(Dropbox, Box, Google Диск, MS SkyDrive или Amazon S3), резултатът може да се види веднага. Възможно е да стартирате процеса ръчно или по график, да изпратите съобщение за резултата от задачата по имейл или да стартирате персонализирани скриптове.

Поддържат се всички опции за архивиране: пълен, диференциален, регистър на транзакциите, копиране на папка с файлове и много други. Старите резервни копия се изтриват автоматично. SQL Management Studio се използва за свързване към виртуалния хост, въпреки че може да има нюанси и това няма да работи във всички подобни конфигурации. Има пет версии, достъпни за изтегляне - от Безплатнодо сложния Prof Lifetime (към момента на писане на тези редове струваше само $149). Функционалността на Free е напълно достатъчна за малки мрежи с инсталиран един или два SQL сървъра, всички основни функции са активни. Броят на резервните бази данни, възможността за изпращане на файлове до Google Drive и SkyDrive и криптирането на файлове са ограничени. Въпреки че интерфейсът не е локализиран, той е много прост и разбираем дори за начинаещ. Просто трябва да се свържете към SQL сървъра, след което ще се покаже списък с бази данни, трябва да изберете тези, от които се нуждаете, да конфигурирате достъпа до отдалечени ресурси и да посочите времето за изпълнение на задачата. И всичко това в един прозорец.

Но има едно „но“. Самата програма не е предназначена за възстановяване на архиви. За това се предлага отделна безплатна помощна програма One-Click SQL Restore, която също разбира формата, създаден от командата BACKUP DATABASE. Администраторът трябва само да посочи архива и сървъра, на който да възстанови данните, и да натисне един бутон. Но в по-сложни сценарии ще трябва да използвате RESTORE.

Характеристики на архивирането на MS SQL Server

Създаването на резервно копие и възстановяването на СУБД има свои собствени различия, които трябва да се вземат предвид, особено при прехвърляне на архив на друг сървър. Като пример, нека да разгледаме някои от нюансите на MS SQL Server. За да архивирате с помощта на Transact-SQL, използвайте командата BACKUP DATABASE (съществува и команда DIFFERENTIAL) и регистъра на транзакциите BACKUP LOG.

Ако резервното копие е разположено на друг сървър, трябва да се уверите, че същото логически устройства. Като опция можете ръчно да посочите правилните пътища за файловете на базата данни, като използвате опцията WITH MOVE на командата RESTORE DATABASE.

Проста ситуация - архивиране и прехвърляне на бази данни към други версии на SQL Server. Тази операция се поддържа, но в случай на SQL Server ще работи, ако версията на сървъра, на който е разположено копието, е същата или по-нова от тази, на която е създадено. Освен това има ограничение: не повече от две версии са по-нови. След възстановяването базата данни ще бъде в режим на съвместимост с версията, с която е направен преходът, т.е. новите функции няма да бъдат налични. Това може лесно да се коригира чрез промяна на COMPATIBILITY_LEVEL. Можете да направите това с помощта на GUI или SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Можете да определите на коя версия е създадено копието, като погледнете заглавката на архивния файл. За да не експериментирате, при преминаване към нова версия SQL Server трябва да работи безплатна помощна програмаСъветник за надстройка на Microsoft.

Иперий

Разрешително:търговски, има безплатна версия

Поддържани СУБД: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL и MS SQL Server

Когато трябва да управлявате няколко типа СУБД, не можете без комбинации. Изборът е голям. Например, Iperius е лека, много лесна за използване, но мощна програма за архивиране на файлове, която включва горещи архиви на база данни без прекъсване или блокиране. Осигурява пълно или инкрементално архивиране. Може да създава пълни дискови изображения за автоматична преинсталацияцялата система. Поддържа архивиране към NAS, USB устройства, streamer, FTP/FTPS, Google Drive, Dropbox и SkyDrive. Поддържа zip компресия без ограничение за размера на файла и AES256 криптиране, стартиране на външни скриптове и програми. Включва много функционален планировчик на задачи, възможно е паралелно или последователно изпълнение на няколко задачи, резултатът се изпраща по имейл. Поддържат се множество филтри, променливи за персонализиране на пътища и настройки.

Възможността за качване по FTP улеснява актуализирането на информация в множество уебсайтове. Отворете файловесе архивират с помощта на VSS (volume shadow copy) технология, която позволява горещо архивиране не само на DBMS файлове, но и на други приложения. За Oracle се използва и инструментът за архивиране и възстановяване RMAN (Recovery Manager). За да избегнете претоварване на канала, е възможно да конфигурирате честотната лента. Архивирането и възстановяването се управляват с помощта на локална и уеб конзола. Всички функции са видими, така че за да настроите задача, трябва само да разберете процеса; дори не е нужно да преглеждате документацията. Просто следваме инструкциите на съветника. Можете също така да отбележите мениджъра на акаунти, което е много удобно, когато имате голям брой системи.

Основните функции се предлагат безплатно, но възможността за архивиране на база данни е включена само в Advanced DB и Full версиите. Поддържа се инсталация от XP до Windows сървър 2012.

Удобно архивиране

Разрешително:реклама

Поддържани СУБД: Oracle, MySQL, IBM DB2 (7–9.5) и MS SQL Server

Една от най-мощните системи за управление релационни бази данниданни - IBM DB2, който има уникални функции за мащабиране и поддържа много платформи. Предлага се в няколко издания, които са изградени на една и съща основа и се различават функционално. Архитектурата на базата данни на DB2 ви позволява да управлявате почти всички типове данни: документи, XML, медийни файлове и т.н. Безплатният DB2 Express-C е особено популярен. Архивирането е много просто:

Db2 резервно db пример

Или моментна снимка с помощта на функцията Advanced Copy Services (ACS):

Db2 резервно копие db образец използва моментна снимка

Но трябва да помним, че в случай на моментни снимки не можем да възстановим (db2 възстановяване на db) отделни таблици. Има и възможности за автоматично архивиране и много други. Продуктите са добре документирани, въпреки че ръководствата са рядкост в рускоезичния интернет. Освен това не всички персонализирани решения предлагат DB2 поддръжка.

Например, Handy Backup ви позволява да архивирате няколко типа сървъри на бази данни и да записвате файлове на почти всеки носител ( HDD, CD/DVD, облачно и мрежово съхранение, FTP/S, WebDAV и други). Архивирането на база данни е възможно чрез ODBC (само за таблици). Това е едно от малкото решения, които поддържат DB2 и също така носят логото „Ready for IBM DB2 Data Server Software“. Цялата процедура се извършва с помощта на обикновен съветник, в който трябва само да изберете желания елемент и да създадете задача. Самият процес на настройка е толкова прост, че дори начинаещ може да го разбере. Можете да създадете няколко задачи, които ще се изпълняват по график. Резултатът се записва в дневник и се изпраща по имейл. Няма нужда да спирате услугата, докато заданието се изпълнява. Архивът е автоматично компресиран и криптиран, което гарантира неговата сигурност.

Две версии на Handy Backup поддържат работа с DB2 - Office Expert (локална) и Server Network (мрежова). Работи на компютри с Win8/7/Vista/XP или 2012/2008/2003. Самият процес на внедряване е лесен за всеки администратор.

Нека да разгледаме как да организираме две от най-често срещаните административни задачи на SQL Server:

• Автоматично архивиране на база данни;
• Изтриване на стари резервни копия.

Планиране на архивиране на база данни

• Отворете SQL Management Studio и се свържете с необходимата база данни. Уверете се, че SQL Server Agent работи;
• Разширете възела Управление – ​​Поддръжка (за това трябва да имате ролята „SYSADMIN“) – щракнете с десния бутон и изберете „Нов план за поддръжка“;
• Въведете име за новия сервизен план;
• Щракнете върху иконата на календар вдясно на един ред. В прозореца, който се отваря, конфигурирайте времето за изпълнение на задачата. Изберете време, когато базата данни е по-малко натоварена;
• От раздела Кутия с инструменти плъзнете задачата за архивиране на база данни в основната област;
• Щракнете два пъти върху Backup Database Task - ще се отвори прозорецът с настройки на backup task - задайте необходимите настройки;
• Щракнете върху OK - сега архивите ще бъдат създадени според планираното време;

Изтриване на стари резервни копия

Тъй като архивните файлове ще се създават често, скоро свободно пространствона вашия твърд диск ще намалее. Следователно ще трябва да изтриете остарели файловерезервни копия. Нека продължим с конфигурирането на плана за обслужване:

• От панела Toolbox плъзнете Maintenance Cleanup Task към основната област;
• Щракнете двукратно върху Maintenance Cleanup Task, за да отворите прозореца със свойства. В него трябва да определите местоположението на архивните копия, тяхното разширение и да определите възрастта на файловете за изтриване. Добра практика е архивирането да се съхранява до един месец;
• Щракнете върху OK и запазете сервизния план;
• След това можете или да изчакате следващия час за изпълнение на плана за поддръжка, или да го изпълните ръчно (щракнете с десния бутон върху плана за поддръжка в Object Explorer).

Препоръчително е да конфигурирате редовно архивиране на бази данни(в случай на хардуерни или софтуерни повреди), като най-добре е да запазите резервни копия за последните няколко дни, например седем (за последната седмица).

За да направите това, можете да използвате или планировчика на задачи, вграден в SQL Server - „SQL Server Agent“ (в безплатна версияне е включен) или стандартния „Windows Scheduler“ в комбинация с помощната програма SQLCMD.EXE, която ви позволява да изпълнявате заявки към SQL Server от командна линия. В планировчика трябва да създадете поне седем задания (по едно за всеки ден от седмицата), всяко от които (веднъж седмично) ще замени един от седемте файла, съдържащи съответния архив на базата данни.

Освен това се препоръчва архивните файлове да се съхраняват не само на твърдия диск на компютъра, на който е инсталиран SQL Server, но и да се дублират на лента или на твърдия диск на друг компютър в мрежата. За да направите това, можете или да използвате специален софтуер, който ви позволява да правите резервни копия на целия диск, или да използвате същия планировчик за копиране на файлове на лента или друг компютър (втора стъпка).

Използване на Windows Scheduler (безплатна версия)

За да създадете задача в " Windows Scheduler" необходимо:

Стартирайте програмата Notepad (Старт->Всички програми->Аксесоари->Notepad) и въведете следните два реда, след което ги запазете като пакетен файл (*.BAT):

SQLCMD -S (локален) -E -Q "РЕЗЕРВНО КОПИРАНЕ НА БАЗА ДАННИ AltaSVHDb НА ДИСК = "D:\BACKUP\ AltaSVHDb_monday.bak" С INIT, NOFORMAT, SKIP, NOUNLOAD"
XCOPY D:\BACKUP\ AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

Където "(местен)"- име на сървър (в случай на инсталиране на именуван екземпляр на SQL Server, трябва да посочите пълното име: „COMPAN_NAME\SQLEXPRESS“), "AltaSVHDb"- име на база данни, "D:\BACKUP\ AltaSVHDb_monday.bak"- името на файла, на който да се създаде резервно копие (ще варира според деня от седмицата), "BACKUP_SERVER"- името на компютъра, на който ще се извършва допълнително копиране, "Папка"- папка на този компютър (тя трябва да бъде споделена).

Стартирайте съветника за планиране на задачи (Контролен панел->Планирани задачи->Добавяне на задача) и щракнете върху бутона „Напред“:

Щракнете върху бутона "Преглед" и посочете пътя до пакетен файл(*.BAT), създаден в стъпка a):

Посочете име за задачата, изберете опцията за изпълнение „седмично“ и щракнете върху бутона „Напред“:

Поставете отметка в квадратчето до желания ден от седмицата и в полето „Начален час“ посочете часа, когато процесът на архивиране трябва да започне (обикновено това се прави през нощта), след което щракнете върху бутона „Напред“:

Въведете потребителското име и паролата (два пъти) на акаунта на операционната система, под който ще се изпълни задачата, и щракнете върху бутона „Напред“:

внимание!За да завърши задачата успешно, трябва да предоставите посочения тук акаунт (домейн или локален компютър) разрешения за запис в горната папка "\\BACKUP_SERVER\Папка", както и да конфигурирате достъпа до самия SQL Server.

Щракнете върху бутона „Край“.

Забележка. За да проверите функционалността на създадената задача, трябва да щракнете с десния бутон върху задачата, която ви интересува в списъка със задачи (Контролен панел->Планирани задачи) и контекстно менюизберете „Run“, след което се уверете, че архивният файл на базата данни е създаден успешно в пътищата, посочени в стъпка a).

Използване на "SQL Server Agent" (не е включен в безплатната версия)

За да създадете работа в SQL Server Agent, трябва да:

Стартирайте помощната програма SQL Server Management Studio и се свържете със сървъра под администраторски акаунт.

В лявата част на прозореца щракнете с десния бутон върху секцията „Сървърни обекти/Устройства за архивиране“ и изберете „Създаване на устройство за архивиране“ в контекстното меню:

В полето „Име на устройството“ въведете името, което ще бъде свързано с архивния файл на базата данни, променете пътя в полето „Файл“, ако е необходимо, и щракнете върху „OK“:

В лявата част на прозореца щракнете с десния бутон върху секцията „SQL Server Agent/Tasks“ и изберете „Create task“ в контекстното меню:

В полето „Име“ въведете името на задачата:

На страницата „Стъпки“ щракнете върху бутона „Създаване“:

В прозореца, който се показва, въведете име в полето „Име на стъпка“, уверете се, че „Transact-SQL (T-SQL) скрипт“ е избрано в полето „Тип“ и въведете реда в полето „Команда“ :

РЕЗЕРВНО КОПИРАНЕ НА БАЗА ДАННИ AltaSVHDb КЪМ AltaSVHDb_monday С INIT, NOFORMAT, SKIP, NOUNLOAD

Където "AltaSVHDb"- име на база данни, „AltaSVHDb_понеделник“- име на устройството за архивиране, създадено в стъпка c) (ще варира според деня от седмицата):

В предишния прозорец щракнете върху бутона „OK“, в резултат на това на страницата „Стъпки“ трябва да се появи следният ред:

За да може резервният файл на базата данни да бъде незабавно копиран на друг компютър в мрежата, трябва да повторите стъпки f) - h), в прозореца „Стъпка за създаване на задание“, като изберете „Тип“ в полето „Тип“ операционна система(CmdExec)", и в полето „Команда", като посочите реда:

XCOPY D:\MSSQL\BACKUP\AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

Където "D:\MSSQL\BACKUP\AltaSVHDb_monday.bak"- пътят, посочен в стъпка c) (ще варира според деня от седмицата), "BACKUP_SERVER"- името на компютъра, на който ще бъде направено копието, "Папка"- папка на този компютър (трябва да се сподели):

Забележка. За да може файлът да бъде копиран успешно, трябва да стартирате „SQL Server Agent“ под акаунт на домейн на Windows, на който са предоставени права за запис в гореспоменатата папка (вижте също „SQL2005_installation.doc“ или „SQL2008_installation.doc“ ), както и конфигуриран достъп до самия SQL сървър (вижте раздела „Задаване на права за достъп до базата данни“, активирайте това сметкатрябва да въведете ролята „sysadmin“ на страницата „Roles на сървъра“ и да не правите нищо на страниците „User Mapping“ и „Securable Objects“).

На страницата „Графици“ щракнете върху бутона „Създаване“:

Въведете име в полето „Име“, уверете се, че „Повтаряща се задача“ е избрано в полето „Тип график“ и „Седмично“ е избрано в полето „Изпълнение“. Поставете отметка в квадратчето до желания ден от седмицата (премахнете отметката от останалите) и в полето „Еднократна задача“ посочете часа, когато процесът на архивиране трябва да започне (обикновено това се прави през нощта):

В предишния прозорец щракнете върху бутона „OK“, в резултат на това на страницата „Графици“ трябва да се появи следният ред:

Щракнете върху бутона „OK“.

Забележка. За да проверите функционалността на създадената задача, трябва да щракнете с десния бутон върху задачата, която ви интересува в секцията „SQL Server Agent/Tasks“ и да изберете „Run task at a step“ в контекстното меню, изберете първата стъпка от това задача в появилия се прозорец и щракнете върху „OK“. След това ще се появи прозорец, показващ напредъка на задачата. Ако задачата завърши с грешка, тогава Подробно описаниегрешките могат да се видят чрез извикване на елемента „Преглед на журнала“ в същото контекстно меню.