Av Techopedia Staff, 7. juni 2017
Takeaway: Vert Eric Kavanagh diskuterer sikkerhetskopiering og gjenoppretting med IDERAs Tep Chantra i denne episoden av Hot Technologies.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: OK, mine damer og herrer, det er onsdag klokken 04 øst, for de som er på bedriften teknologi, vet du hva det betyr: Det er på tide med Hot Technologies. Ja absolutt. Jeg heter Eric Kavanagh, jeg vil være din moderator for dagens arrangement med tittelen “Bulletproof: How Today's Business Leaders Stay on Top.” Og folkens, vi skal ha en hyggelig, intim samtale her i dag; Det kommer til å være Tep Chantra og ditt, som virkelig er vert for denne samtalen. Vi kommer til å snakke alt om en rekke forskjellige ting, inkludert katastrofegjenoppretting, sikkerhetskopiering og gjenoppretting, men egentlig er uttrykket jeg liker å bruke i disse dager dataforsikring - jeg hørte det fra en herre for bare et par uker siden, og det virkelig, det gir mye mening. Fordi det taler til hvor viktig det er å ha en spenstig informasjonsinfrastruktur under virksomheten din.
Dette er informasjonsøkonomien i disse dager, noe som betyr at de fleste selskaper er avhengige i en eller annen forstand av informasjonsmidler, på data. Jeg mener, til og med detaljhandelsselskaper, til og med maskinvareselskaper, egentlig noen form for organisasjon i disse dager vil ha en slags informasjonsryggrad, eller i det minste kommer de til, hvis de er i moderne tid, hvis du vil. Det er noen mamma- og popbutikker som fremdeles kan unngå de tingene, men selv der, begynner du å se mye mer spredning av informasjonssystemer, mange av dem skybaserte, ærlig talt, men mange av dem fremdeles på premiss, for å håndtere kundetransaksjoner, holde deg oppdatert, for å vite hva kundene dine vil ha, for å vite hva varelageret er, for å vite hva det var, å kunne forstå det store bildet - det er virkelig viktige ting i disse dager.
Altså, datasikkerhet er et begrep jeg liker å bruke; redundans er et annet begrep som kommer til hjernen. Men du vil forsikre deg om at uansett hva som skjer, så vil de ansatte og organisasjonen din ha den informasjonen den trenger for å betjene kundene dine. Så jeg kommer til å gå igjennom, bare på en måte å innramme argumentet, før Tep tråkker inn og forklarer oss noen av tingene som IDERA har pågått. IDERA har selvfølgelig gjort ganske mange websendinger med oss det siste året. Det er et veldig, veldig interessant selskap, de er fokusert på noen av messingstussene og blokkerer og takler om nødvendig for å overleve i informasjonsøkonomien. Vi vil litt dykke inn.
Skuddsikker infrastruktur - det er faktisk et gammelt bilde av en stormaskin, se på det, det er som tidlig på 1960-tallet fra Wikipedia. Du tenker på veien tilbake da mainframe-dager ikke var mange tilgangspunkter for stormaskinene, så sikkerheten var litt enkel, sikkerhetskopien var ganske grei, du kunne forstå hva som måtte gjøres, du måtte bare gå inn og gjøre den. Selvfølgelig var det ikke så mange som visste hva de skulle gjøre, men de som gjorde det, det var ganske tydelig hva du måtte gjøre. Og det var det ikke for mye bekymring for. Du hadde problemer av og til, men det var egentlig ikke så vanlig.
Tilbake på dagen var disse tingene ganske enkle - i dag, ikke så mye. Så her er bildet - det er faktisk Hercules som kjemper mot Hydra der. For de av dere som ikke er store med mytologien, var Hydra en veldig irriterende skapning ved at den hadde flere hoder, og hver gang du hakket av en, kom to til på stedet, så det snakker slags utfordringen til Å håndtere noen av problemene du finner i livet, spesielt i den sammenhengen, var virkelig rettet mot skurkene. Du tar ut en skurk, to til i deres sted. Og du ser på en måte dette i hackingverdenen, helt ærlig, det er en stor næring i disse dager, og det er bare en av de store utfordringene som står overfor oss.
Så tenker du på hvis du prøver å kartlegge strategien for datakraft, hva må du bekymre deg for? Vel, det er mange ting å bekymre deg for: katastrofer, branner, flom. Jeg tilbrakte mye tid i Sør og New Orleans har selvfølgelig noen interessante historier angående orkaner og flom og så videre. Og mange ganger kommer menneskelig feil inn i stykket, kommer inn i bildet, skulle jeg si. Og det var tilfellet også i Katrina i New Orleans, fordi ja, en orkan kom gjennom, det er en handling fra Gud, som de sier, en force majeure . Men det var likevel menneskelige feil som førte til orkanen som resulterte i flere av bruddene på avgiftene. Så det var tre av dem, faktisk var det en på industrikanalen, og problemet med at det er et skip hadde ikke blitt fortøyd ordentlig, nedover elven. Og orkanen kom inn og dyttet den fra fortøyningene, og den trådte nålen faktisk rundt svingen, der elven bøyer seg rett utenfor New Orleans, og den gikk rett ned i industrikanalen og krasjet gjennom en av disse murene. Så selv om, ja, det var en naturkatastrofe, fremdeles, var det menneskelige feil som resulterte i det enorme problemet.
Og det samme skjedde på den andre siden av byen, der det var en del av avgiften som aldri hadde blitt fullført, tilsynelatende fordi byen og hærens korps av ingeniører aldri hadde blitt enige om hvem som skulle betale for det. Det krever ikke en rakettforsker å finne ut at hvis du har et stort gapende hull i avgiften din, er det ikke en veldig effektiv avgift. Og så, poenget er at menneskelig feil virkelig spiller inn i scenariet hvor katastrofen rammer. Så selv om det er brann, eller om det er en flom, eller om det er et jordskjelv, eller hva tilfellet måtte være, er det sannsynligvis noe noen kunne ha og burde ha gjort for å forberede seg på en slik hendelse. Og det er selvfølgelig det vi tradisjonelt kaller katastrofegjenoppretting. Så ja, katastrofer forekommer, men mennesker burde virkelig se gjennom de tingene og forberede seg deretter. Vi skal snakke litt om det i dag med Tep.
Så misfornøyde ansatte - ikke undervurder skaden som en misfontert ansatt kan gjøre - de er der ute, de er overalt. Jeg kjenner folk som har fortalt meg historier om bare virkelig ubehagelige ting som har skjedd, der folk bare gjør dårlige ting, de saboterer med vilje sin egen organisasjon, fordi de er ulykkelige. Kanskje fikk de ikke en forhøyning, eller fikk sparken, eller hvem vet hva som skjedde. Men det er noe du må huske på, og det er en veldig viktig komponent. I tilfelle av lisenser, også, som en FYI der ute, folkens. En av statistikkene jeg hørte var noe som 60 prosent av alle tips som programvareselskaper får for manglende betaling av lisensavgift kommer fra tidligere ansatte. Så du vil forsikre deg om at du har kjøpt den programvaren, og at du har den rettferdig og firkantet. Bedriftssabotasje skjer ikke hele tiden, men det skjer. Problemer med personvern kommer også inn i blandingen; du må være forsiktig med hva du lagrer og hvordan du lagrer det, virkelig tenke gjennom disse tingene.
Og jeg prøver alltid å minne folk når det gjelder regulering, det er virkelig viktig å ha en plan og gjennomføre den planen, for når push kommer til å skyve eller noen revisor kommer inn eller en regulator, vil du kunne peke på retningslinjer du har, og deretter forklare hvordan det er at du tar opp den politikken, når visse ting skjer, for eksempel en katastrofe, for eksempel som et spørsmål om å bli revidert eller hva som måtte være. Du vil vite hva du gjorde, og ha en oversikt over det - det kommer til å strekke seg langt for å holde revisoren, og det er bare gode ting.
Så, hackere, selvfølgelig - jeg kommer til å snakke et par minutter om hackere og hvorfor de utgjør en slik trussel. Og selvfølgelig ransomware, bare si hele saken med WannaCry, WannaCry ransomware, som nettopp dekket planeten i veldig kort rekkefølge, og tilsynelatende noen smarte uvennlige mennesker for en haug med informasjon fra NSA, det var hackingverktøy som ble brukt og utsatt. Så jeg minner folk om at det er en gammel fabel, Aesops Fabel, som sier at vi ofte gir fiendene våre verktøy for vår egen ødeleggelse. Dette er noe du må huske på, for igjen, denne teknologien ble avstengt av NSA, av National Security Association - kan ikke huske hva den står for, faktisk. Men den ble utsatt, og kom ut i verden, og bare ødela ødeleggelser. Gjett hva? Og mange selskaper hadde ikke oppgradert Windows-miljøet sitt, så det var et gammelt, tror det var Windows XP, som ble kompromittert. Så igjen, hvis du er flittig, hvis du holder deg oppdatert om oppdateringene og versjonene av operativsystemene dine, og hvis du tar sikkerhetskopi av dataene dine, og gjenoppretter dataene dine. Hvis du gjør alle tingene du bør gjøre, er ikke sånt så stort problem. Men du kan bare si til folkene som er øksemenn, “Hei, gjett hva? Vi bryr oss ikke, slå av systemet, start det på nytt, last inn sikkerhetskopiene. ”Og du er på vei til løpene.
Så poenget er ja, disse dårlige tingene skjer, men det er ting du kan gjøre med det - det er det vi skal snakke om på showet i dag. Så jeg forsket - faktisk var det litt interessant. Hvis du går til Wikipedia og ser opp hacking, går det helt til 1903. Når en fyr hacket et system for telegraf og sendte frekke meldinger gjennom telegrafen, bare for å bevise at han kunne hacket det, antar jeg. Jeg syntes det var ganske morsomt. Poenget er at hackere i utgangspunktet er flinke til å bryte og gå inn, dette er hva de har gjort i mange år og år. De er som låseplukkerne i den moderne internettverdenen.
Og du må huske at ethvert system kan bli hacket, det kan bli hacket fra innsiden, og det kan bli hacket utenfra. Mange ganger, når disse hakkene oppstår, vil de ikke vise seg, eller de menneskene som hacker seg inn i systemet ditt, vil ikke gjøre mye på en stund. De venter en stund; det er litt av strategien involvert, og delvis er det bare fordi forretningssiden av driften deres, fordi det som hackere vanligvis gjør, er at de bare gjør sin ene lille del av programmet, så mange gutter som er flinke til å trenge gjennom brannmurer og gjennomtrengende informasjonssystem, det er vel det de gjør best, og når de først trenger gjennom et system, så snur de seg og prøver å selge den tilgangen til noen. Og det tar tid, så ofte er det sånn at noen bak kulissene bare prøver å selge tilgang til hvilket system de har hacket - systemet ditt, potensielt, som ikke ville være så gøy - og de prøver å finne ut hvem som faktisk vil betale for tilgang til systemet.
Så det er denne typen usammenhengende nettverk av enkeltpersoner eller organisasjoner der ute, som samles sammen og samarbeider for å gjøre bruk av stjålet informasjon. Enten det er identitetstyveri, eller bare datatyveri, om de gjør livet ubehagelig for et selskap - det er tilfelle med denne løseprogramvaren, disse karene tar bare tak i systemene dine og de krever penger, og hvis de får pengene, kanskje eller kanskje de ikke vil gi tingene dine tilbake. Selvfølgelig, det er den virkelige skumle tingen, er det grunnen til at du til og med vil betale den løsepenger? Hvordan vet du at de kommer til å gi det tilbake? De ber kanskje bare om dobbelt eller trippel. Så igjen, alt dette taler til viktigheten av å virkelig tenke gjennom informasjonsstrategien din, din elastisitet for dine data.
Så jeg gjorde litt mer research, det er en gammel 386; Hvis du er gammel som meg, kan du huske disse systemene. Og de var ikke så problematiske med tanke på hacking; det var ikke mange virus da. I disse dager er det et annet spill, så internett følger selvfølgelig med, og endrer alt. Alt henger sammen nå, det er et globalt publikum der ute, de første store virusene begynte å angripe, og virkelig hackingsindustrien begynte å ballong, helt ærlig.
Så skal vi snakke litt om IoT, har vi et godt spørsmål allerede fra et publikummedlem: Hvordan beskytter jeg IoT-enheter fra et sårbarhetssynspunkt? Det er et stort tema - helt ærlig, det er mye arbeid som blir lagt inn i det akkurat nå, i hvordan du takler potensialet for at IoT-enheter blir hacket. Det er mye bruk, de vanlige problemene du fokuserer på, passordbeskyttelse, for eksempel gjennomgå prosessen med å konfigurere det nøye, å sette ditt eget passord. Mange ganger vil folk bare legge igjen et standardpassord der inne, og det vil faktisk føre til sårbarheten. Så det er de grunnleggende tingene. Vi hadde nettopp et nytt show om sikkerhet tidligere denne uken, på radioprogrammet vårt, med flere eksperter der, og de sa alle at 80–90 eller flere prosent av hackingproblemer, enten det er IoT eller ransomware, eller hva som helst, ville bli unngått hvis du bare behandlet det grunnleggende, hvis du bare sørget for at du hadde dekket basene dine, gjorde du alle de grunnleggende tingene, som du vet at du skulle gjøre, som håndterer over 80 prosent av alle problemene der ute.
Så, tingenes internett, OK, IoT. Hvis du tenker på IoT, er det ikke så nytt. Helt ærlig er det high-end produsenter som gjør denne typen ting for 20 og 30 år siden, og så for rundt 15, 20 år siden, det var da RFID kom inn - identifikasjonsmerker for radiofrekvens - som hadde vært ekstremt nyttig for å hjelpe veldig store organisasjoner, som forhandlere, for eksempel rederier, ethvert produktfirma som flytter ting rundt om i landet, rundt om i verden, det er ekstremt nyttig å ha all den informasjonen. Du finner ut hvor tingene dine går; hvis noe forsvinner, finner du ut av det.
Det er selvfølgelig ikke en idiotsikker løsning, faktisk hadde jeg den bærbare datamaskinen min, Apple-en min bort fra, fra Atlanta-flyplassen - Atlanta Hartsfield Airport - noen tok bare vesken min, med datamaskinen min. Jeg trodde de ikke stjeler poser lenger; de finner alltid poser - galt. Noen stjal posen og så dukket den opp omtrent en måned senere, den våknet, jeg fikk en liten beskjed fra Apple fra iCloud om at den våknet omtrent syv til ti minutter sør for Atlanta Hartsfield Airport; noen bestemte seg for å gå inn på det. De hadde nettopp sittet på det i omtrent en måned, og jeg gikk gjennom den ganske frustrerende prosessen med å innse, vel, OK, jeg vet omtrent hvor det er, det kan være i dette huset, det huset, huset over gaten, den var der bare midlertidig. Hva gjør du? Som, hvordan er den informasjonen nyttig for deg?
Så selv om du lærer noe, kan du noen ganger ikke gjøre noe med det. Men likevel, denne IoT-aktiverte verdenen, jeg må si, jeg tror vi ikke er helt klare for det, for å være ærlig. Jeg tror vi har en sak der det er mye god teknologi der ute, og vi kan bevege oss for raskt for å dra nytte av disse tingene, fordi trusselen er så betydelig. Vi tenker bare på antall enheter nå som er en del av trusselbildet, mens folk snakker om det, er det en enorm, enorm bølge av enheter som kommer vår vei.
Noen av de store hacks som har skjedd nylig, og tok ned DNS-servere, hadde å gjøre med at IoT-enheter ble kooperert og dreid mot DNS-servere, bare klassiske DDoS-hacks, distribuert benektelse av tjenesten, hvor bokstavelig talt disse enhetene er omprogrammert til å ringe på en DNS-server i et forbløffende tempo, hvor du vil få hundretusener av forespørsler som kommer inn på denne DNS-serveren, og bare kveler og krasjer og dør. Det er den slags ting der historien om det store på et ikke-så populært nettsted serverne nettopp krasjet - de er bare ikke laget for den slags trafikk.
Så, IoT er bare noe å huske på, igjen, hvis vi har å gjøre med sikkerhetskopi og gjenoppretting, er det bare viktig å huske at noen av disse angrepene kan skje på et gitt tidspunkt. Og hvis du ikke er forberedt på det, vil du miste mange kunder, fordi du kommer til å gjøre mange mennesker veldig ulykkelige. Og du vil ha den omdømmeledelsen å takle. Det er en av de nye begrepene som har flust rundt der, "omdømmestyring." Det lønner seg å huske og sette pris på at omdømme kan ta år å bygge og minutter eller sekunder å kaste bort. Så bare husk det når du planlegger informasjonsstrategien.
Så da er det hele konseptet med hybridskyen. Jeg har fått en av mine gamle, favorittfilmer fra barndommen, Island of Dr. Moreau der, der de skapte disse halve dyrene, halve skapningene, det er litt som hybridskyen. Så de lokale systemene kommer til å være her i flere år - gjør ingen feil med det, det vil ta lang tid å avvikle de lokale datasentrene - og til og med i små bedrifter vil du ha en mye kundedata i systemene og stasjonene dine, og jo mer kompleks situasjonen blir, desto vanskeligere kommer det å være på topp. Når det er sagt, er det alltid en reell utfordring å konsolidere i en database, spesielt med et system som MySQL, for eksempel.
Å prøve å stappe alt inn i ett system har aldri vært veldig enkelt å gjøre. Vanligvis når det er gjort, er det problemer, du får ytelsesproblemer. Så igjen, det kommer til å være et problem ganske lenge nå. Legacy infrastruktur der ute i datasentre og i bedrifter, selvfølgelig. Det var problemet med WannaCry, er at du har alle disse XP-systemene - Microsoft støtter ikke XP lenger. Så det er bare ganske utrolig hvordan noen av disse problemene som blir så alvorlige og så smertefulle monetært og ellers kan unngås med grunnleggende vedlikehold og vedlikehold. Grunnleggende ting.
Så det kommer til å være et ferdighetsgap; disse ferdighetsgapene vil vokse over tid, fordi igjen, skyen er fremtiden - jeg tror ikke det er noen tvil om det - skyen er der ting går; det er allerede et tyngdepunkt i skyen. Og det du kommer til å se er flere og flere selskaper, flere og flere organisasjoner som ser til skyen. Så det vil etterlate noen kompetansegap på stedet-siden; den er ikke der ennå, men den kommer. Og til og med tenke på amortisering, så mange store selskaper, de kan ikke bare flytte til skyen - de kunne, men det ville ikke være mye fornuftig, kostnadsmessig, fordi de amortiserer alle disse eiendelene over tre, til fem, til syv år, kanskje.
Det skaper et ganske betydelig tidsvindu der de vil migrere bort fra på stedet og mot skymiljøet. Og ærlig talt har vi nådd poenget nå, hvor lokaler sannsynligvis er mindre sikre enn skyen. Artig morsomt, for det var det store dunket i lang tid: Bedrifter var bekymret for å gå til skyen av sikkerhetsmessige årsaker, de var bekymret for at skyen var utsatt for hacks. Vel, det er fremdeles, absolutt, men virkelig hvis du ser på de store gutta: Amazon, Microsoft, selv nå SAP og Google, alle disse karene, de er ganske flinke til det, de er ganske flinke til å sikre skyen seg selv.
Og så, selvfølgelig, endelig på forhånd, daterte systemer: disse applikasjonene kommer ganske raskt i tannen i disse dager. Jeg hørte en spøk en gang, definisjonen av gammel programvare er all programvare som er i produksjon. (Ler) Jeg synes det er litt morsomt. Så over til skysystemene, nevnte jeg de store aktørene, de vokser bare om dagen. AWS dominerer fortsatt den plassen, selv om Microsoft på æren deres virkelig har funnet ut noen ting og de er veldig fokuserte. Så er SAP, SAP HANA Cloud, det er HANA Cloud-plattformen de kaller det - det er et enormt fokusområde for SAP og av åpenbare grunner. De vet at skyen nå har tyngdekraft, de vet at skyen er et utmerket kampsportområde for teknologi.
Så det du ser er denne konsolideringen rundt skyarkitekturer, og du vil ha mye arbeid i løpet av de neste to årene med sky-til-sky-migrasjon. Til og med masterdatahåndtering på tvers av skyer kommer til å bli et stort problem. Og Salesforce - se hvor stor Salesforce har blitt - det er en absolutt styrke å regne med. Det er også et markedsføringssystem er i skyen; det er noe sånt som 5.000 markedsføringsteknologiselskaper nå - 5000! Det er vilt. Og du ser mer krefter på denne eneste ruten med glass for å kunne administrere miljøer med flere skyer. Så, et siste lysbilde fra meg, og så overleverer jeg det til Tep for å gi oss noen råd om hvordan vi kan holde oss foran spillet, her.
Dette, vi snakket om på radioprogrammet mitt tidligere denne uken, skymodellen med delt ansvar. Så det de snakker om er hvordan AWS hadde ansvaret for å sikre skyen, så sikkerheten til skyen. Kunne se databutikker, databasenettverk osv. Men kunden er ansvarlig for data og sikkerhet i skyen. Vel, det var morsomt fordi de bruker dette uttrykket “delt ansvar”, og det jeg slags samlet fra gjestene på showet vårt, er at det ikke egentlig deles i det hele tatt. Ideen er at det er ditt ansvar, fordi oddsen er at push kommer til å skyve og noen smitter miljøet ditt, AWS vil sannsynligvis ikke bli holdt ansvarlig, det er du.
Så det er litt av en merkelig verden, jeg synes det er litt av et duplisert begrep, “delt ansvar” fordi det virkelig er slags ikke, det er på det sterkeste ditt ansvar å holde seg oppå alle de tingene. Så med det, og jeg vet at jeg har snakket litt om IoT - vi hadde ett godt spørsmål om hvordan vi sikrer IoT-enheter - det kommer til å være et absolutt spekter av teknologier som kommer ut for å kunne takle det. Det er klart at du har programvare på firmware på IoT-enhetene selv, så det er noe du må huske på; du må bekymre deg for hvilken autentiseringsprotokoll du må bruke til det. Men som jeg sier, det grunnleggende, sannsynligvis kommer til å komme gjennom det meste av det du kommer til å møte, bare å gjøre passordbeskyttelse, gjøre endringer av passord og virkelig holde deg oppdatert - overvåke disse tingene og se på .
Mange av teknologiene som brukes til å overvåke svindel, for eksempel eller ubehagelige aktiviteter i nettverk, fokuserer virkelig på outliers, og det er noe maskinlæring faktisk er ganske bra på, ved å gruppere og se etter outliers, se etter rare atferdsmønstre. Som ærlig talt det vi så med dette nylige DDoS-angrepet på DNS-servere, der alle disse plutselig plutselig begynner å sende en tilbakeringing til en bestemt håndfull servere, vel, det ser ikke bra ut. Og ærlig talt, det jeg alltid minner folk om med disse systemene: Hver gang du har seriøs automatisering i slike miljøer, må du alltid ha den manuelle overstyringen, ha drepebryteren - du vil ha en slags kill-bryter programmert der inne for å stenge de tingene.
Så med det skal jeg skyve Tep sitt første lysbilde, han kommer til å gjøre noen demonstrasjoner for oss. Og så skal jeg gå videre og gi deg nøklene til WebEx-fanen. Nå kommer det din vei og tar den bort.
Tep Chantra: OK, takk, Eric. Jeg heter Tep Chantra, og jeg er produktsjef her på IDERA. I dag ønsket å snakke om IDERAs enterprise backup-løsning, nemlig SQL Safe Backup. For de av dere som er kjent med SQL Safe Backup, la oss ta en rask titt på noen høydepunkter i produktet som - unnskyld. Så som du kanskje allerede har gjettet, sier folk sikkerhetskopiering, SQL Server-sikkerhetskopi og gjenoppretting av produkt, en av nøkkelfunksjonene i SQL Safe er muligheten til å utføre raske sikkerhetskopieringer. Og det er en viktig funksjon, gitt at de fleste sikkerhetskopier må gjøres, og i de fleste tilfeller må de gjøres veldig raskt, i et lite tidsvindu.
I noen miljøer kan det være en utfordring å møte disse sikkerhetskopiene, spesielt når du har flere store databaser som må sikkerhetskopieres. SQL Safes evne til å fullføre sikkerhetskopieringsoperasjonene gjør at sluttbrukere raskt kan være i stand til å møte disse backup-vinduene. Apropos store databaser, sikkerhetskopiere de store databasene, åpenbart større sikkerhetskopifiler. En annen funksjon der SQL Safe lyser, er muligheten til å komprimere sikkerhetskopifiler. Komprimeringsalgoritmen som brukes kan oppnå opptil like 90–95 prosent komprimering. Dette betyr at du kan lagre sikkerhetskopier lenger, eller tillate kostnadsbesparelser når det gjelder lagringsbehov.
På baksiden av sikkerhetskopieringsoperasjonene har du gjenopprettingsoperasjoner. En av kampene som DBA må kjempe for å gjenopprette databaser er at disse databasene må gjenopprettes så raskt som mulig. I tilfeller av store databaser kan en full gjenoppretting av en sikkerhetskopifil ta flere timer, noe som åpenbart betyr lengre driftsstans, og muligens tap av inntekter. SQL Safe har heldigvis denne funksjonen kalt “Instant Restore”, som i utgangspunktet kutter tiden mellom når du starter en gjenoppretting og til databasen kan nås av sluttbrukere eller til og med applikasjoner.
Jeg husker at jeg snakket med en kunde en gang, hvor han rapporterte at gjenoppretting av en bestemt database hadde tatt 14 timer. Men med funksjonen for øyeblikkelig gjenoppretting var han i stand til å få tilgang til databasen i løpet av en time eller mindre. Retningslinjebasert styring, et annet høydepunkt i SQL Safe, er muligheten til å opprette policyer og administrere sikkerhetskopieringsoperasjonene dine gjennom disse policyene. Når du konfigurerer en policy, definerer du i utgangspunktet hvilke forekomster som skal sikkerhetskopieres eller hvilke databaser på disse instansene som skal sikkerhetskopieres, hva slags sikkerhetskopieringsoperasjoner som skal utføres, og til og med tidsplanen for hvilke sikkerhetskopieringen skal skje.
I tillegg kan du også konfigurere varslingsvarsler. På den måten kan du bli varslet om hendelser som sikkerhetskopien er fullført, sikkerhetskopiene mislyktes, kanskje den kunne se dette, men det er noen advarsler knyttet til den operasjonen. Du vil også bli varslet hvis en sikkerhetskopi ikke ble kjørt som planlagt. Det er en viktig varsling, fordi du kanskje kan risikere et tidsvindu der en sikkerhetskopi ikke eksisterte. Og å motta en slik varsling vil indikere for deg at du trenger å gå ut dit og gjøre det sikkerhetskopien kjøres og deretter eventuelt gjøre noen undersøkelser om hvorfor den sikkerhetskopien ikke kjørte som planlagt.
Noen av de andre tingene, la oss se her, feiltolerant speiling, betyr det egentlig at vi har muligheten til å lage dupliserte sikkerhetskopifiler på mer enn ett sted. Så for eksempel, la oss si at du har en måldestinasjon som primær - hva hovedlageret er, hvor alle sikkerhetskopifilene dine går. Imidlertid kan det hende du trenger å ha en kopi av den samme sikkerhetskopifilen for eksempel på den lokale maskinen, bare i tilfelle du trenger å gjøre noen ekstra tester, må du sørge for at databasen kan gjenopprettes, uansett hva tilfellet måtte være. SQL Virtual Database Optimize - hva det egentlig er, er at vi har et annet produkt som nylig ble integrert i SQL Safe, kalt SQL Virtual Database.
Som jeg nevnte, er det nylig integrert, og det er faktisk inkludert i selve SQL Safe. Det SQL Virtual Database egentlig lar deg gjøre, er å faktisk lage en virtuell database. (Ler) Jeg hater å bruke de samme begrepene som definisjonen, men det som egentlig skjer er at vi vil montere en database og ta utgangspunkt i sikkerhetskopifilen. Så det som egentlig skjer er at SQL Server mener at databasen faktisk er i gang, mens den faktisk leser data fra sikkerhetskopifilen, i stedet for å opprette selve databasen i filsystemet.
Dette er veldig nyttig fordi det lar deg få tilgang til dataene som er i sikkerhetskopifilen uten å faktisk kreve ekstra diskplass, så det kommer veldig godt, spesielt når du har å gjøre med enorme databaser som du bare trenger å få, kan du se raskt, eller gjør noe dev arbeid med. Nullvirkningskryptering - hva det egentlig betyr er at der vi utfører sikkerhetskopier av disse databasene, kan vi faktisk kryptere sikkerhetskopifilene, og når vi krypterer disse sikkerhetskopifilene, legger vi ikke til noen ekstra belastning på den faktiske ytelsen til systemet. Så det er helt ubetydelig. Loggfrakt er en annen ting vi kan gjøre, der retningslinjene våre, som jeg nevnte tidligere, og med hensyn til den fordelaktige lisensen - det det egentlig betyr er at lisensmodellene våre lar deg flytte lisensmodeller fra en instans til en annen instans, med noen få enkle museklikk.
Gå videre, la oss ta en rask titt på arkitekturen til selve produktet. Så det er i utgangspunktet fire hovedkomponenter til produktet. Vi starter fra venstre, SQL Safe Management Console og Web Console. Begge disse er i hovedsak brukergrensesnitt, den ene er desktop-klienten og den andre er en webapplikasjon. Begge disse brukergrensesnittene henter data fra neste komponent, som er SQL Safe Repository Database. Lagringsdatabasen lagrer i utgangspunktet all din driftshistorie, alle sikkerhetskopierings- og gjenopprettingsoperasjoner. Disse detaljene lagres her. Alle disse dataene som er i depotet administreres av SQL Safe Management Service, som er den neste komponenten. Management Service er ansvarlig for å oppdatere depotdatabasen og sende varslingsvarsel. Dataene om sikkerhetskopierings- og gjenopprettingsoperasjoner kommer faktisk fra SQL Safe Backup Agent, som er den siste komponenten, helt til høyre.
SQL Safe Backup Agent er en komponent som er installert på alle serverne som er vert for SQL Server-forekomster som du prøver å administrere med SQL Safe. Og dette er tjenesten som faktisk er ansvarlig for å utføre sikkerhetskopiene og komprimere dem. Nå, på dette lysbildet, er det også en femte komponent, som ikke er helt nødvendig, men det er en fin ting å ha. Og det er våre SQL Server Reporting Services RDL-filer. Hva dette i utgangspunktet lar deg gjøre er å distribuere noen RDL-filer til SQL Server Reporting Service, slik at du kan kjøre rapporter mot databasen vår. Og vi har en rekke forskjellige rapporter som forrige gang sikkerhetskopien din kjørte, detaljer angående sikkerhetskopieringsoperasjoner, hva har du.
Og unnskyld. La oss ta en titt på SQL Safe selv. Gi meg et sekund her. Og gi meg et sekund å logge på. Som du ser, jeg har lastet inn akkurat nå er webapplikasjonen, men først vil jeg faktisk gjerne se på desktop-applikasjonen. Så la meg skyte veldig raskt. Og dette er SQL Safe-skrivebordsapplikasjonen, når den først lastes inn tar den deg til visningen SQL Safe i dag. Dette er i hovedsak en liste over alle sikkerhetskopieringsoperasjoner eller gjenopprettingsoperasjoner som har skjedd i dag. Det gir deg også en rask status for miljøet ditt, som du kan se her, står det at policyene mine har en policy, som er i en OK tilstand, noe som er bra, fordi jeg bare har en policy, og jeg håper at det er ikke . Gir deg også et sammendrag av operasjoner som var vellykkede, alle operasjoner som kan ha mislyktes. Totalt sett er jeg i god form: Bare ved å ta en rask titt, kan du se alle greener; vi er flinke til å gå.
Til venstre her kan du se alle serverne du har registrert med SQL Safe, og de som du i utgangspunktet administrerer. Hvis du utvider den, får du se listen over databaser på det systemet. Hvis du velger en bestemt database, kan du se driftshistorikken for den aktuelle databasen. Det er ikke mye mer å forklare, annet enn at du kan gå videre og utføre ad hoc-sikkerhetskopier fra dette vinduet, og det er virkelig raskt og enkelt. Og la meg demonstrere det for deg veldig raskt. Du høyreklikker bare på den og velger operasjonen du vil gjøre. Og for dette formålet vil jeg gå videre og velge sikkerhetskopidatabase. Og SQL Safe Backup Wizard åpnes. Herfra får du dette, for eksempel hvilken forekomst du vil utføre sikkerhetskopien mot, og velge hvilke databaser du vil sikkerhetskopiere. I dette tilfellet valgte jeg forhåndsvalgt HINATA-maskinen og Contoso Retail-databasen, fordi det var det jeg hadde fremhevet da jeg valgte alternativet. Jeg vil gå foran og la det være nå, men du har muligheten til å faktisk velge flere databaser, slik at hvis du vil sikkerhetskopiere all brukerdatabasen din for eksempel, kan du velge denne alternativknappen, og den vil forhåndsvelge alle de. La meg gå videre og fortsette med det.
Videre til neste side av veiviseren. Det er her jeg kan velge sikkerhetskopieringstypen jeg vil utføre, og du har en rekke forskjellige alternativer her. Det er - jeg er sikker på at du finner alle sikkerhetskopieringsverktøyene, for eksempel kan du utføre en full sikkerhetskopi, differensiell sikkerhetskopi, transaksjonslogg-sikkerhetskopi, eller du kan bare bare ta sikkerhetskopi av selve databasen. Du har også mulighetene til å lage en bare kopi som bare er kopi, som i utgangspunktet brukes når du ikke vil rote med LSM-ene. Jeg skal velge “nei” for nå. Og du har også muligheten til å bekrefte sikkerhetskopien etter at sikkerhetskopien er fullført - på den måten sørger du for at sikkerhetskopien er god og kan brukes senere. Det er alltid en av de funksjonene du vil forsikre deg om at du har, bare for å gi deg litt sikkerhet for at sikkerhetskopien er brukbar.
Her finner du navn og databeskrivelse. Dette er egentlig metadata som du enkelt kan hjelpe deg med å identifisere hva sikkerhetskopien ble brukt til, så jeg vil si demo formål her. Og bruk databasens sikkerhetskopi for demo. Deretter definerer vi hvor vi vil lagre sikkerhetskopifilen vår til, og du har flere forskjellige alternativer her: Du kan lagre den i en enkelt fil, du kan opprette stripefiler, du har muligheten til å velge her målet, vi støtter også datadomen. Og det, Amazon ST sky, i tilfelle det er der du vil lagre informasjonen din.
Jeg vil fortsette med den eneste filen for denne demonstrasjonen, dette muliggjøre nettverkssikkerhet, dette er en veldig fin funksjon innen SQL Safe i den forstand at hvis du tar sikkerhetskopi til et nettverkssted - det er det jeg gjør her, kan du se fra det primære arkivet - hvis du tar sikkerhetskopi til nettverksplassering, er det stor sjanse for at du kan støte på noen nettverkshikke. I noen tilfeller hvis nettverkshikke blir motarbeidet, vil sikkerhetskopieringsoperasjonen bli fullstendig utsolgt. Vel, aktiver nettverkssensibilitet, hva det egentlig gjør er hvis det oppstår et nettverk hikke, hva SQL Safe egentlig gjør, er det pauser sikkerhetskopien og venter på en bestemt tid og prøver nettverksplasseringen på nytt. Og hvis den er i stand til å koble seg til, vil den bare gjenoppta sikkerhetskopien rett der den slapp. På den måten bruker du ikke timer om gangen på å prøve å kjøre denne sikkerhetskopien, og når det er nær slutt, har det oppstått et nettverkshikle - vi selger ikke operasjonen med en gang, vi bare venter litt og prøver å fullføre det igjen.
Det er noen andre alternativer når du konfigurerer dette. Nå medfører det i utgangspunktet intervallet som vi prøver på nytt, så i denne forstand, hvis vi støter på et nettverkshygge, vil det prøve å få tilgang til nettverksplasseringen igjen om ti sekunder. Det andre alternativet her forteller deg i utgangspunktet at hvis vi støter på nettverkshikke for, står det 300 sekunder her - så hva, fem minutter, totalt - så selger vi bare sikkerhetskopien. Og det er fem minutter i rekkefølge, så det er hvis vi prøver igjen og igjen og i løpet av de fem minuttene kan vi fremdeles ikke gjenopprette nettverkstilkoblingen, så vil vi selge driften fullstendig. Denne aller siste operasjonen her er i utgangspunktet for hele varigheten av sikkerhetskopien, så hvis du mister ti sekunder her, gjenoppretter tilkoblingen og deretter mister forbindelsen igjen, hvis den i utgangspunktet gjentas i 60 minutter, så vil den operasjonen bli utsolgt. Og disse er konfigurert, som du kan se, slik at du kan skreddersy den til ditt miljø.
Dette speilarkivalternativet akkurat her, dette er det jeg snakket om tidligere, og hadde feiltolerant speiling. Det er her du kan spesifisere en annen backup-plassering, i tilfelle du noen gang skulle ønske det. Jeg kommer til å la dette være avkrysset akkurat nå, for bare jeg vil fortsette og fortsette. I disse alternativvinduene kan du definere ting som din type komprimering som vi ønsker å bruke for denne sikkerhetskopieringen, og om vi vil aktivere kryptering for sikkerhetskopifilen eller ikke. Vi tilbyr en rekke forskjellige alternativer for komprimering, også ingen, hvis du velger at du ikke vil ha noen komprimering i det hele tatt. Så det er bare å raskt gå gjennom disse alternativene.
Høy hastighet prøver i utgangspunktet å fullføre sikkerhetskopien så raskt som mulig, mens du inkluderer en viss komprimering. ISize er mer fokusert på å ta med så mye komprimering som mulig, men det kan - fordi vi prøver å komprimere det så mye - det kan ta litt lengre tid, og sannsynligvis bruke litt mer CPU. Nivå 1 betyr egentlig den minste mengden komprimering helt til nivå 4, den mest mengden komprimering som vi kan legge til. Så dette er litt mer detaljert, iSpeed typisk - hva er ordet? Spenner fra kompresjon mellom nivå 1 og nivå 2; det tar en titt på systemet ditt for å se hvor mye CPU og tilgjengelige ressurser som er tilgjengelige og gjør vurderinger på mye komprimering, den skal bruke mellom nivå 1 og nivå 2.
ISize gjør det samme, bortsett fra med Nivå 3 og Nivå 4. Det er noen andre avanserte alternativer her, som hvor mange det er på CPU-en vi skal bruke, her er alternativet for å lage kartdata for SQLs virtuelle database og også vår øyeblikkelig gjenopprettingsfunksjon. Du kan inkludere database-pålogginger, og noen andre alternativer som noen brukere synes er veldig verdifulle, så som å generere sjekker fra dette, slik at de senere kan sjekke det for å sikre at sikkerhetskopifilene er gode. Hvis vi fortsetter til neste side, er det her du konfigurerer varslene dine. Og du kan se de forskjellige alternativene vi har her: gi beskjed om sikkerhetskopien mislykkes, varsle om sikkerhetskopien er hoppet over, uansett grunn. Hvis sikkerhetskopien avbrytes, eller hvis sikkerhetskopien fullføres med advarsel, og hvis du ønsker det, kan du bli varslet om at sikkerhetskopien din er ren. For miljøer der et stort antall databaser, det er kanskje ikke noe du vil aktivere, bare fordi det er mer sannsynlig at sikkerhetskopien din vil lykkes, og du vil bli oversvømmet av e-post.
På neste side kan du se et sammendrag av hva du har definert, fordi denne sikkerhetskopieringen. Og hvis du ønsker det, hvis alt ser bra ut, kan du gå videre og klikke sikkerhetskopi, sparker vi det av. Før jeg klikker på sikkerhetskopi, la meg gå foran og vise deg denne “generere skriptet” -knappen. Fordi det SQL Safe tilbyr et kommandolinjegrensesnitt der du faktisk kan starte en sikkerhetskopi eller gjenopprette operasjon, hva har du, gjennom en kommandolinje, DOS-ledetekst. Hvis du klikker på genereringsskriptet her, gir det i utgangspunktet det faktiske skriptet du kan bruke, hvis du ville ta sikkerhetskopien fra kommandolinjen.
En annen fin ting er at vi også tilbyr utvidede butikkprosedyrer, og i dette tilfellet genererer vi et skript for deg som vil utføre nøyaktig den samme sikkerhetskopieringsoperasjonen ved å bruke utvidede butikkprosedyrer - bare en liten kjapp tidbit som jeg ville dele. Så la oss gå og sparke av denne sikkerhetskopien. Og du kan se at sikkerhetskopien allerede er startet. Og denne databasen er litt stor, så det kan ta litt tid. Du kan se at jeg løp noen ganger her, tidligere, så det kommer til å ta meg hvor som helst fra ett minutt til tre minutter. Dette er et nivå 4, så jeg antar at det kommer til å være mellom disse to gangene.
Mens dette kjører, la oss ta en rask titt på retningslinjene. Som jeg nevnte tidligere, lar retningslinjer deg konfigurere planlagte sikkerhetskopieringsoperasjoner på tvers av bedriften, så jeg har en policy her, forhåndskonfigurert og heller enn å opprette en ny, la oss gå videre og ta en titt på detaljene til denne. Beklager, VM-en kjører på min personlige bærbare datamaskin, og det ser ut til å kjøre viften ganske hardt. (Ler)
Eric Kavanagh: Det er bra - du vet, jeg hadde tenkt å stille deg et spørsmål mens vi ser på dette her. Bruker IDERA mye endring av datafangst når det gjelder sikkerhetskopiering, eller gjør du hele sikkerhetskopier hver gang? Hvordan fungerer det, vet du?
Tep Chantra: Si det en gang til, jeg beklager?
Eric Kavanagh: Ja, så vet du om IDERA bruker CDC, endrer datainnsamlingsteknologi for å gjøre mindre sikkerhetskopier, eller gjør det full sikkerhetskopi hver gang?
Tep Chantra: Jeg tror ikke det. Jeg husker at jeg har sett det tidligere på en rekke billetter. Og hvis jeg husker riktig, nei, vi utnytter ikke CDC, vi er for å være ærlige, i utgangspunktet lar vi SQL Server utføre sikkerhetskopien, vi tar bare dataene imellom og komprimerer dem, noe som resulterer i en sikkerhetskopifil blir opprettet. Så ved å bruke det. Yeah.
Så nå som jeg har lastet politikken min - å, jeg beklager, hadde du et annet spørsmål?
Eric Kavanagh: Nei, det er det. Gå videre.
Tep Chantra: OK, så nå som jeg har lastet policyen din, kan du se noen raske ting her: navn, beskrivelse, du kan angi hva slags policy du skal lage, enten det er en policy som skal styres, planen vil bli administrert av SQL Server Agent, eller planen vil bli administrert av SQL Server Backup Agent. I de fleste tilfeller vil du bruke SQL Server Agent, fordi det vanligvis er noe som kjører uansett på systemet ditt, så kan like godt utnytte det som er tilgjengelig for deg. På medlemskapsfanen er det her du spesifiserer forekomstene i sikkerhetskopidatabasene du vil sikkerhetskopiere. Og i dette tilfellet kan du se at jeg har lagt til alle mine registrerte forekomster, og jeg har spesifisert en spesifikk database som skal sikkerhetskopieres. Hvis jeg nå ville, kunne jeg gå videre og redigere disse og si: "Jeg vil sikkerhetskopiere alle databasene eller bare brukerdatabaser, eller til og med systemdatabaser." Det fine med dette er at jeg også kan bruke jokertegn og lage visse databaser.
Jeg har ikke tenkt å gjøre den endringen her, bare fordi jeg ikke vil gjøre noen store endringer i innstillingene mine. Så la oss gå tilbake til alternativene. Og på alternativene, er det her du definerer hva slags sikkerhetskopier du skal utføre, og hvis du tar en titt her, har jeg full sikkerhetskopi, differensial sikkerhetskopi og store sikkerhetskopier konfigurert. Og for hver av disse sikkerhetskopiene, kan jeg definere om jeg vil bruke en bestemt mengde komprimering eller slå på krypteringen. Akkurat som alternativene du ville funnet i ad hoc-veiviseren. Og på steder kan du også definere destinasjonen for disse sikkerhetskopieringsoperasjonene. Noe av det gode med policyene er at du også kan definere om du vil gå foran og slette de gamle sikkerhetskopifilene, basert på X antall dager eller uker, hva har du.
Og det er konfigurerbart for hver sikkerhetskopitype. Så du kan se her, jeg har mine fulle sikkerhetskopier å slette etter en uke. Min differensielle sletting etter to dager, og jeg vil at sikkerhetskopiene mine skal slettes etter en dag. Dette er virkelig fint, fordi det automatiserer håndteringsscenario, gamle sikkerhetskopifiler, og holder bare de du virkelig trenger, basert på tid. Neste side du definerer timeplanen, og igjen, kan planen være spesifikk for hver type sikkerhetskopiering du skal fullføre, så for fullt, jeg kjører den ukentlig, og min differensial kjører jeg den hver sjette time, loggene jeg kjører hvert 30. minutt. På neste side er der du konfigurerer varsler, og det er egentlig de samme varslingstypene du har funnet i ad hoc-sikkerhetskopi. Den ene forskjellen er at du har dette nye, andre alternativet der det kan fortelle deg om sikkerhetskopien ikke klarer å starte som planlagt. Det er her du kan bli varslet om situasjoner der sikkerhetskopiene ikke kjørte. Virkelig viktig, spesielt i tilfeller hvor du har visse SLA-er for å forsikre deg om at du har sikkerhetskopier tilgjengelig på de tidspunktene du trenger dem. Og neste side kan du se sammendraget. Hvis jeg hadde gjort noen endringer, hvis jeg klikket på ferdig, ville den gå ut og gjøre disse endringene, lagre den og for eksempel lagre den i depotet til SQL Server Agent-jobber.
Og bare for å vise deg virkelig rask, her er en policy og en jobb som jeg opprettet for den aktuelle politikken. Og du kan se at det ble laget tre forskjellige jobber: en for hver sikkerhetskopitype. La meg ta en rask titt på HUD-grensesnittet og slags - som jeg nevnte tidligere, virtuell database som vi tidligere har integrert i SQL Safe. Som jeg nevnte, narrer det i utgangspunktet SQL Server til å tro at en faktisk database er blitt gjenopprettet når vi i virkeligheten bare leser sikkerhetskopifilen. Så la meg gå foran og ikke en virkelig rask for dere. La meg ta en sikkerhetskopifil. La meg ta en fire her. Prosessen er fullført, og veldig rask, hvis jeg oppdaterer databasene mine her, kan du se at databasen er tilgjengelig og SQL Server tror den er live, men i virkeligheten, leser vi bare dataene fra databasen.
Noen andre funksjoner som er nye for denne utgivelsen, er muligheten til å utføre sikkerhetskopier ved å bruke det nyeste backup-formatet. Det er veldig praktisk for de kundene som trenger å benytte seg av vår policybaserte styring, men de vil beholde SQL Server-filformatet uansett grunn. Nå, jeg vet at vi har tom tid, så jeg tror jeg vil fortsette og stoppe denne presentasjonen, bare slik at vi kan ta noen spørsmål, eller hva ikke.
Eric Kavanagh: Ja, helt sikkert. Så jeg tror en av nøklene egentlig er i policy management, ikke sant? Som i å tenke på den optimale politikken og hva baserer du det på? Det er klart det i noen tilfeller er forskrifter å bekymre deg for, men i en virksomhet er det kanskje ikke veldig regulert; trenger du bare å finne de optimale tidene for sikkerhetskopiering, og da tipper jeg at du får noen rapporter om hvor lang tid det tok og hvor dyrt det var med tanke på beregningskraft og så videre. Hva går ut på å definere den optimale politikken?
Tep Chantra: Det er virkelig tilfelle, hvert miljø vil ha en annen policy når det gjelder når disse sikkerhetskopiene skal kjøres. Også, og det kan innebære den type sikkerhetskopier som kjører, tidsplanen de kjører til, og det avgjør virkelig, virkelig også avhengig av gjenopprettingsbehov, antar jeg, det er svaret.
Eric Kavanagh: OK, ja. Og du snakket om å kunne gjøre forskjellige typer sikkerhetskopier og striper var et av alternativene. Er det for slags varme og kalde data, eller hva er logikken bak å gå stripe, i motsetning til noen annen metode?
Tep Chantra: Så jeg tror det beste svaret jeg kan gi for det, er at så, stripete filer, det vi egentlig gjør er å skrive backupinnholdet over en rekke forskjellige filer. Jeg tror tanken med å bruke stripete filer er at du muligens kan skrive sikkerhetskopifilene dine raskere, på den måten. For eksempel kan du ha hver annen fil til et annet sted. Det koster serveren sikkerhetsmidler også, siden du distribuerer sikkerhetskopifilene dine til forskjellige steder.
Eric Kavanagh: Og det er noen kule, nye ting når det gjelder gjenopprettingsegenskaper, ikke sant? For la oss si at det er en slags hendelse, enten det er en naturkatastrofe eller ransomware, uansett hva tilfellet måtte være. Du trenger ikke bare å ha ett alternativ for å gjenopprette, ikke sant? Kan du sette prioriteringer på hva som blir gjenopprettet og hva slags data? Kan du snakke om alternativene der?
Tep Chantra: Vel, når det gjelder gjenoppretting, nevnte jeg tidligere at vi gir muligheten til å utføre øyeblikkelig gjenoppretting, noe som i utgangspunktet får brukere til dataene raskere, ikke sant? Og bare for å demonstrere, gjorde jeg en tidligere, så du kan se her, at igjen, denne databasen er ikke veldig stor, dette er den som kjører på den bærbare datamaskinen min. Så jeg tror det kanskje er som to spillejobber i størrelse, men denne databasen fullførte i løpet av 37 sekunder. Faktisk gjenoppretting. Så det tok meg 37 sekunder før jeg kunne få tilgang til dataene mine, så med øyeblikkelig gjenoppretting kunne jeg få tilgang til databasen min i løpet av to sekunder. Så du kan forestille deg hvordan den ville se ut hvis databasen din var mye større.
Eric Kavanagh: Ja, bra poeng. Og selvfølgelig snakket vi om dette før showet; du har brukt mye tid på frontlinjene med å støtte folk og deretter flyttet over til produktstyringsområdet, så det er litt av en annen utfordring, antar jeg. Men du var i frontlinjen - jeg synes det er et ganske bra sted å lære hvor folk går galt og hva noen av problemene er. Hva ser du på som noen av de mer vanlige fallgruvene, som folk kan unngå hvis de bare tenker gjennom disse tingene bedre?
Tep Chantra: Noen av de vanlige fallgruvene er bare - jeg antar som du nevnte tidligere - å planlegge sikkerhetskopiene dine. Det har vært tider hvor jeg har sett at folk prøver å utnytte, for eksempel våre retningslinjer, retningslinjer, retningslinjer du utfører mange sikkerhetskopier og baserer det på LSM. Og i noen tilfeller har jeg sett at noen mennesker også har noen andre verktøy som utfører sikkerhetskopier på databasene sine, og som faktisk ødelegger retningslinjene for loggforsendelse, fordi sikkerhetskopier blir gjort i det vesentlige utenfor SQL Safe, og vi er ikke klar over dem. Det er hovedsakelig bare å planlegge ting fremover, det er der fallgruven kommer fra.
Eric Kavanagh: Overrasker meg ikke. Vel, folkens, dette har vært en flott gjennomgang av noe av blokkeringen og taklingen som er nødvendig for å holde bedriften lykkelig, for å holde kundene glade. Jeg vil rette en stor takk til alle, Tep Chantra fra IDERA, stepper inn her, gjør noen live-demoer, det er alltid interessant - det er alltid litt risikabelt å gjøre live-demoen, men jeg synes det gikk ganske bra. Du vet, det er grunnleggende ting, men det er sånt der hvis du ikke gjør det, vil du få alle slags problemer. Så dette er de viktige tingene som selskaper har noen mennesker gjør.
Så Tep, takk for tiden din. Folkens, vi arkiverer alle disse webcastene for senere visning, så vanligvis kan du komme tilbake innen en time eller to og sjekke ut arkivet. Men igjen, gode ting her, vi prøver å hjelpe bedriften med å holde seg oppdatert. Vi setter pris på all din tid og oppmerksomhet, folk der ute. Vi tar deg opp neste gang. Du har hørt på Hot Technologies. Ta vare, folkens. Ha det.
