VPS ижарага олган кўпчилик эгалар "снапшот олиб қўйдим, демак захирам бор" деб ўйлайди. Аслида снапшот ва тўлиқ захира нусха бир-бирига ўхшаса ҳам, турли муаммолардан ҳимоя қилади. Снапшот тизимни тез орқага қайтариш учун қулай восита, бэкап эса сервер бутунлай йўқолган ёки маълумот бир неча кун олдин бузилган ҳолатда ҳам тиклаш имконини берадиган мустақил нусхадир. Бу фарқни тушунмаслик энг оғир пайтда, яъни нусха керак бўлиб қолганда билинади.
Снапшот нима ва у қандай ишлайди
Снапшот виртуал машина дискининг маълум бир лаҳзадаги ҳолатини қайд этади. Кўпинча у тўлиқ нусха кўчирмайди: виртуализация тизими ўша пайтдаги блокларни музлатиб қўяди ва кейинги ўзгаришларни алоҳида ёзиб боради. Шу сабабли снапшот бир неча сония ёки дақиқада тайёр бўлади ва серверни ўша ҳолатга жуда тез қайтариш мумкин. Масалан, оператсион тизимни янги версияга кўтаришдан ёки PHP версиясини алмаштиришдан олдин снапшот олиш яхши одат: бирор нарса бузилса, бир неча дақиқада ишлайдиган ҳолатга қайтасиз.
Бироқ снапшот одатда худди шу инфратузилмада, кўпинча ўша сақлаш тизимида туради. Агар диск массиви ишдан чиқса, аккаунтга рухсатсиз кирилса ёки сервер ўчириб юборилса, снапшот ҳам у билан бирга йўқолиши мумкин. Бундан ташқари, ишлаб турган сервердан олинган снапшот "crash-consistent" бўлади: бу худди электр тўсатдан ўчгандаги ҳолатга ўхшайди. Файл тизими буни кўпинча кўтара олади, лекин хотирада турган ва дискка ҳали ёзилмаган маълумотлар базаси транзакциялари тўлиқ сақланмаслиги мумкин.
Бэкап нима учун алоҳида тушунча
Бэкап деганда маълумотларнинг бошқа жойга кўчирилган, серверга боғлиқ бўлмаган нусхаси тушунилади. У бошқа серверда, объект хотирасида (S3 мос хизмат) ёки офисдаги дискда сақланиши мумкин. Яхши бэкап бир нечта версияни ушлаб туради: кечаги, бир ҳафта олдинги ва бир ой олдинги ҳолат. Бу жуда муҳим, чунки кўп муаммолар дарҳол сезилмайди. Масалан, сайт бузиб кирилиб, файлларга зарарли код қўшилган бўлса, буни баъзан бир-икки ҳафтадан кейин пайқайсиз ва фақат эски версия тоза бўлиб чиқади.
Бэкап одатда бутун дискни эмас, керакли нарсаларни сақлайди: сайт файллари, маълумотлар базаси дампи, созлама файллари (/etc/nginx, cron жадваллари, SSL ва илова конфигурацияси). Оператсион тизимнинг ўзини қайта ўрнатиш осон, лекин сизнинг маълумотларингиз такрорланмас.
Фарқларни бир жадвалда солиштириш
| Мезон | Снапшот | Бэкап |
|---|---|---|
| Яратиш тезлиги | Жуда тез, сониялар ёки дақиқалар | Маълумот ҳажмига қараб дақиқалар ёки соатлар |
| Сақланиш жойи | Одатда ўша инфратузилмада | Алоҳида сервер ёки хотира |
| Нима сақланади | Бутун диск ҳолати | Танланган файллар ва база дампи |
| Сервер йўқолса | Кўпинча бирга йўқолади | Сақланиб қолади |
| Энг яхши қўлланилиши | Янгиланиш олдидан тезкор қайтиш нуқтаси | Узоқ муддатли ҳимоя ва тўлиқ тиклаш |
Маълумотлар базасини тўғри нусхалаш
Ишлаб турган MySQL ёки PostgreSQL базасининг файлларини оддий нусхалаш хавфли, чунки нусха олинаётган пайтда улар ўзгариб туради. Тўғри йўл база воситалари орқали думп олишдир. InnoDB жадваллари учун --single-transaction параметри базани қулфламасдан изчил нусха беради, шунинг учун сайт ишлашда давом этади.
# MySQL / MariaDB
mysqldump --single-transaction --routines --triggers -u backup -p shop_db | gzip > /backup/shop_db_$(date +%F).sql.gz
# PostgreSQL
pg_dump -U postgres -Fc clinic_db > /backup/clinic_db_$(date +%F).dumpДумпни олгандан кейин уни сервердан ташқарига юбориш керак. Бунинг энг содда усули rsync орқали бошқа серверга SSH билан кўчиришдир. Шифрлаш, версиялаш ва такрорий блокларни тежаш керак бўлса, restic ёки borg каби воситалар қулай.
# fayllar va dumplarni boshqa serverga ko'chirish
rsync -az --delete /backup/ backupuser@backup.example.uz:/srv/backups/vps1/
# restic bilan shifrlangan, versiyali nusxa
restic -r sftp:backupuser@backup.example.uz:/srv/restic init
restic -r sftp:backupuser@backup.example.uz:/srv/restic backup /var/www /etc /backup
restic -r sftp:backupuser@backup.example.uz:/srv/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneАмалий мисол: Тошкентдаги интернет-дўкон
Тасаввур қилинг, Тошкентдаги кичик маиший техника дўкони misol.uz сайтини VPS'да юритади: WooCommerce, MySQL базаси ва кунига бир неча ўнлаб буюртма. Администратор ҳар тунда соат 03:00 да cron орқали база дампини олади, /var/www ва /etc билан бирга restic орқали бошқа шаҳардаги захира серверга юборади. Restic 7 кунлик, 4 ҳафталик ва 6 ойлик нусхаларни сақлайди. Ҳар сафар плагин ёки PHP версиясини янгилашдан олдин эса қўшимча равишда снапшот олинади.
# crontab -e
0 3 * * * /usr/local/bin/nightly-backup.sh >> /var/log/nightly-backup.log 2>&1Бир куни янги тўлов плагини ўрнатилгач, сайт оқ экран кўрсатиб қолди. Администратор 5 дақиқада снапшот орқали серверни эрталабки ҳолатга қайтарди. Бошқа сафар эса ходим нотўғри SQL сўров билан нархлар жадвалини бузиб қўйди ва бу икки кундан кейин аниқланди. Бу ҳолатда снапшот ёрдам бермасди, чунки у янгиланишдан олдин олинган эди ва орқага қайтиш кейинги буюртмаларни ўчириб юборарди. Ёрдамга уч кун олдинги бэкап келди: администратор фақат битта жадвални эски думпдан тиклаб, қолган маълумотларга тегмади.
3-2-1 қоидаси ва тиклашни синаш
Захира бўйича кенг тарқалган тамойил 3-2-1 қоидаси деб аталади: маълумотнинг камида учта нусхаси бўлсин, улар икки хил турдаги сақлаш воситасида турсин ва биттаси бошқа жойда сақлансин. VPS учун бу амалда қуйидагича бўлиши мумкин: сервернинг ўзидаги ишчи маълумот, бошқа сервердаги restic омбори ва вақти-вақти билан офис дискига ёки бошқа булут хизматига юклаб олинган нусха.
Энг кўп эътибордан четда қоладиган босқич тиклашни синашдир. Тикланмайдиган бэкап аслида бэкап эмас. Ойига бир марта тест серверда охирги нусхадан сайтни кўтариб кўринг: думп очиладими, файллар тўлиқми, сайт ишга тушадими. Шунингдек, бэкап скрипти хато берса хабар келадиган қилиб созланг, акс ҳолда у бир неча ой жим ишламай ётиши мумкин.
# oxirgi nusxani vaqtinchalik papkaga tiklab tekshirish
restic -r sftp:backupuser@backup.example.uz:/srv/restic restore latest --target /tmp/restore-test
gunzip -t /tmp/restore-test/backup/shop_db_*.sql.gz && echo "dump OK"Қачон қайси бирини ишлатиш керак
Снапшотни катта ўзгариш олдидан қисқа муддатли хавфсизлик тўри сифатида ишлатинг ва ишлар жойида эканига ишонч ҳосил қилгач, уни ўчиринг: узоқ турган снапшотлар диск жойини эгаллайди ва баъзи тизимларда ишлаш тезлигини пасайтиради. Бэкапни эса доимий, автоматлаштирилган ва сервердан ташқарида сақланадиган қилиб қуринг. sayt.uz VPS'ида ишлаётган бўлсангиз, снапшот ёки захира имкониятлари бўйича саволларни кабинет ёки техник ёрдам орқали аниқлаштиришингиз мумкин, лекин ўз маълумотларингизнинг мустақил нусхасини сақлаш барибир сизнинг назоратингизда бўлгани маъқул.
Қисқа қилиб айтганда, снапшот "бир қадам орқага" тугмаси, бэкап эса "ҳамма нарса йўқолса ҳам қайтиб келаман" кафолати. Иккаласи бирга ишлатилганда сервер эгаси ҳам кичик хатолардан, ҳам жиддий фалокатлардан ҳимояланган бўлади.