Door Techopedia Staff, 7 juni 2017
Takeaway: Host Eric Kavanagh bespreekt back-up en herstel met TER Chantra van IDERA in deze aflevering van Hot Technologies.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: OK, dames en heren, het is woensdag om 4:00 Eastern, voor degenen op het gebied van enterprise-technologie, u weet wat dat betekent: het is tijd voor Hot Technologies. Ja inderdaad. Mijn naam is Eric Kavanagh, ik zal je moderator zijn voor het evenement van vandaag getiteld "Bulletproof: hoe de zakelijke leiders van vandaag de top blijven". En mensen, we hebben hier vandaag een leuk, intiem gesprek; het wordt Tep Chantra en de jouwe die dit gesprek echt organiseert. We gaan het hebben over een aantal verschillende dingen, waaronder noodherstel, back-up en herstel, maar eigenlijk is de term die ik tegenwoordig graag gebruik, data-resiliency - ik hoorde dat van een heer slechts een paar weken geleden, en het is echt heel logisch. Omdat het spreekt over hoe belangrijk het is om een veerkrachtige informatie-infrastructuur onder uw bedrijf te hebben.
Dit is tegenwoordig de informatie-economie, wat betekent dat de meeste bedrijven op de een of andere manier afhankelijk zijn van informatie-activa, van gegevens. Ik bedoel, zelfs retailbedrijven, zelfs hardwarebedrijven, echt elke vorm van organisatie zal tegenwoordig een soort van informatie-ruggengraat hebben, of tenminste, als ze in de moderne tijd zijn, als je wilt. Er zijn een aantal moeder- en popwinkels die dat soort dingen nog steeds kunnen vermijden, maar zelfs daar zie je veel meer proliferatie van informatiesystemen, veelal eerlijk gezegd cloud-based, maar veel daarvan nog steeds op locatie, om klanttransacties af te handelen, op de hoogte te blijven, om te weten wat uw klanten willen, om te weten wat de inventaris is, om te weten wat het was, om het grote geheel te begrijpen - het is tegenwoordig heel belangrijk.
Dus, gegevensbestendigheid is een term die ik graag gebruik; redundantie is een andere term die te binnen schiet. Maar u wilt ervoor zorgen dat wat er ook gebeurt, uw werknemers en uw organisatie over de informatie zullen beschikken die zij nodig heeft om uw klanten te bedienen. Dus, ik ga er doorheen, gewoon een soort van framing van het argument, voordat Tep ingrijpt en ons enkele dingen uitlegt die IDERA heeft. Natuurlijk heeft IDERA het afgelopen jaar nogal wat webcasts met ons gedaan. Het is een heel, heel interessant bedrijf, ze zijn gericht op een aantal kopspijkers, blokkeren en aanpakken, indien nodig, om te overleven in de informatie-economie. We duiken er een beetje in.
Kogelvrije infrastructuur - dat is eigenlijk een oude foto van een mainframe, kijk daarnaar, het is zoals begin jaren zestig van Wikipedia. Je denkt over vroeger, mainframedagen waren niet veel toegangspunten voor de mainframes, dus de beveiliging was een beetje eenvoudig, back-up was vrij eenvoudig, je kon begrijpen wat er moest gebeuren, je moest gewoon naar binnen gaan en doen het. Natuurlijk waren er niet zoveel mensen die wisten wat te doen, maar degenen die het wisten, het was vrij duidelijk wat je moest doen. En daar was niet zoveel bezorgdheid over. Je had wel eens een probleem, maar het was niet echt zo gebruikelijk.
Vroeger was dit spul vrij eenvoudig - vandaag, niet zo veel. Dus hier is de foto - dat is eigenlijk Hercules die tegen de Hydra vecht daar. Voor degenen onder u die niet zo groot zijn in mythologie, de Hydra was een erg irritant wezen omdat het meerdere hoofden had, en elke keer dat je er een afhakte, kwamen er twee op zijn plaats, dus het spreekt een beetje aan de uitdaging van het omgaan met enkele van de problemen die je in het leven tegenkomt, specifiek in die context, was echt gericht op slechteriken. Je haalt een slechterik tevoorschijn, er verschijnen er nog twee in hun plaats. En je ziet dit soort van in de hackwereld, eerlijk gezegd, het is tegenwoordig een grote industrie en het is gewoon een van de grote uitdagingen waar we voor staan.
Dus als u probeert uw strategie voor gegevensbestendigheid in kaart te brengen, waarover moet u zich dan zorgen maken? Nou, er zijn veel dingen om je zorgen over te maken: rampen, branden, overstromingen. Ik heb veel tijd doorgebracht in het zuiden en New Orleans heeft natuurlijk een aantal interessante verhalen over orkanen en overstromingen, enzovoort. En vaak komt menselijke fout in het spel, in beeld, zou ik moeten zeggen. En dat was zelfs het geval in Katrina in New Orleans, want ja, er kwam een orkaan door, dat is een daad van God, zoals ze zeggen, een overmacht . Maar toch was het menselijke fout in de aanloop naar de orkaan die resulteerde in verschillende van de inbreuken op de heffingen. Dus er waren er drie, in feite was er een op het industriële kanaal, en het probleem dat er een schip was, was niet goed afgemeerd, rivierafwaarts. En de orkaan kwam binnen en duwde hem van zijn ligplaatsen af, en hij schrok de naald die door de bocht ging, waar de rivier zich net buiten New Orleans naar binnen buigt en ging gewoon recht door het industriële kanaal en crashte door een van die muren. Dus hoewel het inderdaad een natuurramp was, was het toch een menselijke fout die tot dat enorme probleem leidde.
En hetzelfde gebeurde aan de andere kant van de stad, waar een deel van de heffing nog nooit was voltooid, blijkbaar omdat de stad en het leger van ingenieurs nooit hadden afgesproken wie het zou betalen. Welnu, er is geen raketwetenschapper voor nodig om erachter te komen dat als je een groot gapend gat in je heffing hebt, dat niet een zeer effectieve heffing is. En dus is het punt dat menselijke fouten echt spelen in het scenario waarin een ramp toeslaat. Dus, zelfs als het vuur is, of als het een overstroming is, of als het een aardbeving is, of wat dan ook, er is waarschijnlijk iets dat iemand had kunnen en moeten doen om zich voor te bereiden op een dergelijk evenement. En dat is natuurlijk wat we traditioneel rampenherstel noemen. Dus ja, er vinden rampen plaats, maar menselijke wezens moeten echt door dat spul heen kijken en zich daarop voorbereiden. We zullen daar vandaag een beetje over praten met Tep.
Ontevreden werknemers - onderschat dus niet de schade die een ontevreden werknemer kan aanrichten - ze zijn daar, ze zijn overal. Ik ken mensen die me verhalen hebben verteld over gewoon echt onaangename dingen die zijn gebeurd, waar mensen gewoon slechte dingen doen, ze opzettelijk hun eigen organisatie saboteren, omdat ze ongelukkig zijn. Misschien hebben ze geen loonsverhoging gekregen, of zijn ze ontslagen, of wie weet wat er is gebeurd. Maar dat is iets om in gedachten te houden en het is een zeer belangrijk onderdeel. In het geval van licenties ook, net als een FYI die er zijn, mensen. Een van de statistieken die ik hoorde was ongeveer 60 procent van alle tips die softwarebedrijven krijgen als ze geen licentiekosten betalen, zijn afkomstig van ex-werknemers. Dus je wilt er zeker van zijn dat je die software hebt gekocht en dat je het eerlijk hebt. Bedrijfssabotage gebeurt niet altijd, maar het gebeurt wel. Privacykwesties komen ook in de mix; je moet voorzichtig zijn met wat je opslaat en hoe je het opslaat, denk goed na over deze dingen.
En ik probeer altijd mensen eraan te herinneren in termen van regulering, het is echt belangrijk om een plan te hebben en dat plan uit te voeren, want als push komt of een auditor komt of een regulator, wil je kunnen wijzen op je beleid dat je hebt, en leg dan uit hoe je dat beleid aanpakt, wanneer bepaalde dingen gebeuren, zoals een ramp, bijvoorbeeld een kwestie van gecontroleerd worden of wat dan ook. Je wilt weten wat je aan het doen was, en daar een verslag van hebben - het gaat een lange weg gaan om de auditor en de baai te houden, en dat is gewoon goed spul.
Dus, hackers, natuurlijk - ik ga het een paar minuten hebben over hackers en waarom ze zo'n bedreiging vormen. En natuurlijk ransomware, zeg maar deze hele zaak met WannaCry, de WannaCry-ransomware, die net de planeet in zeer korte volgorde bedekt, en blijkbaar enkele slimme onvriendelijke mensen voor een hoop informatie van de NSA, er waren hacktools die werden gebruikt en blootgesteld. Dus, ik herinner mensen eraan, er is een oude fabel, Aesops Fabel, die zegt dat we onze vijanden vaak het gereedschap van onze eigen vernietiging geven. Dit is iets om in gedachten te houden, want nogmaals, deze technologie is afgezet door de NSA, door de National Security Association - kan me eigenlijk niet herinneren waar het voor staat. Maar het werd ontmaskerd en kwam de wereld in, en veroorzaakte gewoon ravage. Raad eens? En veel bedrijven hadden hun Windows-omgeving niet geüpgraded, dus het was een oude, denk dat het Windows XP was, dat gecompromitteerd was. Dus nogmaals, als u ijverig bent, als u op de hoogte blijft van uw patches en uw versies van uw besturingssystemen en als u een back-up van uw gegevens maakt en uw gegevens herstelt. Als je alle dingen doet die je zou moeten doen, is dat soort dingen niet zo'n groot probleem. Maar je kunt de mensen die axmen zijn gewoon zeggen: 'Hé, raad eens? Het kan ons niet schelen, het systeem afsluiten, opnieuw opstarten, de back-ups laden. ”En je gaat op weg naar de races.
Dus het punt is ja, deze slechte dingen gebeuren wel, maar er zijn dingen die je eraan kunt doen - daar gaan we het vandaag over hebben in de show. Dus ik heb wat onderzoek gedaan - het was eigenlijk best interessant, als je naar Wikipedia gaat en hacking opzoekt, gaat het helemaal tot 1903. Toen een man een systeem voor telegrafen hackte en onbeleefde berichten verstuurde via de telegraaf, alleen om te bewijzen dat hij het zou kunnen hacken, denk ik. Ik vond dat nogal grappig. Het punt is dat hackers in principe goed zijn in het breken en binnenkomen, dit is wat ze al jaren en jaren en jaren doen. Ze zijn als de lockplukkers van de moderne internetwereld.
En je moet onthouden dat elk systeem kan worden gehackt, het kan van binnenuit worden gehackt, het kan van buitenaf worden gehackt. Vaak, wanneer die hacks zich voordoen, zullen ze zichzelf niet laten zien, of de mensen die je systeem hacken, zullen een tijdje niet veel doen. Ze wachten een tijdje; er is een beetje van de strategie bij betrokken, en deels is het alleen omdat de zakelijke kant van hun operatie, omdat hackers meestal alleen maar hun kleine deel van het programma doen, dus veel jongens die goed zijn in het penetreren firewalls en doordringend informatiesysteem, nou dat is het ding dat ze het beste doen, en zodra ze een systeem doordringen, draaien ze zich om en proberen die toegang aan iemand te verkopen. En dat kost tijd, zo vaak is het zo dat iemand achter de schermen gewoon probeert toegang te verkopen tot welk systeem ze ook hebben gehackt - jouw systeem, mogelijk, wat niet al te leuk zou zijn - en ze proberen erachter te komen wie daadwerkelijk betalen voor toegang tot het systeem.
Dus, er is een dergelijk onsamenhangend netwerk van individuen of organisaties die samenwerken en samenwerken om gebruik te maken van gestolen informatie. Of het nu gaat om identiteitsdiefstal, of gewoon om gegevensdiefstal, of ze het leven voor een bedrijf onaangenaam maken - dat is het geval met deze ransomware, deze jongens grijpen gewoon naar uw systemen en ze eisen geld, en als ze het geld krijgen, misschien of misschien geven ze je spullen niet terug. Dat is natuurlijk het enge ding, waarom zou je dat losgeld zelfs willen betalen? Hoe weet je dat ze het terug zullen geven? Ze kunnen gewoon vragen om dubbele of driedubbele. Dus nogmaals, dit alles spreekt over het belang van echt nadenken over uw informatiestrategie, uw veerkracht voor uw gegevens.
Dus ik heb wat meer onderzoek gedaan, dat is een oude 386; als je oud bent zoals ik, zou je je deze systemen kunnen herinneren. En ze waren niet zo problematisch in termen van hacken; er waren toen nog niet zoveel virussen. Tegenwoordig is het een ander spel, dus natuurlijk komt internet langs en verandert alles. Alles is nu verbonden, er is een wereldwijd publiek, de eerste grote virussen begonnen aan te vallen, en echt de hacking-industrie begon te ballonvaren, eerlijk gezegd.
Dus we zullen een beetje over IoT praten, we hebben al een goede vraag van een publiekslid: Hoe bescherm ik IoT-apparaten vanuit een kwetsbaarheidsstandpunt? Dat is een groot probleem - eerlijk gezegd, daar wordt op dit moment veel moeite in gestoken, in hoe je omgaat met het potentieel voor IoT-apparaten die worden gehackt. Het is veel gebruik, de gebruikelijke problemen waar u zich op richt, wachtwoordbeveiliging bijvoorbeeld, het proces van zorgvuldig instellen, het instellen van uw eigen wachtwoord doorlopen. Vaak laten mensen daar gewoon een standaardwachtwoord achter en dat zal in feite leiden tot het beveiligingslek. Het is dus de basis. We hadden eerder deze week net een ander programma over beveiliging, in ons radioprogramma, met verschillende experts daar en ze zeiden allemaal dat 80-90 of meer procent van de hackproblemen, of het nu IoT of ransomware is, of wat dan ook, zou worden vermeden als je ik heb net de basis behandeld, als je er gewoon voor hebt gezorgd dat je bases zijn bedekt, heb je alle basisdingen gedaan, waarvan je weet dat je dat zou moeten doen, die meer dan 80 procent van alle problemen aanpakt.
Dus het internet der dingen, OK, IoT. Nou, als je aan IoT denkt, is het niet zo nieuw. Eerlijk gezegd zijn er high-end fabrikanten die dit soort dingen 20 en 30 jaar geleden doen, en toen ongeveer 15, 20 jaar geleden, dat was toen RFID binnenkwam - identificatiecodes voor radiofrequentie - die zeer nuttig waren geweest bij het helpen van zeer grote organisaties, zoals detailhandelaren, bijvoorbeeld rederijen, elk productbedrijf dat spullen in het hele land verplaatst, over de hele wereld, het is uiterst handig om al die gegevens te hebben, je komt erachter waar je spullen naartoe gaan; als er iets verdwijnt, kom je erachter.
Het is natuurlijk geen waterdichte oplossing, in feite had ik mijn laptop, mijn Apple ondergedoken bij, van de luchthaven van Atlanta - Atlanta Hartsfield Airport - iemand nam gewoon mijn tas, met mijn computer. Ik dacht dat ze geen tassen meer stelen; ze vinden altijd tassen - verkeerd. Iemand stal de tas en toen verscheen het ongeveer een maand later, het werd wakker, ik kreeg een klein bericht van Apple, van iCloud dat het ongeveer zeven tot tien minuten ten zuiden van Atlanta Hartsfield Airport wakker werd; iemand besloot er gewoon op in te gaan. Ze zaten er gewoon ongeveer een maand op en ik ging door het vrij frustrerende proces van het realiseren, nou, OK, ik weet ongeveer waar het is, het kan zijn in dit huis, dat huis, het huis aan de overkant, het was er gewoon tijdelijk. Wat doe je? Zoals, hoe is die informatie nuttig voor u?
Dus hoewel je iets leert, kun je er soms niet veel aan doen. Maar toch moet ik zeggen dat deze IoT-compatibele wereld er eerlijk gezegd niet helemaal klaar voor is. Ik denk dat we een zaak hebben waarin veel goede technologie beschikbaar is en dat we misschien te snel gaan om van deze dingen te profiteren, omdat de dreiging zo groot is. We denken alleen maar aan het aantal apparaten dat deel uitmaakt van het bedreigingslandschap, terwijl mensen erover praten, dat is een enorme, enorme golf apparaten die onze kant op komt.
Sommige van de grote hacks die onlangs hebben plaatsgevonden, waarbij DNS-servers werden uitgeschakeld, hadden te maken met het feit dat IoT-apparaten werden gecoöpteerd en zich tegen DNS-servers keerden, alleen klassieke DDoS-hacks, gedistribueerde denial of service, waar deze apparaten letterlijk opnieuw worden geprogrammeerd om te bellen op een DNS-server in een zinderend tempo, waar je honderdduizenden aanvragen op deze DNS-server krijgt, en alleen maar stikt en crasht en sterft. Het is iets waar het verhaal van de grote op een niet zo populaire website de servers gewoon crashten - ze zijn gewoon niet gemaakt voor dat soort verkeer.
Dus, IoT is gewoon iets om in gedachten te houden, nogmaals, als we te maken hebben met back-up en herstel, is het gewoon belangrijk om te onthouden dat elk van deze aanvallen op een bepaald moment kan plaatsvinden. En als je daar niet op voorbereid bent, verlies je veel klanten, omdat je veel mensen heel ongelukkig zult maken. En u zult dat reputatiemanagement hebben om mee om te gaan. Dat is een van de nieuwe termen die daar ronddrijft, 'reputatiemanagement'. Het loont om te onthouden en te waarderen dat het jaren kan duren om aan reputaties op te bouwen en minuten of zelfs seconden te verkwisten. Dus, hou daar maar een beetje rekening mee bij het plannen van uw informatiestrategie.
Dus dan is er dit hele concept van de hybride cloud. Ik heb daar een van mijn oude, favoriete films, The Island of Dr. Moreau, waar ze deze dingen met half dieren, half schepsel hebben gemaakt, die een beetje zoals de hybride wolk zijn. Dus de on-premise systemen zullen er al jaren zijn - vergis je niet, het zal lang duren om die on-premise datacenters af te ronden - en zelfs in kleine bedrijven heb je een veel klantgegevens in uw systemen en uw schijven, en hoe complexer die situatie wordt, hoe moeilijker het wordt om aan de top te blijven. Dat gezegd hebbende, consolideren in één database is ook altijd een echte uitdaging, vooral met een systeem zoals MySQL, bijvoorbeeld.
Alles in één systeem proberen te proppen is nog nooit zo gemakkelijk geweest. Als het klaar is, zijn er meestal problemen, je krijgt prestatieproblemen. Dus nogmaals, het wordt al geruime tijd een probleem. Verouderde infrastructuur die er is in datacenters en in bedrijven, natuurlijk. Dat was het probleem met WannaCry, is dat je al deze XP-systemen hebt - Microsoft ondersteunt XP niet meer. Het is dus gewoon een beetje verbazingwekkend hoe sommige van deze problemen die zo ernstig en zo pijnlijk monetair worden en anders kunnen worden vermeden met basisonderhoud en onderhoud. Basic dingen.
Er zal dus een vaardigheidskloof zijn; deze lacunes in vaardigheden zullen in de loop van de tijd toenemen, want nogmaals, de cloud is de toekomst - ik denk dat daar geen twijfel over bestaat - de cloud is waar de dingen naartoe gaan; er is al een zwaartepunt in de wolk. En wat je gaat zien, zijn steeds meer bedrijven, steeds meer organisaties die naar de cloud kijken. Dat laat dus wat lacunes in de vaardigheden achter op het terrein; het is er nog niet, maar het komt eraan. En denk zelfs aan amortisatie, dus veel grote bedrijven kunnen niet zomaar naar de cloud verhuizen - ze zouden het kunnen, maar het zou niet logisch zijn, wat de kosten betreft, omdat ze al die activa afschrijven drie, tot vijf, tot zeven jaar misschien.
Dat schept een vrij aanzienlijk tijdvenster, gedurende welke ze van on-prem naar de cloudomgeving migreren. En eerlijk gezegd hebben we nu het punt bereikt, waar on-premise waarschijnlijk minder veilig is dan de cloud. Best grappig, want dat was lange tijd de grote klop: bedrijven maakten zich zorgen om naar de cloud te gaan om veiligheidsredenen, ze waren bezorgd dat de cloud vatbaar was voor hacks. Nou, dat is het nog steeds, zeker, maar echt als je naar de grote jongens kijkt: Amazon, Microsoft, zelfs nu SAP en Google, al deze jongens, ze zijn behoorlijk goed in dat spul, ze zijn behoorlijk goed in het beveiligen van de cloud zelf.
En dan, natuurlijk, eindelijk aan de kant, on-prem, gedateerde systemen: deze toepassingen raken tegenwoordig vrij snel in de tand. Ik hoorde ooit een grap, de definitie van oudere software is alle software die in productie is. (Lacht) Ik vind het best grappig. Dus over de cloudsystemen, ik noemde de belangrijkste spelers, ze groeien alleen maar met de dag. AWS domineert die ruimte nog steeds, hoewel Microsoft tot hun eer heeft wat dingen uitgevonden en ze zijn zeer aandachtig gefocust. Dat geldt ook voor SAP, de SAP HANA Cloud, het is het HANA Cloud-platform dat ze het noemen - het is een enorm aandachtsgebied voor SAP en om voor de hand liggende redenen. Ze weten dat de wolk nu zwaartekracht heeft, ze weten dat de wolk een uitstekend vechtsportgebied is voor technologie.
Dus wat u ziet, is deze consolidatie rond cloud-architecturen, en u zult de komende twee jaar veel werk hebben over cloud-naar-cloud migratie. Zelfs masterdatabeheer in de wolken wordt een groot probleem. En Salesforce - kijk hoe groot Salesforce is geworden - het is een absolute kracht om rekening mee te houden. Het is ook een marketingsysteem in de cloud; er zijn nu ongeveer 5.000 marketingtechnologiebedrijven - 5.000! Het is gek. En u ziet meer inspanningen op dit enkele glasvenster, om multi-cloudomgevingen te kunnen beheren. Dus nog een laatste dia van mij, en dan zal ik het overhandigen aan Tep om ons wat advies te geven over hoe we hier voorop kunnen blijven lopen.
Dit hebben we eerder deze week besproken in mijn radioprogramma, het cloudmodel met gedeelde verantwoordelijkheid. Dus waar ze het over hebben is hoe AWS verantwoordelijk was voor het beveiligen van de cloud, dus beveiliging van de cloud. Kon computeropslag, databasernetwerken, enz. Zien. Maar de klant is verantwoordelijk voor gegevens en beveiliging in de cloud. Nou, het was grappig omdat ze deze term "gedeelde verantwoordelijkheid" gebruiken en wat ik eigenlijk van de gasten in onze show heb verzameld, is dat het helemaal niet echt wordt gedeeld. Het idee is, het is jouw verantwoordelijkheid, want de kans is groot dat als push komt en iemand je omgeving infecteert, AWS waarschijnlijk niet aansprakelijk wordt gesteld, jij wel.
Dus het is een beetje een vreemde wereld, ik denk dat het een beetje een dubbelzinnige term is, "gedeelde verantwoordelijkheid", want het is echt een beetje niet, het is nog steeds jouw verantwoordelijkheid om op de hoogte te blijven van al die dingen. Daarmee, en ik weet dat ik wat heb gesproken over het IoT - we hadden een goede vraag over hoe IoT-apparaten te beveiligen - er komt een absoluut scala aan technologieën om dat aan te kunnen. Uiteraard heb je wat software op sommige firmware op de IoT-apparaten zelf, dus dat is iets om in gedachten te houden; je moet je zorgen maken over het authenticatieprotocol dat je daarvoor moet gebruiken. Maar zoals ik al zei, de basis zal waarschijnlijk door de meeste problemen heen gaan die je zult tegenkomen, gewoon wachtwoordbeveiliging doen, het veranderen van wachtwoorden en echt een beetje bovenop blijven - die dingen monitoren en kijken .
Veel van de technologieën die worden gebruikt voor het monitoren van bijvoorbeeld fraude of snode activiteiten in netwerken zijn echt gericht op uitbijters, en dat is iets waar machine learning eigenlijk behoorlijk goed in is, in clusteren en uitkijken naar uitbijters, kijken naar vreemde gedragspatronen. Zoals, eerlijk gezegd, wat we zagen met deze recente DDoS-aanval op DNS-servers, waar al deze apparaten plotseling een callback naar een bepaald handvol servers sturen, nou dat ziet er niet goed uit. En eerlijk gezegd, waar ik mensen altijd aan herinner met deze systemen: elke keer dat je in dat soort omgevingen serieuze automatisering hebt, moet je altijd de handmatige override hebben, de kill-schakelaar hebben - je wilt een soort kill-schakelaar laten programmeren om daar te sluiten die dingen naar beneden.
Dus daarmee ga ik de eerste dia van Tep duwen, hij gaat wat demo's voor ons doen. En dan zal ik doorgaan en u de sleutels van het WebEx-tabblad geven. Nu komt het uw kant op en neem het weg.
Tep Chantra: Oké, bedankt, Eric. Mijn naam is Tep Chantra en ik ben de productmanager hier bij IDERA. Vandaag wilde praten over IDERA's enterprise backup-oplossing, namelijk SQL Safe Backup. Voor degenen onder u die bekend zijn met SQL Safe Backup, laten we een paar hoogtepunten van het product eens bekijken die - sorry. Dus, zoals je misschien al hebt geraden, zeggen mensen back-up, SQL Server-back-up en herstelproduct, een van de belangrijkste kenmerken van SQL Safe is de mogelijkheid om snelle back-ups te maken. En het is een belangrijke functie, aangezien de meeste back-ups moeten worden gemaakt en in de meeste gevallen zeer snel moeten worden gemaakt, in een kort tijdsbestek.
In sommige omgevingen kan het nu een hele uitdaging zijn om aan die back-upvensters te voldoen, vooral als u over meerdere grote databases moet beschikken waarvan een back-up moet worden gemaakt. Dankzij het vermogen van SQL Safe om de back-upbewerkingen snel te voltooien, kunnen eindgebruikers aan die back-upvensters voldoen. Over grote databases gesproken, een back-up van die grote databases, uiteraard grotere back-upbestanden. Een ander kenmerk van SQL Safe is de mogelijkheid om back-upbestanden te comprimeren. Het gebruikte compressie-algoritme kan tot 90-95 procent compressie bereiken. Dit betekent dat u back-ups langer kunt opslaan of kostenbesparingen kunt realiseren in termen van opslagbehoeften.
Aan de andere kant van de back-upbewerkingen hebt u herstelbewerkingen. Een van de gevechten die DBA's moeten bestrijden bij het herstellen van databases, is dat die databases zo snel mogelijk moeten worden hersteld. In het geval van grote databases kan een volledig herstel van een back-upbestand enkele uren duren, wat uiteraard langere uitvaltijd en mogelijk verlies van inkomsten betekent. Gelukkig heeft SQL Safe deze functie genaamd "Direct herstel", die in principe de tijd verkort tussen het moment waarop u een herstel start en de toegang tot de database voor eindgebruikers of zelfs toepassingen.
Ik herinner me dat ik een keer met een klant sprak, waar hij meldde dat het herstellen van een bepaalde database 14 uur had geduurd. Maar met de functie voor direct herstel kon hij binnen een uur of minder toegang krijgen tot die database. Op beleid gebaseerd beheer, een ander hoogtepunt van SQL Safe is de mogelijkheid om beleid te maken en uw back-upactiviteiten te beheren via dat beleid. Wanneer u een beleid configureert, definieert u in principe van welke exemplaren een back-up moet worden gemaakt of van welke databases op die instanties een back-up moet worden gemaakt, wat voor soort back-upbewerkingen moeten worden uitgevoerd, en zelfs het schema waarin die back-ups moeten worden gemaakt.
Bovendien kunt u ook waarschuwingsmeldingen configureren. Op die manier kunt u op de hoogte worden gebracht van gebeurtenissen zoals de back-up met succes voltooid, de back-ups mislukt, misschien kan dit zien, maar er zijn enkele waarschuwingen in verband met die bewerking. U ontvangt ook een melding als een back-up niet is uitgevoerd zoals gepland. Dat is een belangrijke melding, want dan heb je misschien een tijdvenster waarin geen back-up bestond. En het ontvangen van een dergelijke melding zal je aangeven dat je daarheen moet gaan en die back-up moet uitvoeren en dan mogelijk wat onderzoek moet doen naar waarom die back-up niet volgens plan is uitgevoerd.
Sommige van de andere dingen, laten we hier kijken, fouttolerante mirroring, betekent in wezen dat we de mogelijkheid hebben om dubbele back-upbestanden op meer dan één locatie te maken. Laten we bijvoorbeeld zeggen dat u een doelbestemming op uw primaire locatie hebt als - wat uw hoofdopslag is, waar al uw back-upbestanden naartoe gaan. Het is echter mogelijk dat u een kopie van hetzelfde back-upbestand nodig hebt, bijvoorbeeld op de lokale machine zelf, voor het geval u wat extra testen moet doen, zorg ervoor dat die database kan worden hersteld, ongeacht het geval. Optimaliseren van virtuele SQL-database - wat dat in wezen is, is dat we een ander product hebben dat onlangs is geïntegreerd in SQL Safe, SQL Virtual Database genaamd.
Zoals ik al zei, is dat recent geïntegreerd en is dat ook daadwerkelijk opgenomen in de SQL Safe zelf. Wat u in wezen kunt doen met SQL Virtual Database, is eigenlijk een virtuele database maken. (Lacht) Ik haat het om dezelfde termen te gebruiken als de definitie, maar wat er in wezen gebeurt, is dat we een database gaan koppelen en het back-upbestand gebruiken. Dus, wat er in wezen gebeurt, is dat SQL Server denkt dat de database daadwerkelijk actief is, terwijl het feitelijk gegevens uit het back-upbestand leest, in plaats van de feitelijke database zelf op het bestandssysteem te maken.
Dit is echt handig omdat het u toegang geeft tot de gegevens die zich in het back-upbestand bevinden zonder daadwerkelijk extra schijfruimte te verbruiken, dus het is erg handig, vooral als u te maken hebt met enorme databases die u gewoon nodig hebt, neem snel een kijkje, of werk eraan. Nuleffectencodering - wat in wezen betekent dat waar we back-ups van deze databases uitvoeren, we de back-upbestanden daadwerkelijk kunnen coderen, en wanneer we deze back-upbestanden coderen, voegen we geen extra belasting toe aan de werkelijke prestaties van het systeem. Het is dus volledig te verwaarlozen. Logverzending is een ander ding dat we kunnen doen, waarbij ons beleid, zoals ik eerder al zei, en met betrekking tot de voordelige licenties - wat dit in wezen betekent dat u met onze licentiemodellen licentiemodellen van de ene naar de andere instantie kunt verplaatsen, met een paar simpele muisklikken.
Laten we verder gaan met de architectuur van het product zelf. Er zijn dus in wezen vier hoofdcomponenten van het product. We hebben vanaf links de SQL Safe Management Console en Web Console. Beide zijn in wezen gebruikersinterfaces, de ene is de desktop-client en de andere is een webapplicatie. Beide gebruikersinterfaces halen gegevens uit de volgende component, de SQL Safe Repository-database. De repository-database slaat in principe al uw operationele geschiedenis, alle back-up- en herstelbewerkingen op. Die gegevens worden hier opgeslagen. Al deze gegevens in de repository worden beheerd door de SQL Safe Management Service, het volgende onderdeel. De Management Service is verantwoordelijk voor het bijwerken van de repository-database en het verzenden van waarschuwingsmeldingen. De gegevens met betrekking tot de back-up- en herstelbewerkingen zijn eigenlijk afkomstig van de SQL Safe Backup Agent, het laatste onderdeel aan de rechterkant.
De SQL Safe Backup Agent is een component die wordt geïnstalleerd op alle servers die de SQL Server-exemplaren hosten die u probeert te beheren met SQL Safe. En dit is de service die eigenlijk verantwoordelijk is voor het uitvoeren van de back-ups en het comprimeren ervan. Nu, op deze dia, is er ook een vijfde component, die niet helemaal vereist is, maar het is een leuk ding om te hebben. En dat is onze RDL-bestanden voor SQL Server Reporting Services. Wat u in principe kunt doen, is enkele RDL-bestanden implementeren in SQL Server Reporting Service zodat u rapporten kunt uitvoeren in onze repository-database. En we hebben een aantal verschillende rapporten, zoals de laatste keer dat uw back-up is uitgevoerd, details over back-upbewerkingen, wat heeft u.
En excuseer mij. Laten we doorgaan en SQL Safe zelf bekijken. Geef me een seconde hier. En geef me een seconde om in te loggen. Zoals u ziet, heb ik nu de webapplicatie geladen, maar eerst zou ik eigenlijk de desktopapplicatie willen bekijken. Dus laat me dat heel snel opstarten. En dit is de SQL Safe-desktopapp, wanneer u deze voor het eerst laadt, gaat u naar de weergave SQL Safe vandaag. Dit is in wezen een lijst van alle back-up- of herstelbewerkingen die vanaf vandaag zijn gebeurd. Het geeft je ook een snelle status van je omgeving, zoals je hier kunt zien, staat dat mijn beleid één beleid heeft, dat in een goede staat is, wat goed is, omdat ik maar één beleid heb en ik hoop dat het is niet . Geeft u ook een overzicht van bewerkingen die zijn geslaagd, alle bewerkingen die mogelijk zijn mislukt. Over het algemeen ben ik goed in vorm: alleen al door snel te kijken, zie je alle greens; we zijn goed om te gaan.
Links ziet u alle servers die u hebt geregistreerd bij SQL Safe en de servers die u in principe beheert. Als u het uitvouwt, krijgt u de lijst met databases op dat systeem te zien. Als u een bepaalde database selecteert, kunt u de operationele geschiedenis van die specifieke database bekijken. Er valt niet veel meer uit te leggen, behalve dat je vanuit dit venster ook ad hoc back-ups kunt maken, en het is echt snel en eenvoudig. En laat me dat heel snel aan je tonen. Klik er gewoon met de rechtermuisknop op en selecteer de bewerking die u wilt uitvoeren. En voor dit doel zal ik doorgaan en een back-updatabase kiezen. En de SQL Safe Backup Wizard wordt geopend. Vanaf hier krijg je dit, zoals tegen welk exemplaar je de back-up wilt uitvoeren en selecteer je naar welke databases je een back-up wilt maken. In dit geval heb ik de HINATA-machine en deze Contoso Retail-database vooraf geselecteerd, omdat ik dat had benadrukt toen ik de optie koos. Ik ga door en laat dat voorlopig maar je hebt wel de optie om daadwerkelijk meer databases te selecteren, zodat je, als je bijvoorbeeld een back-up van al je gebruikersdatabases wilt maken, dit keuzerondje kunt selecteren en alle die. Laat me doorgaan en daarmee doorgaan.
Op naar de volgende pagina van de wizard. Hier kan ik het type back-up selecteren dat ik wil uitvoeren en je hebt hier een aantal verschillende opties. Dat is - ik weet zeker dat deze in alle back-uphulpprogramma's te vinden is, u kunt bijvoorbeeld een volledige back-up, een differentiële back-up, transactielogboekback-up maken of u kunt gewoon een back-up maken van het databasebestand zelf. Je hebt ook de opties om een back-up te maken die alleen kopieert, die in principe wordt gebruikt als je niet wilt rommelen met de LSM's. Ik ga nu "nee" selecteren. En u hebt ook de optie om de back-up te verifiëren nadat de back-up is voltooid - op die manier zorgt u ervoor dat uw back-up goed is en later kan worden gebruikt. Het is altijd een van die functies die u zeker wilt weten, alleen om u een beetje zekerheid te geven dat de back-up bruikbaar is.
Hier vindt u de naam en gegevensbeschrijving. Dit zijn in wezen metadata waarmee u eenvoudig kunt identificeren waarvoor de back-up is gebruikt, dus ik ga hier een demo-doel zeggen. En gebruik de back-up van uw database voor een demo. Hierna bepalen we waar we ons back-upbestand willen opslaan, en u hebt hier verschillende opties: u kunt het opslaan in een enkel bestand, u kunt streepbestanden maken, u kunt hier de doelbestemming selecteren, we ondersteunen ook datadomein. En dat, Amazon ST cloud, voor het geval dat is waar u uw informatie wilt opslaan.
Ik ga door met het enkele bestand voor deze demonstratie, dit maakt netwerkresiliency mogelijk, dit is echt een leuke functie binnen SQL Safe in de zin dat als je een back-up maakt naar een netwerklocatie - wat ik hier doe, kunt u zien in het primaire archief - als u een back-up maakt van de netwerklocatie, zijn er kansen dat u mogelijk netwerkproblemen ondervindt. In sommige gevallen als uw netwerkproblemen worden verholpen, is de back-upbewerking volledig uitverkocht. Welnu, schakel de optie netwerkresiliency in, wat het in wezen doet als er een netwerkstoring optreedt, wat SQL Safe in wezen doet, is dat het de back-up pauzeert en een specifieke tijd wacht en de netwerklocatie opnieuw probeert. En als het in staat is om verbinding te maken, zal het gewoon de back-up hervatten waar het was gebleven. Op die manier besteed je niet uren achter elkaar aan het proberen om deze back-up uit te voeren en meteen wanneer deze bijna klaar is, is er een netwerkstoring opgetreden - we verkopen de bewerking niet meteen, we wachten gewoon even en proberen om het opnieuw te voltooien.
Er zijn enkele andere opties bij het configureren hiervan. Nu houdt het in feite het interval in waarop we het opnieuw proberen, dus in deze zin zal het proberen om binnen tien seconden opnieuw toegang te krijgen tot de netwerklocatie als we een netwerkstoring tegenkomen. De tweede optie hier vertelt je in feite dat als we netwerkproblemen ondervinden, hier 300 seconden staat - dus vijf minuten in totaal - dan zullen we de back-upbewerking volledig verkopen. En dat is vijf minuten na elkaar, dus als we het steeds opnieuw proberen en binnen die vijf minuten we de netwerkverbinding nog steeds niet kunnen herstellen, dan zullen we de operatie volledig verkopen. Deze allerlaatste operatie hier is in principe voor de gehele duur van de back-up, dus als je hier tien seconden verliest, breng je de verbinding opnieuw tot stand en verlies je de verbinding opnieuw, als dat in feite 60 minuten herhaalt, dan is die operatie uitverkocht. En deze zijn geconfigureerd, zoals u kunt zien, zodat u het kunt aanpassen aan uw omgeving.
Deze spiegelarchiefoptie hier, hier had ik het eerder over, met fouttolerante mirroring. Hier kunt u een andere back-uplocatie opgeven, voor het geval u dat ooit zou willen. Ik laat dit nu niet aangevinkt, gewoon omdat ik door wil gaan en door wil gaan. In deze optievensters kunt u dingen definiëren, zoals uw type compressie die we voor deze back-upbewerking willen gebruiken en of we al dan niet codering voor het back-upbestand willen inschakelen. We bieden een aantal verschillende compressiemogelijkheden, zelfs geen, als u ervoor kiest om helemaal geen compressie te hebben. Het is dus gewoon om deze opties snel te bespreken.
Hoge snelheid probeert in principe de back-up zo snel mogelijk te voltooien, met inbegrip van enige hoeveelheid compressie. ISize is meer gericht op het opnemen van zoveel mogelijk compressie, maar het kan - omdat we het zoveel proberen te comprimeren - iets langer duren en waarschijnlijk een beetje meer CPU gebruiken. Niveau 1 betekent in wezen de minste hoeveelheid compressie helemaal tot niveau 4, de meeste hoeveelheid compressie die we kunnen toevoegen. Dus dit is een beetje meer gedetailleerd, typisch iSpeed - wat is het woord? Varieert tussen niveau 1 en niveau 2 compressie; het bekijkt uw systeem om te zien hoeveel CPU en beschikbare bronnen beschikbaar zijn en maakt een oordeel over veel compressie, het zou tussen niveau 1 en niveau 2 moeten gebruiken.
ISize doet hetzelfde, behalve met niveau 3 en niveau 4. Er zijn hier enkele andere geavanceerde opties, zoals hoeveel er op de CPU zijn die we zouden moeten gebruiken, hier is de optie voor het maken van de kaartgegevens voor de virtuele database van SQL en ook onze directe herstelfunctie. U kunt database-aanmeldingen opnemen en sommige andere opties die sommige gebruikers erg waardevol vinden, zoals het genereren van controles hieruit, zodat ze dat later kunnen controleren om te controleren of de back-upbestanden goed zijn. Als we doorgaan naar de volgende pagina, stelt u hier uw meldingen in. En u kunt de verschillende opties zien die we hier hebben: melden als de back-up mislukt, melden als de back-up wordt overgeslagen, om welke reden dan ook. Als de back-up wordt geannuleerd of als de back-up wordt voltooid met een waarschuwing, en als u dat wilt, kunt u een melding krijgen dat uw back-up schoon is. Voor omgevingen waar een groot aantal databases is, is dat misschien niet iets dat u wilt inschakelen, alleen omdat het meer dan waarschijnlijk is dat uw back-up zal slagen en u zult worden overspoeld met e-mails.
Op de volgende pagina kunt u een samenvatting bekijken van wat u hebt gedefinieerd, omdat deze back-upbewerking is uitgevoerd. En als u wilt, als alles er goed uitziet, kunt u doorgaan en op back-up klikken, we beginnen het. Voordat ik op back-up klik, laat me doorgaan en u deze knop 'script genereren' tonen. Omdat wat SQL Safe een opdrachtregelinterface biedt waar u een back-up of herstelbewerking kunt starten, wat heeft u, via een opdrachtregel, DOS-prompt. Als u hier op het script genereren klikt, krijgt u in feite het daadwerkelijke script dat u kunt gebruiken als u de back-up van de opdrachtregel wilt verwijderen.
Wat nog leuker is, is dat we ook uitgebreide winkelprocedures aanbieden, en in dit geval genereren we een script voor u dat exact dezelfde back-upbewerking uitvoert met behulp van uitgebreide winkelprocedures - slechts een kleine snelle hap die ik wilde delen. Laten we deze back-up dus beginnen. En je kunt zien dat de back-up al is gestart. En deze database is een beetje groot, dus het kan even duren. Je kunt zien dat ik hier eerder een paar keer heb gelopen, dus het gaat me ergens van een minuut tot drie minuten duren. Dit is een niveau 4, dus ik denk dat het tussen deze twee keer zal zijn.
Terwijl dat loopt, laten we het beleid eens snel bekijken. Zoals ik al eerder zei, kunt u met het beleid geplande back-upbewerkingen in uw hele onderneming configureren, dus ik heb hier een beleid, al vooraf geconfigureerd en in plaats van een nieuw te maken, laten we de details van deze eens bekijken. Mijn excuses, mijn VM draait op mijn persoonlijke laptop en het lijkt erop dat de ventilator behoorlijk hard draait. (Lacht)
Eric Kavanagh: Dat is goed - weet je, ik zou je een vraag stellen terwijl we dit hier bekijken. Gebruikt IDERA veel gegevensveranderingen bij het maken van back-ups of maakt u steeds hele back-ups? Hoe werkt dat, weet je dat?
Tep Chantra: Zeg dat nog een keer, het spijt me?
Eric Kavanagh: Ja, weet je of IDERA CDC gebruikt, de technologie voor het vastleggen van gegevens wijzigen om kleinere back-ups te maken, of doet het elke keer volledige back-ups?
Tep Chantra: Ik geloof het niet. Ik herinner me dat ik dat eerder zag in een aantal kaartjes. En als ik het me goed herinner, nee, we maken geen gebruik van de CDC, maar, om eerlijk te zijn, laten we in wezen SQL Server de back-up uitvoeren, we vangen alleen de gegevens ertussen en comprimeren het, wat resulteert in er wordt een back-upbestand gemaakt. Dus in wezen dat gebruiken. Ja.
Dus nu ik mijn beleid heb geladen - oh, het spijt me, had je nog een vraag?
Eric Kavanagh: Nee, dat is het. Doe Maar.
Tep Chantra: OK, dus nu ik mijn beleid heb geladen, kun je hier enkele snelle dingen zien: naam, beschrijving, je kunt instellen wat voor soort beleid je gaat maken, of het een beleid is dat wordt beheerd, wordt het schema beheerd door de SQL Server Agent of wordt het schema beheerd door de SQL Server Backup Agent. In de meeste gevallen wilt u de SQL Server Agent gebruiken, want dat is meestal iets dat sowieso op uw systeem wordt uitgevoerd, dus u kunt net zo goed gebruikmaken van wat voor u beschikbaar is. Op het tabblad lidmaatschap geeft u hier de instanties op in de back-updatabases waarvan u een back-up wilt maken. En in dit geval ziet u dat ik al mijn geregistreerde exemplaren heb toegevoegd en een specifieke database heb opgegeven waarvan een back-up moet worden gemaakt. Nu, als ik zou willen, zou ik deze kunnen bewerken en zeggen: "Ik wil een back-up maken van alle databases of alleen gebruikersdatabases of zelfs systeemdatabases." Het leuke hiervan is dat ik ook wildcards kan gebruiken en bepaalde databases.
Ik ga die wijziging hier niet maken, alleen omdat ik geen grote wijzigingen in mijn instellingen wil aanbrengen. Laten we dus teruggaan naar de opties. En bij de opties definieer je hier wat voor soort back-ups je gaat maken, en als je hier een kijkje neemt, heb ik volledige back-ups, differentiële back-ups en grote back-ups geconfigureerd. En voor elk van deze back-ups kan ik bepalen of ik een specifieke hoeveelheid compressie wil gebruiken of de codering wil inschakelen. Net als de opties die u zou hebben gevonden in de ad hoc wizard. En op locaties kunt u ook de bestemming van deze back-upbewerkingen definiëren. Een van de goede dingen van het beleid is dat u ook kunt bepalen of u al dan niet door wilt gaan en die oude back-upbestanden wilt verwijderen, op basis van het X-aantal dagen of weken, wat heeft u.
En dat is configureerbaar voor elk type back-up. Dus je kunt hier zien dat ik na een week mijn volledige back-ups moet verwijderen. Mijn differentieel wordt na twee dagen verwijderd en ik wil dat mijn back-ups na één dag worden verwijderd. Dit is echt leuk, want het automatiseert het verwerkingsscenario, oude back-upbestanden en houdt alleen die bestanden bij die je echt nodig hebt, op basis van tijd. Volgende pagina definieert u het schema, en nogmaals, het schema kan specifiek zijn voor elk type back-upbewerking dat u gaat voltooien, dus voor mijn volledige werk ik het wekelijks, mijn differentieel voer ik het elke zes uur uit, mijn logbestanden worden elke 30 minuten uitgevoerd. Op de volgende pagina stelt u meldingen in en het zijn in wezen dezelfde soorten meldingen die u in ad hoc back-up hebt gevonden, het enige verschil is dat u deze nieuwe, andere optie hebt waarmee u kunt zien of de back-up niet kan worden gestart zoals gepland. Hier kunt u worden gewaarschuwd voor situaties waarin uw back-ups niet zijn uitgevoerd. Heel belangrijk, vooral in het geval dat je bepaalde SLA's hebt om ervoor te zorgen dat je back-ups beschikbaar hebt op de momenten dat je ze nodig hebt. En op de volgende pagina kunt u de samenvatting bekijken. Als ik wijzigingen had aangebracht, als ik op Voltooien klikte, zou het uitgaan en die wijzigingen aanbrengen, opslaan en bijvoorbeeld opslaan in de repository van de SQL Server Agent-taken.
En om je snel een beetje snel te laten zien, hier is een beleid en een taak die ik voor dat specifieke beleid heb gemaakt. En u kunt zien dat het drie verschillende taken heeft gemaakt: een voor elk back-uptype. Nu, heel snel, laat me een snelle blik werpen op de HUD-interface en een soort - zoals ik al eerder zei, was virtuele database een die we hebben geïntegreerd in SQL Safe. Zoals ik al zei, houdt het SQL Server eigenlijk voor de gek door te geloven dat een echte database is hersteld, terwijl we in feite alleen maar het back-upbestand lezen. Dus, laat me doorgaan en niet echt snel voor jullie. Laat me een back-upbestand nemen. Hier, laat me hier een vier nemen. Het proces is voltooid en heel snel, als ik mijn databases hier ververs, zie je dat de database toegankelijk is en SQL Server denkt dat deze live is, maar in werkelijkheid lezen we de gegevens gewoon uit de database.
Enkele andere functies die nieuw zijn in deze versie is de mogelijkheid om back-ups uit te voeren met behulp van de nieuwste back-upindeling. Het is echt handig voor die klanten die gebruik moeten maken van ons beleidgebaseerd beheer, maar ze willen om welke reden dan ook het SQL Server-bestandsformaat behouden. Nu weet ik dat we bijna geen tijd meer hebben, dus ik denk dat ik deze presentatie zou willen stoppen, gewoon zodat we wat vragen kunnen beantwoorden, of wat dan ook.
Eric Kavanagh: Ja, natuurlijk. Dus ik denk dat een van de sleutels echt ligt in beleidsbeheer, toch? Zoals bij het denken over het optimale beleid en waar baseer je dat op? Natuurlijk zijn er in sommige gevallen regels om je zorgen over te maken, maar in een bedrijf is dat misschien niet sterk gereguleerd; je hoeft alleen de optimale tijden te vinden om je back-ups te maken en dan denk ik dat je wat rapporten krijgt over hoe lang het duurde en hoe duur het was in termen van rekenkracht enzovoort. Wat wordt er gebruikt om het optimale beleid te bepalen?
Tep Chantra: Dat is echt geval per geval, elke omgeving zal een ander beleid hebben met betrekking tot wanneer deze back-ups moeten worden uitgevoerd. Ook, en dat kan het type back-ups inhouden, het schema waarmee ze worden uitgevoerd, en het bepaalt echt, echt ook afhankelijk van hun herstelbehoeften, denk ik, dat is het antwoord.
Eric Kavanagh: OK, ja. En je had het over het kunnen maken van verschillende soorten back-ups en strepen was een van de opties. Is dat voor een soort warme en koude gegevens, of wat is de logica achter het gaan van streep, in tegenstelling tot een andere methode?
Tep Chantra: Dus ik denk dat het beste antwoord dat ik daar op kan geven, is dat gestreepte bestanden, wat we in wezen doen, de back-upinhoud over een aantal verschillende bestanden schrijven. Ik geloof dat het idee om gestreepte bestanden te gebruiken is dat je je back-upbestanden mogelijk sneller kunt schrijven, op die manier. U kunt bijvoorbeeld elk ander bestand naar een andere locatie laten gaan. Dat kost de server ook beveiligingsmiddelen, omdat u uw back-upbestanden naar verschillende locaties distribueert.
Eric Kavanagh: En er zijn een aantal coole, nieuwe dingen in termen van herstelmogelijkheden, toch? Want laten we zeggen dat er een soort evenement is, of het nu een natuurramp of ransomware is, wat het geval ook is. Je hoeft niet slechts één optie te hebben om te herstellen, toch? Kunt u prioriteiten stellen voor wat wordt hersteld en welke soorten gegevens? Kun je daar over de opties praten?
Tep Chantra: Nou, in termen van herstel heb ik eerder gezegd dat we de mogelijkheid bieden om onmiddellijk herstel uit te voeren, wat gebruikers in wezen sneller naar de gegevens brengt, toch? En om te demonstreren, ik heb er eerder een gedaan, dus je kunt hier zien dat deze database niet erg groot is, deze draait op mijn laptop. Dus ik denk dat het misschien twee optredens groot zijn, maar deze database is binnen 37 seconden voltooid. Werkelijk herstel. Het duurde dus 37 seconden voordat ik toegang kon krijgen tot mijn gegevens, dus met het onmiddellijke herstel had ik binnen twee seconden toegang tot mijn database. U kunt zich dus voorstellen hoe het eruit zou zien als uw database veel groter was.
Eric Kavanagh: Ja, goed punt. En natuurlijk hadden we het hier al over voor de show; je hebt veel tijd besteed aan de frontlinies om mensen te ondersteunen en vervolgens overgestapt naar de ruimte voor productbeheer, dus het is een beetje een andere uitdaging, denk ik. Maar je stond in de frontlinie - ik vind het een behoorlijk goede plek om te leren waar mensen fout gaan en wat sommige problemen zijn. Wat zie je als een aantal van de meest voorkomende valkuilen, die mensen kunnen vermijden als ze er gewoon beter over nadenken?
Tep Chantra: Enkele veel voorkomende valkuilen zijn gewoon - ik veronderstel zoals je eerder al zei - je back-ups in te plannen. Er zijn tijden geweest dat mensen mensen probeerden te benutten, bijvoorbeeld ons beleid, beleid, beleid dat u veel back-ups uitvoert en het baseert op LSM. En in sommige gevallen heb ik gezien dat sommige mensen ook een ander hulpprogramma hebben voor het uitvoeren van back-ups in hun databases, waardoor hun beleid voor het verzenden van logboeken in feite wordt verstoord, omdat back-ups in wezen buiten SQL Safe worden gemaakt en we hiervan niet op de hoogte zijn. Het is vooral gewoon dingen vooruit plannen, dat is waar de valkuil vandaan komt.
Eric Kavanagh: Verbaast me niet. Welnu, mensen, dit is een goede beoordeling geweest van enkele blokkades en oplossingen die nodig zijn om uw onderneming tevreden te houden en uw klanten tevreden te houden. Ik wil iedereen hartelijk bedanken, Tep Chantra van IDERA, die hier binnenkomt, wat live demo's doet, dat is altijd interessant - het is altijd een beetje riskant om de live demo te doen, maar ik denk dat dat redelijk goed ging. Weet je, het zijn basale dingen, maar het is iets waar je, als je het niet doet, allerlei problemen zult hebben. Dit is dus de belangrijke dingen die bedrijven sommige mensen laten doen.
Dus, Tep, bedankt voor je tijd. Mensen, we archiveren al deze webcasts om ze later te bekijken, dus meestal kun je binnen een uur of twee terugkomen en het archief bekijken. Maar nogmaals, geweldige dingen hier, we proberen de onderneming te helpen de zaken op de voet te houden, we waarderen al uw tijd en aandacht, mensen daar. We zullen je de volgende keer bijpraten. Je hebt geluisterd naar Hot Technologies. Wees voorzichtig, mensen. Tot ziens.
