От служители на Techopedia, 7 юни 2017 г.
Отнемане: Домакинът Ерик Кавана обсъжда архивирането и възстановяването с Tep Chantra на IDERA в този епизод на Hot Technologies.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре, госпожи и господа, в сряда в 4:00 източно е, за онези, които са на корпоративното технологично пространство, знаете какво означава това: Време е за горещи технологии. Да, именно. Казвам се Ерик Кавана, ще бъда ваш модератор на днешното събитие, озаглавено „Bulletproof: Как днешните бизнес лидери остават на върха.“ И хора, днес ще имаме приятен, интимен разговор; това ще бъде Теп Чантра и твоят наистина домакин на този разговор. Ще говорим за много различни неща, включително възстановяване при бедствия, архивиране и възстановяване, но наистина терминът, който обичам да използвам в наши дни, е устойчивост на данните - чух това от джентълмен преди няколко седмици, и наистина, има много смисъл. Защото това говори колко важно е да имате устойчива информационна инфраструктура под бизнеса си.
Това е информационната икономика в наши дни, което означава, че повечето компании разчитат в някакъв или друг смисъл на информационните активи, на данните. Искам да кажа, че дори компаниите на дребно, дори хардуерните компании, наистина всякакъв вид организация в наши дни ще имат някакъв информационен гръбнак или поне ще отидат, ако са в модерната епоха, ако щете. Има някои магазини за мама и поп, които все още могат да избегнат тези неща, но дори и там, вие започвате да виждате много повече разпространение на информационни системи, много от тях, базирани на облаци, честно казано, но много от тях все още са в предпоставка, за обработка на клиентски транзакции, за поддържане на всичко отгоре, за това да знаят какво искат клиентите ви, за да знаят какъв е инвентарът, за да знаят какво е, да могат да разберат общата картина - това са наистина важни неща днес.
И така, устойчивостта на данните е термин, който обичам да използвам; съкращението е друг термин, който идва на ум. Но искате да сте сигурни, че независимо какво се случва, вашите служители и вашата организация ще разполагат с необходимата информация, за да обслужват клиентите ви. И така, аз ще разгледам, просто като рамкирам спора, преди Теп да влезе и да ни обясни някои от нещата, които IDERA продължава. Разбира се, IDERA направи доста уеб излъчвания с нас през последната година. Това е много, много интересна компания, те са фокусирани върху някои от месинговите връзки, блокиращи и справящи се, ако е необходимо, за да оцелеят в информационната икономика. Ще се потопим.
Бронеустойчива инфраструктура - това всъщност е стара картина на мейнфрейм, вижте, това е като началото на 60-те години от Wikipedia. Помислете за връщане тогава, дните на мейнфрейм не бяха много точки за достъп до мейнфреймите, така че сигурността беше някак лесна, архивирането беше доста лесно, можете да разберете какво трябва да се направи, просто трябваше да влезете и да направите то. Разбира се, тогава нямаше толкова много хора, които знаеха какво да правят, но тези, които го направиха, беше съвсем ясно какво трябва да направите. И нямаше твърде много притеснения в това. Имахте случайни проблеми, но всъщност не беше всичко толкова често.
В миналото, тези неща бяха доста лесни - днес, не толкова. И така, ето картината - това всъщност е Херкулес, който се бори с Хидрата точно там. За онези от вас, които не са големи в митологията, Хидрата беше много неприятно същество, тъй като имаше множество глави и всеки път, когато я отрежете, на нейно място се появиха още две, така че това нещо говори за предизвикателството на справянето с някои от проблемите, които откривате в живота, конкретно в този контекст, наистина беше насочено около лошите. Изваждате лош човек, на тяхно място се появяват още две. И вие виждате това в хакерския свят, честно казано, това е голяма индустрия в наши дни и това е само едно от големите предизвикателства, които са изправени пред нас.
И така, мислите ли, ако се опитвате да очертаете стратегията си за устойчивост на данните, за какво трябва да се притеснявате? Е, има много неща за притеснение: бедствия, пожари, наводнения. Прекарах много време в Южен и Ню Орлиънс, разбира се има няколко интересни истории относно урагани и наводнения и т.н. И много пъти човешката грешка влиза в пиесата, влиза в картината, би трябвало да кажа. И такъв беше случаят дори в Катрина в Ню Орлеан, защото да, дойде ураган, това е Божи акт, както се казва, непреодолима сила . Но въпреки това човешката грешка водеше до урагана, довела до няколко нарушения на налозите. И така, имаше три от тях, всъщност имаше един по индустриалния канал и проблемът с това, че корабът не е бил акостирал правилно, надолу по реката. И ураганът влезе и го изтласка от швартовете си и всъщност наниза иглата, минаваща през завоя, където реката се огъва точно от Ню Орлиънс и тя просто тръгна право по индустриалния канал и се разби през една от тези стени. Така че, макар да, това беше природно бедствие, все пак човешката грешка доведе до този огромен проблем.
Същото нещо се случи и от другата страна на града, където имаше част от таксата, която никога не е била завършена, очевидно, защото градът и армейският корпус от инженери никога не са се договаряли кой ще плати за това. Е, не е нужно ракетен учен да разбере, че ако имате една голяма зееща дупка в налога, това не е много ефективен налог. И така, въпросът е, че човешката грешка наистина играе в сценария, при който се стига до бедствия. Така че, дори ако е огън, или наводнение, или земетресение, или какъвто и да е случаят, вероятно има нещо, което някой би могъл да има и би трябвало да направи, за да се подготви за такова събитие. И разбира се, това е, което традиционно наричаме възстановяване след бедствия. Така че, да, се случват бедствия, но хората трябва наистина да виждат тези неща и да се подготвят съответно. Ще поговорим малко за това днес с Теп.
Така че, недоволните служители - не подценявайте щетите, които един недоволен служител може да нанесе - те са там, те са навсякъде. Познавам хора, които са ми разказвали истории за наистина наистина неприятни неща, които са се случили, където хората просто правят лоши неща, умишлено саботират собствената си организация, защото са нещастни. Може би не са получили повишение, или са уволнени, или кой знае какво се е случило. Но това е нещо, което трябва да имате предвид и това е много важен компонент. В случай на лицензиране, също като FYI там, хора. Една от статистиките, които чух, беше нещо като 60 процента от всички съвети, които софтуерните компании получават за неплащане на лицензионни такси идват от бивши служители. Така че, вие искате да сте сигурни, че сте закупили този софтуер и че сте го направили справедлив и прав. Корпоративният саботаж не се случва непрекъснато, но се случва. Проблемите с поверителността също влизат в сместа; трябва да внимавате какво съхранявате и как го съхранявате, наистина помислете за тези неща.
И винаги се опитвам да напомня на хората от гледна точка на регулирането, наистина е важно да имаш план и да изпълняваш този план, защото когато натискането идва, за да се блъснеш или идва някой одитор или регулатор, ти искаш да можеш да посочиш политика, която имате, и след това обяснете как е да се обърнете към тази политика, когато се случват определени неща, като например бедствие, като въпрос на одит или какъвто и да е случаят. Искате да знаете какво правите, и да имате записи - това ще измине дълъг път, за да запазите одитора и да го правите, и това са просто добри неща.
И така, хакери, разбира се - ще говоря няколко минути за хакерите и защо те представляват такава заплаха. И разбира се, откупи, просто кажете за целия този случай с WannaCry, откупния софтуер WannaCry, който просто покри планетата в много кратък ред и явно някои умни недружелюбни хора за куп информация от NSA, имаше хакерски инструменти, които бяха използвани и изложени. Така че, напомням на хората, има една стара басня, баснята на Езоп, която казва, че често даваме на враговете си инструментите на собственото си унищожение. Това трябва да се има предвид, защото отново тази технология беше оградена от НСА, от Асоциацията за национална сигурност - всъщност не мога да си спомня какво представлява. Но той беше изложен и излезе на бял свят и просто предизвика поразия. Познай какво? И много компании не бяха надстроили средата си с Windows, така че беше стара, мислете, че това е Windows XP, това беше компрометирано. И така, отново, ако сте прилежни, ако оставате на върха на своите лепенки и версиите на операционните си системи и ако архивирате данните си и възстановявате данните си. Ако правите всички неща, които би трябвало да правите, подобни неща не са толкова голям проблем. Но можете просто да кажете на хората, които са аксими: „Хей, познайте какво? Не ни интересува, изключете системата, рестартирайте я, заредете резервните копия. ”И тръгвате към състезанията.
Така че въпросът е да, тези лоши неща се случват, но има неща, които можете да направите за това - за това днес ще говорим в шоуто. И така, направих някои проучвания - всъщност беше някак интересно, ако отидете в Уикипедия и потърсите хакерство, стига чак до 1903 г. Когато човек хакна система за телеграфи и изпращаше груби съобщения през телеграфа, само за да докажа, че може да го хакне, предполагам. Мислех, че това е доста забавно. Въпросът е, че хакерите по принцип са добри в разбиването и влизането, това е, което правят години и години и години. Те са като бравите за заключване на съвременния интернет свят.
И трябва да запомните, че всяка система може да бъде хакната, тя може да бъде хакната отвътре, тя може да бъде хакната отвън. Много пъти, когато тези хакове се появят, те няма да се покажат, или хората, които влизат във вашата система, няма да направят много за известно време. Изчакват известно време; има малко включена стратегия и отчасти това е само защото бизнес страницата на тяхната работа, защото обикновено това, което хакерите правят, е, че те просто правят една своя малка част от програмата, така че много момчета, които са добри в проникването защитни стени и проникваща информационна система, това е нещото, което те правят най-добре, а след като проникнат в система, тогава те се обръщат и се опитват да продадат този достъп на някого. И това отнема време, така че често това се случва, че някой зад кулисите просто се опитва да продаде достъп до всяка система, която е хакнал - вашата система, потенциално, която не би била много забавна - и се опитва да разбере кой всъщност плати за достъп до системата.
Така че, съществува такава разнородна мрежа от хора или организации, които сплотяват и си сътрудничат, за да използват открадната информация. Независимо дали става въпрос за кражба на самоличност или просто кражба на данни, дали те правят живота неприятен за една компания - това е така с този откуп, тези момчета просто се хващат за вашите системи и изискват пари, и ако получат парите, може би или може би няма да ти върнат нещата. Разбира се, това е истинското страшно нещо, защо бихте искали дори да платите този откуп? Откъде знаеш, че ще го върнат? Те може просто да поискат двойно или тройно. И така, отново всичко това говори за важността на истинското мислене чрез вашата информационна стратегия, вашата устойчивост на вашите данни.
И така, направих още няколко изследвания, това е старо 386; ако си стар като мен, би могъл да си спомниш тези системи. И не бяха толкова проблематични по отношение на хакването; тогава нямаше много вируси. В наши дни това е различна игра, така че, разбира се, идва интернет и променя всичко. Всичко е свързано сега, там има глобална аудитория, първите големи вируси започнаха да атакуват и наистина хакерската индустрия започна да балонира, честно казано.
Така че, ще поговорим малко за IoT, имаме добър въпрос вече от член на аудиторията: Как да защитя IoT устройства от гледна точка на уязвимостта? Това е голям проблем - откровено казано, в това се влагат много усилия в момента как да се справите с потенциала за хакване на IoT устройства. Това е много полза, обичайните проблеми, върху които се фокусирате, защита на паролата например, преминавайки през процеса на настройка внимателно, задаване на собствена парола. Много пъти хората просто ще оставят парола по подразбиране там и това всъщност ще доведе до уязвимост. Така че, това са основните неща. Току-що направихме поредното предаване за сигурността по-рано тази седмица, в нашето радио предаване, с няколко експерти там и всички те казаха, че 80–90 или повече процента от хакерските проблеми, независимо дали става въпрос за IoT или софтуер за откупуване, или каквото и да е, ще бъдат избегнати, ако просто се занимавахте с основните положения, ако просто сте се уверили, че сте покрили базите си, вие сте направили всички основни неща, които знаете, че трябва да правите, които се справят с над 80 процента от всички проблеми навън.
И така, интернет на нещата, ОК, IoT. Е, ако мислите за IoT, не всичко е толкова ново. Честно казано, има производители от висок клас, които правят такива неща преди 20 и 30 години, а след това преди около 15, 20 години, тогава влезе RFID - етикети за радиочестотна идентификация - което беше изключително полезно за подпомагане на много големи организации, като търговци на дребно, например транспортни компании, всяка продуктова компания, която премества нещата из цялата страна, по целия свят, изключително полезно е да разполагате с всички тези данни, да разберете къде отиват вашите неща; ако нещо изчезне, разберете.
Разбира се, това не е глупаво решение, всъщност аз имах моя лаптоп, с който Apple бягаше от летището в Атланта - летището в Атланта Хартсфийлд - някой просто ми взе чантата с компютъра. Мислех, че вече не крадат чанти; те винаги намират чанти - грешно. Някой открадна чантата и след това се появи около месец по-късно, тя се събуди, получих малко съобщение от Apple, от iCloud, че се събуди на около седем до десет минути южно от летището в Атланта Хартсфийлд; някой просто реши да влезе в него. Те просто седяха на него около месец и аз преминах през доста отчайващия процес на осъзнаване, добре, добре, знам грубо къде е, може да е в тази къща, тази къща, къщата от другата страна на улицата, просто беше временно. Какво правиш? Как, как ви е полезна тази информация?
Така че, въпреки че научавате нещо, понякога не можете да направите много за това. Но въпреки всичко този свят с активиран IoT, трябва да кажа, мисля, че не сме съвсем готови за него, да бъдем честни. Мисля, че имаме случай, в който има много добри технологии навън и може да се движим твърде бързо, за да се възползваме от тези неща, защото заплахата е толкова значителна. Просто мислим за броя на устройствата, които сега са част от пейзажа на заплахите, тъй като хората говорят за това, това е огромна, огромна вълна от устройства, която идва на пътя ни.
Някои от големите хакове, които се случиха напоследък, сваляйки DNS сървъри, се отнасят до кооптиране на IoT устройства и обръщане срещу DNS сървъри, просто класически DDoS хакове, разпределено отказване на услуга, където буквално тези устройства се препрограмират за повикване на DNS сървър с мехурни темпове, където ще получите стотици хиляди заявки, постъпващи в този DNS сървър, и просто се задавя и срива и умира. Това е нещо, при което историята на страхотното в не толкова популярен уебсайт сървърите просто се срива - те просто не са направени за такъв тип трафик.
И така, IoT е просто нещо, което трябва да имате предвид, ако отново се занимаваме с архивиране и възстановяване, просто е важно да запомните, че всяка от тези атаки може да се случи във всеки даден момент от време. И ако не сте подготвени за това, тогава ще загубите много клиенти, защото ще направите много хора много нещастни. И вие ще имате това управление на репутацията, за да се справите. Това е един от новите термини, които се носят наоколо, „управление на репутацията.“ Струва си да си спомним и оценим, че репутацията може да отнеме години за изграждане и минути или дори секунди за пропиляване. Така че, просто имайте това предвид, когато планирате информационната си стратегия.
И така, има цялата тази концепция за хибридния облак. Имам един от старите си, любими филми от детството, Островът на д-р Моро там, където те създадоха тези неща, полу-животни, полу-създания, това е нещо като хибридния облак. Така че локалните системи ще са тук от години - не се заблуждавайте, ще отнеме много време, за да приключите тези локални центрове за данни - и дори в малкия бизнес ще имате много клиентски данни във вашите системи и вашите дискове, и колкото по-сложна е ситуацията, толкова по-трудно ще бъде да останете на върха. Това каза, консолидирането в една база данни също винаги е истинско предизвикателство, особено със система като MySQL, например.
Опитът да претъпчете всичко в една система никога не е бил много лесен за правене. Обикновено когато се прави, има проблеми, получавате проблеми с производителността. Така че, отново, това ще бъде проблем от доста време. Наследена инфраструктура там в центровете за данни и в бизнеса, разбира се. Това беше проблемът с WannaCry, имате ли всички тези XP системи - Microsoft вече не поддържа XP. Така че е просто невероятно как някои от тези проблеми, които стават толкова тежки и толкова болезнени парично и по друг начин, могат да бъдат избегнати с основна поддръжка и поддръжка. Основни неща.
Така че, ще има разлика в уменията; тези пропуски в уменията ще нарастват с течение на времето, защото отново облакът е бъдещето - не мисля, че в това има съмнение - облакът е там, където вървят нещата; в облака вече има център на тежестта. И това, което ще видите, са все повече компании, все повече организации, които гледат към облака. Така че това ще остави някои пропуски в уменията от страна на помещението; все още не е там, но идва. И дори да помислите за амортизацията, така че много големи компании, те не могат просто да се преместят в облака - биха могли, но това няма да има много смисъл, скъпо, защото амортизират всички тези активи три, пет, седем години, може би.
Това създава доста важен период от време, по време на който те ще мигрират далеч от предварително и към облачната среда. И честно казано сега стигнахме до момента, в който локалните вероятно са по-малко сигурни от облака. Странно, защото това беше голямото почукване за дълго време: компаниите се тревожеха, че ще отидат в облака от съображения за сигурност, притесняват се облакът да е податлив на хакове. Е, все пак е, със сигурност, но наистина ако погледнете големите момчета: Amazon, Microsoft, дори сега SAP и Google, всички тези момчета, те са доста добри в тези неща, те са доста добри в осигуряването на облака себе си.
И след това, разбира се, най-накрая от страна на предварително инсталирани системи: тези приложения се набиват много дълго в зъба в наши дни. Чух един виц един път, определението за наследен софтуер е всеки софтуер, който се произвежда. (Смее се) Смятам, че е някак смешно. И така, към облачните системи споменах основните играчи, те просто растат с всеки изминал ден. AWS все още доминират в това пространство, въпреки че Microsoft, за да имат кредит, наистина е измислил някои неща и те са фокусирани много внимателно. Така е и SAP, облакът SAP HANA, това е платформата HANA Cloud, както го наричат - това е огромна зона на фокус за SAP и по очевидни причини. Те знаят, че облакът сега има гравитация, знаят, че облакът е отлична бойна зона за технологии.
И така, това, което виждате, е тази консолидация около облачните архитектури и ще имате много работа през следващите две години относно миграцията от облак в облак. Дори главното управление на данни в облаци ще се превърне в голям проблем. А Salesforce - вижте колко голяма Salesforce стана - това е абсолютна сила, с която трябва да се съобразите. Също така, маркетинговите системи са в облака; има нещо като 5000 компании за маркетингови технологии сега - 5000! Това е лудо. И виждате повече усилия в този един стъклен прозорец, за да можете да управлявате много облачни среди. И така, един последен слайд от мен и след това ще го предам на Теп, за да ни даде съвет за това как можем да останем пред играта, ето.
Това, за което говорихме в моето радио шоу по-рано тази седмица, моделът за облак на споделена отговорност. И така, това, което те говорят, е как AWS е бил отговорен за осигуряването на облака, така че сигурността на облака. Може да видите магазини за изчисления, мрежи от бази данни и т.н. Но клиентът е отговорен за данните и сигурността в облака. Е, беше смешно, защото те използват този термин „споделена отговорност“ и това, което аз събрах от гостите на нашето шоу, е, че това изобщо не е споделено. Идеята е, че е ваша отговорност, защото шансовете са, ако натискането се появи, а някой зарази околната среда, AWS вероятно няма да бъде подведен под отговорност.
Така че, това е някакъв странен свят, мисля, че това е малко двуличен термин, „споделена отговорност“, защото наистина е нещо не, това е все още ваша отговорност да останете на върха на всички тези неща. Така че, с това и знам, че говорих малко за IoT - имахме един добър въпрос как да защитим IoT устройства - ще излезе абсолютен набор от технологии, за да можем да се справим с това. Очевидно имате някакъв софтуер за някакъв фърмуер на самите IoT устройства, така че това е нещо, което трябва да имате предвид; трябва да се притеснявате за протокола за удостоверяване, който трябва да използвате за тези неща. Но както казвам, основите, вероятно ще преживеете голяма част от неприятностите, с които ще се сблъскате, просто правите защита на паролата, правене на смяна на пароли и наистина вид на това - да наблюдавате тези неща и да гледате,
Голяма част от технологиите, използвани например за мониторинг на измамите или злобната активност в мрежите, наистина се фокусират върху извънредните хора и това е нещо, в което машинното обучение всъщност е доста добро, в групирането и гледането на хора, които са извънградни, като се наблюдават странни модели на поведение. Честно казано, това, което видяхме с тази скорошна DDoS атака на DNS сървъри, където изведнъж всички тези устройства започват да изпращат обратно повикване до определена шепа сървъри, добре, че не изглежда добре. И честно казано, за какво винаги напомням на хората с тези системи: Всеки път, когато имате сериозна автоматизация в такива видове среда, винаги имате ръчно отмяна, имате ключ за убийство - искате да имате програмиран ключ за убийство там, за да се затвори тези неща надолу.
Така че, с това, ще натисна първия слайд на Теп, той ще прави някои демонстрации за нас. И тогава ще продължа напред и ще ви дам ключовете от раздела WebEx. Сега, той идва на вашия път и го отнемете.
Теп Чантра: Добре, благодаря, Ерик. Казвам се Теп Чантра и съм продуктов мениджър тук в IDERA. Днес исках да поговорим за решението за архивиране на предприятието на IDERA, а именно SQL Safe Backup. За тези от вас, които са запознати със SQL Safe Backup, нека да разгледаме накратко някои акценти на продукта, които … извинете ме. Така че, както може би вече сте се досетили, хората казват, че архивирането, архивирането и възстановяването на продукта на SQL Server, една от ключовите характеристики на SQL Safe е възможността за извършване на бързо архивиране. И това е важна характеристика, като се има предвид, че повечето резервни копия трябва да бъдат направени и в повечето случаи те трябва да бъдат направени много бързо, в малък прозорец от време.
В някои среди срещата с тези прозорци за архивиране може да бъде доста предизвикателство, особено когато имате няколко големи бази данни, които трябва да бъдат архивирани. Способността на SQL Safe да завърши операциите за архивиране бързо позволява на крайните потребители да могат да се срещнат с тези прозорци за архивиране. Говорейки за големи бази данни, архивиране на тези големи бази данни, очевидно по-големи архивни файлове. Друга функция, при която SQL Safe свети е възможността за компресиране на архивни файлове. Използваният алгоритъм за компресия може да постигне до 90–95 процента компресия. Това означава, че можете да съхранявате резервни копия по-дълго или да позволявате икономия на разходи по отношение на нуждите от съхранение.
От обратната страна на операциите за архивиране имате операции по възстановяване. Една от битките, с които DBA трябва да се бори при възстановяването на бази данни е, че тези бази трябва да бъдат възстановени възможно най-бързо. В случаи на големи бази данни пълното възстановяване на архивен файл може да отнеме няколко часа, което очевидно означава по-дълъг престой и евентуално загуба на приходи. SQL Safe за щастие има тази функция, наречена „Незабавно възстановяване“, която основно съкращава времето между започване на възстановяване и когато базата данни може да бъде достъпна от крайни потребители или дори приложения.
Спомням си, че веднъж говорих с клиент, където той съобщи, че възстановяването на една конкретна база данни отне 14 часа. Но с функцията за незабавно възстановяване той успя да получи достъп до тази база данни в рамките на един час или по-малко. Управлението на базата на политики, още една отличителна черта на SQL Safe е способността да създавате политики и да управлявате операциите за архивиране чрез тези политики. Когато конфигурирате политика, вие основно определяте кои инстанции трябва да се архивират или кои бази данни за тези инстанции трябва да бъдат архивирани, какви операции за архивиране да се извършват и дори графикът, в който тези резервни копия трябва да се извършват.
Освен това можете да конфигурирате и известия за предупреждения. По този начин можете да бъдете уведомявани за събития като архивирането, завършено успешно, архивирането не успя, може би това може да се види, но има някои предупреждения, свързани с тази операция. Ще бъдете уведомени и ако резервното копие не се изпълни по график. Това е важно известие, тъй като тогава може да имате риск да се появи прозорец от време, в който не е имало резервно копие. И получаването на такова известие ще ви покаже, че трябва да отидете там и да направите това архивиране и след това евентуално да направите някои проучвания защо това архивиране не се изпълни по план.
Някои от другите неща, нека да видим тук, огледално устойчиво на откази, което по същество означава, че имаме способността да създаваме дублиращи се резервни файлове на повече от едно място. Така че, например, да кажем, че имате основно целево местоназначение като - какво е основното ви хранилище, където отиват всичките ви резервни файлове. Въпреки това може да имате нужда да имате копие на същия файл за архивиране, например на самата локална машина, само в случай, че трябва да направите някои допълнителни тестове, уверете се, че тази база данни може да бъде възстановена, независимо от случая. SQL Virtual Database Optimize - това, което по същество е, е, че имаме друг продукт, който наскоро беше интегриран в SQL Safe, наречен SQL Virtual Database.
Както споменах, това е наскоро интегрирано, така че всъщност е включено в самия SQL Safe. Сега това, което виртуалната база данни SQL по същество ви позволява да направите, е всъщност да създадете виртуална база данни. (Смее се) Мразя да използвам същите термини като дефиницията, но това, което по същество се случва е, че ще монтираме база данни и базираме на резервния файл. И така, това, което по същество се случва е, че SQL Server смята, че базата данни всъщност е работеща и работеща, докато всъщност чете данни от резервния файл, а не всъщност създава самата база данни във файловата система.
Това е наистина полезно, защото ви позволява да получите достъп до данните, които са в резервния файл, без всъщност да изразходвате допълнително дисково пространство, така че той е наистина удобен, особено когато имате работа с огромни бази данни, които просто трябва да получите, направете бърз преглед или да свършите някаква разработка. Шифроване с нулево въздействие - това, което по същество означава, е, че когато извършваме архивиране на тези бази данни, всъщност можем да кодираме архивните файлове и когато шифроваме тези резервни файлове, не добавяме никакво допълнително натоварване към действителното производителност на системата. Така че, това е напълно нищожно. Доставкаът на журнали е друго нещо, което можем да направим, когато нашите правила, както споменах по-рано, и по отношение на изгодното лицензиране - това, което по същество означава, е, че нашите лицензионни модели ви позволяват да премествате лицензионни модели от една инстанция в друга инстанция, с няколко прости кликвания на мишката.
Нататък, нека да разгледаме накратко архитектурата на самия продукт. Така че, има основно четири основни компонента на продукта. Започваме отляво, конзолата за безопасно управление на SQL и уеб конзолата. И двете по същество са потребителски интерфейси, единият е настолен клиент, а другият е уеб приложение. И двата потребителски интерфейса извличат данни от следващия компонент, който е базата данни на SQL Safe Repository. Базата данни на хранилището основно съхранява цялата ви оперативна история, всички операции за архивиране и възстановяване. Тези подробности се съхраняват тук. Всички тези данни, които са в хранилището, се управляват от услугата за безопасно управление на SQL, която е следващият компонент. Службата за управление е отговорна за актуализирането на базата данни на хранилището и изпращане на известие за предупреждение. Данните относно операциите за архивиране и възстановяване всъщност идват от SQL Safe Backup Agent, който е последният компонент, вдясно вдясно.
SQL Safe Backup Agent е компонент, който е инсталиран на всички сървъри, хостващи екземпляри на SQL Server, които се опитвате да управлявате със SQL Safe. И това е услугата, която всъщност е отговорна за извършването на архивирането и компресирането им. Сега на този слайд има и пети компонент, който не е напълно задължителен, но това е приятно нещо. И това са нашите RDL файлове за SQL Server Reporting Services. Това, което по принцип ви позволява да направите, е да разгърнете някои RDL файлове към SQL Server Reporting Service, така че да можете да пускате отчети срещу нашата база данни на хранилището. И ние имаме редица различни доклади, като последния път, когато вашият архив се изпълни, подробности относно операциите за архивиране, какво имате.
И ме извинявай. Нека продължим напред и да разгледаме самия SQL Safe. Дай ми секунда тук. И дайте ми секунда да вляза. Както виждате, в момента съм заредил уеб приложението, но първо, всъщност бих искал да разгледам настолното приложение. Така че, нека бързо да го уволня. И това е настолното приложение SQL Safe, когато за първи път се зареди, ще ви отведе до изгледа SQL Safe днес. Това по същество изброява всички операции за архивиране или възстановяване, които са се случили от днес. Той също така ви дава бърз статус на вашата среда, както можете да видите тук, той казва, че моите политики имат една политика, които са в състояние на ОК, което е добре, защото имам само една политика и се надявам, че не е . Също така ви дава обобщение на успешните операции, всички операции, които може да са се провалили. Като цяло съм в добра форма: Само с бърз поглед можете да видите всички зелени; добре сме да отидем.
Отляво тук можете да видите всички сървъри, които сте регистрирали в SQL Safe и тези, които основно управлявате. Ако го разширите, ще видите списъка с бази данни в тази система. Ако изберете конкретна база данни, можете да видите оперативната история за тази конкретна база данни. Няма какво повече да обясняваме, освен това, че можете да продължите напред и да извършвате ad hoc архивиране и от този прозорец, и това е наистина бързо и просто. И нека ви демонстрирам това наистина бързо. Просто кликнете с десния бутон върху него и изберете операцията, която искате да направите. И за тази цел ще продължа и ще избера резервна база данни. И SQL Safe Backup Wizard се отваря. От тук получавате това, например кой екземпляр, който искате да извършите архивирането, и изберете кои бази данни, които искате да архивирате. В този случай избрах машината HINATA и тази база данни на Contoso Retail, тъй като това бях подчертал, когато избрах опцията. Ще продължа напред и ще го оставя за сега, но наистина имате възможност да изберете повече бази данни, така че, ако искате да архивирате цялата си потребителска база данни, например, можете да изберете този радио бутон и той ще селектира предварително всички тези. Нека продължа напред и просто да продължа с това.
На следващата страница на съветника. Тук мога да избера типа на архивиране, който искам да изпълнявам, и тук имате няколко различни опции. Това е - Сигурен съм, че се намират във всички помощни програми за архивиране, например можете да извършите пълно архивиране, диференциално архивиране, архивиране на архив на транзакции или всъщност можете просто да архивирате самия файл на базата данни. Имате и опции за създаване на резервно копие само за копиране, което основно се използва, когато не искате да се забърквате с LSM. Засега ще избера „не“. Освен това имате възможност да проверите резервното копие след пълното архивиране - по този начин вие се уверявате, че резервното копие е добро и може да бъде използвано по-късно. Винаги е една от тези функции, които искате да сте сигурни, че имате, само за да ви дам малко увереност, че архивирането е използваемо.
Тук можете да намерите името и описанието на данните. Това са по същество метаданни, които можете да помогнете лесно да идентифицирате за какво е използвано архивирането, така че тук ще кажа демо цел. И използвайте резервното копие на вашата база данни за демонстрация. На следващо място, тук определяме къде да запишем резервния си файл и тук имате няколко различни опции: Можете да го запишете в един файл, можете да създадете файлове с ивици, имате възможност да изберете тук целевата дестинация, ние също поддържат домейн с данни. И това, облак Amazon ST, в случай, че там искате да запазите информацията си.
Ще продължа с един файл за тази демонстрация, това активиране на мрежовата устойчивост, това е наистина приятна функция в SQL Safe в смисъл, че ако архивирате до мрежово местоположение - това е, което правя тук, можете да видите от основния архив - ако създавате резервно копие на мрежово местоположение, има вероятност да срещнете някакви мрежови икони. В някои случаи, ако вашите мрежови хълцания са противодействани, операцията по архивиране ще се разпродаде напълно. Е, активирайте опцията за устойчивост на мрежата, това, което тя по същество прави, е, ако се срещне хълцане на мрежата, това, което по същество прави SQL Safe, прави ли пауза на архивирането и чака определен период от време и опитва отново мрежовото местоположение. И ако е в състояние да се свърже, то просто ще възобнови архивирането точно там, където е спряло. По този начин не прекарвате часове в даден момент, опитвайки се да стартирате тази резервна копия и точно когато тя се приближава до приключване, срещна се мрежово хълцане - ние не продаваме операцията веднага, просто ще изчакаме малко и опитаме за да го попълните отново.
Има някои други опции при конфигурирането на това. Сега това основно включва интервала, през който ние се опитваме отново, така че в този смисъл, ако срещнем мрежово хълцане, той ще се опита да влезе в мрежовото местоположение отново след десет секунди. Вторият вариант тук ви казва, че ако срещнем хитрици на мрежата, той казва 300 секунди тук - така че, пет минути, общо - тогава просто напълно ще продадем операцията за архивиране. И това е пет минути последователно, така че ако отново опитаме отново и отново и в рамките на тези пет минути все още не можем да възстановим мрежовата връзка, тогава напълно ще продадем операцията. Тази последна операция тук е основно за цялото време на архивиране, така че ако загубите десет секунди тук, възстановете връзката си и след това отново загубете връзката, ако това основно се повтаря за 60 минути, тогава тази операция ще се разпродаде. И те са конфигурирани, както виждате, така че можете да го приспособите към вашата среда.
Тази опция за огледален архив тук, това е, за което говорих по-рано, имайки отказоустойчиво огледало. Тук можете да посочите друго местоположение за архивиране, в случай че някога искате да го направите. Сега ще оставя това без проверка, просто защото бих искал да продължа напред и да продължа. В тези прозорци с опции можете да определите неща като вашия тип компресия, който искаме да използваме за тази резервна операция и дали искаме да активираме криптиране за архивния файл. Предлагаме няколко различни опции за компресия, дори и нито една, ако решите, че изобщо не искате да правите компресия. Така че, просто е бързо да преминете през тези опции.
Високата скорост основно се опитва да завърши архивирането възможно най-бързо, като същевременно включва известна степен на компресия. ISize е по-фокусиран върху включването на възможно най-много компресия, но може - тъй като се опитваме да го компресираме толкова много - може да отнеме малко повече време и вероятно да използва малко повече процесор. Ниво 1 по същество означава най-малкото количество компресия чак до ниво 4, най-голямото количество компресия, което можем да добавим. И така, това е малко по-подробно, обикновено iSpeed - каква е думата? Диапазони между компресия от ниво 1 и ниво 2; трябва да погледнете вашата система, за да видите колко CPU и налични ресурси са на разположение и взема решения за много компресия, тя трябва да използва между ниво 1 и ниво 2.
ISize прави същото, с изключение на ниво 3 и ниво 4. Има някои други разширени опции тук, колкото и колко има в процесора, който трябва да използваме, ето опцията за създаване на картографски данни за виртуалната база данни на SQL, а също и нашата функция за незабавно възстановяване. Можете да включите вход в базата данни и някои други опции, които някои потребители намират за много ценни, така че например да генерирате проверки от това, за да могат да проверят това по-късно, за да се убедят, че резервните файлове са добри. Ако преминем към следващата страница, тук настройвате известията си. И можете да видите различните опции, които имаме тук: уведомете, ако резервното копие не успее, уведомете дали резервното копие е пропуснато, по някаква причина. Ако резервното копие е анулирано или ако резервното копие завърши с предупреждение, и ако желаете, можете да бъдете уведомени дали е резервно копие чисто. За среди, където има голям брой бази данни, това може да не е нещо, което искате да активирате, само защото е повече от вероятно резервното копие да успее и ще бъдете заляти с имейли.
На следващата страница можете да видите обобщение на това, което сте дефинирали, защото тази операция за архивиране. И ако желаете, ако всичко изглежда добре, можете да продължите и да кликнете върху резервно копие, ние го стартираме. Преди да щракна за резервно копие, нека да продължа напред и да ви покажа този бутон за генериране на скрипт. Защото това, което SQL Safe предлага интерфейс на командния ред, където всъщност можете да стартирате операция за архивиране или възстановяване, какво имате чрез командния ред, DOS подкана. Ако щракнете върху генериращия скрипт тук, той по същество ви предоставя действителния скрипт, който можете да използвате, ако искате да свалите резервното копие от командния ред.
Друго хубаво нещо е, че ние също предлагаме разширени процедури за съхранение и в този случай генерираме скрипт за вас, който ще изпълни тази същата операция за архивиране, използвайки разширени процедури за съхранение - само един малък бърз шрифт, който исках да споделя. Така че да отидем и да стартираме тази резервна копия. И можете да видите, че архивирането вече е започнало. И тази база данни е малко голяма, така че може да отнеме малко време. Виждате, че преди съм тичал няколко пъти, така че ще ми отнеме от една минута до три минути. Това е ниво 4, така че предполагам, че ще е между тези два пъти.
Докато това върви, нека да разгледаме наистина бързи политики. Както споменах по-рано, политиките ви позволяват да конфигурирате планирани операции за архивиране във вашето предприятие, така че тук имам политика, предварително конфигурирана и вместо създаване на нова, нека да продължим напред и да разгледаме подробностите на тази. Извинете се, моят VM работи на моя личен лаптоп и изглежда, че работи с вентилатора доста трудно. (Смее)
Ерик Кавана: Това е добре - знаете, щях да ви задам въпрос, докато наблюдаваме това тук. Използва ли IDERA много заснемане на данни по отношение на архивиране, или правите цели архиви всеки път? Как става това, знаете ли?
Теп Чантра: Кажи това още веднъж, съжалявам?
Ерик Кавана: Да, така че знаете ли дали IDERA използва CDC, променя технологията за заснемане на данни, за да прави по-малки резервни копия или всеки път прави пълни архиви?
Теп Чантра: Не вярвам. Спомням си, че видях това преди, в редица билети. И ако си спомням правилно, не, ние не използваме CDC, ние, за да бъдем честни, по същество оставяме SQL Server да извърши архивирането, ние просто улавяме данните между тях и ги компресираме, което води до създаден е резервен файл. Така че, по същество използвайки това. Да.
И така, сега, когато моята политика е заредена - о, съжалявам, имахте ли друг въпрос?
Ерик Кавана: Не, това е всичко. Продължавай.
Теп Чантра: Добре, така че сега, когато моята политика е заредена, можете да видите някои бързи неща тук: име, описание, можете да зададете каква политика ще създадете, независимо дали е политика, която ще се управлява, графикът ще се управлява от агента на SQL Server или графикът ще се управлява от резервния агент за SQL Server. В повечето случаи ще искате да използвате агента на SQL Server, тъй като това обикновено е нещо, което работи във вашата система, така че може да се възползвате от това, което е достъпно за вас. В раздела за членство тук посочвате копията в резервните бази данни, които искате да архивирате. И в този случай можете да видите, че съм добавил всички мои регистрирани инстанции и съм посочил конкретна база данни, която трябва да бъде архивирана. Сега, ако исках, бих могъл да продължа напред и да редактирам тези неща и да кажа: „Искам да архивирам всички бази данни или просто потребителски бази данни, или дори системни бази данни.“ Хубавото на това е, че мога също да използвам заместващи символи и да създавам определени бази данни.
Няма да правя тази промяна тук, просто защото не искам да правя големи промени в настройките си. Така че, да се върнем към опциите. И при опциите, тук определяте какъв вид архивиране ще изпълнявате и ако погледнете тук, имам конфигурирани пълни архиви, диференциални архиви и големи архиви. И за всяка от тези резервни копия мога да определя дали искам да използвам определено количество компресия или да включа криптирането. Точно като опциите, които бихте намерили в съветника за ad hoc. И на места можете също да определите местоназначението на тези операции за архивиране. Едно от хубавите неща в политиките е, че можете също така да определите дали искате да продължите или да изтриете тези стари архивни файлове, въз основа на броя X дни или седмици, какво имате.
И това може да се конфигурира за всеки тип архивиране. И така, можете да видите тук, имам пълните си резервни копия за изтриване след една седмица. Диференциалното ми изтриване след два дни и искам резервните ми копия да се изтрият след един ден. Това е наистина хубаво, защото автоматизира обработката на сценарии, стари архивни файлове, като запазва само тези, които наистина ви трябват, в зависимост от времето. Следващата страница определяте графика и отново графикът може да бъде специфичен за всеки тип операция за архивиране, която ще завършите, така че за моята пълна, аз я изпълнявам седмично, моята разлика я изпълнявам на всеки шест часа, моите дневници правя на всеки 30 минути. На следващата страница е мястото, където сте задали известията и това е по същество същите типове известия, които сте намерили в ad hoc резервно копие, едната разлика е, че имате тази нова, друга опция, при която тя може да ви каже дали резервното копие не се стартира Както е планирано. Това е мястото, където можете да бъдете предупредени при ситуации, в които резервните ви копия не се изпълниха. Истински важно, особено в случаите, когато имате определени SLAs, за да сте сигурни, че имате резервни копия на разположение в моментите, в които имате нужда от тях. И на следващата страница можете да видите обобщението. Ако бях направил някакви промени, ако щракнах на финала, той ще излезе и ще направи тези промени, запишете го и например ще го запиша в хранилището на задачите на агента на SQL Server.
И само за да ви покажа бързо бързо, ето една политика и работа, които създадох за тази конкретна политика. И можете да видите, че създаде три различни работни места: по един за всеки тип архивиране. Сега, наистина бързо, позволете ми да разгледам накратко HUD интерфейса и вида - както споменах по-рано, виртуалната база данни беше до, която сме интегрирали в SQL Safe. Както вече споменах, по същество заблуждава SQL Server, че вярва, че действителна база данни е възстановена, когато в действителност ние просто четем резервния файл. Така че, нека да продължа напред и не един истински бърз за вас, момчета. Нека да взема архивен файл. Ето, нека да взема четирима тук. Процесът е завършен и наистина бързо, ако освежа моите бази данни тук, можете да видите, че базата данни е достъпна и SQL Server смята, че е на живо, но в действителност ние просто четем данните от базата данни.
Някои други функции, които са нови за това издание, е възможността за извършване на архивиране, използвайки най-новия формат за архивиране. Това е наистина удобно за онези клиенти, които трябва да се възползват от нашето управление, основано на политики, но те искат да запазят файловия формат на SQL Server по някаква причина. Сега знам, че ни липсва времето, така че мисля, че бих искал да продължа напред и да спра тази презентация, само за да можем да вземем някои въпроси или какво ли още не.
Ерик Кавана: Да, разбира се. Така че, мисля, че един от ключовете наистина е в управлението на политиките, нали? Както като мислите за оптималната политика и на какво се основавате? Очевидно в някои случаи има правила, за които трябва да се притеснявате, но в бизнес може би това не е силно регулирано; просто трябва да намерите оптималните времена, за да правите резервни копия и тогава предполагам, че получавате някои отчети за това колко време отне и колко скъпо беше това по отношение на изчислителната мощност и т.н. Какво влиза в определянето на оптималната политика?
Теп Чантра: Това наистина е от всеки случай, всяка среда ще има различна политика по отношение на това кога трябва да се изпълняват тези архиви. Също така, и това може да доведе до типа на изпълняваните архиви, графикът, в който те се изпълняват, и това наистина определя, наистина зависи и от техните нужди за възстановяване, предполагам, това е отговорът.
Ерик Кавана: Добре, да. И вие говорихте за възможността да правите различни видове архивиране и ивици беше една от възможностите. Това ли е за някакви горещи и студени данни, или каква е логиката зад ивицата, за разлика от някакъв друг метод?
Теп Чантра: Така че, мисля, че най-добрият отговор, който мога да дам, е, че така, райените файлове, това, което по същество правим, е да напишем резервното съдържание в редица различни файлове. Вярвам, че идеята за използване на райеви файлове е, че евентуално можете да напишете резервните си файлове по-бързо по този начин. Например, можете да имате всеки различен файл да отиде на различно място. Това струва на сървъра и средства за сигурност, тъй като разпространявате резервните си файлове на различни места.
Ерик Кавана: И има някои готини, нови неща по отношение на възможностите за възстановяване, нали? Защото да кажем, че има някакво събитие, независимо дали става въпрос за природна катастрофа или откуп, независимо от случая. Не е нужно да имате само една възможност за възстановяване, нали? Можете ли да зададете приоритети за това какво се възстановява и какви видове данни? Можете ли да говорите за опциите там?
Tep Chantra: Е, що се отнася до възстановяването, споменах по-рано, че предоставяме възможност за незабавно възстановяване, което по същество получава потребителите по-бързо данните, нали? И само за да демонстрирам, го направих по-рано, така че можете да видите тук, че отново тази база данни не е много огромна, това е тази, която работи на моя лаптоп. Така че, мисля, че може би е като два гига в размер, но тази база данни е завършена в рамките на 37 секунди. Действително възстановяване. И така, на мен ми отне 37 секунди, преди да имам достъп до данните си, така че с моменталното възстановяване успях да дойда до моята база данни в рамките на две секунди. Така че можете да си представите как би изглеждало, ако вашата база данни е много по-голяма.
Ерик Кавана: Да, добър момент. И разбира се, говорехме за това преди шоуто; сте прекарали много време на фронтовите линии в подкрепа на хората и след това се преместихте в пространството за управление на продукти, така че предполагам е малко по-различно предизвикателство. Но ти беше на първа линия - мисля, че е доста добро място да научиш къде хората се объркват и какви са някои от проблемите. Какво виждате като някои от по-често срещаните клопки, които хората биха могли да избегнат, ако просто мислят за тези неща по-добре?
Теп Чантра: Някои от често срещаните клопки са само - предполагам, както споменахте по-рано - да планирате своите резервни копия. Имало е моменти, в които съм виждал, че хората се опитват да използват, например, нашите политики, политики, политики, които изпълнявате много резервни копия и базирате на LSM. И в някои случаи съм виждал, че някои хора имат и друга помощна програма, извършваща архивиране в техните бази данни, което всъщност обърква техните политики за изпращане на журнали, тъй като архивирането се прави по същество извън SQL Safe и не сме наясно с тях. Главно е само да планирате нещата напред, оттам идва и камъкът.
Ерик Кавана: Не ме изненадва. Е, хора, това беше страхотен преглед на някои от блокирането и справянето, които са необходими, за да поддържате вашето предприятие щастливо, за да поддържате клиентите си щастливи. Искам да благодаря на всички, Теп Чантра от IDERA, влязохте тук, правехте няколко демонстрации на живо, това винаги е интересно - винаги е малко рисковано да направите демонстрацията на живо, но мисля, че това мина доста добре. Знаеш ли, това са основни неща, но това е видът, в който ако не го направиш, ще имаш всякакви проблеми. Това са важните неща, които компаниите правят на някои хора.
Така че, Теп, благодаря за отделеното време. Хора, ние архивираме всички тези уеб предавания за по-късен преглед, така че обикновено можете да се върнете след час или два и да проверите архива. Но отново, страхотни неща тук, ние се опитваме да помогнем на предприятието да остане на върха на нещата, ние ценим цялото ви време и внимание, хора там. Ще те догоним следващия път. Слушахте горещи технологии. Внимавайте, хора. Чао чао.
