Techopedia Staff tarafından, Haziran 7, 2017
Paket Servisi: Sunucu Eric Kavanagh, Hot Technologies'in bu bölümünde IDERA'dan Tep Chantra ile yedekleme ve kurtarma konularını tartışıyor.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.
Eric Kavanagh: Pekala bayanlar ve baylar, Çarşamba günü saat 4: 00'de Doğu, kurumsal teknoloji alanında olanlar için bunun ne anlama geldiğini biliyorsunuz: Hot Technologies zamanı. Evet kesinlikle. Benim adım Eric Kavanagh, “Kurşun geçirmez: Bugünün İş Liderleri Nasıl Üstte Kalıyor?” Konulu bugünkü etkinliğinizin moderatörü olacağım. Dostlar, bugün burada güzel ve samimi bir görüşme yapacağız; Tep Chantra olacak ve siz de bu sohbete gerçekten ev sahipliği yapacaksınız. Felaket kurtarma, yedekleme ve geri yükleme de dahil olmak üzere bir dizi farklı şey hakkında konuşacağız, ancak bugünlerde kullanmayı sevdiğim terim veri esnekliği - Bir beyefendiden birkaç hafta önce duydum ve gerçekten çok mantıklı. Çünkü işinizin altında esnek bir bilgi altyapısına sahip olmanın ne kadar önemli olduğunu ifade ediyor.
Bu, bugünlerde bilgi ekonomisidir, yani çoğu şirket bir anlamda veya başka bir şekilde bilgi varlıklarına, verilere güvenmektedir. Demek istediğim, perakende şirketleri, hatta donanım şirketleri, gerçekten de bugünlerde her türlü organizasyon bir çeşit bilgi omurgasına sahip olacak, ya da en azından eğer modern çağdalarsa, yapacaklar. Hala bu şeylerden kaçınabilecek bazı anne ve pop dükkanları var, ama orada bile, birçoğu bulut tabanlı, açıkçası, ama birçoğu hala yerinde olan çok daha fazla bilgi sistemi yayılımı görmeye başlıyorsunuz, müşteri işlemlerini yürütmek, işlerin üstesinden gelmek, müşterilerinizin ne istediğini bilmek, envanterin ne olduğunu bilmek, ne olduğunu bilmek, büyük resmi anlayabilmek - bu günlerde gerçekten önemli şeyler.
Bu nedenle, veri esnekliği kullanmak istediğim bir terimdir; artıklık akla gelen başka bir terimdir. Ancak, ne olursa olsun, çalışanlarınızın ve kuruluşunuzun müşterilerinize hizmet etmek için gereken bilgilere sahip olduğundan emin olmak istersiniz. Tep'den içeri girip bize IDERA'nın devam ettiği bazı şeyleri açıklamadan önce, sadece bir tür argümanı çerçeveleyeceğim. Tabii ki, IDERA geçtiğimiz yıl bizimle birlikte birkaç web yayını yaptı. Bu çok ama çok ilginç bir şirket, bilgi ekonomisinde hayatta kalmak için gerektiğinde bazı pirinç meselelerine odaklanıyorlar. Bir tür dalış yapacağız.
Kurşun geçirmez altyapı - bu aslında bir anabilgisayarın eski bir resmi, şuna bakın, Wikipedia'dan 1960'ların başında olduğu gibi. O zamanlar yolunu düşünüyorsunuz, ana bilgisayar günleri ana çerçeveler için çok fazla erişim noktası değildi, bu yüzden güvenlik biraz kolaydı, yedekleme oldukça basitti, ne yapılması gerektiğini anlayabiliyordunuz, sadece girip yapmalısınız o. Tabii ki, o zaman ne yapacağını bilen çok fazla insan yoktu, ama yapanlar ne yapmanız gerektiği çok açıktı. Ve bu konuda çok fazla endişe yoktu. Ara sıra bir sorunla karşılaştınız, ama aslında bu kadar yaygın değildi.
Gün içinde, bu şeyler oldukça kolaydı - bugün, çok fazla değil. İşte resim - bu aslında Herkül'ün Hydra ile savaşması. Mitolojide büyük olmayanlarınız için Hydra, çok kafaları olduğu için çok can sıkıcı bir yaratıktı ve her birini kesdiğinizde, iki tane daha yerine geldi, bu yüzden biraz zorlanıyor hayatta bulacağınız bazı sorunların üstesinden gelmek, özellikle bu bağlamda, gerçekten kötü adamların etrafında duruyordu. Kötü bir adam çıkar, onların yerine iki tane daha mahsul çıkar. Ve bunu bilgisayar korsanlığı dünyasında görüyorsunuz, açıkçası, bu günlerde büyük bir endüstri ve bize karşı gelen büyük zorluklardan sadece biri.
Dolayısıyla, veri esnekliği stratejinizi haritalamaya çalışıyorsanız, endişelenmeniz gereken şey nedir? Endişelenecek çok şey var: felaketler, yangınlar, seller. Güney ve New Orleans'da çok zaman geçirdim elbette kasırgalar, sel ve benzeri ilginç hikayeler var. Ve çoğu zaman insan hatası oyuna giriyor, resme geliyor, söylemeliyim. New Orleans'ta Katrina'da bile durum böyleydi, çünkü evet, bir kasırga ortaya çıktı, dedikleri gibi, bir mücbir sebep . Ancak yine de kasırgaya yol açan insan hatasıydı, bu da kefalet ihlallerinin birkaçına neden oldu. Yani, üç tane vardı, aslında, endüstriyel kanalda bir tane vardı ve problem, bir geminin nehirde düzgün bir şekilde demirlenmemiş olmasıydı. Ve kasırga içeri girdi ve demirlemelerini itti ve aslında nehrin New Orleans'ın hemen dışında büküldüğü ve sadece endüstriyel kanaldan aşağı indi ve bu duvarlardan birine çarptığı iğneyi büktü. Bu yüzden, evet, bu doğal bir felaketti, yine de, bu büyük problemle sonuçlanan insan hatasıydı.
Ve aynı şey, kentin ve mühendislerin ordu birliklerinin asla kimin için ödeme yapacağına karar vermedikleri için, verginin hiç tamamlanmayan bir bölümünün olduğu diğer tarafta da meydana geldi. Peki, eğer levyinizde büyük bir boşluk varsa, bunun çok etkili bir levy olmadığını anlamak, roket bilimcisi değildir. Ve asıl mesele, insan hatası gerçekten felaketin olduğu senaryoya giriyor. Bu nedenle, yangın olsa da, bir sel olsa da, bir deprem ya da durum ne olursa olsun, birinin böyle bir olaya hazırlanmak için yapabileceği ve yapması gereken bir şey olması muhtemeldir. Ve elbette, geleneksel olarak olağanüstü durum kurtarma olarak adlandırdığımız şey budur. Yani, evet, felaketler meydana gelir, ancak insanlar bu şeyleri gerçekten görmeli ve buna göre hazırlanmalıdır. Bugün Tep ile bunun hakkında biraz konuşacağız.
Yani, hoşnutsuz çalışanlar - hoşnutsuz bir çalışanın yapabileceği zararı hafife almayın - dışarıdalar, her yerdeler. Bana olan gerçekten hoş olmayan şeylerin hikayelerini anlatan insanları tanıyorum, insanların kötü şeyler yaptıkları, kasıtlı olarak kendi organizasyonlarını sabote ediyorlar, çünkü mutsuzlar. Belki zam almadılar, kovuldular ya da ne olduğunu kim bilebilirdi. Ama bu akılda tutulması gereken bir şey ve çok önemli bir bileşen. Lisanslama durumunda da, tıpkı bir FYI gibi, millet. Duyduğum istatistiklerden biri, yazılım şirketlerinin lisans ücretlerini ödemede başarısız oldukları tüm ipuçlarının yüzde 60'ı eski çalışanlardan geldi. Yani, bu yazılımı aldığınızdan ve adil ve kare aldığınızdan emin olmak istiyorsunuz. Kurumsal sabotaj her zaman gerçekleşmez, ancak olur. Gizlilik sorunları da karışıma giriyor; neyi sakladığınıza ve nasıl sakladığınıza dikkat etmelisiniz, gerçekten bunları düşünün.
İnsanları her zaman düzenleme açısından hatırlatmaya çalışıyorum, bir plana sahip olmak ve o plan üzerinde yürütmek gerçekten önemlidir, çünkü itme kıpırdamaya geldiğinde veya bir denetçi geldiğinde veya bir düzenleyici olarak, ve ardından belirli bir şey olduğunda, örneğin bir felaket gibi, denetlenecek bir konu veya durum ne olursa olsun, bu politikaya nasıl hitap ettiğinizi açıklayın. Ne yaptığınızı bilmek istiyorsunuz ve bunun bir kaydını tutuyorsunuz - denetçiyi ve körfezi tutmak için uzun bir yol kat edecek ve bu sadece iyi şeyler.
Bilgisayar korsanları, elbette - bilgisayar korsanları ve neden böyle bir tehdit oluşturdukları hakkında birkaç dakika konuşacağım. Ve elbette fidye yazılımı, sadece gezegeni çok kısa bir sırayla kaplayan WannaCry fidye yazılımı olan WannaCry ile ilgili tüm vakayı ve görünüşe göre bazı akıllıca düşmanca insanlar NSA'dan bir grup bilgi için, kullanılan ve maruz. Yani, hatırlıyorum, eski bir masal var, Ezop Masalı, düşmanlarımıza sık sık kendi yıkımımızın araçlarını verdiğimizi söylüyor. Bu akılda tutulması gereken bir şey, çünkü yine, bu teknoloji Ulusal Güvenlik Birliği tarafından NSA tarafından kordon altına alındı - aslında ne anlama geldiğini hatırlayamıyor. Ama ortaya çıktı ve dünyaya çıktı ve sadece hasara yol açtı. Bil bakalım ne oldu? Ve birçok şirket Windows ortamlarını yükseltmemişti, bu yüzden eski biriydi, Windows XP olduğunu düşünüyorum, bu tehlikeye düştü. Bu yüzden, yine, çalışıyorsanız, yamalarınızın ve işletim sistemlerinizin sürümlerinin üstünde kalıyorsanız ve verilerinizi yedekliyorsanız ve verilerinizi geri yüklüyorsanız. Yapmanız gereken her şeyi yapıyorsanız, bunun gibi bir sorun o kadar büyük değil. Ama sadece axmen olan insanlara “Hey, tahmin et ne oldu? Umurumuzda değil, sistemi kapatıyoruz, yeniden başlatıyor, yedekleri yüklüyoruz. ”Ve yarışlara gidiyorsunuz.
Mesele şu ki, bu kötü şeyler oluyor, ancak bu konuda yapabileceğiniz şeyler var - bugün şovda konuşacağız. Bu yüzden, biraz araştırma yaptım - aslında, ilginçti, Wikipedia'ya gidip hack yapmaya bakarsanız, 1903'e kadar gidiyor. Bir adam telgraflar için bir sistemi hacklediğinde ve telgraf yoluyla kaba mesajlar gönderdiğinde, sanırım onu hackleyebileceğini kanıtlamak için. Bunun oldukça eğlenceli olduğunu düşündüm. Mesele şu ki, bilgisayar korsanları temelde kırılma ve girme konusunda iyi, yıllardır ve yıllardır yaptıkları şey bu. Modern internet dünyasının kilit seçicileri gibidirler.
Ve herhangi bir sistemin hacklenebileceğini, içeriden hacklenebileceğini, dışarıdan hacklenebileceğini hatırlamanız gerekir. Çoğu zaman, bu hack'ler meydana geldiğinde, kendilerini göstermezler veya sisteminize giren insanlar bir süre fazla bir şey yapmazlar. Bir süre beklerler; içerdiği stratejinin bir kısmı var ve kısmen operasyonlarının iş tarafı nedeniyle, çünkü genellikle bilgisayar korsanlarının yaptığı şey, programın sadece küçük bir bölümünü yapıyorlar, bu yüzden nüfuz etme konusunda iyi olan birçok adam güvenlik duvarları ve delici bilgi sistemi, bu en iyi yaptıkları şeydir ve bir sisteme girdikten sonra, arkanı dönüp birine erişimi satmaya çalışırlar. Ve bu zaman alır, bu yüzden çoğu zaman perde arkasındaki birisinin sadece saldırıya uğramış oldukları sisteme erişim satmaya çalıştığı durumdur - sisteminiz, potansiyel olarak, çok eğlenceli olmaz - ve aslında kimin kim olacağını anlamaya çalışırlar sisteme erişim için ödeme yapın.
Yani, çalınan bilgileri kullanmak için bir araya gelen ve işbirliği yapan bu tür ayrık bireyler veya kuruluşlar ağı var. İster kimlik hırsızlığı, isterse sadece veri hırsızlığı olsun, bir şirket için hayatı tatsız hale getirip getirmedikleri - bu fidye yazılımı ile durum böyle, bu adamlar sistemlerinizi ele geçiriyorlar ve para istiyorlar ve para alırlarsa, belki de belki eşyalarını geri vermezler. Tabii ki, bu gerçekten korkutucu şey, neden bu fidye ödemek istesin ki? Geri vereceklerini nereden biliyorsun? Sadece çift ya da üçlü isteyebilirler. Yani, yine, tüm bunlar bilgi stratejiniz, verileriniz için esnekliğiniz aracılığıyla gerçekten düşünmenin öneminden bahsediyor.
Biraz daha araştırma yaptım, bu eski bir 386; benim gibi yaşlıysan, bu sistemleri hatırlayabilirsin. Ve hackleme konusunda o kadar da sorunlu değildi; o zamanlar çok fazla virüs yoktu. Bu günlerde, bu farklı bir oyun, bu yüzden elbette internet geliyor ve her şeyi değiştiriyor. Şimdi her şey bağlandı, orada küresel bir izleyici var, ilk büyük virüsler saldırmaya başladı ve gerçekten de hack endüstrisi açıkçası balonlaşmaya başladı.
Yani, IoT hakkında biraz konuşacağız, zaten bir kitle üyesinden iyi bir sorum var: IoT cihazlarını güvenlik açığı açısından nasıl koruyabilirim? Bu büyük bir mesele - açıkçası, şu anda IoT cihazlarının saldırıya uğrama potansiyeli ile nasıl başa çıkacağınıza dair çok çaba sarf ediyor. Çok fazla kullanım, odaklandığınız olağan sorunlar, örneğin parola koruması, dikkatli bir şekilde kurma, kendi parolanızı ayarlama işleminden geçiyor. Çoğu zaman insanlar orada varsayılan bir şifre bırakacak ve bu da güvenlik açığına neden olacaktır. Yani, bu temel şeyler. Bu hafta başında, radyo şovumuzda, orada birkaç uzmanla güvenlik konusunda başka bir şovumuz daha vardı ve hepsi, IoT veya fidye yazılımı ya da her neyse, bilgisayar korsanlığı sorunlarının yüzde 80-90'ının veya daha fazlasının önleneceğini söyledi. sadece temelleri ele aldım, eğer üslerinizin kapalı olduğundan emin olduysanız, yapmanız gereken tüm temel şeyleri yaptınız, buradaki tüm sorunların yüzde 80'inden fazlasını hallediyorsunuz.
Yani, şeylerin interneti, tamam IoT. IoT hakkında düşünürseniz, o kadar da yeni değil. Açıkçası, 20 ve 30 yıl önce bu tür bir şey yapan üst düzey üreticiler var ve daha sonra yaklaşık 15, 20 yıl önce, RFID geldiğinde - çok büyük yardımda son derece yararlı olan radyo frekansı tanımlama etiketleri - perakendeciler gibi organizasyonlar, örneğin, nakliye şirketleri, ülke çapında, dünya çapında hareket eden herhangi bir ürün şirketi, tüm bu verilere sahip olmak son derece yararlıdır, eşyalarınızın nereye gittiğini öğrenirsiniz; bir şey kaybolursa, öğrenirsiniz.
Tabii ki, bu kusursuz bir çözüm değil, aslında, dizüstü bilgisayarım vardı, Apple'ım ile kaçtı, Atlanta havaalanından - Atlanta Hartsfield Havaalanı - birisi bilgisayarımla çantamı aldı. Artık çanta çalmadıklarını sanıyordum; her zaman çanta bulurlar - yanlış. Birisi çantayı çaldı ve yaklaşık bir ay sonra ortaya çıktı, uyandı, Apple'dan, iCloud'dan Atlanta Hartsfield Havalimanı'nın yaklaşık yedi ila on dakika güneyinde uyandığı küçük bir mesaj aldım; Birisi onun içine girmeye karar verdi. Sadece bir aydır oturmuşlardı ve oldukça sinir bozucu bir süreçten geçtim, tamam, tamam, kabaca nerede olduğunu biliyorum, bu evde, o evde, caddenin karşısındaki evde olabilir, sadece geçici olarak oradaydı. Ne yaparsın? Mesela, bu bilgi sizin için ne kadar yararlı?
Yani, bir şeyler öğrenseniz bile, bazen bu konuda çok şey yapamazsınız. Ama yine de, IoT özellikli bu dünya, şunu söylemeliyim ki, dürüst olmak gerekirse, bunun için hazır değiliz. Sanırım orada çok iyi teknolojilerin olduğu bir durum var ve bunlardan yararlanmak için çok hızlı hareket ediyor olabiliriz, çünkü tehdit çok önemlidir. Sadece tehdit manzarasının bir parçası olan cihazların sayısını düşünüyoruz, insanlar bundan bahsederken, bu yolumuza gelen devasa, devasa bir cihaz dalgası.
Son zamanlarda meydana gelen ve DNS sunucularını devre dışı bırakan bazı büyük hack'lerin, IoT cihazlarının DNS sunucularına karşı seçilmesi ve dönüştürülmesi ile ilgisi vardı, sadece klasik DDoS korsanları, dağıtılmış hizmet reddi, bu cihazların tam anlamıyla çağrılacak şekilde yeniden programlandığı bu DNS sunucusuna gelen yüzbinlerce talebin geleceği ve sadece boğulup çöktüğü ve öldüğü bir DNS sunucusunda. Sunucuların çöktüğü o kadar popüler olmayan bir web sitesinde harika hikayenin hikayesi - bu tür trafik için yapılmadı.
Yani, IoT sadece akılda tutulması gereken bir şey, yine, yedekleme ve geri yükleme ile uğraşıyorsak, bu saldırıların herhangi birinin herhangi bir zamanda gerçekleşebileceğini hatırlamak önemlidir. Ve eğer buna hazır değilseniz, o zaman çok sayıda müşteri kaybedeceksiniz, çünkü birçok insanı mutsuz yapacaksınız. Ve başa çıkmak için bu itibar yönetimine sahip olacaksınız. Bu, etrafta yüzen yeni terimlerden biri, “itibar yönetimi”. İtibarların inşanın yıllar alabileceği ve boşa çıkması dakikalar hatta saniyeler alabileceğini hatırlamak ve takdir etmek gerekir. Bilgi stratejinizi planlarken bunu aklınızda bulundurun.
Böylece, hibrit bulutun tüm konsepti var. Çocukluğumdan beri en sevdiğim eski filmlerimden biri var, bu yarı hayvan, yarı yaratık şeyleri yarattıkları Dr. Moreau Adası, bu melez bulut gibi. Böylece, şirket içi sistemler yıllarca burada olacak - bu konuda hiçbir hata yapmayın, şirket içi veri merkezlerini kapatmak uzun zaman alacak - ve küçük işletmelerde bile sistemlerinizdeki ve sürücülerinizdeki birçok müşteri verisi ve durum ne kadar karmaşık olursa, zirvede kalmak o kadar zor olacaktır. Bununla birlikte, örneğin MySQL gibi bir sistemde, bir veritabanında birleştirmek her zaman gerçek bir zorluktur.
Her şeyi tek bir sisteme sıkıştırmaya çalışmak hiç bu kadar kolay olmamıştı. Genellikle bittiğinde, sorunlar vardır, performans sorunları alırsınız. Yani, yine, uzun bir süre için bir sorun olacak. Tabii ki veri merkezlerinde ve işyerlerinde eski altyapı. WannaCry ile ilgili sorun buydu, tüm bu XP sistemlerine sahip misiniz - Microsoft artık XP'yi desteklemiyor. Bu nedenle, bu sorunlardan bazılarının parasal olarak çok şiddetli ve çok acı verici hale gelmesi ve temel bakım ve bakım ile nasıl önlenebileceği şaşırtıcı. Temel şeyler.
Yani, bir beceri boşluğu olacak; bu beceri boşlukları zamanla büyüyecek, çünkü yine bulut gelecek - bununla ilgili herhangi bir şüphe olduğunu düşünmüyorum - bulut işlerin gittiği yer; bulutta zaten bir ağırlık merkezi var. Ve göreceğiniz şey gittikçe daha fazla şirket, daha fazla organizasyon buluta bakıyor. Yani, bu şirket içi bazı beceri boşlukları bırakacaktır; henüz orada değil, ama geliyor. Ve hatta amortismanı düşünün, bu yüzden birçok büyük şirket, sadece buluta geçemezler - yapabilirlerdi, ancak maliyet açısından çok mantıklı olmazdı, çünkü tüm bu varlıkları amortismana tabi tutuyorlar belki üç, beş, yedi yıl.
Bu, şirket içinde ve bulut ortamına doğru göç edecekleri oldukça önemli bir zaman penceresi yaratır. Açıkçası, şirket içi buluttan daha az güvenli olan noktaya geldik. Komik, çünkü bu uzun zamandır büyük bir darbe oldu: Şirketler güvenlik nedeniyle buluta gitme konusunda endişeliydiler, bulutun saldırılara karşı duyarlı olmasından endişe ediyorlardı. Eh, hala, kesinlikle, ama gerçekten büyük adamlara bakarsanız: Amazon, Microsoft, şimdi bile SAP ve Google, tüm bu adamlar, bu şeylerde oldukça iyiler, bulutun güvenliğini sağlama konusunda oldukça iyi kendisi.
Ve sonra, elbette, nihayet yerinde, tarihli sistemlerde: bu uygulamalar bu günlerde dişte oldukça hızlı bir şekilde uzar. Bir keresinde bir şaka duydum, eski yazılımın tanımı üretimde olan herhangi bir yazılımdır. (Gülüyor) Bence biraz komik. Bulut sistemlerine gelince, büyük oyunculardan bahsettim, sadece gün geçtikçe büyüyorlar. AWS hala bu alana egemendir, ancak Microsoft'un kredilerine gerçekten bir şeyler bulmuş ve çok dikkatli bir şekilde odaklanmıştır. SAP, SAP HANA Cloud da, dedikleri HANA Cloud platformu - SAP ve bariz nedenlerden dolayı büyük bir odak alanı. Bulutun artık yerçekimi olduğunu biliyorlar, bulutun teknoloji için mükemmel bir savaş alanı olduğunu biliyorlar.
Gördüğünüz şey bulut mimarileri etrafındaki bu konsolidasyon. Önümüzdeki iki yıl buluttan buluta geçiş konusunda çok işiniz olacak. Bulutlardaki ana veri yönetimi bile büyük bir sorun haline gelecektir. Ve Salesforce - Salesforce'un ne kadar büyük olduğuna bakın - dikkate alınması gereken mutlak bir güçtür. Ayrıca, bulutta bulunan bir pazarlama sistemi; Şimdi 5.000 pazarlama teknolojisi şirketi gibi bir şey var - 5.000! Bu delilik. Ve çoklu bulut ortamlarını yönetebilmeniz için bu cam bölmesinde daha fazla çaba görüyorsunuz. Bu yüzden benden son bir slayt daha sonra oyunu burada nasıl önümüzde tutabileceğimize dair tavsiyeler vermek için Tep'e teslim edeceğim.
Bu, bu hafta başlarında paylaşılan sorumluluk bulutu modeli olan radyo şovumdan bahsettik. Yani, konuştukları şey AWS'nin bulutun güvenliğinden nasıl sorumlu olduğudur, bu yüzden bulutun güvenliği. Bilgi işlem depolarını, veritabanı ağlarını vb. Görebiliyordu. Ancak buluttaki veri ve güvenlikten müşteri sorumludur. Bu komikti çünkü bu “ortak sorumluluk” terimini kullanıyorlar ve şovumuzdaki konuklardan ne tür bir topladığım gerçekten paylaşılmadığı. Fikir, bu sizin sorumluluğunuzdur, çünkü itme kıpırdamaya gelirse ve birisi ortamınıza bulaşırsa, AWS muhtemelen sorumlu tutulmayacaktır, sizsiniz.
Yani, bu biraz garip bir dünya, sanırım bu biraz ikilemli bir terim, “paylaşılan sorumluluk” çünkü gerçekten de öyle değil, tüm bu şeylerin üstünde kalmak sizin sorumluluğunuzda. Yani, bununla birlikte, IoT hakkında biraz konuştuğumu biliyorum - IoT cihazlarını nasıl güvence altına alacağımızla ilgili iyi bir sorum vardı - bununla başa çıkabilmek için mutlak bir dizi teknoloji olacak. Açıkçası IoT cihazlarının bazı yazılımlarında bazı yazılımlarınız var, bu akılda tutulması gereken bir şey; bu tür şeyler için hangi kimlik doğrulama protokolünü kullanmanız gerektiği konusunda endişelenmeniz gerekir. Ama dediğim gibi, temeller, muhtemelen karşılaşacağınız sıkıntıların çoğunu çözecek, sadece şifre koruması yapıyor, şifreleri değiştiriyor ve gerçekten bunun üstünde kalıyor - bu şeyleri izliyor ve izliyor .
Örneğin, sahtekarlığı izlemek için kullanılan teknolojilerin çoğu veya ağlardaki hain faaliyetler gerçekten aykırı değerlere odaklanır ve bu makine öğreniminin aslında aykırı değerlerde, kümelenmelerde ve garip davranış kalıplarını izlemekte oldukça iyi olduğu bir şeydir. Açıkçası, DNS sunucularına bu son DDoS saldırısıyla gördüklerimiz gibi, aniden tüm bu cihazların belirli bir avuç sunucuya geri arama yapmaya başladığı, iyi görünmüyor. Ve açıkçası, bu sistemlerle insanlara her zaman hatırlattığım şey: Bu tür ortamlarda ciddi bir otomasyona sahip olduğunuzda, her zaman manuel geçersiz kılma, kill anahtarına sahip olmak - orada kapatmak için programlanmış bir çeşit kill anahtarına sahip olmak istiyorsunuz bu şeyler aşağı.
Böylece, Tep'in ilk slaydını iteceğim, bizim için bazı demolar yapacak. Ve sonra devam edip size WebEx sekmesinin anahtarlarını vereceğim. Şimdi, senin yoluna geliyor ve götür.
Tep Chantra: Pekala, teşekkürler Eric. Benim adım Tep Chantra ve IDERA'da ürün müdürüyüm. Bugün IDERA'nın kurumsal yedekleme çözümü, yani SQL Güvenli Yedekleme hakkında konuşmak istedim. SQL Güvenli Yedekleme konusunda bilginiz olanlar için, mazereti olan ürünün bazı önemli noktalarına hızlı bir göz atalım. Yani, tahmin edebileceğiniz gibi, insanlar yedekleme, SQL Server yedekleme ve ürünü geri yükleme derler, SQL Safe'in temel özelliklerinden biri hızlı yedekleme yapma yeteneğidir. Çoğu yedeklemenin yapılması ve çoğu durumda küçük bir zaman diliminde çok hızlı bir şekilde yapılması gerektiği göz önüne alındığında, bu önemli bir özelliktir.
Şimdi bazı ortamlarda, özellikle yedeklenmesi gereken birkaç büyük veritabanınız olduğunda, bu yedekleme pencerelerini karşılamak oldukça zor olabilir. SQL Safe'in yedekleme işlemlerini hızlı bir şekilde tamamlayabilmesi, son kullanıcıların bu yedekleme pencerelerini karşılayabilmesini sağlar. Büyük veritabanlarından bahsetmişken, bu büyük veritabanlarını yedekleyen, tabii ki daha büyük yedekleme dosyaları. SQL Safe'in parladığı bir başka özellik de yedekleme dosyalarını sıkıştırma yeteneğidir. Kullanılan sıkıştırma algoritması yüzde 90-95'e kadar sıkıştırma elde edebilir. Bu, yedeklemeleri daha uzun süre saklayabileceğiniz veya depolama ihtiyaçları açısından maliyet tasarrufu sağlayabileceğiniz anlamına gelir.
Yedekleme işlemlerinin kapak tarafında geri yükleme işlemleriniz vardır. DBA'ların veritabanlarını geri yüklemek için savaşmaları gereken savaşlardan biri, bu veritabanlarının mümkün olduğunca çabuk geri yüklenmesi gerektiğidir. Büyük veritabanlarında, bir yedekleme dosyasının tam olarak geri yüklenmesi birkaç saat sürebilir, bu da daha uzun kesinti süresi ve muhtemelen gelir kaybı anlamına gelir. Neyse ki SQL Safe, “Anında Geri Yükleme” adı verilen ve temelde geri yüklemeye başladığınız zaman ile veritabanına son kullanıcılar veya hatta uygulamalar tarafından erişilebilecek zamanları azaltan bu özelliğe sahiptir.
Bir müşteriyle bir kez konuştuğumu hatırlıyorum, burada belirli bir veritabanının geri yüklenmesinin 14 saat sürdüğünü bildirdi. Ancak anında geri yükleme özelliğiyle, bu veritabanına bir saat veya daha kısa sürede erişebildi. İlke tabanlı yönetim, SQL Safe'in bir başka özelliği de politika oluşturma ve yedekleme politikalarınızı bu politikalar aracılığıyla yönetme yeteneğidir. Bir ilke yapılandırdığınızda, temel olarak hangi örneklerin yedekleneceğini veya bu örneklerin hangi veritabanlarının yedekleneceğini, ne tür yedekleme işlemlerinin gerçekleştirileceğini ve hatta bu yedeklemelerin gerçekleştirileceği zamanlamayı tanımlarsınız.
Ayrıca, uyarı bildirimlerini de yapılandırabilirsiniz. Bu şekilde yedekleme başarıyla tamamlandı, yedeklemeler başarısız oldu, belki bunu görebiliyordu, ancak bu işlemle ilgili bazı uyarılar var. Ayrıca, bir yedekleme planlandığı gibi yürütülmediyse size bildirilir. Bu önemli bir bildirimdir, çünkü o zaman sahip olabilirsiniz, yedeklemenin olmadığı bir zaman penceresini riske atarsınız. Ve böyle bir bildirim almak size oraya gidip o yedeklemeyi çalıştırmanız ve muhtemelen bu yedeklemenin neden planlandığı gibi çalışmadığı konusunda biraz araştırma yapmanız gerektiğini gösterecektir.
Diğer şeylerden bazılarına bakalım, hataya dayanıklı yansıtma, bu aslında birden fazla konumda yinelenen yedekleme dosyaları oluşturma yeteneğine sahip olduğumuz anlamına gelir. Örneğin, birincil depolama biriminizde bir hedef hedefiniz olduğunu varsayalım - ana depolamanızın ne olduğu, tüm yedek dosyalarınızın nereye gittiği. Ancak, bazı ek testler yapmanız gerektiğinde, durum ne olursa olsun, veritabanının geri yüklenebildiğinden emin olmak için aynı yedekleme dosyasının bir kopyasına sahip olmanız gerekebilir. SQL Sanal Veritabanı Optimize Etme - esas olarak, SQL Sanal Veritabanı adı verilen SQL Safe'e yakın zamanda entegre edilmiş başka bir ürünümüz olması.
Bahsettiğim gibi, yakın zamanda entegre olan, aslında SQL Güvenli'nin içine dahil edilmiş olmasıdır. Şimdi, SQL Sanal Veritabanı'nın temel olarak yapmanıza izin verdiği şey, aslında bir sanal veritabanı oluşturmaktır. (Gülüşmeler) Tanımla aynı terimleri kullanmaktan nefret ediyorum, ama esasen bir veritabanı bağlayacağımız ve yedekleme dosyasını temel alacağımız. Yani, esasen, SQL Server'ın gerçekte dosya sisteminde gerçek veritabanını oluşturmak yerine, aslında yedekleme dosyasından veri okurken, veritabanının gerçekten çalışır durumda olduğunu düşünmesidir.
Bu gerçekten yararlıdır, çünkü aslında ek disk alanı kullanmadan yedekleme dosyasındaki verilere erişmenizi sağlar, bu nedenle özellikle kullanmanız gereken büyük veritabanlarıyla uğraşırken, hızlı bir şekilde baktığınızda çok kullanışlı olur, veya üzerinde biraz geliştirme yapın. Sıfır etkili şifreleme - temelde bu, bu veritabanlarının yedeklerini gerçekleştirdiğimizde, yedekleme dosyalarını gerçekten şifreleyebileceğimiz ve bu yedekleme dosyalarını şifrelediğimizde, gerçek sistemin performansı. Yani, tamamen ihmal edilebilir. Günlük gönderim yapabileceğimiz başka bir şeydir, daha önce de belirttiğim gibi, politikalarımız ve avantajlı lisanslama ile ilgili olarak - esasen bunun anlamı, lisanslama modellerimizin lisanslama modellerini bir örnekten başka bir örneğe taşımanıza izin vermesidir. farenin birkaç basit tıklaması.
Devam edelim, ürünün mimarisine hızlı bir göz atalım. Yani, ürünün temel olarak dört ana bileşeni var. Soldan başlayarak SQL Güvenli Yönetim Konsolu ve Web Konsolu var. Bunların her ikisi de esasen kullanıcı arayüzleridir, biri masaüstü istemcisi diğeri ise bir web uygulamasıdır. Bu kullanıcı arabirimlerinin her ikisi de, verileri SQL Güvenli Depo Veritabanı olan bir sonraki bileşenden alır. Depo veritabanı temel olarak tüm işletim geçmişinizi, tüm yedekleme ve geri yükleme işlemlerini depolar. Bu ayrıntılar burada saklanır. Depodaki tüm bu veriler, bir sonraki bileşen olan SQL Güvenli Yönetim Hizmeti tarafından yönetilir. Yönetim Hizmeti, veri tabanı veritabanını güncellemekten ve uyarı bildirimi göndermekten sorumludur. Yedekleme ve geri yükleme işlemleriyle ilgili veriler, en sağdaki son bileşen olan SQL Güvenli Yedekleme Aracısı'ndan geliyor.
SQL Güvenli Yedekleme Aracısı, SQL Safe ile yönetmeye çalıştığınız SQL Server örneklerini barındıran tüm sunuculara yüklenen bir bileşendir. Ve bu, yedeklemeleri gerçekleştirmek ve sıkıştırmaktan gerçekten sorumlu olan hizmettir. Şimdi, bu slaytta, tamamen gerekli olmayan beşinci bir bileşen de var, ancak bu güzel bir şey. Ve bu bizim SQL Server Reporting Services RDL dosyalarımız. Bunun temel olarak yapmanıza izin verdiği şey, depo veritabanımızla ilgili raporlar çalıştırabilmeniz için bazı RDL dosyalarını SQL Server Raporlama Hizmeti'ne dağıtmaktır. Ayrıca yedeklemenizin son çalıştırılması, yedekleme işlemleriyle ilgili ayrıntılar, neyiniz olduğu gibi bir dizi farklı raporumuz var.
Ve özür dilerim. Hadi devam edelim ve SQL Safe'e bir göz atalım. Bana bir saniye ver. Ve oturum açmak için bir saniye verin. Gördüğünüz gibi, şu anda yükledim web uygulaması, ama önce masaüstü uygulamasına bir göz atmak istiyorum. Öyleyse, bunu çabucak kovayım. Ve bu SQL Safe masaüstü uygulamasıdır, ilk yüklendiğinde sizi bugün SQL Safe görünümüne götürür. Bu temelde, bugüne kadar olan tüm yedekleme işlemlerini veya geri yükleme işlemlerini listeler. Ayrıca, çevrenizin hızlı bir durumunu verir, burada da görebileceğiniz gibi, politikalarımın tek bir politikası olduğunu, bu da iyi durumda olduğunu, bu iyi olduğunu söylüyor, çünkü sadece bir politikam var ve bunu umuyorum değil . Ayrıca, başarılı olan işlemlerin, başarısız olabilecek işlemlerin bir özetini de verir. Genel olarak, iyi durumdayım: Sadece hızlıca bakarak tüm yeşillikleri görebilirsiniz; gitmeye hazırız.
Burada sol tarafta SQL Safe'e kaydettiğiniz tüm sunucuları ve temel olarak yönettiğiniz sunucuları görebilirsiniz. Genişletirseniz, bu sistemdeki veritabanlarının listesini görürsünüz. Belirli bir veritabanını seçerseniz, söz konusu veritabanının çalışma geçmişini görebilirsiniz. Açıklamak için çok fazla şey yok, bunun dışında bu pencereden de geçici yedeklemeler yapabilirsiniz ve bu gerçekten hızlı ve basittir. Ve bunu size hızlıca göstereyim. Sadece sağ tıklayın ve yapmak istediğiniz işlemi seçin. Ve bu amaçla, devam edip yedekleme veritabanını seçeceğim. Ve SQL Güvenli Yedekleme Sihirbazı açılır. Buradan, yedeği gerçekleştirmek istediğiniz örnek gibi bunu elde edersiniz ve yedeklemek istediğiniz veritabanlarını seçin. Bu durumda, HINATA makinesini ve bu Contoso Retail veritabanını önceden seçtim, çünkü seçeneği seçtiğimde vurguladığım şey buydu. Şimdilik gideceğim ve şimdilik bırakacağım, ancak aslında daha fazla veritabanı seçme seçeneğiniz var, böylece tüm kullanıcı veritabanınızı yedeklemek isterseniz, bu radyo düğmesini seçebilir ve tüm şunlar. Devam edeyim ve devam edeyim.
Sihirbazın sonraki sayfasına gidin. Bu, gerçekleştirmek istediğim yedekleme türünü seçebileceğim ve burada birkaç farklı seçeneğiniz var. Bu, tüm yedekleme yardımcı programlarında bulunduğundan eminim, örneğin, tam bir yedekleme, farklı bir yedekleme, işlem günlüğü yedeklemesi gerçekleştirebilir veya aslında sadece veritabanı dosyasını yedekleyebilirsiniz. Ayrıca, temel olarak LSM'lerle uğraşmak istemediğinizde kullanılan, salt kopya bir yedekleme oluşturma seçenekleriniz de vardır. Şimdilik “hayır” ı seçeceğim. Ayrıca, yedekleme tamamlandıktan sonra yedeklemeyi doğrulama seçeneğiniz de vardır - bu şekilde yedeklemenizin iyi olduğundan ve daha sonra kullanılabileceğinden emin olabilirsiniz. Yedeklemenin kullanılabilir olduğuna dair size biraz güvence vermek için, sahip olduğunuzdan emin olmak istediğiniz her zaman bu özelliklerden biridir.
Burada adı ve veri açıklamasını bulabilirsiniz. Bu aslında yedeklemenin ne için kullanıldığını kolayca tanımlamanıza yardımcı olabilecek meta verilerdir, bu yüzden burada demo amacını söyleyeceğim. Ve demo için veritabanınızın yedeğini kullanın. Sonra, burada yedekleme dosyamızı nereye kaydetmek istediğimizi tanımlarız ve burada birkaç farklı seçeneğiniz vardır: Tek bir dosyaya kaydedebilirsiniz, şerit dosyaları oluşturabilirsiniz, burada hedef hedefi seçme olanağınız var, biz ayrıca veri etki alanını destekler. Ve bu, Amazon ST bulutu, bilgilerinizi kaydetmek istediğiniz yer.
Bu gösteri için tek bir dosya ile devam edeceğim, bu ağ esnekliğini etkinleştirin, bu, bir ağ konumuna yedekleme yapıyorsanız, burada yaptığım şey olduğu için SQL Safe'te gerçekten güzel bir özelliktir. birincil arşivden görebilirsiniz - ağ konumuna yedekleme yapıyorsanız, bazı ağ hıçkırıklarıyla karşılaşma olasılığınız vardır. Bazı durumlarda ağ hıçkırıklarınız geri sayılırsa, yedekleme işlemi tamamen satılır. Ağ esnekliği seçeneğini etkinleştirin, temelde yaptığı şey, bir ağ hıçkırmasıyla karşılaşıldığında, SQL Safe'in temelde yaptığı şey, yedeklemeyi duraklatması ve belirli bir süre beklemesi ve ağ konumunu tekrar denemesidir. Bağlanabiliyorsa, yedeklemeyi kaldığı yerden devam ettirir. Bu şekilde, bu yedeklemeyi çalıştırmak için her seferinde saatlerce harcamazsınız ve bitirmeye yaklaştığında bir ağ hıçkırığıyla karşılaşırsınız - işlemi hemen satmıyoruz, biraz bekleyip deneyeceğiz tekrar tamamlamak için.
Bunu yapılandırırken başka seçenekler de var. Şimdi, temel olarak tekrar denediğimiz aralığı içeriyor, bu nedenle, bir ağ hıçkırığıyla karşılaşırsak, on saniye içinde ağ konumuna tekrar erişmeye çalışacaktır. Buradaki ikinci seçenek, temel olarak, ağ hıçkırıklarıyla karşılaşırsak, burada 300 saniye diyor - yani, beş dakika, toplam - o zaman yedekleme işlemini tamamen satacağız. Ve bu sırayla beş dakika, yani tekrar tekrar denerseniz ve bu beş dakika içinde hala ağ bağlantısını yeniden kuramazsak, işlemi tamamen satarız. Bu son işlem temel olarak tüm yedekleme süresi içindir, bu yüzden burada on saniye kaybederseniz, bağlantıyı yeniden kurun ve bağlantıyı tekrar kaybedin, eğer bu temelde 60 dakika boyunca tekrarlanırsa, o işlem satılacaktır. Ve bunlar, gördüğünüz gibi yapılandırılmıştır, böylece ortamınıza uyarlayabilirsiniz.
Buradaki ayna arşivi seçeneği, daha önce bahsettiğim, hataya dayanıklı aynalama. İstediğiniz takdirde, başka bir yedekleme konumu belirtebileceğiniz yer burasıdır. Bunu şimdi işaretlenmeden bırakacağım, çünkü devam edip ilerlemek istiyorum. Bu seçenekler pencerelerinde, bu yedekleme işlemi için kullanmak istediğimiz sıkıştırma türünüz ve yedekleme dosyası için şifrelemeyi etkinleştirmek isteyip istemediğimiz gibi şeyler tanımlayabilirsiniz. Sıkıştırma yapmak istemediğinizi seçerseniz, sıkıştırma dahil olmak üzere bir dizi farklı seçenek sunuyoruz. Yani, bu seçenekleri hızla gözden geçirmek.
Yüksek hız temel olarak yedeklemeyi bir miktar sıkıştırma dahil ederken mümkün olduğunca hızlı tamamlamaya çalışır. ISize olabildiğince fazla sıkıştırmaya daha fazla odaklanmış ancak bunu çok fazla sıkıştırmaya çalıştığımız için biraz daha uzun sürebilir ve muhtemelen biraz daha fazla CPU kullanabilir. Seviye 1 esas olarak, ekleyebileceğimiz en fazla sıkıştırma olan Seviye 4'e kadar en az miktarda sıkıştırma anlamına gelir. Yani, bu biraz daha ayrıntılı, tipik olarak iSpeed - kelime nedir? Seviye 1 ve Seviye 2 sıkıştırma arasında değişir; ne kadar CPU ve kullanılabilir kaynak olduğunu görmek için sisteminize bakar ve çok fazla sıkıştırma konusunda karar verir, Seviye 1 ve Seviye 2 arasında kullanılmalıdır.
ISize, Seviye 3 ve Seviye 4 hariç, aynı şeyi yapıyor. Burada, kullanmamız gereken CPU'da kaç tane var olduğu gibi, bazı gelişmiş seçenekler de var, işte SQL'in Sanal Veritabanı ve ayrıca anında geri yükleme özelliği. Veritabanı girişlerini ve bazı kullanıcıların çok değerli bulduğu diğer bazı seçenekleri ekleyebilirsiniz, bu nedenle bundan kontroller oluşturmak gibi, böylece yedek dosyaların iyi olduğundan emin olmak için daha sonra kontrol edebilirler. Bir sonraki sayfaya geçersek, bildirimlerinizi burada ayarlayabilirsiniz. Burada sahip olduğumuz çeşitli seçenekleri görebilirsiniz: yedeklemenin başarısız olup olmadığını bildir, yedeklemenin atlanıp atlanmadığını, ne olursa olsun bildir. Yedekleme iptal edilirse veya yedekleme uyarı ile tamamlanırsa ve isterseniz, yedeklemenizin temiz olduğu size bildirilebilir. Çok sayıda veritabanının bulunduğu ortamlar için, etkinleştirmek isteyebileceğiniz bir şey olmayabilir, çünkü yedeklemenizin başarılı olması muhtemeldir ve e-postalarla dolup taşarsınız.
Sonraki sayfada, bu yedekleme işlemine neden olduğundan, tanımladığınız şeyin bir özetini görüntüleyebilirsiniz. Ve eğer isterseniz, her şey iyi görünüyorsa, devam edip yedeklemeyi tıklayabilirsiniz, biz başlıyoruz. Yedeklemeyi tıklamadan önce, devam edip size bu “komut dosyasını oluştur” düğmesini göstereyim. SQL Safe'in bir yedekleme veya geri yükleme işlemini gerçekten başlatabileceğiniz bir komut satırı arabirimi sunduğu için, komut satırı aracılığıyla DOS komut istemi size ne olur. Burada komut dosyası oluştur'u tıklatırsanız, yedeklemeyi komut satırından çıkarmak istiyorsanız, temel olarak kullanabileceğiniz gerçek komut dosyasını sağlar.
Diğer düzgün şey, genişletilmiş mağaza prosedürleri de sunmamızdır ve bu durumda, genişletilmiş mağaza prosedürleri kullanarak bu aynı yedekleme işlemini yürütecek bir komut dosyası oluşturuyoruz - paylaşmak istediğim küçük bir hızlı tidbit. Hadi gidip bu yedeklemeyi başlatalım. Ve yedeklemenin zaten başladığını görebilirsiniz. Ve bu veritabanı biraz büyük, bu yüzden biraz zaman alabilir. Burada birkaç kez koştuğumu görebiliyorsunuz, bu yüzden beni bir dakikadan üç dakikaya kadar her yere götürecek. Bu bir Seviye 4, bu yüzden bu iki kez arasında olacağını tahmin ediyorum.
Bu işlem devam ederken, politikalara hızlıca bir göz atalım. Daha önce de belirttiğim gibi, politikalar kuruluşunuz genelinde zamanlanmış yedekleme işlemlerini yapılandırmanıza izin verir, bu yüzden burada önceden yapılandırılmış ve yeni bir tane oluşturmak yerine bir politikam var, devam edelim ve bunun ayrıntılarına bir göz atalım. Özür dilerim, VM'm kişisel dizüstü bilgisayarımda çalışıyor ve fan oldukça zor çalışıyor gibi görünüyor. (Gülüyor)
Eric Kavanagh: Bu iyi - bilirsiniz, biz bunu burada izlerken size bir soru soracaktım. IDERA yedeklemeler açısından çok fazla veri yakalama kullanıyor mu yoksa her seferinde tam yedekleme mi yapıyorsunuz? Bu nasıl çalışıyor, biliyor musunuz?
Tep Chantra: Bir kez daha söyle, üzgünüm?
Eric Kavanagh: Evet, IDERA'nın CDC kullanıp kullanmadığını, daha küçük yedeklemeler yapmak için veri yakalama teknolojisini değiştirip değiştirmediğini biliyor musunuz yoksa her seferinde tam yedekleme yapıyor mu?
Tep Chantra: İnanmıyorum. Bunu daha önce bir çok bilette gördüğümü hatırlıyorum. Ve doğru hatırlıyorsam, hayır, CDC'den yararlanmıyoruz, dürüst olmak gerekirse, esas olarak SQL Server'ın yedeklemeyi yapmasına izin veriyoruz, sadece aradaki verileri alıyor ve sıkıştırıyoruz, sonuç olarak bir yedekleme dosyası oluşturuluyor. Yani, aslında bunu kullanmak. Evet.
Şimdi politikam yüklendiğine göre - oh, üzgünüm, başka bir sorunuz mu var?
Eric Kavanagh: Hayır, hepsi bu. Devam et.
Tep Chantra: Tamam, şimdi politikam yüklendi, burada bazı hızlı şeyler görebilirsiniz: ad, açıklama, yönetilecek bir politika olsun, ne tür bir politika oluşturacağınızı ayarlayabilirsiniz, zamanlama SQL Server Agent tarafından yönetilecek veya zamanlama SQL Server Yedekleme Agent tarafından yönetilecektir. Çoğu durumda SQL Server Agent'ı kullanmak isteyeceksiniz, çünkü bu genellikle sisteminizde zaten çalışan bir şeydir, bu nedenle sizin için mevcut olanlardan da yararlanabilirsiniz. Üyelik sekmesinde, yedekleme veritabanlarında yedeklemek istediğiniz örnekleri belirtirsiniz. Ve bu durumda, tüm kayıtlı örneklerimi eklediğimi ve yedeklenmesi gereken belirli bir veritabanı belirlediğimi görebilirsiniz. Şimdi isteseydim, devam edip bunları düzenleyebilir ve “Tüm veritabanlarını, yalnızca kullanıcı veritabanlarını, hatta sistem veritabanlarını yedeklemek istiyorum.” Diyebilirim. Bunun güzel yanı, joker karakterler de kullanabilir ve bazı veritabanları.
Bu değişikliği burada yapmayacağım, çünkü ayarlarımda büyük değişiklikler yapmak istemiyorum. Şimdi seçeneklere geri dönelim. Ve seçeneklerde, ne tür yedeklemeler yapacağınızı tanımladığınız yerdir ve buraya bir göz atarsanız, tam yedeklemeler, diferansiyel yedeklemeler ve büyük yedeklemeler yapılandırılır. Ve bu yedeklemelerin her biri için, belirli bir miktarda sıkıştırma kullanmak mı yoksa şifrelemeyi açmak mı istediğimi tanımlayabilirim. Tıpkı geçici sihirbazda bulacağınız seçenekler gibi. Ve konumlarda, bu yedekleme işlemlerinin hedefini de tanımlayabilirsiniz. Politikalarla ilgili iyi şeylerden biri, devam etmek ve bu eski yedekleme dosyalarını, X gün veya hafta sayısına göre neleriniz olduğunu temel alarak silmek isteyip istemediğinizi de tanımlayabilmenizdir.
Bu da her bir yedekleme türü için yapılandırılabilir. Burada, bir hafta sonra silmek için tam yedeklemelerim var. Diferansiyelim iki gün sonra silinir ve yedeklerimin bir gün sonra silinmesini istiyorum. Bu gerçekten güzel, çünkü senaryoya, eski yedek dosyalara, yalnızca gerçekten ihtiyacınız olanları zamana bağlı olarak işlemeyi otomatikleştiriyor. Sonraki sayfayı zamanlamayı tanımlarsınız ve yine zamanlama, tamamlayacağınız her bir yedekleme işlemi türü için özel olabilir, bu yüzden dolum için haftalık olarak çalıştırıyorum, diferansiyelim altı saatte bir çalıştırıyorum, günlüklerim her 30 dakikada bir çalışıyorum. Bir sonraki sayfada, bildirimleri ayarladığınız yer ve aslında ad hoc backup'da bulduğunuz bildirimlerle aynıdır, tek fark, yedeklemenin başlayamadığını söyleyebileceği bu yeni, diğer seçeneğe sahip olmanızdır. planlandığı gibi. Bu, yedeklemelerinizin çalışmadığı durumlar hakkında uyarı alabileceğiniz yerdir. Özellikle, ihtiyaç duyduğunuz zamanlarda yedeklerinizin bulunduğundan emin olmak için belirli SLA'larınızın olduğu durumlarda gerçekten önemlidir. Ve bir sonraki sayfayı özet olarak görüntüleyebilirsiniz. Herhangi bir değişiklik yapmış olsaydım, bitirmeyi tıklarsam dışarı çıkar ve bu değişiklikleri yapar, kaydeder ve örneğin SQL Server Agent işlerinin deposuna kaydederdi.
Ve size hızlı bir şekilde gerçek hızlı bir şekilde göstermek için, işte o politika için oluşturduğum bir politika ve iş. Bunun üç farklı iş yarattığını görebilirsiniz: her yedekleme türü için bir tane. Şimdi, gerçekten hızlı, HUD arayüzüne hızlıca bir göz atalım ve daha önce de belirttiğim gibi, SQL veritabanına entegre ettiğimiz bir sanal veritabanı. Şimdi, daha önce de belirttiğim gibi, temelde SQL Server'ı, gerçekte sadece yedekleme dosyasını okurken gerçek bir veritabanının geri yüklendiğine inanarak kandırır. Öyleyse devam edeyim ve sizin için hızlı bir iş değil. Bir yedek dosya alalım. Letţte, bir tane almama izin verin. İşlem tamamlandı ve gerçek hızlı, veritabanlarımı burada yenileyirsem, veritabanının erişilebilir olduğunu ve SQL Server'ın canlı olduğunu düşündüğünü görebilirsiniz, ancak gerçekte, verileri sadece veritabanından okuyoruz.
Bu sürümde yeni olan diğer bazı özellikler, en son yedekleme biçimini kullanarak yedekleme yapma yeteneğidir. İlke tabanlı yönetimimizi kullanması gereken müşteriler için gerçekten kullanışlıdır, ancak SQL Server dosya biçimini herhangi bir nedenle tutmak isterler. Şimdi, zamanımızın tükendiğini biliyorum, bu yüzden devam edip bu sunumu durdurmak istiyorum, sadece bazı soruları alabilir miyiz?
Eric Kavanagh: Evet, kesinlikle. Yani, anahtarlardan birinin gerçekten politika yönetiminde olduğunu düşünüyorum, değil mi? Optimal politika hakkında düşünürken olduğu gibi ve bunu neye dayandırıyorsunuz? Açıkçası bazı durumlarda endişelenmeniz gereken düzenlemeler vardır, ancak bir işte belki de yüksek düzeyde düzenlenmiş değildir; Yedeklemelerinizi yapmak için en uygun zamanları bulmanız yeterlidir ve daha sonra, hesaplama gücü ve bunun ne kadar sürdüğü ve ne kadar pahalı olduğu hakkında bazı raporlar aldığınızı tahmin ediyorum. Optimal politikayı tanımlamak için neler yapılır?
Tep Chantra: Bu gerçekten duruma göre, bu yedeklemelerin ne zaman çalışması gerektiği konusunda her ortamın farklı bir politikası olacak. Ayrıca, çalışan yedekleme türlerini, çalıştıkları programı da gerektirebilir ve sanırım gerçekten de onların kurtarma ihtiyaçlarına bağlı olduğunu belirler, cevap budur.
Eric Kavanagh: Tamam, evet. Ve siz de farklı türlerde yedekleme ve şeritler yapabilmenizden bahsettiniz. Bu, sıcak ve soğuk veriler için mi, yoksa başka bir yöntemin aksine, şeritlerin arkasındaki mantık nedir?
Tep Chantra: Yani, bunun için verebileceğim en iyi cevabın, çizgili dosyaların, aslında yaptığımız şey, yedek içeriği bir dizi farklı dosyaya yazmak olmasıdır. Çizgili dosyaları kullanma fikrinin muhtemelen yedekleme dosyalarınızı daha hızlı yazabileceğinize inanıyorum. Örneğin, her farklı dosyanın farklı bir konuma gitmesini sağlayabilirsiniz. Yedek dosyalarınızı farklı konumlara dağıttığınız için bu, sunucu güvenlik araçlarına da mal olur.
Eric Kavanagh: Ve geri yükleme yetenekleri açısından harika, yeni şeyler var, değil mi? Çünkü diyelim ki doğal bir felaket ya da fidye yazılımı olsun, durum ne olursa olsun. Geri yüklemek için sadece bir seçeneğiniz olması gerekmez, değil mi? Nelerin geri yüklendiği ve ne tür verilerle ilgili öncelikler belirleyebilir misiniz? Oradaki seçenekler hakkında konuşabilir misiniz?
Tep Chantra: Peki, geri yükleme açısından, daha önce kullanıcılara verilere daha hızlı ulaşan anlık geri yükleme gerçekleştirebileceğimizi belirtmiştim, değil mi? Ve sadece göstermek için, daha önce bir tane yaptım, böylece burada görebilirsiniz, yine, bu veritabanı çok büyük değil, bu dizüstü bilgisayarımda çalışan. Bu yüzden, belki de iki konser büyüklüğünde olduğunu düşünüyorum, ancak bu veritabanı 37 saniye içinde tamamlandı. Gerçek geri yükleme. Bu yüzden, verilerime erişebilmem 37 saniye sürdü, bu yüzden anında geri yükleme ile veritabanıma iki saniye içinde erişebildim. Yani, veritabanınız çok daha büyük olsaydı nasıl görüneceğini hayal edebilirsiniz.
Eric Kavanagh: Evet, iyi bir nokta. Ve elbette, şovdan önce bunun hakkında konuşuyorduk; ön cephelerde insanlara destek vermek için çok zaman harcadınız ve daha sonra ürün yönetimi alanına geçtiniz, bu yüzden biraz farklı bir meydan okuma. Ama ön cephedeydiniz - bence insanların nerede yanlış gittiğini ve bazı problemlerin ne olduğunu öğrenmek için oldukça iyi bir yer. İnsanların bu tür şeyleri daha iyi düşünürlerse kaçabilecekleri daha yaygın tuzaklardan bazıları olarak ne görüyorsunuz?
Tep Chantra: Bazı yaygın tuzaklar sadece - daha önce de belirttiğin gibi - yedeklerinizi planlamak. İnsanların, politikalarımız, politikalarımız, çok fazla yedekleme yaptığınız ve LSM'yi temel alarak uyguladığımız politikalardan yararlanmaya çalıştıklarını gördüğüm zamanlar oldu. Bazı durumlarda, bazı kişilerin veritabanlarında yedekleme gerçekleştiren başka bir yardımcı program olduğunu gördüm, bu da aslında günlük sevkiyat politikalarını bozar, çünkü yedeklemeler esas olarak SQL Safe dışında yapılır ve biz bunların farkında değiliz. Esasen sadece ilerideki şeyleri planlamak, tuzakların geldiği yer burası.
Eric Kavanagh: Beni şaşırtmıyor. Millet, bu, işletmenizi mutlu etmek, müşterilerinizi mutlu etmek için gerekli olan bazı engelleme ve mücadele çalışmalarının harika bir incelemesi oldu. Herkese çok teşekkür etmek istiyorum, IDERA'dan Tep Chantra, buraya adım atmak, canlı demolar yapmak, bu her zaman ilginç - canlı demo yapmak her zaman biraz riskli, ama bence bu iyi gitti. Biliyorsunuz, bu temel şeyler, ama bunu yapmazsanız, her türlü probleminiz olacak. Bu, şirketlerin bazı insanların yaptığı önemli şeyler.
Tep, zaman ayırdığın için teşekkürler. Millet, tüm bu web yayınlarını daha sonra izlemek üzere arşivliyoruz, bu yüzden genellikle bir veya iki saat içinde geri dönüp arşivi kontrol edebilirsiniz. Ama bir kez daha, burada harika şeyler, kuruluşun şeylerin üstünde kalmasına yardımcı olmaya çalışıyoruz, tüm zaman ve dikkatinizi takdir ediyoruz, orada millet. Bir dahaki sefere seni yakalayacağız. Hot Technologies'i dinliyorsunuz. Kendine iyi bak millet. Güle güle.
