Бул эскертүү камдык көчүрмөнү сактоо циклин аяктайт. Анда резервдик көчүрүү үчүн ыңгайлуу атайын сервердин (же VPS) логикалык уюштуруусу талкууланат, ошондой эле кырсык болгон учурда көп иштебей туруп резервдик көчүрмөдөн серверди тез калыбына келтирүү варианты сунушталат.
алгачкы маалыматтар
Атайын серверде көбүнчө биринчи деңгээлдеги RAID массивин (күзгү) уюштуруу үчүн кызмат кылган жок дегенде эки катуу диск бар. Бул бир диск иштебей калса, серверди иштетүүнү улантуу үчүн зарыл. Эгер бул кадимки атайын сервер болсо, SSDде активдүү кэштөө технологиясы менен өзүнчө аппараттык RAID контроллери болушу мүмкүн, андыктан кадимки катуу дисктерден тышкары, бир же бир нече SSD туташтырылышы мүмкүн. Кээде атайын серверлер сунушталат, аларда SATADOM (кичинекей дисктер, структуралык жактан SATA портуна туташтырылган флеш-диск) же атайын ички портко туташтырылган кадимки кичинекей (8-16 ГБ) флеш-диск жана маалыматтар атайын сактоо тармагы (Ethernet 10G, FC ж.б.) аркылуу туташтырылган сактоо тутумунан алынат жана түздөн-түз сактоо тутумунан жүктөлгөн атайын серверлер бар. Мен мындай варианттарды карап отурбайм, анткени мындай учурларда сервердин резервдик көчүрмөсүн сактоо милдети сактоо тутумун тейлеген адиске өтөт; эреже катары, сүрөттү түзүү үчүн ар кандай менчик технологиялары, орнотулган дедупликация жана системалык администратордун башка кубанычтары бар. , бул сериянын мурунку бөлүмдөрүндө талкууланган. Бөлүнгөн сервердин диск массивинин көлөмү серверге туташтырылган дисктердин санына жана өлчөмүнө жараша бир нече ондогон терабайттарга жетиши мүмкүн. VPS учурда, көлөмү кыйла жөнөкөй: адатта 100 ГБ ашпайт (бирок андан да көп), жана мындай VPS үчүн тарифтер бир эле хосттердин эң арзан арналган серверлерине караганда оңой эле кымбатыраак болушу мүмкүн. VPS көбүнчө бир дискке ээ, анткени анын астында сактоо тутуму (же гиперконвергацияланган нерсе) болот. Кээде VPS ар кандай максаттар үчүн, ар кандай мүнөздөмөлөргө ээ бир нече дисктерге ээ:
- кичинекей система - операциялык системаны орнотуу үчүн;
- чоң - колдонуучунун маалыматтарын сактоо.
Башкаруу панелинин жардамы менен системаны кайра орнотконуңузда, колдонуучунун маалыматтары бар диск кайра жазылбайт, бирок системалык диск толугу менен толтурулат. Ошондой эле, VPS болгон учурда, хосттер VPS (же диск) абалынын сүрөтүн тартуучу баскычты сунушташы мүмкүн, бирок эгер сиз өзүңүздүн операциялык системаңызды орнотуп алсаңыз же VPS ичинде каалаган кызматты жандырууну унутуп калсаңыз, кээ бир маалыматтардын дагы эле жоголуп кетиши мүмкүн. Баскычтан тышкары, адатта, маалыматты сактоо кызматы сунушталат, көбүнчө өтө чектелген. Эреже катары, бул FTP же SFTP аркылуу, кээде SSH менен бирге, ажыратылган кабыкчасы бар (мисалы, rbash) же authorized_keys (ForcedCommand аркылуу) аркылуу буйруктарды аткарууга чектөө коюлган каттоо эсеби.
Тармакка атайын сервер 1 Гбит/сек ылдамдыктагы эки порт аркылуу туташтырылган, кээде бул 10 Гбит/сек ылдамдыктагы карталар болушу мүмкүн. VPS көбүнчө бир тармак интерфейсине ээ. Көбүнчө дата борборлору маалымат борборунун ичиндеги тармактын ылдамдыгын чектебейт, бирок Интернетке кирүү ылдамдыгын чектейт.
Мындай арналган сервердин же VPSтин типтүү жүгү бул веб-сервер, маалымат базасы жана тиркеме сервери. Кээде ар кандай кошумча жардамчы кызматтар орнотулушу мүмкүн, анын ичинде веб-сервер же маалымат базасы үчүн: издөө системасы, почта системасы ж.б.
Атайын даярдалган сервер резервдик көчүрмөлөрдү сактоо үчүн мейкиндиктин ролун аткарат, биз бул тууралуу кийинчерээк кененирээк жазабыз.
Диск системасын логикалык уюштуруу
Эгерде сизде RAID контроллери же бир диски бар VPS бар болсо жана дисктин подсистемасынын иштеши үчүн атайын артыкчылыктар жок болсо (мисалы, маалымат базасы үчүн өзүнчө тез диск), бардык бош мейкиндик төмөнкүчө бөлүнөт: бир бөлүм түзүлөт жана анын үстүнө LVM томдук тобу түзүлөт, анда бир нече томдор түзүлөт: тамыр файл системасы катары колдонулган бирдей өлчөмдөгү 2 кичинекей томдор (тез артка кайтаруу мүмкүнчүлүгү үчүн жаңыртуулар учурунда бирден өзгөртүлгөн, идея Calculate Linux дистрибутивинен алынды), дагы бири своп бөлүмү үчүн, бош мейкиндиктин калган бөлүгү чакан көлөмгө бөлүнөт, толук кандуу контейнерлер, виртуалдык машиналар үчүн дисктер, файл үчүн тамыр файл системасы катары колдонулат. /үйдөгү эсептик системалар (ар бир эсептин өзүнүн файл системасы бар), колдонмо контейнерлери үчүн файл тутумдары.
Маанилүү эскертүү: томдор толугу менен өз алдынча болушу керек, б.а. бири-биринен же тамыр файл системасына көз каранды болбошу керек. Виртуалдык машиналарда же контейнерлерде бул чекит автоматтык түрдө байкалат. Эгерде булар тиркеме контейнерлери же үй каталогдору болсо, веб-сервердин жана башка кызматтардын конфигурация файлдарын мүмкүн болушунча көлөмдөрдүн ортосундагы көз карандылыкты жок кылуу үчүн бөлүү жөнүндө ойлонушуңуз керек. Мисалы, ар бир сайт өзүнүн колдонуучусунан иштейт, сайттын конфигурация файлдары колдонуучунун үй каталогунда, веб-сервер орнотууларында, сайттын конфигурация файлдары /etc/nginx/conf.d/ аркылуу камтылбайт..conf жана, мисалы, /home//configs/nginx/*.conf
Эгерде бир нече диск бар болсо, анда сиз RAID программалык массивин түзө аласыз (жана анын кэшин SSDде конфигурациялай аласыз, эгер зарылчылык жана мүмкүнчүлүк болсо), анын үстүнө жогоруда сунушталган эрежелерге ылайык LVM кура аласыз. Ошондой эле бул учурда, сиз ZFS же BtrFS колдоно аласыз, бирок бул жөнүндө эки жолу ойлонушуңуз керек: экөө тең ресурстарга олуттуураак мамилени талап кылат жана андан тышкары, ZFS Linux ядросуна кирбейт.
Колдонулган схемага карабастан, дисктерге өзгөртүүлөрдү жазуунун болжолдуу ылдамдыгын алдын ала эсептеп, андан кийин сүрөттү түзүү үчүн сактала турган бош орундун көлөмүн эсептөө керек. Мисалы, эгерде биздин сервер секундасына 10 мегабайт ылдамдыкта маалыматтарды жазса, ал эми бардык берилиштер массивинин көлөмү 10 терабайт болсо - синхрондоштуруу убактысы бир суткага жетиши мүмкүн (22 саат - ушундай көлөм ушул канчага которулат) тармак аркылуу 1 Гбит/сек) - бул болжол менен 800 ГБ ээлеп коюуга арзыйт. Чындыгында, көрсөткүч азыраак болот, сиз аны логикалык томдордун санына коопсуз бөлсөңүз болот.
Камдык сактоо серверинин түзмөгү
Резервдик көчүрмөлөрдү сактоо үчүн сервердин негизги айырмасы анын чоң, арзан жана салыштырмалуу жай дисктери. Заманбап HDD бир дискте 10 ТБ тилкеден өтүп кеткендиктен, файл тутумдарын же контролдук суммалары бар RAIDди колдонуу керек, анткени массивди кайра курууда же файлдык системаны калыбына келтирүү учурунда (бир нече күн!) Экинчи диск иштебей калышы мүмкүн. жогорулатылган жүк үчүн. 1ТБга чейинки сыйымдуулугу бар дисктерде бул анчалык сезгич эмес. Сүрөттөмөнүн жөнөкөйлүгү үчүн, мен диск мейкиндиги болжол менен бирдей өлчөмдөгү эки бөлүккө бөлүнөт деп ойлойм (кайра, мисалы, LVM колдонуу менен):
- колдонуучунун маалыматтарын сактоо үчүн колдонулган серверлерге туура келген көлөмдөр (акыркы жасалган резервдик көчүрмө текшерүү үчүн аларда жайгаштырылат);
- BorgBackup репозиторийлери катары колдонулган көлөмдөр (камдык көчүрмөлөр үчүн маалыматтар түздөн-түз бул жерде болот).
Иштөө принциби - BorgBackup репозиторийлери үчүн ар бир сервер үчүн өзүнчө томдор түзүлөт, анда согуштук серверлердин маалыматтары кетет. Репозиторийлер тиркеме режиминде гана иштешет, бул маалыматтарды атайылап өчүрүү мүмкүнчүлүгүн жокко чыгарат жана репозиторийлерди эски резервдик көчүрмөлөрдөн дедупликациялоонун жана мезгил-мезгили менен тазалоонун эсебинен (жылдык көчүрмөлөр акыркы жыл үчүн ай сайын, акыркы ай үчүн жума сайын, күн сайын акыркы жумада, балким өзгөчө учурларда - акыркы күн үчүн саат сайын: жалпы 24 + 7 + 4 + 12 + жылдык - ар бир сервер үчүн болжол менен 50 нуска).
BorgBackup репозиторийлери тиркеме гана режимин иштетпейт; анын ордуна .ssh/authorized_keys ичиндеги ForcedCommand төмөнкүдөй колдонулат:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Көрсөтүлгөн жол боргдун үстүндө орогуч скрипти камтыйт, ал экиликти параметрлери менен ишке киргизүүдөн тышкары, маалыматтар алынып салынгандан кийин резервдик көчүрмөнү калыбына келтирүү процессин кошумча баштайт. Бул үчүн, орогуч скрипти тиешелүү репозиторийдин жанында тег файлын түзөт. Акыркы жасалган камдык көчүрмө маалыматтарды толтуруу процесси аяктагандан кийин автоматтык түрдө тиешелүү логикалык көлөмгө калыбына келтирилет.
Бул дизайн керексиз резервдик көчүрмөлөрдү мезгил-мезгили менен тазалоого мүмкүндүк берет, ошондой эле согуштук серверлердин резервдик сактоо сервериндеги нерселерди жок кылуусуна жол бербейт.
Камдык көчүрмөнү сактоо процесси
Резервдик көчүрүүнүн демилгечиси болуп атайын сервер же VPS өзү саналат, анткени бул схема бул сервер тарабынан резервдик көчүрүү процессин көбүрөөк көзөмөлдөөгө мүмкүндүк берет. Биринчиден, жигердүү тамыр файл тутумунун абалынын сүрөтү алынат, ал BorgBackup аркылуу камдык сактоо серверине орнотулат жана жүктөлөт. Маалыматтар тартылып бүткөндөн кийин, сүрөт монтаждан ажыратылат жана жок кылынат.
Эгерде кичинекей маалымат базасы бар болсо (ар бир сайт үчүн 1 ГБ чейин), ошол эле сайт үчүн калган маалыматтар жайгашкан, бирок ошол эле сайт үчүн тиешелүү логикалык көлөмдө сакталган маалымат базасынын таштандысы түзүлөт. веб-сервер аркылуу жеткиликтүү эмес. Эгерде маалымат базалары чоң болсо, сиз "ысык" маалыматтарды алып салууну конфигурациялашыңыз керек, мисалы, MySQL үчүн xtrabackup аркылуу же PostgreSQLде archive_command менен WAL менен иштешиңиз керек. Бул учурда, маалымат базасы сайттын маалыматтарынан өзүнчө калыбына келтирилет.
Эгер контейнерлер же виртуалдык машиналар колдонулса, сиз qemu-guest-агент, CRIU же башка керектүү технологияларды конфигурациялашыңыз керек. Башка учурларда, кошумча орнотуулар көбүнчө талап кылынбайт - биз жөн гана логикалык көлөмдөрдүн сүрөттөрүн түзөбүз, алар андан кийин тамыр файл тутумунун абалынын сүрөтү сыяктуу эле иштетилет. Маалыматтар алынгандан кийин, сүрөттөр өчүрүлөт.
Резервдик сактоо серверинде андан аркы иштер аткарылат:
- ар бир репозиторийде жасалган акыркы камдык текшерилет,
- маалыматтарды чогултуу процесси аяктагандыгын көрсөтүүчү белги файлынын бар экендиги текшерилет,
- маалыматтар тиешелүү жергиликтүү көлөмгө чейин кеңейтилген,
- тег файлы жок кылынат
Серверди калыбына келтирүү процесси
Эгерде негизги сервер өлсө, анда кандайдыр бир стандарттуу сүрөттөлүштөн жүктөлгөн окшош арналган сервер ишке киргизилет. Кыязы, жүктөө тармак аркылуу ишке ашат, бирок серверди орноткон маалымат борборунун адиси бул стандарттуу сүрөттү дисктердин бирине дароо көчүрө алат. Жүктөп алуу оперативдүү эс тутумга өтөт, андан кийин калыбына келтирүү процесси башталат:
- блоктук түзүлүштү iscsinbd же башка ушул сыяктуу протокол аркылуу өлгөн сервердин тамыр файл тутумун камтыган логикалык томго тиркөө өтүнүчү берилет; Тамыр файл системасы кичинекей болушу керек болгондуктан, бул кадам бир нече мүнөттүн ичинде бүтүшү керек. Жүктөгүч да калыбына келтирилди;
- локалдык логикалык томдордун структурасы кайра түзүлөт, логикалык томдор dm_clone ядро модулунун жардамы менен резервдик серверден тиркелет: маалыматтарды калыбына келтирүү башталат жана өзгөртүүлөр дароо локалдык дисктерге жазылат.
- контейнер бардык жеткиликтүү физикалык дисктер менен ишке киргизилди - сервердин иштеши толугу менен калыбына келтирилди, бирок өндүрүмдүүлүгү төмөндөйт;
- маалыматтарды синхрондоштуруу аяктагандан кийин, резервдик серверден логикалык томдор ажыратылат, контейнер өчүрүлөт жана сервер кайра жүктөлөт;
Кайра жүктөөдөн кийин серверде камдык көчүрмө түзүлгөн учурда болгон бардык маалыматтар болот, ошондой эле калыбына келтирүү процессинде жасалган бардык өзгөртүүлөр камтылат.
Сериядагы башка макалалар
Камдык 7-бөлүк: Корутундулар
Сунушталган вариантты комментарийлерде талкуулоого чакырам, көңүл бурганыңыз үчүн рахмат!
Source: www.habr.com