Երբ ֆայլային սերվերը, հաշվապահական բազան կամ վիրտուալ մեքենան խափանվում են, բիզնեսի համար գլխավոր հարցը միայն այն չէ, թե արդյոք առկա է պահուստային պատճենը (backup): Գլխավոր հարցն է. որքա՞ն ժամանակում կվերականգնվի աշխատանքային միջավայրը և որքա՞ն տվյալ կկորչի: Հետևաբար, պահուստային պատճենահանման ծրագրի ընտրությունը պետք է հիմնված լինի վերականգնման իրական պահանջների, առկա ենթակառուցվածքի և պատասխանատու աշխատակիցների աշխատանքային գործընթացի վրա, այլ ոչ միայն լիցենզիայի սկզբնական արժեքի:

Նախ որոշեք, թե ինչ եք ակնկալում վերականգնել

Պահուստային պատճենահանման ծրագիրը սովորական ֆայլեր պատճենելու գործիք չէ: Բիզնես միջավայրում այն պետք է պաշտպանի ֆիզիկական սերվերները, վիրտուալ մեքենաները, աշխատակայանները, տվյալների բազաները, Microsoft 365-ի տվյալները կամ այլ SaaS հարթակներ: Այս համակարգերն ունեն վերականգնման տարբեր տրամաբանություն:

Օրինակ՝ ընդհանուր թղթապանակի համար կարող է բավարար լինել նախորդ օրվա պատճենը: SQL կամ այլ տրանզակցիոն տվյալների բազայի համար այս մոտեցումը հաճախ անընդունելի է, քանի որ օրվա ընթացքում կատարված գործարքները կկորչեն: VMware կամ Hyper-V միջավայրում անհրաժեշտ է ոչ միայն վիրտուալ սկավառակների պատճենումը, այլև VM-ի արագ թողարկումը, ցանցային պարամետրերի պահպանումը և հավելվածի հաջորդական (application-consistent) վերականգնումը:

Ուստի, նախքան ծրագիրը գնահատելը, ցուցակագրեք առաջնահերթ համակարգերը և յուրաքանչյուրի համար որոշեք երկու ցուցանիշ՝ RPO և RTO: RPO-ն (Recovery Point Objective) ցույց է տալիս, թե որքան տվյալների կորուստն է թույլատրելի ժամանակային կտրվածքով: Եթե RPO-ն չորս ժամ է, ապա պահուստավորումը կամ ռեպլիկացիան պետք է կատարվեն առնվազն այդ ինտերվալով: RTO-ն (Recovery Time Objective) որոշում է, թե որքան ժամանակում համակարգը պետք է վերադառնա աշխատանքային վիճակի: Փոքր գրասենյակի համար ֆայլային սերվերի վերականգնումը մինչև հաջորդ աշխատանքային օրը կարող է ընդունելի լինել. առցանց վաճառքի, լոգիստիկայի կամ ERP համակարգի համար նույնիսկ մի քանի ժամը նշանակում է մեծ գործառնական կորուստ:

Պահուստային պատճենահանման ծրագրի ընտրության հիմնական չափանիշները

1. Վերականգնման հնարավորությունն ավելի կարևոր է, քան պատճենի ստեղծումը

Շատ լուծումներ հաջողությամբ ստեղծում են պահուստային պատճեն, սակայն իրական տարբերությունը ի հայտ է գալիս վերականգնման փուլում: Ստուգեք՝ արդյոք ծրագիրը կարող է ամբողջությամբ վերականգնել կոնկրետ ֆայլը, ամբողջ թղթապանակը, հավելվածը, վիրտուալ մեքենան և ֆիզիկական սերվերը: Ցանկալի է bare-metal recovery-ի առկայությունը՝ օպերացիոն համակարգի, դրայվերների և կոնֆիգուրացիայի վերականգնումը բոլորովին նոր սարքավորման վրա:

Վիրտուալացված միջավայրում հատկապես օգտակար է instant recovery ֆունկցիան: Այն թույլ է տալիս VM-ը ժամանակավորապես գործարկել անմիջապես backup-ի պահոցից, քանի դեռ տվյալները տեղափոխվում են հիմնական պահոց: Սա զգալիորեն նվազեցնում է պարապուրդը (downtime), թեև պահանջում է արագ պահոց և ճիշտ պլանավորված ցանցային ռեսուրսներ: Էժան NAS սարքը կարող է բավարար լինել արխիվի համար, բայց չի կարող ապահովել մի քանի տերաբայթանոց VM-ի արագ գործարկումը:

Գնահատման ժամանակ անպայման անցկացրեք փորձնական վերականգնում: Ադմինիստրատիվ վահանակում միայն կանաչ կարգավիճակը չի հաստատում, որ պահուստային պատճենը իրոք պիտանի է: Անհրաժեշտ է պարբերաբար բացել վերականգնված ֆայլը, գործարկել վիրտուալ մեքենան և ստուգել տվյալների բազայի կոնսիստենտությունը (ամբողջականությունը):

2. 3-2-1 սկզբունքը և մեկուսացված պատճենը

Նույն սերվերում գտնվող մեկ սկավառակը պահուստային պատճեն չէ: Դա միայն լրացուցիչ ռիսկ է, հատկապես սկավառակի վնասման, վիրուսային վերծանման (ransomware) կամ ադմինիստրատորի սխալի դեպքում: Պրակտիկ նվազագույնը 3-2-1 սկզբունքն է. տվյալների երեք պատճեն, երկու տարբեր կրիչների վրա և մեկ պատճեն այլ տեղակայման վայրում (offsite):

Սա հնարավոր է իրականացնել հիմնական սերվերի տվյալներով, տեղական backup պահոցով և առանձին աշխարհագրական վայրում կամ ամպում (cloud) տեղադրված պատճենով: Սա հատկապես օգտակար է գրասենյակի ֆիզիկական ռիսկերի դեպքում. հրդեհը, ջրի վնասը, գողությունը կամ էլեկտրական ենթակառուցվածքի լուրջ խնդիրը մեկ վայրում տեղադրված սերվերը և NAS-ը կվնասեն միաժամանակ:

Ransomware վիրուսներից պաշտպանվելու համար գնահատեք immutable backup-ի, WORM պահոցի կամ air-gapped պատճենի աջակցությունը: Նման պատճենի հեռացումը կամ փոփոխումը սահմանված ժամկետում անհնար է, նույնիսկ ադմինիստրատորի հաշվի հասանելիության կորստի (խոցման) դեպքում: Այս ֆունկցիան մեծացնում է պահոցի արժեքը և կառավարման բարդությունը, բայց կրիտիկական տվյալների համար լիովին արդարացված է:

3. Անվտանգություն և հաշիվների կառավարում

Պահուստային համակարգն ինքնին բարձր արժեք ունեցող թիրախ է: Եթե հարձակվողը վերահսկում է backup-ի վահանակը, նա կարող է ջնջել վերականգնման կետերը կամ փոխել դրանց պահպանման քաղաքականությունը (retention policy): Ուստի ծրագիրը պետք է ապահովի բազմագործոն աուԹենտիֆիկացիա (MFA), դերերի վրա հիմնված հասանելիություն (RBAC), գործողությունների մատյան (logging) և ծածկագրում ինչպես փոխանցման, այնպես էլ պահպանման ժամանակ (in-transit & at-rest):

Հատկապես կարևոր է, թե ով է տիրապետում ծածկագրման բանալիներին: Եթե բանալին կապված է միայն մեկ աշխատակցի կամ մեկ չհաստատված հաշվի հետ, դրա կորուստը վերականգնումը կդարձնի անհնար: Սահմանեք բանալիների պահպանման և պատասխանատվության հստակ ընթացակարգ, ինչպես նաև ադմինիստրատորի հաշիվների վթարային հասանելիության (break-glass) մեխանիզմներ:

4. Լիցենզավորում և լրիվ արժեք (TCO)

Backup ծրագրերի գների համեմատությունը հաճախ մոլորեցնում է գնումների թիմին: Լիցենզիան կարող է հաշվարկվել սերվերների, VM-ների, պրոցեսորի սոկետների, օգտատերերի, աշխատակայանների կամ պաշտպանված տվյալների ծավալի (TB) հիման վրա: Լրացուցիչ արժեք կարող են ունենալ cloud connector-ը, Microsoft 365-ի մոդուլը, տվյալների բազայի agent-ը, տեխնիկական աջակցությունը և offsite պահոցը:

Համեմատության համար օգտագործեք 3-ամյա լրիվ արժեքը (Total Cost of Ownership): Դրա մեջ ներառեք լիցենզիայի թարմացումը, NAS կամ սերվերային պահոցի ընդլայնումը, սկավառակները, cloud-ի փոխանցման և պահպանման վճարը, ինչպես նաև ադմինիստրացման ժամանակը: Ամենաէժան լիցենզիան միշտ չէ, որ ամենատնտեսողն է, եթե վերականգնման ժամանակ պահանջում է ձեռքի գործողություններ կամ մշտական փորձագիտական միջամտություն:

Ծրագիրը պետք է համապատասխանի ձեր ենթակառուցվածքին

Windows Server, Linux, VMware, Hyper-V, Microsoft 365, SQL Server, Active Directory և NAS սարքերը հավասարապես չեն ինտեգրվում բոլոր ապրանքների հետ: Որոշ լուծումներ ունեն agentless backup վիրտուալ հարթակների համար, ինչը պարզեցնում է կառավարումը: Այլ դեպքերում յուրաքանչյուր մեքենայի վրա agent-ի տեղադրումը անհրաժեշտ է և տալիս է ավելի մանրամասն վերահսկողություն: Ընտրությունը կախված է միջավայրի չափսից, փոփոխությունների հաճախականությունից և ադմինիստրացման ռեսուրսից:

10-20 աշխատակից ունեցող ընկերությունում, որտեղ կա մեկ ֆիզիկական սերվեր և մի քանի կրիտիկական աշխատակայան, կենտրոնացված և պարզ կառավարման վահանակը հաճախ լավագույն ընտրությունն է: 100-ից ավելի օգտատեր, մի քանի մասնաճյուղ և վիրտուալացված սերվերներ ունեցող կազմակերպությունում անհրաժեշտ է մասշտաբայնացվող ճարտարապետություն, դերերի տարանջատում, մանրամասն հաշվետվություն և բազմատեղակայման քաղաքականություններ:

Սարքավորումն այս պատկերում հավասարապես կարևոր է: Backup սերվերը կամ NAS-ը պետք է ունենան բավարար տարողություն ոչ միայն այսօրվա տվյալների համար, այլև հաշվի առնելով պահպանման ժամկետը, տարբերակների քանակը և աճի տեմպը: RAID-ը մեծացնում է սկավառակների խափանման նկատմամբ կայունությունը, բայց չի փոխարինում անկախ backup-ին: Գնահատեք նաև UPS-ը. էլեկտրաէներգիայի անջատման ժամանակ չպլանավորված անջատումը կարող է վնասել ինչպես հիմնական, այնպես էլ պահուստային պահոցը:

Ինչպես անցկացնել ճիշտ փորձնական նախագիծ (Pilot)

Փորձնական նախագիծը պետք է լինի փոքր, բայց հնարավորինս մոտ իրական միջավայրին: Ընտրեք մեկ ֆայլային սերվեր, մեկ կրիտիկական VM և անհրաժեշտության դեպքում տվյալների բազա: Սահմանեք backup-ի քաղաքականությունը ըստ ձեր RPO-ի, ստեղծեք տեղական և արտաքին պատճեն, այնուհետև կատարեք վերականգնման տեստ մեկուսացված ցանցում:

Թեստի ժամանակ չափեք ոչ միայն backup-ի ավարտի ժամանակը: Ֆիքսեք, թե որքան տևեց VM-ի գործարկումը, որքան ժամանակ պահանջվեց կոնկրետ ֆայլը գտնելու համար, արդյոք հավելվածի տվյալները վերականգնվեցին ճիշտ, և քանի ձեռքի գործողություն պահանջվեց ադմինիստրատորից: Եթե ծրագիրը ամենօրյա օգտագործման մեջ չափազանց բարդ է, ճգնաժամային իրավիճակում այդ բարդությունը ավելի թանկ կնստի:

Փորձնական նախագծից հետո կազմեք փաստաթուղթ. պաշտպանված համակարգերի ցանկը, backup-ի հաճախականությունը, պահպանման ժամկետը, պահոցի տեղադրությունը, պատասխանատու անձանց և վերականգնման թեստի օրացույցը: Այս փաստաթուղթը օգտակար է ինչպես IT թիմի, այնպես էլ ղեկավարության համար, որին անհրաժեշտ է հստակ տեսլական, թե ինչ ռիսկեր է ծածկում ենթակառուցվածքում կատարված ներդրումը:

Երբ մեկ ծրագիրը բավարար չէ

Միասնական հարթակը պարզեցնում է կառավարումը, բայց հաճախ մասնագիտացված գործիքն ավելի լավ արդյունք է տալիս: Օրինակ՝ վիրտուալ սերվերների backup-ը, Microsoft 365-ի տվյալների պաշտպանությունը և բարձր ծանրաբեռնվածությամբ տվյալների բազայի log-backup-ը կարող են ներկայացնել տարբեր տեխնիկական պահանջներ: Նման դեպքում մի քանի լուծումների օգտագործումն արդարացված է, եթե դրանց մոնիտորինգը և պատասխանատվությունները հստակ տարանջատված են:

Կարևոր է չգնել ֆունկցիաներ միայն այն պատճառով, որ դրանք հասանելի են: Եթե ընկերությունը չունի վիրտուալացում, VMware-ի ընդլայնված մոդուլն այս փուլում ավելորդ ծախս է: Սակայն, եթե սերվերային միջավայրի վիրտուալացումը պլանավորվում է առաջիկա 12 ամսում, հարթակը փոխելու փոխարեն նախապես համատեղելի ծրագիր ընտրելն ավելի ողջամիտ քայլ է:

Ճիշտ ընտրված backup-ն իր արժեքն ապացուցում է այն ժամանակ, երբ խնդրի դեպքում թիմը չի սկսում մտածել, թե որտեղ են տվյալները և ինչպես պետք է վերականգնի դրանք: Պլանավորեք առաջին վերականգնման թեստը գնում կատարելուց անմիջապես հետո, այլ ոչ թե այն օրը, երբ սերվերն արդեն անհասանելի կդառնա: