Архивиране, част 1: Цел, преглед на методи и технологии

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

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

-Неизвестен

Тъй като програмите все още се пишат от разработчици на протеини и често няма процес на тестване, освен това програмите рядко се доставят с помощта на „най-добри практики“ (които сами по себе си също са програми и следователно несъвършени), системните администратори най-често трябва да решават проблеми, които звучат накратко, но накратко: „върнете се към това, което беше“, „доведете базата до нормална работа“, „работи бавно - върнете се“, а също и любимото ми „не знам какво, но го поправете“.

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

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

Добрите художници копират, големите художници крадат.

— Пабло Пикасо.

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

Например, птиците и самолетите имат крила, но въпреки функционалното сходство - принципът на работа в някои режими е един и същ, а техническите проблеми се решават по подобен начин: кухи кости, използването на здрави и леки материали и т.н. резултатите са напълно различни, макар и много сходни. Най-добрите примери, които виждаме в нашата технология, също са до голяма степен заимствани от природата: отделенията под налягане на кораби и подводници са пряка аналогия с пръстеновидните червеи; изграждане на raid масиви и проверка на целостта на данните - дублиране на ДНК веригата; както и сдвоени органи, независимост на работата на различни органи от централната нервна система (автоматизация на сърцето) и рефлекси - автономни системи в интернет. Разбира се, приемането и прилагането на готови решения „напред“ е изпълнено с проблеми, но кой знае, може би няма други решения.

Само да знаех къде ще паднеш, сламки щях да тегля!

— Беларуска народна поговорка

Това означава, че резервните копия са жизненоважни за тези, които искат:

• Бъдете в състояние да възстановите работата на вашите системи с минимален престой или дори без него
• Действайте смело, защото в случай на грешка винаги има възможност за връщане назад
• Минимизиране на последствията от умишлено повреждане на данни

Ето малко теория

Всяка класификация е произволна. Природата не класифицира. Класифицираме, защото така ни е по-удобно. И ние класифицираме според данни, които също вземаме произволно.

— Жан Брюлер

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

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

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

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

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

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

— Има два вида системни администратори, тези, които не правят резервни копия, и тези, които ВЕЧЕ го правят.
- Всъщност има три вида: има и такива, които проверяват дали архивите могат да бъдат възстановени.

-Неизвестен

Също така си струва да се разбере, че самият процес на архивиране на данни се извършва от програми, така че има всички същите недостатъци като всяка друга програма. За да се премахне (а не да се премахне!) зависимостта от човешкия фактор, както и характеристики - които поотделно нямат силен ефект, но заедно могат да дадат забележим ефект - т.нар. правило 3-2-1. Има много опции за това как да го дешифрирам, но следната интерпретация ми харесва повече: 3 набора от едни и същи данни трябва да се съхраняват, 2 набора трябва да се съхраняват в различни формати и 1 набор трябва да се съхранява в географски отдалечено хранилище.

Форматът на съхранение трябва да се разбира, както следва:

• Ако има зависимост от метода на физическо съхранение, ние променяме физическия метод.
• Ако има зависимост от логическия метод на съхранение, ние променяме логическия метод.

За да постигнете максимален ефект от правилото 3-2-1, се препоръчва да промените формата за съхранение и по двата начина.

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

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

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

Диференциалните инкрементални архиви са опит да се спести място за съхранение на резервни копия. По този начин в резервното копие се записват само променени данни от предишния архив.

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

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

Quis custodiet ipsos custodes?

(Кой ще пази самите пазачи? - лат.)

Много е неприятно, когато няма резервни копия, но е много по-лошо, ако изглежда, че е направено резервно копие, но при възстановяване се оказва, че не може да бъде възстановено, защото:

• Целостта на изходните данни е компрометирана.
• Резервното хранилище е повредено.
• Възстановяването работи много бавно; не можете да използвате данни, които са били частично възстановени.

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

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

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

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

Експерт в подправките не е този, който ги добавя към всяко ястие, а този, който никога не добавя нищо допълнително към него.

-IN. Синявски

Практиките по отношение на софтуера, използван от системните администратори, може да варират, но общите принципи все още са, по един или друг начин, едни и същи, по-специално:

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

Има следните общи програми за архивиране от блокови устройства:

• dd, познат на ветераните в системната администрация, това включва и подобни програми (същия dd_rescue, например).
• Помощни програми, вградени в някои файлови системи, които създават дъмп на файловата система.
• Всеядни комунални услуги; например partclone.
• Собствени, често частни решения; например NortonGhost и по-нови.

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

• Rsync, програма с общо предназначение и протокол за синхронизиране на състоянието на файловите системи.
• Вградени инструменти за архивиране (ZFS).
• Инструменти за архивиране на трети страни; най-популярният представител е катран. Има и други, например dar - заместител на tar, насочен към съвременните системи.

Заслужава да се спомене отделно за софтуерните инструменти за осигуряване на последователност на данните при създаване на резервни копия. Най-често използваните опции са:

• Монтиране на файловата система в режим само за четене (ReadOnly) или замразяване на файловата система (freeze) - методът е с ограничена приложимост.
• Създаване на моментни снимки на състоянието на файлови системи или блокови устройства (LVM, ZFS).
• Използване на инструменти на трети страни за организиране на импресии, дори в случаите, когато предишните точки не могат да бъдат предоставени по някаква причина (програми като hotcopy).
• Техниката копиране при промяна (CopyOnWrite) обаче най-често е свързана с използваната файлова система (BTRFS, ZFS).

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

• Лесен за използване - не са необходими специални допълнителни стъпки по време на работа, минимални стъпки за създаване и възстановяване на копия.
• Универсален - работи както на големи, така и на малки сървъри; това е важно при увеличаване на броя на сървърите или мащабиране.
• Инсталира се от мениджър на пакети или чрез една или две команди като „изтегляне и разопаковане“.
• Стабилен - използва се стандартен или отдавна установен формат за съхранение.
• Бърз в работата.

Кандидати от тези, които повече или по-малко отговарят на изискванията:

• rdiff-резервно копие
• rsnapshot
• оригване
• дубликат
• лицемерие
• нека дуп
• но
• zbackup
• резистичен
• borgbackup

Виртуална машина (базирана на XenServer) със следните характеристики ще бъде използвана като стенд за тестване:

• 4 ядра 2.5 GHz,
• 16 GB RAM,
• 50 GB хибридно съхранение (система за съхранение с кеширане на SSD 20% от размера на виртуалния диск) под формата на отделен виртуален диск без разделяне,
• 200 Mbps интернет канал.

Почти същата машина ще се използва като резервен приемен сървър, само че с 500 GB твърд диск.

Операционна система - Centos 7 x64: стандартен дял, допълнителен дял ще се използва като източник на данни.

Като първоначални данни нека вземем WordPress сайт с 40 GB медийни файлове и mysql база данни. Тъй като виртуалните сървъри се различават значително по характеристики, а също и за по-добра възпроизводимост, ето

резултати от тестване на сървъра с помощта на sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 изпълнение на процесора
sysbench 1.1.0-18a9f86 (с използване на пакет LuaJIT 2.1.0-beta3)
Изпълнение на теста със следните опции:
Брой нишки: 4
Инициализиране на генератора на случайни числа от текущото време

Ограничение за прости числа: 20000 XNUMX

Работните нишки се инициализират...

Темите започнаха!

Скорост на процесора:
събития в секунда: 836.69

Пропускателна:
събития/и (eps): 836.6908
изминало време: 30.0039s
общ брой събития: 25104

Закъснение (ms):
мин.: 2.38
ср.: 4.78
макс.: 22.39
95-ти процентил: 10.46
сума: 119923.64

Честност на нишките:
събития (ср./стандартно отклонение): 6276.0000/13.91
време за изпълнение (ср./стандартно отклонение): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=четене на изпълнение на паметта
sysbench 1.1.0-18a9f86 (с използване на пакет LuaJIT 2.1.0-beta3)
Изпълнение на теста със следните опции:
Брой нишки: 4
Инициализиране на генератора на случайни числа от текущото време

Изпълнение на тест за скорост на паметта със следните опции:
размер на блока: 1KiB
общ размер: 102400MiB
операция: прочетете
обхват: глобален

Работните нишки се инициализират...

Темите започнаха!

Общо операции: 50900446 (1696677.10 в секунда)

49707.47 MiB прехвърлени (1656.91 MiB/сек)

Пропускателна:
събития/и (eps): 1696677.1017
изминало време: 30.0001s
общ брой събития: 50900446

Закъснение (ms):
мин.: 0.00
ср.: 0.00
макс.: 24.01
95-ти процентил: 0.00
сума: 39106.74

Честност на нишките:
събития (ср./стандартно отклонение): 12725111.5000/137775.15
време за изпълнение (ср./стандартно отклонение): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=запис изпълнение на памет
sysbench 1.1.0-18a9f86 (с използване на пакет LuaJIT 2.1.0-beta3)
Изпълнение на теста със следните опции:
Брой нишки: 4
Инициализиране на генератора на случайни числа от текущото време

Изпълнение на тест за скорост на паметта със следните опции:
размер на блока: 1KiB
общ размер: 102400MiB
операция: запис
обхват: глобален

Работните нишки се инициализират...

Темите започнаха!

Общо операции: 35910413 (1197008.62 в секунда)

35068.76 MiB прехвърлени (1168.95 MiB/сек)

Пропускателна:
събития/и (eps): 1197008.6179
изминало време: 30.0001s
общ брой събития: 35910413

Закъснение (ms):
мин.: 0.00
ср.: 0.00
макс.: 16.90
95-ти процентил: 0.00
сума: 43604.83

Честност на нишките:
събития (ср./стандартно отклонение): 8977603.2500/233905.84
време за изпълнение (ср./стандартно отклонение): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (с използване на пакет LuaJIT 2.1.0-beta3)
Изпълнение на теста със следните опции:
Брой нишки: 4
Инициализиране на генератора на случайни числа от текущото време

Флагове за отваряне на допълнителни файлове: (няма)
128 файла, 8MiB всеки
1GiB общ размер на файла
Размер на блока 4KiB
Брой IO заявки: 0
Съотношение четене/запис за комбиниран произволен IO тест: 1.50
Активиран периодичен FSYNC, извикващ fsync() на всеки 100 заявки.
Извикване на fsync() в края на теста, разрешено.
Използване на синхронен I/O режим
Извършване на случаен r/w тест
Работните нишки се инициализират...

Темите започнаха!

Пропускателна:
четене: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
запис: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

Закъснение (ms):
мин.: 0.00
ср.: 0.27
макс.: 18.01
95-ти процентил: 1.08
сума: 238469.45

Тази бележка започва голямо

серия от статии за архивиране

1. Архивиране, част 1: Защо е необходимо архивиране, преглед на методите, технологиите
2. Архивиране Част 2: Преглед и тестване на базирани на rsync инструменти за архивиране
3. Архивиране, част 3: Преглед и тестване на дублиране, дублиране, дежа дублиране
4. Архивиране Част 4: Преглед и тестване на zbackup, restic, borgbackup
5. Архивиране, част 5: Тестване на bacula и veeam архивиране за linux
6. Архивиране, част 6: Сравняване на инструментите за архивиране
7. Архивиране Част 7: Заключения

Източник: www.habr.com