Глава 7. Архивиране и възстановяване на данни с помощта на Acronis True Image Home Днес на пазара има много различни продукти за архивиране и възстановяване и ние вече се запознахме с някои от тях в

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

Данните често са много ценни. И няма значение дали това са лични файлове или информация, която се използва за работа. Нека да видим какви функции за архивиране и възстановяване на данни разработчиците на Microsoft са оборудвани с най-новата версия на своята операционна система - Windows 10, а също така да разгледаме възможността за архивиране на възстановяване на данни с помощта на програми на трети страни.

Архивиране на данни: какво е това?

Архивиране на файл

Понякога чуваме за необходимостта да „архивирате компютъра си“. Но не е съвсем правилно да се каже така, тъй като има два начина за архивиране на данни. Първо, създаване на резервно копие на файлове, с което можете да създавате копия на отделни файлове и папки, съхранявани на компютър или друг носител за съхранение. Всеки потребител, който има важни данни, съхранявани на компютъра, трябва да ги архивира на външен твърд диск, в случай че оригиналният източник бъде загубен или изтрит.

Системно архивиране

Друг начин за архивиране на данни е известен като System Backup или System Image. Това е по-сложен начин за архивиране на данни, тъй като в този случай говорим за създаване на копие на цялата операционна система на конкретен компютър, заедно с програми, файлове и настройки. Резервно копие на системата се използва за възстановяването му, ако Windows стане нестабилна или спре да работи напълно.

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

Архивиране и възстановяване на данни с помощта на Windows

Windows 10 има вградени инструменти, които са предназначени да създават резервни копия на файлове и системата, както и да възстановяват информация с тяхна помощ. Много потребители не ги използват, без да знаят за тяхното съществуване или как да ги конфигурират правилно. Те са по-склонни да използват програми на трети страни, отколкото инструменти, вградени в операционната система.

История на файловете

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

За да настроите История на файловете, отидете в менюто "Старт" и изберете Настройки. В менюто Опции, което се отваря, отидете на Актуализация и сигурност / Услуга за архивиране.

От дясната страна на панела, в секцията Архивиране с помощта на хронология на файлове, щракнете върху Добавяне на диск. Ще бъдете подканени да изберете един от външните носители за съхранение, свързани към вашия компютър. Изберете този, към който искате да архивирате данни и задайте параметрите за архивиране: интервалът за запазване на файлови копия и продължителността на тяхното съхранение, ако е необходимо, можете да посочите конкретна папка за копие на файлове, от които искате да създадете или премахнете ненужния.

По време на архивиране, File History също така автоматично копира всички папки на потребителски акаунт: снимки, документи, изтегляния и т.н.

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

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

Възстановяване на файлове от резервно копие

За да възстановите файлове от резервно копие, отидете на контролния панел и изберете менюто File History.

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

Облачна услуга OneDrive

Друг начин да се предпазите от загуба на важни файлове е да ги прехвърлите в облачно хранилище и да го синхронизирате с вашия компютър. Има много такива хранилища: Dropbox, Google диски т.н. Но особеност на най-новите версии на Windows (10, 8, 8.1) е наличието на собствена облачна услуга на Microsoft, вградена в операционната система, наречена OneDrive.

Когато използват някоя от облачните услуги, те обикновено създават папка на диска на компютъра под свое име, файловете от която се синхронизират. V най-новите версии Windows папка OneDrive съществува по подразбиране, т.е. Услугата е достъпна за всеки потребител веднага след инсталиране на операционната система.

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

Точка на възстановяване

Друга страна на архивирането и възстановяването Данни на Windows 10, има възстановяване системни файловеи производителност на операционната система. Създаването и възстановяването на архив на операционната система е по-сложен процес, отколкото с личните файлове и папки на потребителя. Но за това Windows 10 предоставя специална функция - Възстановяване на системата. С негова помощ потребителят може да върне работоспособността на операционната система, като се „връща обратно“ към запазеното ранно състояние - точката на възстановяване.

По подразбиране функцията за възстановяване в операционната система не е активирана. За да можете да го използвате, той трябва да бъде конфигуриран. Възстановяването на системата работи чрез създаване на точки за възстановяване, които запазват състоянието на Windows в определен момент от време. Наред с настройките и състоянието на операционната система, точката за възстановяване включва инсталирани приложения(Например, Microsoft Office) и драйвери на устройства (например видеокарти).

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

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

За да направите това, отидете в Control Panel и изберете менюто Recovery / System Recovery Settings / Customize, с което активирате и конфигурирате функцията.

За да възстановите Windows от точка за възстановяване, отидете на контролния панел и изберете менюто Възстановяване / Стартиране на възстановяване на системата, изберете необходимата точка за възстановяване и щракнете върху Напред.

Изображение на системата

Вероятно най-основната и сложна функция за архивиране на Windows е функция, наречена System Image.

Използвайки тази опция, можете да създадете „дубликат“ на целия компютърен диск, включително Windows 10, както и всички програми и лични данни на потребителя. Образът на системата се записва на външен твърд диск, от който, ако е необходимо или компютърът се повреди, се разгръща обратно на твърдия диск на компютъра. В резултат на това потребителят получава работеща версия на операционната система, заедно с програми и файлове.

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

За да създадете системно изображение, отидете на контролния панел и изберете менюто File Backup and Restore. В колоната отляво щракнете върху Създаване на системно изображение и изберете устройството, където искате да го запишете. Имайте предвид, че изображението на системата обикновено е голямо.

За да възстановите системата от системно изображение, отидете на Системни настройки / Актуализация и сигурност / Възстановяване и изберете специални опции за зареждане. След рестартиране на Windows 10 изберете System Image Recovery от предоставеното меню.

Други програми за архивиране и възстановяване Windows файлове 10

АЛЕКСЕЙ БЕРЕЖНИ,Системен администратор. Основни дейности: виртуализация и хетерогенни мрежи. Друго хоби освен писането на статии е популяризирането на безплатния софтуер.

Архивиране
Теория и практика. Резюме

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

Архивирането (или, както още се нарича, архивиране - от английската дума „backup“) е важен процес в живота на всяка ИТ структура. Това е парашут за спасяване в случай на непредвидена катастрофа. В същото време архивирането се използва за създаване на своеобразен исторически архив на дейността на компанията през определен период от нейния живот. Да работиш без дубльор е като да живееш на открито – времето всеки момент може да се влоши и няма къде да се скриеш. Но как да го организирате правилно, за да не загубите важни данни и да не харчите фантастични суми за това?

Обикновено се фокусират основно статии на тема организиране на архивиране технически решения, като само от време на време се обръща внимание на теорията и методите за организиране на съхранение на данни.

В тази статия ще говорим точно за обратното: основното внимание се обръща на общите понятия, а техническите средства ще бъдат засегнати само като примери. Това ще ни позволи да се абстрахираме от хардуера и софтуера и да отговорим на два основни въпроса: „Защо правим това?“, „Можем ли да направим това по-бързо, по-евтино и по-надеждно?“.

Цели и задачи на архивирането

В процеса на организиране на архивиране се поставят две основни задачи: възстановяване на инфраструктурата в случай на повреди (Disaster Recovery) и поддържане на архив с данни с цел последващо осигуряване на достъп до информация за минали периоди.

Класически пример за архивиране за Disaster Recovery е изображение на системния дял на сървъра, създадено от Acronis True Image.

Пример за архив може да бъде месечно качване на бази данни от 1C, записани на касети с последващо съхранение на специално определено място.

Има няколко фактора, които отличават резервното копие за бързо възстановяванеот архива:

• Период на съхранение на данни.За архивни копия е доста дълъг. В някои случаи то е регламентирано не само от изискванията на бизнеса, но и от закона. За копия за аварийно възстановяване той е сравнително малък. Обикновено се създават едно или две (с повишени изисквания за надеждност) резервни копия за Disaster Recovery с максимален интервал от ден-два, след което се презаписват с нови. В особено критични случаи е възможно и по-често да актуализирате архива за аварийно възстановяване, например веднъж на всеки няколко часа.
• Скорост на достъп до данни.Скоростта на достъп до дългосрочен архив не е критична в повечето случаи. Обикновено необходимостта от „събиране на данни за периода“ възниква в момента на съгласуване на документите, връщане към предишна версият.н., тоест не в авариен режим. Друго нещо е възстановяването при бедствия, когато необходимите данни и производителност на услугите трябва да бъдат върнати възможно най-скоро. В този случай скоростта на достъп до архива е изключително важен показател.
• Съставът на копираната информация.Архивът обикновено съдържа само потребителски и бизнес данни за посочения период. Копието за аварийно възстановяване съдържа, в допълнение към тези данни, или системни изображения, или копия на настройките на операционната система и приложния софтуер и друга информация за възстановяване.

Понякога е възможно да се комбинират тези задачи. Например годишен набор от месечни пълни „моментни снимки“ на файлов сървър плюс промени, направени през седмицата. True Image е подходящ като инструмент за създаване на такъв архив.

Най-важното е ясно да разберете за какво е резервацията. Нека ви дам пример: критичен SQL сървър се провали поради повреда на дисков масив. Имаме правилния на склад Хардуер, така че решението на проблема беше само възстановяването на софтуера и данните. Ръководството на компанията задава разбираем въпрос: "Кога ще заработи?" - и е неприятно изненадан да научи, че възстановяването ще отнеме цели четири часа. Факт е, че през целия живот на сървъра редовно се архивираха само бази данни, без да се отчита необходимостта от възстановяване на самия сървър с всички настройки, включително софтуерсамата СУБД. Просто казано, нашите герои са запазили само бази данни и са забравили за системата.

Ще ви дам друг пример. През цялата си кариера младият професионалист създава едно копие на файлов сървър, работещ под Windows Server 2003, използвайки програмата ntbackup, включително данните и състоянието на системата в споделена папка на друг компютър. Поради липса на дисково пространство, това копие непрекъснато се презаписваше. Известно време по-късно той беше помолен да възстанови предишна версия на многостраничен доклад, който е бил повреден при запазване. Ясно е, че след като няма архивна история с изключено Shadow Copy, той не може да изпълни тази заявка.

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

С малки количества данни и не много сложна ИТ инфраструктура, можете да опитате да комбинирате и двете задачи в една, например да правите ежедневно пълно архивиране на всички дискови дялове и бази данни. Но все пак е по-добре да правите разлика между две цели и да изберете правилните средства за всяка от тях. Съответно за всяка задача се използва различен инструмент, въпреки че има универсални решения, като пакета Acronis True Image или програмата ntbackup

Ясно е, че при определяне на целите и задачите на архивирането, както и решенията за внедряване, е необходимо да се изхожда от бизнес изискванията.

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

В някои случаи е необходимо системата да се възстанови директно до "гол метал" (bare metal). Това може да се направи например с помощта на програмата Acronis True Image, която е в комплект с модула Universal Restore. В този случай конфигурацията на сървъра може да бъде върната в експлоатация за много кратко време. Например, дял с операционна система от 20 GB е доста реалистично да се вдигне от резервно копие за осем минути (при условие, че архивното копие е достъпно в мрежа от 1 GB / s).

При друг вариант е по-целесъобразно просто да „върнете“ настройките към новоинсталираната система, като копиране на конфигурационни файлове от папката /etc и други на UNIX-подобни системи (в Windows това приблизително съответства на копиране и възстановяване на Състояние на системата). Разбира се, с този подход сървърът ще бъде пуснат в експлоатация не по-рано от инсталирането на операционната система и възстановяването на необходимите настройки, което ще отнеме много повече дългосрочен. Но във всеки случай решението какво да бъде Disaster Recovery произтича от нуждите на бизнеса и ресурсните ограничения.

Основната разлика между резервните и резервните системи за резервиране

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

Чувал съм фразата: „Имаме много надеждно оборудване, навсякъде има RAID масиви, така че нямаме нужда от резервни копия“. Да, разбира се, същият RAID масив ще спаси данните от унищожаване, ако един твърд диск се повреди. Но това е от повреда на данните компютърен вирусили няма да спаси от неумелите действия на потребителя. Той няма да запази RAID, дори ако файловата система се срине в резултат на неоторизирано рестартиране.

Ще дам един пример. Има случаи, когато събитията се развиват по следния сценарий: когато диск се повреди, данните се възстановяват поради механизма за резервиране, по-специално с помощта на запазени контролни суми. В същото време се наблюдава значително намаляване на производителността, сървърът замръзва, контролът е почти загубен. Системен администратор, като не вижда друг изход, рестартира сървъра със студено рестартиране (с други думи, щраква върху "RESET"). В резултат на такова претоварване на живо възникват грешки в файловата система. Най-доброто, което може да се очаква в този случай, е продължителната работа на проверката на диска, за да се възстанови целостта на файловата система. В най-лошия случай трябва да се сбогувате с файлова системаи бъдете озадачени от въпроса къде, как и в какъв период от време можете да възстановите данните и производителността на сървъра.

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

Единственото нещо, което може да действа като по-нисък резервен заместител за Disaster Recovery, е наличието на огледален резервен сървър с постоянно репликация на данни от главния сървър към резервния (според принципа Primary  Standby). В този случай, ако основният сървър се повреди, неговите задачи ще бъдат поети от резервния и дори няма да се налага да прехвърляте данни. Но такава система е доста скъпа и отнема много време за организиране. Не забравяйте за необходимостта от постоянна репликация.

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

И, разбира се, никоя система за излишно дублиране няма да реши проблема с поддържането на архив с данни за определен период.

Концепцията за "резервен прозорец"

Извършването на архивиране натоварва силно излишния сървър. Това е особено вярно за дисковата подсистема и мрежовите връзки. В някои случаи, когато процесът на копиране е достатъчно висок приоритет, това може да доведе до недостъпност на определени услуги. Освен това копирането на данни по време на промените е свързано със значителни трудности. Разбира се, има технически средства за избягване на проблеми при запазване на целостта на данните в този случай, но ако е възможно, такова копиране в движение е най-добре да се избягва.

Изходът при решаването на тези проблеми, описани по-горе, се подсказва сам: да се отложи стартирането на процеса на създаване на копие за неактивен период от време, когато взаимното влияние на архивирането и другите работещи системи ще бъде минимално. Този период от време се нарича "резервен прозорец". Например, за организация, работеща по формула 8x5 (пет осемчасови работни дни в седмицата), такъв „прозорец“ обикновено са уикендите и нощните часове.

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

Видове архивиране

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

Пълно архивиране (или пълно архивиране)

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

Инкрементално копие

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

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

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

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

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

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

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

Резервна топология

Нека да разгледаме какви са схемите за архивиране.

децентрализирана схема

Ядрото на тази схема е мрежовото споделяне (вижте фигура 1). Например споделена папка или FTP сървър. Необходим е и набор от програми за архивиране, които от време на време качват информация от сървъри и работни станции, както и други мрежови обекти (например конфигурационни файлове от рутери) към този ресурс. Тези програми са инсталирани на всеки сървър и работят независимо една от друга. Несъмненото предимство е лекотата на изпълнение на тази схема и нейната ниска цена. Като програми за копиране са подходящи обикновени инструменти, вградени в операционната система, или софтуер като СУБД. Например, това може да бъде програмата ntbackup за семейството на Windows, програмата tar за UNIX-подобни операционни системи или набор от скриптове, съдържащи вградени SQL сървърни команди за изхвърляне на бази данни в архивни файлове. Друг плюс е възможността за използване на различни програми и системи, стига всички те да имат достъп до целевия ресурс за съхранение на архиви.

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

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

Централизирано архивиране

За разлика от предишната схема, този случай използва ясен йерархичен модел, който работи на принципа "клиент-сървър". В класическата версия на всеки компютър се инсталират специални агентски програми, а на централния сървър е инсталиран сървърен модул на софтуерния пакет. Тези системи имат и специализирана конзола за управление на сървъра. Схемата за управление е следната: от конзолата създаваме задачи за копиране, възстановяване, събиране на информация за системата, диагностика и т.н., а сървърът дава на агентите необходимите инструкции за извършване на тези операции.

Повечето от популярните системи за архивиране работят на този принцип, като Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula и други (вижте фигура 2).

В допълнение към различни агенти за повечето операционни системи, има разработки за архивиране на популярни бази данни и корпоративни системи, например, за MS SQL Server, MS Exchange, Oracle Database и т.н.

За много малки компании в някои случаи можете да опитате опростена версия на схемата за централизирано архивиране без използването на агентски програми (вижте фигура 3). Също така, тази схема може да се използва, ако не е внедрен специален агент за използвания софтуер за архивиране. Вместо това сървърният модул ще използва вече съществуващи услуги и услуги. Например, "извличане" на данни от скрити споделени папкина Windows сървъри или копирайте файлове с помощта на SSH протоколот сървъри, работещи под UNIX системи. Тази схема има много значителни ограничения, свързани с проблемите със запазването на файлове, отворени за запис. В резултат на такива действия отворените файлове или ще бъдат пропуснати и няма да бъдат включени в архива, или ще бъдат копирани с грешки. Има различни решения за този проблем, като например повторно изпълнение на заданието за копиране само на предварително отворени файлове, но нито един не е надежден. Следователно такава схема е подходяща за използване само в определени ситуации. Например в малки организации, работещи в режим 5x8, с дисциплинирани служители, които запазват промените и затварят файлове, преди да напуснат дома. За организиране на такава съкратена централизирана схема, работеща изключително в Windows среда, ntbackup работи добре. Ако трябва да използвате подобна схема в хетерогенни среди или изключително сред UNIX компютри, препоръчвам да погледнете към Backup PC (вижте).

Фигура 4. Смесена схема за архивиране

Какво е извън сайта?

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

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

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

Отделно си струва да споменем мерките за сигурност при организацията на съхранение на данни. На първо място е необходимо да се внимава носителите на данни да са в защитено помещение и да се вземат мерки, които не позволяват на неоторизирани лица да прочетат данните. Например, използвайте система за криптиране, сключвайте споразумения за неразкриване и т.н. Ако се включва сменяем носител, данните върху него също трябва да бъдат криптирани. Използваната система за маркиране не трябва да помага на нападателя при анализа на данните. Необходимо е да се използва безлика схема за номериране за маркиране на носителите на имената на прехвърлените файлове. Когато прехвърляте данни през мрежа, е необходимо (както вече беше споменато по-горе) да използвате сигурни методи за пренос на данни, например VPN тунел.

Анализирахме основните моменти при организиране на резервно копие. В следващата част ще бъдат разгледани методически препоръки и практически примериза създаване на ефективна система за архивиране.

1. Описание на архива Windows система, включително състоянието на системата - http://www.datamills.com/Tutorials/systemstate/tutorial.htm.
2. Описание на Shadow Copy - http://ru.wikipedia.org/wiki/Shadow_Copy.
3. Официален уебсайт на Acronis - http://www.acronis.ru/enterprise/products.
4. Описанието на ntbackup е http://en.wikipedia.org/wiki/NTBackup.
5. Бережной А. Оптимизиране на работата на MS SQL Server. // Системен администратор, No1, 2008 - С. 14-22 ().
6. Бережной А. Ние организираме резервна система за малки и средни офиси. // Системен администратор, No 6, 2009 - С. 14-23 ().
7. Маркелов А. Linux на стража на Windows. Преглед и инсталиране на системата за архивиране на BackupPC. // Системен администратор, No9, 2004 - С. 2-6 ().
8. Описание на VPN - http://ru.wikipedia.org/wiki/VPN.
9. Дедупликация на данни - http://en.wikipedia.org/wiki/Data_deduplication.

Във връзка с

Почти всички наши клиенти, които са внедрили резервна система (BMS), смятат, че това решава всичките им проблеми. Те направиха всичко по силите си, за да гарантират, че всичко е архивирано и, в случай на авария, правилно възстановено. Но често се случва така: компанията е изправена пред сериозен проблем и традиционната система за архивиране не ви позволява да се възстановите в рамките на времето, което компанията счита за цел. Всъщност SLA, който трябва да спазва системата за архивиране, не е спазен. Уви, по време на нашата работа натрупахме много тъжни примери, потвърждаващи това. По-долу представяме два случая и даваме съвети какви технически средства ще намалят времето за възстановяване. При избора на случаи се фокусирахме върху примери, свързани с бази данни, където се съхранява най-критичната за бизнеса информация.

Предизвикателства на дребно

Клиент:голяма застрахователна компания.

Кратко описание на причината за срива: грешка на персонала, неправилна инсталация на корекция на Oracle.

Описание на проблема

Говорим за голяма компания, която има зрял ИТ отдел и инвестира достатъчно в своето оборудване и персонал. Достатъчно е да се каже, че СУБД на Oracle работеше на два Oracle Exadata, разпределени в два технологични сайта, с добре развито DR решение и персонализирана система за архивиране.

Един тъжен ден беше решено да се инсталира корекция на СУБД на Oracle. За съжаление, инженерът не прочете инструкциите до края: „Какво, няма да инсталирам пластира без лист хартия?!” - и го направи погрешно. Грешката беше забелязана няколко часа по-късно, когато СУБД започна да се държи странно и да го отчита в логовете. Тогава инженерът реши да се върне назад. Това действие най-накрая обездвижи и двете копия на базата данни (всички промени успяха да бъдат репликирани в режим на готовност) и повреди всички данни.

Компанията остана без основния си информационен актив – база данни, чрез която работеха всички бизнес процеси. Бизнесът на практика спря.

Решение

Клиентът е решил да възстанови от резервно копие. По това време възстановяването на база данни от 5 TB (сега ~ 15 TB) отне - внимание! - над 30 часа!Общо след 1,5 дни базата беше възстановена ден преди инцидента. Но имаше повече данни! Всичко останало е възстановено от програмисти и служители от други фирмени системи, от първична документация (формуляри за кандидатстване, копия, сканирания). Отне още 1,5 дни упорита работа.

Обща сума

2 висок клас Oracle Exadata системи, Oracle Standby, работеща резервна система и 3!!! дни пълен престойпри неправилна инсталациякръпка. Това беше позволено от политиката на компанията? Разбира се, че не.

Основният проблем: липсата на инструменти за бързо възстановяване на логически грешки.

Как можахте да избегнете

За да смекчите последствията от подобни аварии, трябва да се движите в две посоки. От една страна да правите по-често резервни копия, а от друга да можете бързо да се възстановявате. Следните продукти могат да помогнат:

Oracle FlashBack- технология, която ви позволява не само да "навивате" нови данни към резервна система Oracle, но и връщане към желаната транзакция. С такава схема би било възможно да се върне системата, преди да са започнали проблемите с корекцията, което значително би улеснило възстановяването на данни.

Технология за моментни снимки.Моментните снимки ви позволяват да архивирате и възстановявате данни за секунди. В същото време те имат малък ефект върху производителността и е възможно да правите моментни снимки доста често (например веднъж на час). По този начин беше възможно да се върне един час назад и да се възстанови само час загубени данни.

Постоянна защита на данните- непрекъсната защита на данните. Това са собствени устройства или софтуер, които ви позволяват да регистрирате всички записи с възможност за връщане към всеки момент във времето. Работи подобно на Oracle FlashBack, но за всякакви данни.

Случай: Хардуерна повреда

Клиент:Федерална служба в един от съставните образувания на Руската федерация

Кратко описание на причината за срива: хардуерна грешка в дисковия масив.

Описание на проблема

Този път компанията има малко по-слабо развита ИТ инфраструктура, но е по-често срещана при нашите клиенти: дискови масиви от средно ниво, Oracle DBMS, Standby не се използват.

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

Решение

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

По-нататък - по-дълбоко. Компанията, както и много други, в някои моменти използваше нерегистрирани операции в Oracle, което значително подобрява производителността, но не оставя шанс за възстановяване, освен от резервно копие. Тоест трябва да се направи веднага след сесията на операцията. Естествено, с годините оперативната служба забрави за това. Така част от данните бяха напълно загубени.

Отне още няколко дни за пълно възстановяване на инфраструктурните услуги - нямаше резервни копия на операционни системи, двоични файлове, конфигурации и т.н.

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

Обща сума

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

Основни проблеми:

• RMS е настроен неправилно, пробните възстановявания не са извършени.
• Нямаше средства за бързо възстановяване в случай на авария и излишни системи.
• Нямаше ясен план за DR.

Как може да се избегне това:

• Използвайте режим на готовност на Oracle, разположен в друг масив. Това ще позволи за кратко време да преминете към работещ екземпляр на данни.
• Oracle ZDLRA би направила възможно възстановяването на базата данни на резервно оборудване за много по-кратко време.
• Правилното планиране на процесите за архивиране и възстановяване би избегнало толкова големи загуби и би се възстановило за по-малко от ден.

Заключение.От горните примери може да се види, че системите за архивиране са инсталирани и конфигурирани, но въпреки това те не успяха да се възстановят в рамките на срока, посочен в SLA.

Основни проблеми на системите за архивиране

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

Скорост на архивиране и последващо възстановяване

На този моментСкоростта на архивиране е право пропорционална на количеството данни, докато всички наши клиенти имат годишен ръст на данните от поне 30%. За 3-4 години данните поне се удвояват, но за някои компании тази цифра е дори по-висока, докато в същото време скоростта на архивиране изобщо не се променя. Тук можем да направим едно просто заключение, че тези термини и тези SLA, които са били актуални преди 3–4 години, сега трябва да бъдат поне удвоени. В същото време бизнес изискванията за възстановяване на данни (RPO / RTO) непрекъснато нарастват.

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

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

Зависимост на времето за възстановяване от количеството данни

Възстановяване с ниска грануларност

Всъщност повечето грешки се дължат на загуба на част от данните. В същото време традиционните инструменти за архивиране ви позволяват да възстановите данни директно от архивиране, но по-често трябва да възстановите цялата система. Ако вашата база данни е 15 TB, ще прекарате няколко дни в нея. Не познаваме клиенти, които имат изискване за RTO (време за възстановяване) от 2 дни. В нашата практика нямаше такива примери, когато клиентът да каже: „Момчета, нормално е да се възстановя за 2 дни, ще бъда търпелив“, ако администраторът случайно изтрие няколко реда от базата данни. Доста често срещан проблем, с който се сблъскват нашите клиенти, е как да изолират малка част от данни от резервно копие, без да го възстановяват сами (и да не прекарват няколко дни за него).

Прекомерно RPO (цел за точка на възстановяване)

В свят, където хартиените записи са изчезнали и всичко се съхранява в ИТ системите, всяка секунда се създават данни, които бихме искали да защитим незабавно – в същия момент, когато са създадени. Но с помощта на класическите системи за архивиране това не може да се направи. За всяка част от данни има определен дълъг период от време, през който тези данни съществуват по целия свят в едно копие. Нашите клиенти искат да защитават данните непрекъснато, от момента, в който се появят. Когато решите да възстановите от резервно копие, най-вероятно ще трябва да възстановите преди ден, след което данните за деня ще трябва да бъдат получени от някъде другаде. По правило това дълга работаадминистратори, което отнема няколко дни. В най-негативния сценарий това може да се превърне в загуба съществена информация. Разбира се, въпросът не се ограничава само до архивиране, той се отнася до изграждането на ИТ система като цяло, но темата за RMS в случая е много важна, не може да бъде пренебрегната.

Скрити бъгове

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

Уви, повечето от нашите клиенти не го правят. Често се случва всеки да прави резервни копия, но към момента на възстановяването се оказва, че те не могат да бъдат направени - те просто не се възстановяват, въпреки външно правилната работа на RMS. Това се случва по различни причини. И най-добрият начин да демонстрирате това е с пример. Един от нашите клиенти използваше SAP система с база данни на Oracle. Архивирането беше извършено от вградени SAP инструменти с помощта на един от най-големите доставчици на SRK.

Бяха конфигурирани 2 различни политики за архивиране: едната беше базирана на файлове - копираше данни на операционната система и софтуерни настройки, а втората - самата база данни. Тъй като те бяха насочени към една и съща система, беше създаден списък за изключване, в който беше въведена базата данни. Файловата политика взе предвид този списък и не запази онези директории, в които се намира базата данни. Поради особеностите на архитектурата на RMS, политиката за резервиране на база данни игнорира списъка с изключения и коректно копира необходимите данни.

В една от версиите на софтуера, този доставчик поправи този „бъг“, от този ден и двете политики започнаха да вземат предвид списъка с изключения и да заобикалят базата данни. Освен това това не повлия по никакъв начин на грешките в софтуера RMS, тъй като той работеше нормално: всички данни, които не са посочени в списъка, бяха архивирани нормално. Системата отчете своята изправност.

Така всичко работеше повече от шест месеца. Докато не трябва да се възстановите...

Несистематичен подход

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

Представихме няколко казуси, които показват, че подходът към защитата на данните трябва да бъде изчерпателен. Уви, SRC е просто резервен парашут, а не сребърен куршум, така че когато започнете да го създавате, трябва ясно да разберете какво място ще заеме в глобалната стратегия за защита на данните.

За да проверите колко систематично сте подходили към въпроса за изграждането на RMS, отговорете на няколко прости въпроса:

• Имате ли вграден рисков модел, в който се регистрира мястото на IBS?
• От какви неуспехи ви предпазва IBS?
• Как да се предпазите от други рискове (това може да са не само технически решения, но и други компенсаторни мерки)?
• Сигурни ли сте, че системата ще се възстанови в рамките на посочения период от време?
• Тествали ли сте това на практика?

Решение

Въз основа на собствения си опит и опита на нашите клиенти, ние се опитахме да разработим подход, който ни позволява да разрешим или значително да намалим последствията от тези проблеми. Същността на нашия подход:

Първо, трябва да отделите скоростта на архивиране и възстановяване от обема на системата.Производителите на системи за съхранение, приложен софтуер и RMS предлагат някои инструменти, които могат да се използват за решаване на този проблем. По-долу ще опиша най-обещаващите от тях.

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

Друго решение може да бъде използването на различни приложни инструменти, като Oracle Standby, DB2 HADR, MS SQL Always On. Всички тези инструменти ви позволяват да имате работно копие на продуктивна система, отделено от оригинала, което може да бъде разгърнато незабавно. Това ви позволява да започнете работа веднага след повреда.

Второто е да се даде възможност за възстановяване само на необходимите данни.Нашият подход отчита, че при възстановяване на част от данните не е необходимо да копираме цялата система, можем да възстановим данните, които са ни необходими в момента. Това се постига чрез възможността за бързо разгръщане или използване на вече разгърнати системи, които съдържат тези данни. Точно както в първия случай, моментните снимки ви позволяват да разрешите този проблем (можете бързо да отворите моментна снимка към съседен сървър и да изтеглите необходимата част от данни). Това включва и технологии за непрекъсната защита на данните, например Oracle Standby с Flashback, решения за непрекъсната защита на данните (CDP). Те ви позволяват бързо да разположите работно копие на вашите данни точен моментвреме.

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

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

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

За най-критичните системи може изобщо да няма времеви интервал - данните трябва да бъдат защитени непрекъснато. Има няколко решения от този клас, например, Oracle Standby с FlashBack, който ви позволява да върнете базата данни преди известно време, като регистрирате всички промени. Можете също да използвате Oracle ZDLRA HSS, който почти синхронно получава всички промени в базата данни или софтуерни и хардуерни системи с общо предназначениекато EMC RecoverPoint, Vision Solutions Double-Take софтуер. Те също така регистрират всички промени и ви позволяват да възстановите до всяка точка от интервала от време.

Когато става въпрос за иновации в системите за архивиране и възстановяване, не може да не се спомене Oracle Zero Data Loss Recovery Appliance (ZDLRA). Този софтуерен и хардуерен комплекс от семейството на Oracle Engineered Systems предоставя възможност за архивиране и бързо възстановяване на база данни на Oracle на всяка платформа и всяко издание (Enterprise и Standard). ZDLRA се основава на виртуални резервни бази данни (Virtual Full Backup), получени на базата на първото пълно архивиране и последващите регистрационни файлове за промени. Благодарение на тези виртуални архиви можете да възстановите базата данни във всеки момент много по-бързо, отколкото при класическото използване на RMS по схемата „пълно архивиране веднъж седмично, постепенно веднъж на ден“. Можем да кажем, че ZDLRA продължава посоката, дадена от Oracle Exadata. В Exadata, благодарение на специален софтуер, е внедрена иновативна система за съхранение, оптимизирана за задачи на Oracle Database. А в ZDLRA има специален софтуер, който оптимизира архивирането на Oracle Database.

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

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

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

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

Пето - прозрачността на системата за архивиране.Описаният интегриран подход включва изграждане на сложна система с помощта на различни технологии от различни производители. Задачата да се направи тази система наистина работеща, като се постави в нея възможността за допълнителни промени и мащабиране, не е тривиална и може да бъде решена по два начина:

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

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

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