Резервна копија, дел 1: Цел, преглед на методи и технологии

Зошто треба да правите резервни копии? На крајот на краиштата, опремата е многу, многу сигурна, а покрај тоа, има „облаци“ кои се подобри во доверливост од физичките сервери: со соодветна конфигурација, „облак“ серверот лесно може да го преживее дефектот на инфраструктурниот физички сервер, и од од гледна точка на корисниците на услугите, ќе има мал, едвај забележлив скок во временската услуга. Покрај тоа, дуплирањето на информации често бара плаќање за „дополнително“ време на процесорот, оптоварување на дискот и мрежниот сообраќај.

Идеална програма работи брзо, не пропушта меморија, нема дупки и не постои.

- Непознато

Бидејќи програмите сè уште ги пишуваат програмерите на протеини и често нема процес на тестирање, плус програмите ретко се испорачуваат со користење на „најдобри практики“ (кои самите се програми и затоа се несовршени), системските администратори најчесто треба да решаваат проблеми што звучат накратко, но пократко: „вратете се како што беше“, „доведете ја основата во нормална работа“, „работа полека - врати се назад“, а исто така и моето омилено „Не знам што, но поправете го“.

Покрај логичките грешки што се јавуваат како резултат на невнимателна работа на програмерите, или комбинација на околности, како и нецелосно знаење или недоразбирање на малите карактеристики на градежните програми - вклучително и поврзувачките и системските, вклучително и оперативните системи, драјверите и фирмверот - има и други грешки. На пример, повеќето програмери се потпираат на траење, целосно заборавајќи на физичките закони, кои сè уште е невозможно да се заобиколат со користење на програми. Ова ја вклучува бесконечната доверливост на потсистемот на дискот и, генерално, секој потсистем за складирање податоци (вклучувајќи ја RAM меморијата и кешот на процесорот!), и нула време на обработка на процесорот и отсуство на грешки при пренос преку мрежата и за време на обработката на процесор и мрежна доцнење, што е еднакво на 0. Не треба да го занемарите озлогласениот рок, бидејќи ако не го испочитувате навреме, ќе има проблеми полоши од нијансите на работењето на мрежата и дискот.

Што да се прави со проблемите што се зголемуваат со полна сила и висат над вредни податоци? Нема ништо што може да ги замени живите програмери и не е факт дека тоа ќе биде можно во блиска иднина. Од друга страна, само неколку проекти успеаја целосно да докажат дека програмата ќе работи како што е предвидено, и нема да биде нужно можно да се земат и да се применат доказите на други слични проекти. Исто така, таквите докази одземаат многу време и бараат посебни вештини и знаења, а тоа практично ја минимизира можноста за нивна употреба земајќи ги предвид роковите. Дополнително, сè уште не знаеме како да користиме ултра брза, евтина и бескрајно сигурна технологија за складирање, обработка и пренос на информации. Таквите технологии, доколку постојат, се во форма на концепти, или - најчесто - само во научно-фантастичните книги и филмови.

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

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

Најуспешните решенија и изненадувачки едноставните работи обично се случуваат таму каде што се среќаваат концепти, технологии, знаење и области на науката кои се апсолутно некомпатибилни на прв поглед.

На пример, птиците и авионите имаат крилја, но и покрај функционалната сличност - принципот на работа во некои режими е ист, а техничките проблеми се решаваат на сличен начин: шупливи коски, употреба на силни и лесни материјали итн. - резултатите се сосема различни, иако многу слични. Најдобрите примери што ги гледаме во нашата технологија, исто така, во голема мера се позајмени од природата: одделите под притисок на бродовите и подморниците се директна аналогија со анелидите; изградба на низи за рација и проверка на интегритетот на податоците - дуплирање на синџирот на ДНК; како и спарени органи, независност на работата на различни органи од централниот нервен систем (автоматизација на срцето) и рефлекси - автономни системи на Интернет. Се разбира, преземањето и примената на готови решенија „главно“ е полн со проблеми, но кој знае, можеби нема други решенија.

Само да знаев каде ќе паднеш, ќе поставев сламки!

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

Ова значи дека резервните копии се од витално значење за оние кои сакаат:

• Бидете способни да ја обновите работата на вашите системи со минимален прекин или дури и без него
• Дејствувајте смело, бидејќи во случај на грешка секогаш постои можност за враќање назад
• Минимизирајте ги последиците од намерното оштетување на податоците

Еве малку теорија

Секоја класификација е произволна. Природата не класифицира. Класифицираме затоа што ни е попогодно. И ние класифицираме според податоци кои исто така произволно ги земаме.

- Жан Брулер

Без оглед на методот на физичко складирање, логичното складирање на податоци може да се подели на два начина за пристап до овие податоци: блок и датотека. Оваа поделба неодамна беше многу заматена, бидејќи чисто блок, како и чисто датотека, логично складирање не постои. Сепак, за едноставност, ќе претпоставиме дека постојат.

Блокирање на складирање податоци подразбира дека постои физички уред каде што податоците се запишуваат во одредени фиксни делови, блокови. Блоковите се пристапуваат на одредена адреса; секој блок има своја адреса во уредот.

Резервната копија обично се прави со копирање на блокови од податоци. За да се обезбеди интегритет на податоците, снимањето на нови блокови, како и промените на постоечките, се суспендирани во моментот на копирање. Ако земеме аналогија од обичниот свет, најблиску е плакарот со идентични нумерирани ќелии.

Складирањето на податоци за датотеките засновано на принципот на логички уред е блиску до блокираното складирање и често се организира на врвот. Важни разлики се присуството на хиерархија за складирање и имиња читливи за луѓе. Апстракција се доделува во форма на датотека - именувана област со податоци, како и директориум - специјална датотека во која се зачувани описи и пристап до други датотеки. Датотеките може да се обезбедат со дополнителни метаподатоци: време на создавање, знаменца за пристап итн. Резервните копии обично се прават на овој начин: тие бараат променети датотеки, а потоа ги копираат во друго складирање на датотеки со истата структура. Интегритетот на податоците обично се имплементира со отсуство на датотеки на кои се пишуваат. На ист начин се прави резервна копија на метаподатоците на датотеката. Најблиската аналогија е библиотека, која има делови со различни книги, а има и каталог со имиња на книгите читливи за луѓе.

Неодамна, понекогаш се опишува друга опција, од која, во принцип, започна складирањето на податоци за датотеки и која ги има истите архаични карактеристики: складирање на податоци за објекти.

Се разликува од складирањето датотеки по тоа што нема повеќе од едно вгнездување (рамна шема), а имињата на датотеките, иако читливи за луѓе, сепак се посоодветни за обработка од машини. Кога правите резервни копии, складирањето на објекти најчесто се третира слично како складирањето на датотеки, но повремено има и други опции.

— Постојат два вида системски администратори, оние кои не прават резервни копии и оние кои ВЕЌЕ прават.
- Всушност, постојат три вида: има и такви кои проверуваат дали резервните копии може да се обноват.

- Непознато

Исто така, вреди да се разбере дека самиот процес на резервна копија на податоци се спроведува од програми, така што ги има сите исти недостатоци како и секоја друга програма. Да се ​​отстрани (не елиминира!) зависноста од човечкиот фактор, како и карактеристиките - кои поединечно немаат силен ефект, но заедно можат да дадат забележлив ефект - т.н. правило 3-2-1. Има многу опции за тоа како да се дешифрира, но подобро ми се допаѓа следнава интерпретација: мора да се складираат 3 групи исти податоци, 2 сета мора да се складираат во различни формати и 1 сет мора да се складира во географски оддалечен склад.

Форматот за складирање треба да се разбере на следниов начин:

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

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

Од гледна точка на подготвеноста на резервната копија за наменетата цел - враќање на функционалноста - се прави разлика помеѓу „топли“ и „ладни“ резервни копии. Топлите се разликуваат од ладните само по едно: веднаш се спремни за употреба, додека ладните бараат некои дополнителни чекори за обновување: дешифрирање, вадење од архивата итн.

Не мешајте топли и ладни копии со онлајн и офлајн копии, кои подразбираат физичка изолација на податоците и, всушност, се уште еден знак за класификацијата на резервните методи. Значи, офлајн копија - не директно поврзана со системот каде што треба да се врати - може да биде или топла или ладна (во смисла на подготвеност за обновување). Онлајн копија може да биде достапна директно таму каде што треба да се врати, а најчесто е жешко, но има и ладни.

Дополнително, не заборавајте дека самиот процес на создавање резервни копии обично не завршува со создавање на една резервна копија и може да има прилично голем број копии. Затоа, потребно е да се направи разлика помеѓу целосните резервни копии, т.е. оние што можат да се обноват независно од други резервни копии, како и диференцијални (порасна, диференцијални, декрементални, итн.) копии - оние што не можат да се обноват независно и бараат прелиминарно обновување на еден или повеќе други резервни копии.

Диференцијалните поединечни резервни копии се обид да се заштеди простор за складирање резервни копии. Така, само променетите податоци од претходната резервна копија се запишуваат во резервната копија.

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

Одделно, вреди да се разгледа процесот на резервна копија преку складирање, што поддржува отсуство на складирање на дупликати. Така, ако напишете целосни резервни копии врз него, всушност ќе бидат напишани само разликите помеѓу резервните копии, но процесот на враќање на резервните копии ќе биде сличен на враќањето од целосна копија и целосно транспарентен.

Quis custodiet ipsos custodes?

(Кој ќе ги чува самите стражари? - лат.)

Многу е непријатно кога нема резервни копии, но многу е полошо ако се чини дека е направена резервна копија, но при обновувањето излегува дека не може да се врати затоа што:

• Интегритетот на изворните податоци е загрозен.
• Меморијата за резервна копија е оштетена.
• Реставрацијата работи многу бавно; не можете да користите податоци што се делумно обновени.

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

Интегритетот на изворните податоци може да се гарантира на неколку начини. Најчесто користени се следните: а) создавање снимки од датотечниот систем на ниво на блок, б) „замрзнување“ на состојбата на датотечниот систем, в) специјален блок уред со складирање верзии, г) секвенцијално снимање на датотеки или блокови. Се применуваат и контролни суми за да се осигура дека податоците се потврдени за време на обновувањето.

Корупцијата на складирањето може да се открие и со помош на контролни суми. Дополнителен метод е употребата на специјализирани уреди или датотечни системи во кои веќе снимените податоци не можат да се променат, но може да се додадат нови.

За да се забрза обновувањето, обновувањето на податоците се користи со повеќе процеси за обновување - под услов да нема тесно грло во форма на бавна мрежа или бавен систем на дискови. За да ја заобиколите ситуацијата со делумно обновени податоци, можете да го разделите процесот на резервна копија на релативно мали подзадачи, од кои секоја се изведува посебно. Така, станува возможно постојано да се враќаат перформансите додека се предвидува времето за опоравување. Овој проблем најчесто лежи во организационата рамнина (SLA), па затоа нема да се задржуваме на ова подетално.

Експерт за зачини не е оној кој ги додава во секое јадење, туку оној кој никогаш не додава ништо дополнително во него.

-ВО. Сињавски

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

• Силно се препорачува да се користат готови решенија.
• Програмите треба да работат предвидливо, т.е. Не треба да има недокументирани карактеристики или тесни грла.
• Поставувањето на секоја програма треба да биде толку едноставно што не мора да го читате прирачникот или листот за измами секој пат.
• Ако е можно, решението треба да биде универзално, бидејќи серверите може многу да се разликуваат во нивните хардверски карактеристики.

Постојат следниве вообичаени програми за правење резервни копии од блок уреди:

• dd, познат на ветераните на системската администрација, исто така вклучува слични програми (истиот dd_rescue, на пример).
• Услужни програми вградени во некои датотечни системи кои создаваат депонија на датотечен систем.
• Сештојади комунални услуги; на пример парклон.
• Сопствени, често сопственички, одлуки; на пример, NortonGhost и подоцна.

За датотечните системи, проблемот со резервната копија е делумно решен со помош на методи применливи за блок уреди, но проблемот може да се реши поефикасно користејќи, на пример:

• Rsync, програма за општа намена и протокол за синхронизирање на состојбата на датотечните системи.
• Вградени алатки за архивирање (ZFS).
• Алатки за архивирање од трета страна; најпопуларниот претставник е катран. Има и други, на пример, дар - замена за катран насочен кон современи системи.

Вреди да се спомене посебно за софтверските алатки за обезбедување конзистентност на податоците при креирање резервни копии. Најчесто користени опции се:

• Монтирање на датотечен систем во режим само за читање (ReadOnly) или замрзнување на датотечниот систем (замрзнување) - методот е со ограничена применливост.
• Создавање снимки од состојбата на датотечен систем или блок уреди (LVM, ZFS).
• Употреба на алатки од трети лица за организирање на впечатоци, дури и во случаи кога претходните точки не можат да се обезбедат поради некоја причина (програми како копирање).
• Техниката копирање-на-промена (CopyOnWrite), сепак, најчесто е поврзана со користениот датотечен систем (BTRFS, ZFS).

Значи, за мал сервер треба да обезбедите резервна шема која ги исполнува следните барања:

• Лесен за користење - не се потребни посебни дополнителни чекори за време на работата, минимални чекори за креирање и враќање на копии.
• Универзална - работи и на големи и на мали сервери; ова е важно кога се зголемува бројот на сервери или скалирање.
• Инсталиран од менаџер на пакети или во една или две команди како „преземи и отпакувај“.
• Стабилен - се користи стандарден или долго воспоставен формат за складирање.
• Брзи во работата.

Кандидати од оние кои повеќе или помалку ги исполнуваат условите:

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

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

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

Речиси истата машина ќе се користи како резервен сервер за приемник, само со хард диск од 500 GB.

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

Како првични податоци, да земеме страница на WordPress со 40 GB медиумски датотеки и база на податоци mysql. Бидејќи виртуелните сервери се разликуваат многу во карактеристиките, а исто така и за подобра репродуктивност, еве

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

Ограничување на прости броеви: 20000

Се иницијализираат работните нишки…

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

Брзина на процесорот:
настани во секунда: 836.69

Пропусна моќност:
настани/и (eps): 836.6908
поминато време: 30.0039 сек
вкупен број на настани: 25104

Латентност (ms):
мин: 2.38
просек: 4.78
макс: 22.39
95-ти перцентил: 10.46
збир: 119923.64

Праведност на нишки:
настани (avg/stddev): 6276.0000/13.91
време на извршување (avg/stddev): 29.9809/0.01

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

Извршување на тест за брзина на меморијата со следниве опции:
големина на блок: 1KiB
вкупна големина: 102400 MiB
операција: читање
опсег: глобален

Се иницијализираат работните нишки…

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

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

Префрлени 49707.47 MiB (1656.91 MiB/сек.)

Пропусна моќност:
настани/и (eps): 1696677.1017
поминато време: 30.0001 сек
вкупен број на настани: 50900446

Латентност (ms):
мин: 0.00
просек: 0.00
макс: 24.01
95-ти перцентил: 0.00
збир: 39106.74

Праведност на нишки:
настани (avg/stddev): 12725111.5000/137775.15
време на извршување (avg/stddev): 9.7767/0.10

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

Извршување на тест за брзина на меморијата со следниве опции:
големина на блок: 1KiB
вкупна големина: 102400 MiB
операција: пишува
опсег: глобален

Се иницијализираат работните нишки…

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

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

Префрлени 35068.76 MiB (1168.95 MiB/сек.)

Пропусна моќност:
настани/и (eps): 1197008.6179
поминато време: 30.0001 сек
вкупен број на настани: 35910413

Латентност (ms):
мин: 0.00
просек: 0.00
макс: 16.90
95-ти перцентил: 0.00
збир: 43604.83

Праведност на нишки:
настани (avg/stddev): 8977603.2500/233905.84
време на извршување (avg/stddev): 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 датотеки, по 8 MiB
1 ГиБ вкупна големина на датотека
Големина на блок 4KiB
Број на барања за ИО: 0
Сооднос читање/запишување за комбиниран случаен IO тест: 1.50
Овозможено е периодично FSYNC, повикувајќи се на fsync() на секои 100 барања.
Повикување на fsync() на крајот од тестот, Овозможено.
Користење на синхрони В/И режим
Правење случаен р/в тест
Се иницијализираат работните нишки…

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

Пропусна моќност:
прочитајте: 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: Тестирање на бакула и бекап на veeam за Linux
6. Резервна копија Дел 6: Споредување на алатките за резервна копија
7. Бекап Дел 7: Заклучоци

Извор: www.habr.com