Hjem Sikkerhed Skudsikker: hvordan dagens forretningsførere forbliver på toppen

Skudsikker: hvordan dagens forretningsførere forbliver på toppen

Anonim

Af Techopedia Staff, 7. juni 2017

Takeaway: Værten Eric Kavanagh diskuterer sikkerhedskopiering og gendannelse med IDERAs Tep Chantra i denne episode af Hot Technologies.

Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.

Eric Kavanagh: OK, mine damer og herrer, det er onsdag kl. 04 øst for dem, der er på virksomheds-teknologirummet, ved du hvad det betyder: Det er tid for Hot Technologies. Ja bestemt. Mit navn er Eric Kavanagh, jeg vil være din moderator for dagens begivenhed med titlen ”Skudsikker: Hvordan dagens forretningsledere forbliver på toppen.” Og folkens, vi har en dejlig, intim samtale her i dag; det bliver Tep Chantra, og din er virkelig vært for denne samtale. Vi skal tale alt om en række forskellige ting, herunder gendannelse af katastrofe, sikkerhedskopiering og gendannelse, men det udtryk, jeg gerne vil bruge i disse dage, er faktisk datagrebstabilitet - det hørte jeg fra en herre for bare et par uger siden, og det giver virkelig meget mening. Fordi det taler til, hvor vigtigt det er at have en elastisk informationsinfrastruktur under din virksomhed.

Dette er informationsøkonomien i disse dage, hvilket betyder, at de fleste virksomheder i en eller anden forstand er afhængige af informationsaktiver på data. Jeg mener, selv detailfirmaer, endda hardwarefirmaer, virkelig enhver form for organisation i disse dage vil have en form for informationsryggraden, eller i det mindste de vil, hvis de er i den moderne tidsalder, hvis du vil. Der er nogle mor- og popbutikker, som stadig kan undgå de ting, men selv der, begynder du at se en meget mere udbredelse af informationssystemer, mange af dem skybaseret, ærligt, men mange af dem stadig på præmis, til at håndtere kundetransaktioner, holde øje med tingene, for at vide, hvad dine kunder vil have, for at vide, hvad beholdningen er, for at vide, hvad det var, at være i stand til at forstå det store billede - det er virkelig vigtige ting i disse dage.

Altså, datagens elasticitet er et udtryk, jeg gerne vil bruge; redundans er et andet udtryk, der kommer til at tænke på. Men du vil sikre dig, at uanset hvad der sker, vil dine medarbejdere og din organisation have de oplysninger, den har brug for for at betjene dine kunder. Så jeg kommer til at gå igennem, lige ved at indramme argumentet, før Tep træder ind og forklarer os nogle af de ting, som IDERA har foregået. Naturligvis har IDERA lavet en hel del webcasts med os i det sidste år eller deromkring. Det er en meget, meget interessant virksomhed, de er fokuseret på nogle af messingstikkerne og blokerer og tackler om nødvendigt for at overleve i informationsøkonomien. Vi dykker lidt ind.

Skudsikker infrastruktur - det er faktisk et gammelt billede af en mainframe, se på det, det er som i begyndelsen af ​​1960'erne fra Wikipedia. Du tænker over vejen tilbage da mainframe-dage var ikke mange adgangspunkter til mainframes, så sikkerhed var slags let, backup var temmelig ligetil, du kunne forstå, hvad der skulle gøres, du var bare nødt til at gå ind og gøre det. Selvfølgelig var der ikke så mange mennesker, der vidste, hvad de skulle gøre, men dem, der gjorde, det var temmelig klart, hvad du havde at gøre. Og der var ikke for meget bekymring over det. Du havde det lejlighedsvise problem, men det var virkelig ikke så almindeligt.

Tilbage i dagen var det her ret let - i dag, ikke så meget. Så her er billedet - det er faktisk Hercules, der kæmper mod Hydra lige der. For dem af jer, der ikke er store med mytologien, var Hydra en meget irriterende væsen, idet den havde flere hoveder, og hver gang du hakkede en af ​​dem, kom to mere op på stedet, så det taler slags til udfordringen fra at håndtere nogle af de problemer, du finder i livet, specifikt i denne sammenhæng, var virkelig rettet mod onde fyre. Du tager en ond fyr ud, to mere dukker op i deres sted. Og du ser det slags i hackingverdenen, helt ærligt, det er en stor industri i disse dage, og det er bare en af ​​de store udfordringer, som vi står overfor.

Så du tænker over, hvis du forsøger at kortlægge din strategi for datadygtighed, hvad skal du bekymre dig om? Der er mange ting at bekymre sig om: katastrofer, brande, oversvømmelser. Jeg tilbragte meget tid i Syden og New Orleans har selvfølgelig nogle interessante historier om orkaner og oversvømmelser osv. Og mange gange kommer menneskelig fejl ind i stykket, kommer ind i billedet, skulle jeg sige. Og det var tilfældet også i Katrina i New Orleans, fordi ja, en orkan kom igennem, det er en handling fra Gud, som de siger, en force majeure . Men ikke desto mindre var det menneskelig fejl, der førte til orkanen, der resulterede i flere af brud på afgifterne. Så der var tre af dem, faktisk var der en på industrikanalen, og problemet med at der er et skib, var ikke blevet fortøjet ordentligt, ned ad floden. Og orkanen kom ind og skubbede den fra fortøjningspladsen, og den trådte faktisk nålen, der gik rundt om svingen, hvor floden bøjede ind lige uden for New Orleans, og den gik lige ned ad industrikanalen og styrtede ned gennem en af ​​disse mure. Så selvom ja, det var en naturkatastrofe, var det stadig menneskelige fejl, der resulterede i det enorme problem.

Og det samme skete på den anden side af byen, hvor der var et afsnit af afgiften, der aldrig var blevet afsluttet, tilsyneladende fordi byen og hærens korps af ingeniører aldrig var enige om, hvem der skulle betale for det. Det kræver ikke en raketforsker at finde ud af, at hvis du har et stort gapende hul i din afgift, er det ikke en meget effektiv afgift. Og så, pointen er, at menneskelig fejl virkelig spiller ind i scenariet, hvor katastrofen rammer. Så selvom det er ild, eller hvis det er en oversvømmelse, eller hvis det er et jordskælv, eller hvad end det er tilfældet, er der sandsynligvis noget, som nogen kunne have og burde have gjort for at forberede sig til en sådan begivenhed. Og det er selvfølgelig, hvad vi traditionelt kalder katastrofegendannelse. Så ja, katastrofer forekommer, men mennesker skal virkelig se igennem disse ting og forberede sig i overensstemmelse hermed. Vi taler lidt om det i dag med Tep.

Så utilfredse medarbejdere - undervurder ikke den skade, som en utilfredse medarbejder kan gøre - de er derude, de er overalt. Jeg kender folk, der har fortalt mig historier om bare virkelig ubehagelige ting, der er sket, hvor folk bare gør dårlige ting, de saboterer med vilje deres egen organisation, fordi de er ulykkelige. Måske fik de ikke en forhøjelse, eller de blev fyret, eller hvem ved hvad der skete. Men det er noget man skal huske på, og det er en meget betydelig komponent. I tilfælde af licens, også, som en FYI derude, folk. En af de statistikker, jeg hørte, var noget i retning af 60 procent af alle tip, som softwarevirksomheder får til manglende betaling af licensgebyrer kommer fra tidligere ansatte. Så du vil være sikker på, at du har købt den software, og at du fik den fair og firkantet. Corporate sabotage sker ikke hele tiden, men det sker. Problemer med fortrolighed kommer også ind i blandingen; du skal være forsigtig med, hvad du gemmer, og hvordan du opbevarer det, virkelig tænke gennem disse ting.

Og jeg prøver altid at minde folk om regulering, det er virkelig vigtigt at have en plan og gennemføre den plan, for når push kommer til at skyve, eller en revisor kommer ind eller en regulator, vil du være i stand til at pege på din politik, som du har, og forklar derefter, hvordan det er, at du adresserer denne politik, når visse ting sker, som f.eks. en katastrofe, som et spørgsmål om at blive revideret, eller hvad der måtte være tilfældet. Du vil vide, hvad du gjorde, og have en oversigt over det - det vil gå langt for at holde revisoren og bugten, og det er bare gode ting.

Så hackere, selvfølgelig - jeg vil tale et par minutter om hackere, og hvorfor de udgør en sådan trussel. Og selvfølgelig ransomware, bare sige hele denne sag med WannaCry, WannaCry ransomware, der lige dækkede planeten i meget kort rækkefølge, og tilsyneladende nogle kloge uvenlige mennesker til en masse information fra NSA, der var hackingværktøjer, der blev brugt og udsat for. Så jeg minder folk om, at der er en gammel fabel, Aesops Fabel, der siger, at vi ofte giver vores fjender værktøjet til vores egen ødelæggelse. Dette er noget at huske på, fordi igen, denne teknologi blev afbrudt af NSA, af National Security Association - kan ikke huske, hvad den står for, faktisk. Men det blev udsat for, og kom ud i verden og bare ødelagde kaos. Gæt hvad? Og mange virksomheder havde ikke opgraderet deres Windows-miljø, så det var et gammelt, tror det var Windows XP, der blev kompromitteret. Så igen, hvis du er flittig, hvis du holder dig på toppen af ​​dine programrettelser og dine versioner af dine operativsystemer, og hvis du sikkerhedskopierer dine data og gendanner dine data. Hvis du laver alle de ting, du skal gøre, er ting som det ikke så stort af et problem. Men du kan bare fortælle folk, der er øksemænd, ”Hej, gæt hvad? Vi er ligeglad, luk systemet ned, genstart det, indlæs sikkerhedskopierne. ”Og du er ude af løbene.

Så pointen er ja, disse dårlige ting sker, men der er ting, du kan gøre ved det - det er det, vi skal tale om på showet i dag. Så jeg gjorde noget research - faktisk var det lidt interessant, hvis du går til Wikipedia og ser på hacking, går det helt til 1903. Da en fyr hacket et system til telegrafer og sendte uhøflige beskeder gennem telegrafen, bare for at bevise, at han kunne hacke det, antager jeg. Jeg troede, det var ret morsomt. Pointen er, at hackere stort set er gode til at bryde og komme ind, det er hvad de har gjort i år og år og år. De er som låseplukkerne fra den moderne internetverden.

Og du skal huske, at ethvert system kan hackes, det kan hackes indefra, det kan hackes udefra. Mange gange, når disse hacks opstår, viser de sig ikke, eller de mennesker, der hacker ind i dit system, vil ikke gøre meget i et stykke tid. De venter et stykke tid; der er lidt af den involverede strategi, og delvis er det bare fordi den forretningsmæssige side af deres operation, fordi det, som hackere typisk gør, er at de bare laver deres ene lille del af programmet, så mange fyre, der er gode til at trænge ind firewalls og gennemtrængende informationssystem, det er godt det, de gør bedst, og når de først trænger ind i et system, så drejer de rundt og prøver at sælge denne adgang til nogen. Og det tager tid, så ofte er det tilfældet, at nogen bag kulisserne bare prøver at sælge adgang til det system, de har hacket - dit system, potentielt, hvilket ikke ville være for sjovt - og de prøver at finde ud af, hvem der faktisk vil betale for adgang til systemet.

Så der er denne form for sammenkoblet netværk af enkeltpersoner eller organisationer derude, som samles sammen og samarbejder for at gøre brug af stjålet information. Uanset om det er identitetstyveri eller bare datatyveri, om de gør livet ubehageligt for et firma - det er tilfældet med denne løsepenge, disse fyre griber bare fat i dine systemer, og de kræver penge, og hvis de får pengene, måske eller måske giver de ikke dine ting tilbage. Selvfølgelig er det den rigtige skræmmende ting, hvorfor skulle du endda betale det løsepenge? Hvordan ved du, at de vil give det tilbage? De beder måske bare om dobbelt eller tredobbelt. Så igen, alt dette taler til vigtigheden af ​​virkelig at tænke gennem din informationsstrategi, din elasticitet for dine data.

Så jeg gjorde noget mere research, det er en gammel 386; Hvis du er gammel som mig, kan du huske disse systemer. Og de var ikke så problematiske med hensyn til hacking; der var ikke en hel masse vira dengang. I disse dage er det et andet spil, så selvfølgelig kommer internettet sammen og ændrer alt. Alt er forbundet nu, der er et globalt publikum derude, de første store vira begyndte at angribe, og virkelig hackingindustrien begyndte at ballonere, helt ærligt.

Så vi skal tale lidt om IoT, vi har allerede et godt spørgsmål fra et publikummedlem: Hvordan beskytter jeg IoT-enheder fra et sårbarhedsmæssigt synspunkt? Det er et stort emne - helt ærligt, det er en stor indsats, der placeres lige nu, i hvordan du håndterer potentialet for, at IoT-enheder bliver hacket. Det er meget brug, de sædvanlige problemer, som du fokuserer på, f.eks. Adgangskodebeskyttelse, gennemgå processen med at opsætte det omhyggeligt, at indstille din egen adgangskode. Mange gange vil folk bare efterlade et standardadgangskode derinde, og det vil faktisk resultere i sårbarheden. Så det er de grundlæggende ting. Vi havde lige et nyt show om sikkerhed tidligere i denne uge, på vores radioprogram, med flere eksperter derude, og de sagde alle, at 80–90 eller flere procent af hackingproblemer, hvad enten det er IoT eller ransomware, eller hvad som helst, ville blive undgået, hvis du bare behandlet det grundlæggende, hvis du bare sørgede for, at dine baser var dækket, gjorde du alle de grundlæggende ting, som du ved, at du skulle gøre, der håndterer over 80 procent af alle de problemer derude.

Altså, tingenes internet, OK, IoT. Hvis du tænker på IoT, er det ikke så nyt. Helt ærligt er der avancerede producenter, der laver denne slags ting for 20 og 30 år siden, og derefter for omkring 15, 20 år siden, det var da RFID kom ind - identifikations tags for radiofrekvens - som havde været yderst nyttigt i at hjælpe meget store organisationer som detailhandlere, for eksempel rederier, ethvert produktfirma, der flytter ting rundt omkring i landet, rundt om i verden, det er yderst nyttigt at have alle disse data, du finder ud af, hvor dine ting går; hvis noget forsvinder, finder du ud af det.

Selvfølgelig er det ikke en idiotsikker løsning, faktisk havde jeg min bærbare computer, min Apple bortfaldt med, fra Atlanta lufthavn - Atlanta Hartsfield Lufthavn - nogen tog lige min taske med min computer. Jeg troede, at de ikke stjæler poser mere; de finder altid tasker - forkert. En person stjal posen, og så dukkede den op omkring en måned senere, den vågnede op, jeg fik en lille besked fra Apple fra iCloud om, at den vågnede omkring syv til ti minutter syd for Atlanta Hartsfield Airport; nogen besluttede bare at gå ind i det. De havde lige siddet på det i cirka en måned, og jeg gennemgik den temmelig frustrerende proces med at indse, ja, OK, jeg ved omtrent hvor det er, det kan være i dette hus, det hus, huset på tværs af gaden, det var bare der midlertidigt. Hvad laver du? Hvordan er disse oplysninger nyttige for dig?

Så selvom du lærer noget, kan du nogle gange ikke gøre noget ved det. Men ikke desto mindre må jeg sige, denne IoT-aktiverede verden, jeg tror, ​​vi ikke er helt klar til det, for at være ærlige. Jeg tror, ​​vi har et tilfælde, hvor der er en masse god teknologi derude, og vi bevæger os muligvis for hurtigt for at drage fordel af disse ting, fordi truslen er så betydelig. Vi tænker bare på antallet af enheder nu, der er en del af truslen, da folk snakker om det, det er en enorm, enorm bølge af enheder, der kommer vores vej.

Nogle af de store hacks, der er forekommet for nylig, idet de fjernede DNS-servere, havde at gøre med at IoT-enheder blev koopereret og vendt mod DNS-servere, bare klassiske DDoS-hacks, distribueret benægtelse af service, hvor bogstaveligt talt disse enheder er omprogrammeret til at ringe på en DNS-server i et blændende tempo, hvor du får hundreder af tusinder af anmodninger, der kommer ind på denne DNS-server, og bare kvæler og går ned og dør. Det er den slags ting, hvor historien om det store på et ikke så populært websted, hvor serverne lige styrtede ned - de er bare ikke skabt til den slags trafik.

Så IoT er bare noget at huske på, igen, hvis vi beskæftiger os med sikkerhedskopiering og gendannelse, er det bare vigtigt at huske, at et af disse angreb kan ske på et givet tidspunkt. Og hvis du ikke er forberedt på det, vil du miste mange kunder, fordi du vil gøre mange mennesker meget utilfredse. Og du har den omdømmehåndtering at håndtere. Det er en af ​​de nye udtryk, der har svævet rundt der, ”omdømmestyring.” Det lønner sig at huske og værdsætte, at omdømme kan tage år at bygge og minutter eller endda sekunder at skære. Så bare hold det i tankerne, når du planlægger din informationsstrategi.

Så der er hele dette begreb med hybridskyen. Jeg har fået en af ​​mine gamle, yndlingsfilm fra barndommen, øen Dr. Moreau der, hvor de skabte disse halvdyrs, halvdyrsdyr, det er ligesom hybridskyen. Så de lokale systemer vil være her i årevis - giv ingen fejl ved det, det vil tage lang tid at afvikle de lokale datacentre - og selv i små virksomheder vil du have en mange kundedata i dine systemer og dine drev, og jo mere kompleks denne situation bliver, desto sværere bliver det at være på toppen. Når det er sagt, er konsolidering i en database også altid en reel udfordring, især med et system som MySQL, for eksempel.

Det har aldrig været meget let at prøve at proppe alt sammen i et system. Når det er gjort, er der problemer, du får ydelsesproblemer. Så igen, det vil være et problem i ganske lang tid nu. Ældre infrastruktur derude i datacentre og i virksomheder, selvfølgelig. Det var problemet med WannaCry, er du har alle disse XP-systemer - Microsoft understøtter ikke XP længere. Så det er bare lidt forbløffende, hvordan nogle af disse problemer, der bliver så alvorlige og så smertefulde monetært og ellers kunne undgås med grundlæggende vedligeholdelse og vedligeholdelse. Grundlæggende ting.

Så der vil være et kompetencegap; disse kvalifikationsgap vil vokse med tiden, for igen er skyen fremtiden - jeg tror ikke der er nogen tvivl om det - skyen er, hvor tingene går; der er allerede et tyngdepunkt i skyen. Og hvad du vil se, er flere og flere virksomheder, flere og flere organisationer, der ser hen til skyen. Så det vil efterlade nogle kompetencehuller på stedet-siden; den er ikke der endnu, men den kommer. Og tænk endda på amortisering, så mange store virksomheder, de kan ikke bare flytte til skyen - de kunne, men det ville ikke være meget fornuftigt, omkostningsmæssigt, fordi de amortiserer alle disse aktiver over tre, til fem, til syv år, måske.

Det skaber et ret betydeligt tidsvindue, hvor de vil migrere væk fra on-prem og mod skymiljøet. Og helt ærligt har vi nået det punkt nu, hvor lokalet sandsynligvis er mindre sikkert end skyen. Slags sjovt, fordi det var det store bank i lang tid: Virksomheder var bekymrede for at gå til skyen af ​​sikkerhedsmæssige årsager, de var bekymrede for, at skyen var modtagelig for hacks. Nå, det er stadig, bestemt, men virkelig hvis du ser på de store fyre: Amazon, Microsoft, selv nu SAP og Google, alle disse fyre, de er temmelig gode til det, de er ret gode til at sikre skyen sig selv.

Og så, selvfølgelig, endelig på den før-side side, daterede systemer: disse applikationer bliver langt i tanden temmelig hurtigt i disse dage. Jeg hørte en joke en gang, definitionen af ​​ældre software er enhver software, der er i produktion. (Ler) Jeg synes det er lidt sjovt. Så over til skysystemerne nævnte jeg de store spillere, de vokser bare om dagen. AWS dominerer stadig dette rum, selvom Microsoft til deres kredit virkelig har fundet nogle ting ud, og de er fokuseret meget intenst. Så er SAP, SAP HANA Cloud, det er HANA Cloud-platformen, de kalder det - det er et enormt fokusområde for SAP og af indlysende grunde. De ved, at skyen nu har tyngdekraft, de ved, at skyen er et fremragende kampsportområde for teknologi.

Så det, du ser, er denne konsolidering omkring skyarkitekturer, og du vil have en masse arbejde i de næste to år med sky-til-sky-migration. Selv styredatastyring på tværs af skyer bliver et stort problem. Og Salesforce - se, hvor stor Salesforce er blevet - det er en absolut styrke, der skal regnes med. Det er også et marketingsystem, der er i skyen; der er noget som 5.000 marketingteknologiselskaber nu - 5.000! Det er vanvittigt. Og du ser en større indsats på denne ene rude af glas for at være i stand til at administrere multi-cloud-miljøer. Så et sidste glid fra mig, og så overleverer jeg det til Tep for at give os nogle råd om, hvordan vi kan forblive foran spillet, her.

Det talte vi om på mit radioprogram tidligere i denne uge, skymodellen med delt ansvar. Så hvad de taler om, er, hvordan AWS var ansvarlig for at sikre skyen, så skyens sikkerhed. Kunne se databutikker, databasenetværk osv. Men kunden er ansvarlig for data og sikkerhed i skyen. Nå, det var sjovt, fordi de bruger dette udtryk "delt ansvar", og hvad jeg slags samlet fra gæsterne på vores show er, at det overhovedet ikke er delt. Ideen er, det er dit ansvar, fordi odds er, hvis push kommer til at skyve, og nogen inficerer dit miljø, AWS vil sandsynligvis ikke blive holdt ansvarlig, det er du.

Så det er en slags mærkelig verden, jeg synes, det er lidt af en duplikeret betegnelse, “delt ansvar”, for det er virkelig slags det ikke, det er slags stadig dit ansvar at være på toppen af ​​alle de ting. Så med det, og jeg ved, at jeg har talt lidt om IoT - vi havde et godt spørgsmål om, hvordan man sikrer IoT-enheder - der kommer til at være et absolut udvalg af teknologier, der kommer ud for at kunne håndtere det. Det er klart, at du har noget software på nogle firmware på IoT-enhederne selv, så det er noget du skal huske på; du skal bekymre dig om, hvilken autentificeringsprotokol du skal bruge til det. Men som jeg siger, det grundlæggende, sandsynligvis kommer til at komme igennem det meste af det problem, du vil støde på, bare udføre adgangskodebeskyttelse, udføre ændring af adgangskoder og virkelig slags at være på toppen af ​​det - overvåge disse ting og se .

Mange af de teknologier, der bruges til overvågning af svig, for eksempel eller ubehagelige aktiviteter i netværk, fokuserer virkelig på outliers, og det er noget, som maskinlæring faktisk er temmelig god til, ved at klynge og se efter outliers, se efter mærkelige opførselsmønstre. Helt ærligt, hvad vi så med dette nylige DDoS-angreb på DNS-servere, hvor pludselig alle disse enheder pludselig begynder at sende et tilbagekald til en bestemt håndfuld servere, ja, det ser ikke godt ud. Og ærligt talt, hvad jeg altid minder folk om med disse systemer: Hver gang du har seriøs automatisering i disse slags miljøer, skal du altid have den manuelle tilsidesættelse, have dræbskontakten - du vil have en slags kill-switch programmeret derinde for at lukke disse ting ned.

Så med det vil jeg skubbe Tep's første dias, han laver nogle demoer for os. Og så går jeg videre og giver dig nøglerne til fanen WebEx. Nu kommer det din vej og tager det væk.

Tep Chantra: Okay, tak, Eric. Jeg hedder Tep Chantra, og jeg er produktchef her på IDERA. I dag ønskede at tale om IDERAs enterprise backup-løsning, nemlig SQL Safe Backup. For dem af jer, der er bekendt med SQL Safe Backup, lad os se hurtigt på nogle højdepunkter i produktet, der - undskyld mig. Så som du måske allerede har gættet, siger folk sikkerhedskopiering, SQL Server-sikkerhedskopiering og gendannelse af produkt, en af ​​nøglefunktionerne i SQL Safe er muligheden for at udføre hurtige sikkerhedskopieringer. Og det er en vigtig funktion, i betragtning af at de fleste sikkerhedskopier skal foretages, og i de fleste tilfælde skal de laves meget hurtigt, i et lille tidsvindue.

I nogle miljøer nu kan det være en udfordring at møde disse backupvinduer, især når du har flere store databaser, der skal sikkerhedskopieres. SQL Safe's evne til at gennemføre sikkerhedskopieringsoperationer giver hurtigt slutbrugere mulighed for at imødekomme disse backupvinduer. Apropos store databaser, sikkerhedskopiering af de store databaser, åbenbart større sikkerhedskopifiler. En anden funktion, hvor SQL Safe lyser, er muligheden for at komprimere sikkerhedskopifiler. Den anvendte komprimeringsalgoritme kan nå op til 90–95 procent komprimering. Dette betyder, at du kan gemme sikkerhedskopier længere eller tillade omkostningsbesparelser med hensyn til lagerbehov.

På bagsiden af ​​backup-operationerne har du gendannelsesfunktioner. Et af de slag, som DBA'er skal kæmpe for at gendanne databaser, er, at disse databaser skal gendannes så hurtigt som muligt. I tilfælde af store databaser kan en fuld gendannelse af en sikkerhedskopifil tage flere timer, hvilket naturligvis betyder længere nedetid og muligvis tab af indtægter. SQL Safe har heldigvis denne funktion kaldet "Øjeblikkelig gendannelse", som dybest set nedskærer tiden mellem, hvornår du starter en gendannelse, og til databasen kan nås af slutbrugere eller endda applikationer.

Jeg kan huske, at jeg engang talte med en kunde, hvor han rapporterede, at gendannelsen af ​​en bestemt database havde taget 14 timer. Men med funktionen til øjeblikkelig gendannelse var han i stand til at få adgang til denne database inden for en time eller mindre. Politikbaseret styring, et andet højdepunkt i SQL Safe, er muligheden for at oprette politikker og styre dine backup-operationer gennem disse politikker. Når du konfigurerer en politik, definerer du dybest set, hvilke forekomster der skal sikkerhedskopieres, eller hvilke databaser på disse forekomster, der skal sikkerhedskopieres, hvilken slags sikkerhedskopiering, der skal udføres, og endda den tidsplan, hvorpå disse sikkerhedskopier skal finde sted.

Derudover kan du også konfigurere advarselsmeddelelser. På den måde kan du få besked om hændelser som f.eks. Sikkerhedskopien er afsluttet, sikkerhedskopieringen mislykkedes, måske kunne den se dette, men der er nogle advarsler forbundet med denne operation. Du får også besked, hvis en sikkerhedskopi ikke køres som planlagt. Det er en vigtig anmeldelse, fordi du måske risikerer et tidsvindue, hvor en sikkerhedskopi ikke eksisterede. Og modtagelse af en sådan meddelelse vil indikere dig, at du er nødt til at gå derude og foretage denne sikkerhedskopi og derefter muligvis undersøge, hvorfor sikkerhedskopien ikke kørte som planlagt.

Nogle af de andre ting, lad os se her, fejltolerant spejling, betyder det i det væsentlige, at vi har evnen til at oprette duplikat-backup-filer på mere end et sted. Så lad os for eksempel sige, at du har en måldestination til din primære som en - hvad dit vigtigste lager er, hvor alle dine sikkerhedskopifiler går. Dog har du muligvis behov for at have en kopi af den samme sikkerhedskopifil for eksempel på selve den lokale maskine, bare hvis du har brug for nogle yderligere test, skal du sørge for, at databasen kan gendannes, uanset hvad der måtte være. SQL Virtual Database Optimize - hvad det egentlig er, er, at vi har et andet produkt, der for nylig blev integreret i SQL Safe, kaldet SQL Virtual Database.

Som jeg nævnte, er det for nylig integreret, så er det faktisk inkluderet i selve SQL Safe. Hvad SQL Virtual Database faktisk giver dig mulighed for at gøre, er faktisk at oprette en virtuel database. (Griner) Jeg hader at bruge de samme udtryk som definitionen, men hvad der i det væsentlige sker, er, at vi vil montere en database og basere backup-filen. Det, der i det væsentlige sker, er, at SQL Server mener, at databasen faktisk er i gang, mens den faktisk læser data fra sikkerhedskopifilen i stedet for faktisk at oprette selve databasen på filsystemet.

Dette er virkelig nyttigt, fordi det giver dig adgang til de data, der findes i sikkerhedskopifilen uden faktisk at forbruge ekstra diskplads, så det kommer meget praktisk, især når du har at gøre med enorme databaser, som du bare har brug for at få, skal du hurtigt se, eller laver noget dev arbejde på. Nul-påvirkningskryptering - hvad det væsentligt betyder er, at hvor vi udfører sikkerhedskopier af disse databaser, kan vi faktisk kryptere sikkerhedskopifilerne, og når vi krypterer disse sikkerhedskopifiler, tilføjer vi ikke nogen ekstra belastning til den faktiske systemets ydelse. Så det er helt ubetydeligt. Logforsendelse er en anden ting, som vi kan gøre, hvor vores politikker, som jeg nævnte tidligere, og med hensyn til den fordelagtige licens - hvad det egentlig betyder, er, at vores licensmodeller giver dig mulighed for at flytte licensmodeller fra en instans til en anden instans, med et par enkle museklik.

Gå videre, lad os tage et hurtigt kig på arkitekturen i selve produktet. Så der er dybest set fire hovedkomponenter til produktet. Vi starter fra venstre, SQL Safe Management Console og Web Console. Begge disse er i det væsentlige brugergrænseflader, den ene er desktop-klienten og den anden er en webapplikation. Begge disse brugergrænseflader trækker data fra den næste komponent, som er SQL Safe Repository Database. Lagringsdatabasen gemmer dybest set al din operationelle historie, alle sikkerhedskopierings- og gendannelsesoperationer. Disse oplysninger gemmes her. Alle disse data, der findes i depotet, administreres af SQL Safe Management Service, som er den næste komponent. Managementtjenesten er ansvarlig for opdatering af depotdatabasen og afsendelse af advarsel. Dataene vedrørende sikkerhedskopiering og gendannelse kommer faktisk fra SQL Safe Backup Agent, som er den sidste komponent, helt til højre.

SQL Safe Backup Agent er en komponent, der er installeret på alle de servere, der er vært for SQL Server-instanser, som du prøver at administrere med SQL Safe. Og dette er den service, der faktisk er ansvarlig for at udføre sikkerhedskopierne og komprimere dem. Nu på dette lysbillede er der også en femte komponent, som ikke helt kræves, men det er en dejlig ting at have. Og det er vores SQL Server Reporting Services RDL-filer. Hvad dette dybest set giver dig mulighed for at gøre, er at distribuere nogle RDL-filer til SQL Server Reporting Service, så du kan køre rapporter mod vores depotdatabase. Og vi har en række forskellige rapporter, f.eks. Sidste gang din sikkerhedskopi kørte, oplysninger om sikkerhedskopieringsoperationer, hvad har du.

Og undskyld mig. Lad os gå foran og se på SQL Safe selv. Giv mig et øjeblik her. Og giv mig et øjeblik til at logge på. Som du ser, jeg har indlæst lige nu er webapplikationen, men først vil jeg faktisk gerne se på desktop-applikationen. Så lad mig skyde det meget hurtigt op. Og dette er SQL Safe-desktop-applikationen, når den først indlæses, fører det dig til visningen af ​​SQL Safe i dag. Dette er i det væsentlige en liste over alle sikkerhedskopieringsoperationer eller gendannelse af operationer, der er sket i dag. Det giver dig også en hurtig status for dit miljø, som du kan se her, det siger, at mine politikker har en politik, der er i en OK tilstand, hvilket er godt, fordi jeg kun har en politik, og jeg håber, at det er ikke . Giver dig også et resume af de operationer, der var succesrige, alle operationer, der måtte have mislykkedes. Generelt set er jeg i god form: Bare ved at kigge hurtigt kan du se alle grønne; vi er gode til at gå.

Til venstre her kan du se alle de servere, du har registreret med SQL Safe, og dem, du stort set administrerer. Hvis du udvider det, får du vist listen over databaser på det system. Hvis du vælger en bestemt database, kan du se driftshistorikken for den pågældende database. Der er ikke meget mere at forklare, bortset fra at du også kan gå videre og udføre ad hoc-sikkerhedskopier fra dette vindue, og det er virkelig hurtigt og enkelt. Og lad mig demonstrere det for dig virkelig hurtigt. Du skal bare højreklikke på den og vælge den handling, du vil udføre. Og med det formål vil jeg gå videre og vælge backup-database. Og guiden SQL Safe Backup åbnes. Herfra får du dette, ligesom hvilken forekomst, du vil udføre sikkerhedskopien imod, og vælge hvilke databaser, du vil tage backup af. I dette tilfælde forvalgte jeg HINATA-maskinen og denne Contoso Retail-database, fordi det var det, jeg havde fremhævet, da jeg valgte indstillingen. Jeg vil fortsætte med at forlade det i øjeblikket, men du har mulighed for faktisk at vælge flere databaser, så hvis du f.eks. Vil sikkerhedskopiere al din brugerdatabase, kan du vælge denne alternativknap, og den vil forudvælge alle de der. Lad mig gå videre og fortsæt bare med det.

Gå videre til næste side af guiden. Det er her jeg kan vælge den sikkerhedskopieringstype, jeg vil udføre, og du har en række forskellige muligheder her. Det er - jeg er sikker på, at de findes i alle sikkerhedskopieringsværktøjer, for eksempel kan du udføre en fuld sikkerhedskopi, en differentiel sikkerhedskopi, transaktionslog-sikkerhedskopi, eller du kan faktisk bare blot tage backup af selve databasefilen. Du har også mulighederne for at oprette en kopi, der kun er kopi, som grundlæggende bruges, når du ikke ønsker at rod med LSM'erne. Jeg vil vælge “nej” for nu. Og du har også muligheden for at bekræfte sikkerhedskopien, når sikkerhedskopien er fuldført - på den måde skal du på den måde sørge for, at din sikkerhedskopi er god og kan bruges senere. Det er altid en af ​​disse funktioner, som du vil sikre dig, at du har, bare for at give dig en lille smule sikkerhed for, at sikkerhedskopien er brugbar.

Her finder du navn og databeskrivelse. Dette er i det væsentlige metadata, som du nemt kan hjælpe med at identificere, hvad sikkerhedskopien blev brugt til, så jeg vil sige demo-formål her. Og brug din databases sikkerhedskopi til demo. Dernæst definerer vi, hvor vi vil gemme vores backup-fil til, og du har flere forskellige muligheder her: Du kan gemme den i en enkelt fil, du kan oprette stripefiler, du har muligheden for at vælge her mål destination, vi understøtter også datadomæne. Og det, Amazon ST sky, i tilfælde af at det er her, du vil gemme dine oplysninger til.

Jeg fortsætter med den ene fil til denne demonstration, dette muliggør netværksfjernelse, dette er en rigtig dejlig funktion inden for SQL Safe i den forstand, at hvis du sikkerhedskopierer til en netværksplacering - hvilket er det, jeg laver her, kan du se fra det primære arkiv - hvis du sikkerhedskopierer til netværksplacering er der chancer for, at du kan støde på nogle netværkshicker. I nogle tilfælde, hvis dine netværkshicker modvirkes, vil sikkerhedskopieringen helt udsolgt. Nå, aktiver netværksfjernelsesmulighed. Hvad det egentlig gør, er, hvis der opstår et netværkshygie, hvad SQL Safe egentlig gør, er det pauser sikkerhedskopien og venter på en bestemt tid og prøver netværksplaceringen igen. Og hvis den er i stand til at oprette forbindelse, genoptager den bare sikkerhedskopien lige der, hvor den slap. På den måde bruger du ikke timer ad gangen på at prøve at køre denne sikkerhedskopi, og lige når det er tæt på at afslutte, er der opstået et netværkshik - vi sælger ikke operationen med det samme, vi venter bare lidt og prøver for at afslutte det igen.

Der er nogle andre indstillinger, når du konfigurerer dette. Nu medfører det dybest set det interval, hvorpå vi prøver igen, så i denne forstand, hvis vi støder på et netværkshygie, vil det forsøge at få adgang til netværksplaceringen igen om ti sekunder. Den anden mulighed her fortæller dybest set, at hvis vi støder på netværkshik til, siger det 300 sekunder her - så hvad, fem minutter, i alt - så vil vi bare helt sælge backup-operationen. Og det er fem minutter i rækkefølge, så det er, hvis vi prøver igen og igen, og inden for de fem minutter kan vi stadig ikke genoprette netværksforbindelsen, så sælger vi operationen helt ud. Denne allerførste operation her er dybest set i hele varigheden af ​​sikkerhedskopien, så hvis du mister ti sekunder her, genindstiller forbindelsen og derefter mister forbindelsen igen, hvis den dybest set gentages i 60 minutter, vil denne operation blive udsolgt. Og disse er konfigureret, som du kan se, så du kan skræddersy den til dit miljø.

Denne mulighed for spejlarkiv lige her, det var det, jeg talte om tidligere, med fejlagtolerant spejling. Det er her du kan specificere en anden sikkerhedskopi placering, hvis du nogensinde skulle ønske det. Jeg vil forlade dette ikke markeret lige nu, for jeg vil gerne gå videre og fortsætte. I disse indstillingsvinduer kan du definere ting som din type komprimering, som vi vil bruge til denne sikkerhedskopiering, og om vi vil aktivere kryptering til sikkerhedskopifilen eller ej. Vi tilbyder en række forskellige muligheder for komprimering, også ingen, hvis du vælger, at du overhovedet ikke vil have nogen komprimering. Så det er bare at hurtigt gå over disse muligheder.

Høj hastighed forsøger dybest set at fuldføre sikkerhedskopien så hurtigt som muligt, mens den inkluderer en vis mængde komprimering. ISize er mere fokuseret på at inkludere så meget komprimering som muligt, men det kan - fordi vi prøver at komprimere det så meget - det kan tage lidt længere tid og sandsynligvis bruge lidt mere CPU. Niveau 1 betyder i det væsentlige den mindste mængde komprimering helt til niveau 4, den mest mængde komprimering, som vi kan tilføje. Så dette er lidt mere detaljeret, iSpeed ​​typisk - hvad er ordet? Spænder fra mellem niveau 1 og niveau 2-komprimering; det tager et kig på dit system for at se, hvor meget CPU og tilgængelige ressourcer er tilgængelige og træffer afgørelser om meget komprimering, det skal bruge mellem niveau 1 og niveau 2.

ISize gør det samme, undtagen med niveau 3 og niveau 4. Der er nogle andre avancerede indstillinger her, som hvor mange der er på CPU'en, vi skal bruge, her er muligheden for at oprette kortdata til SQL's virtuelle database og også vores øjeblikkelig gendannelsesfunktion. Du kan inkludere database-logins og nogle andre muligheder, som nogle brugere finder meget værdifulde, så som at generere kontroller fra dette, så de senere kan kontrollere det for at sikre, at sikkerhedskopieringsfilerne er gode. Hvis vi fortsætter til næste side, er det her du konfigurerer dine underretninger. Og du kan se de forskellige muligheder, vi har her: underret, hvis sikkerhedskopien mislykkes, underret, hvis sikkerhedskopien er sprunget over, uanset af hvilken grund. Hvis sikkerhedskopien annulleres, eller hvis sikkerhedskopien afsluttes med advarsel, og hvis du ønsker det, kan du få besked om, at din sikkerhedskopi er ren. I miljøer, hvor et stort antal databaser, er det måske ikke noget, du vil aktivere, bare fordi det er mere sandsynligt, at din sikkerhedskopi vil lykkes, og du vil blive oversvømmet af e-mails.

På den næste side kan du se et resumé af det, du har defineret, fordi denne sikkerhedskopiering. Og hvis du ønsker det, hvis alt ser godt ud, kan du gå videre og klikke på backup, sparker vi det af. Før jeg klikker på backup, så lad mig gå videre og vise dig denne "generer script" -knap. Fordi hvad SQL Safe tilbyder en kommandolinjegrænseflade, hvor du faktisk kan starte en sikkerhedskopi eller gendanne operation, hvad har du via en kommandolinie DOS-prompt. Hvis du klikker på generer-scriptet her, giver det dybest set det egentlige script, du kan bruge, hvis du ville fjerne sikkerhedskopien fra kommandolinjen.

En anden pæn ting er, at vi også tilbyder udvidede butiksprocedurer, og i dette tilfælde genererer vi et script til dig, der vil udføre nøjagtigt den samme sikkerhedskopieringsoperation ved hjælp af udvidede butiksprocedurer - bare en lille hurtig snavs, som jeg ville dele. Så lad os gå og sparke denne sikkerhedskopi af. Og du kan se, at sikkerhedskopien allerede er startet. Og denne database er lidt stor, så det kan tage lidt tid. Du kan se, at jeg løb et par gange her tidligere, så det vil tage mig overalt fra et minut til tre minutter. Dette er et niveau 4, så jeg gætter på, at det vil være mellem disse to gange.

Mens det kører, lad os kigge hurtigt igennem på politikker. Som jeg nævnte tidligere giver politik dig mulighed for at konfigurere planlagte backup-operationer på tværs af din virksomhed, så jeg har en politik her, forudkonfigureret og snarere end at oprette en ny, lad os gå videre og se på detaljerne i denne. Undskyld, min VM kører på min personlige bærbare computer, og det ser ud til at køre fan temmelig hårdt. (Griner)

Eric Kavanagh: Det er godt - du ved, jeg ville stille dig et spørgsmål, mens vi ser dette her. Bruger IDERA meget ændring af datafangst med hensyn til sikkerhedskopiering, eller laver du hele sikkerhedskopier hver gang? Hvordan fungerer det, ved du?

Tep Chantra: Sig det endnu en gang, jeg er ked af det?

Eric Kavanagh: Ja, så ved du, om IDERA bruger CDC, ændrer datafangsteknologi for at gøre mindre sikkerhedskopier, eller gør det fuld sikkerhedskopiering hver gang?

Tep Chantra: Jeg tror ikke på det. Jeg husker, at jeg så det tidligere på et antal billetter. Og hvis jeg husker rigtigt, nej, vi udnytter ikke CDC, vi er, for at være ærlige, faktisk lader vi SQL Server udføre sikkerhedskopien, vi fanger bare dataene imellem og komprimerer dem, hvilket resulterer i der oprettes en sikkerhedskopifil. Så ved at bruge det. Ja.

Så nu, hvor jeg har ladet min politik - åh, jeg er ked af, havde du et andet spørgsmål?

Eric Kavanagh: Nej, det er det. Fortsæt.

Tep Chantra: OK, så nu jeg har min politik indlæst, kan du se nogle hurtige ting her: navn, beskrivelse, du kan indstille, hvilken slags politik du skal oprette, uanset om det er en politik, der skal styres, planen administreres af SQL Server Agent, eller tidsplanen administreres af SQL Server Backup Agent. I de fleste tilfælde vil du bruge SQL Server Agent, fordi det typisk er noget, der kører under alle omstændigheder på dit system, så kan lige så godt udnytte det, der er tilgængeligt for dig. På fanen medlemskab er det her, du specificerer de forekomster i sikkerhedskopidatabaser, du vil tage backup af. Og i dette tilfælde kan du se, at jeg har tilføjet alle mine registrerede tilfælde, og jeg har specificeret en bestemt database, der skal sikkerhedskopieres. Hvis jeg nu ville, kunne jeg gå videre og redigere disse og sige: ”Jeg vil tage backup af alle databaser eller bare brugerdatabaser eller endda systemdatabaser.” Det gode ved dette er, at jeg også kan bruge jokertegn og oprette visse databaser.

Jeg vil ikke foretage denne ændring her, bare fordi jeg ikke ønsker at foretage nogen store ændringer i mine indstillinger. Så lad os gå tilbage til indstillingerne. Og på valgmulighederne, det er her du definerer, hvilken slags sikkerhedskopier du skal udføre, og hvis du kigger her, har jeg fulde sikkerhedskopier, differentielle sikkerhedskopier og store sikkerhedskopier konfigureret. Og for hver af disse sikkerhedskopier kan jeg definere, om jeg vil bruge en bestemt mængde komprimering eller tænde krypteringen. Ligesom de indstillinger, du ville have fundet i ad hoc-guiden. Og på lokationer kan du også definere destinationen for disse sikkerhedskopieringsoperationer. En af de gode ting ved politikker er, at du også kan definere, om du vil gå videre eller slette de gamle sikkerhedskopifiler, baseret på X antal dage eller uger, hvad har du.

Og det kan konfigureres for hver backup-type. Så du kan se her, jeg har mine fulde sikkerhedskopier til at slette efter en uge. Min differentielle sletning efter to dage, og jeg vil have, at mine sikkerhedskopier slettes efter en dag. Dette er virkelig rart, fordi det automatiserer håndteringsscenariet, gamle sikkerhedskopifiler, og kun holder dem, du virkelig har brug for, baseret på tid. Næste side definerer du skemaet, og igen, kan skemaet være specifikt for hver type backup-operation, du skal gennemføre, så for min fulde kører jeg den ugentligt, min forskel, jeg kører den hver sjette time, mine logfiler, jeg kører hvert 30. minut. På den næste side er det sted, hvor du konfigurerer underretninger, og det er stort set de samme typer underretninger, som du har fundet i ad hoc-sikkerhedskopi. Den ene forskel er, at du har denne nye, andre mulighed, hvor den kan fortælle dig, om sikkerhedskopien ikke starter som planlagt. Det er her du kan blive advaret om situationer, hvor dine sikkerhedskopier ikke kørte. Virkelig vigtigt, især i tilfælde, hvor du har visse SLA'er for at sikre dig, at du har sikkerhedskopier tilgængelige på de tidspunkter, du har brug for dem. Og næste side kan du se resuméet. Hvis jeg havde foretaget nogen ændringer, hvis jeg klikkede på finish, ville det gå ud og foretage disse ændringer, gemme det og for eksempel gemme det i depotet i SQL Server Agent-job.

Og bare for lidt hurtigt at vise dig virkelig hurtig, her er en politik og et job, som jeg oprettede til den bestemte politik. Og du kan se, at det er oprettet tre forskellige job: et for hver sikkerhedskopieringstype. Lad mig nu kigge hurtigt på HUD-grænsefladen og slags - som jeg nævnte tidligere, virtuelle databaser, som vi tidligere har integreret i SQL Safe. Som jeg nævnte, narrer det grundlæggende SQL Server til at tro, at en faktisk database er blevet gendannet, når vi i virkeligheden bare læser sikkerhedskopifilen. Så lad mig gå foran og ikke en rigtig hurtig for jer. Lad mig tage en sikkerhedskopifil. Lad mig tage en fire lige her. Processen er afsluttet og virkelig hurtig, hvis jeg opdaterer mine databaser her, kan du se, at databasen er tilgængelig, og SQL Server mener, at den er live, men i virkeligheden læser vi bare dataene ud af databasen.

Nogle andre funktioner, der er nye i denne udgivelse, er muligheden for at udføre sikkerhedskopier ved hjælp af det nyeste backupformat. Det er rigtig praktisk for de kunder, der har brug for vores politikbaserede styring, men de vil beholde SQL Server-filformatet uanset grund. Nu ved jeg, at vi løber tør for tid, så jeg tror, ​​jeg gerne vil gå videre og stoppe denne præsentation, bare for at vi kan tage nogle spørgsmål eller hvad.

Eric Kavanagh: Ja, sikker. Så jeg tror, ​​en af ​​nøglerne virkelig er inden for politikstyring, ikke? Som ved at tænke på den optimale politik, og hvad baserer du det på? Det er klart, at der i nogle tilfælde er regler, man skal bekymre sig om, men i en virksomhed er det måske ikke meget reguleret; du behøver bare at finde de optimale tidspunkter for at lave dine sikkerhedskopier, og derefter antager jeg, at du får nogle rapporter om, hvor lang tid det tog, og hvor dyrt det var med hensyn til computerkraft osv. Hvad går der i at definere den optimale politik?

Tep Chantra: Det er virkelig tilfældigt, hvert miljø vil have en anden politik med hensyn til hvornår disse sikkerhedskopier skal køre. Også, og det kan medføre den type sikkerhedskopier, der kører, den tidsplan, som de kører, og det bestemmer virkelig, virkelig også afhængig af deres gendannelsesbehov, antager jeg, det er svaret.

Eric Kavanagh: OK, ja. Og du talte om at være i stand til at lave forskellige slags sikkerhedskopier og striber var en af ​​mulighederne. Er det for slags varme og kolde data, eller hvad er logikken bag at gå stribe i modsætning til en anden metode?

Tep Chantra: Så jeg tror, ​​det bedste svar, jeg kan give, er, at så, stribede filer, hvad vi egentlig gør er at skrive backup-indholdet over et antal forskellige filer. Jeg tror, ​​at ideen om at bruge stribede filer er, at du muligvis kan skrive dine sikkerhedskopier hurtigere på den måde. For eksempel kan du have hver anden fil til en anden placering. Det koster serveren også sikkerhedsmidler, da du distribuerer dine sikkerhedskopier til forskellige placeringer.

Eric Kavanagh: Og der er nogle seje, nye ting med hensyn til gendannelsesfunktioner, ikke? For lad os sige, at der er en slags begivenhed, hvad enten det er en naturkatastrofe eller ransomware, uanset hvad der er tilfældet. Du behøver ikke bare have en mulighed for at gendanne, ikke? Kan du sætte prioriteter for, hvad der gendannes, og hvilke slags data? Kan du tale om mulighederne der?

Tep Chantra: Nå, hvad angår gendannelse, nævnte jeg tidligere, at vi giver mulighed for at udføre øjeblikkelige gendannelser, hvilket i det væsentlige får brugerne til dataene hurtigere, ikke? Og bare for at demonstrere, gjorde jeg en tidligere, så du kan se her, at igen, denne database er ikke meget enorm, det er den, der kører på min bærbare computer. Så jeg tror, ​​det er måske som to optrædener i størrelse, men denne database er afsluttet inden for 37 sekunder. Faktisk gendannelse. Så det tog mig 37 sekunder, før jeg kunne få adgang til mine data, så med den øjeblikkelige gendannelse kunne jeg få adgang til min database inden for to sekunder. Så du kan forestille dig, hvordan det ville se ud, hvis din database var meget større.

Eric Kavanagh: Ja, godt punkt. Og selvfølgelig talte vi om dette inden showet; du har brugt en masse tid på frontlinjerne med at hjælpe mennesker og derefter flyttet over til produktstyringsområdet, så det er lidt af en anden udfordring, antager jeg. Men du var i frontlinjen - jeg synes, det er et ret godt sted at lære, hvor folk går galt, og hvad nogle af problemerne er. Hvad kan du se som nogle af de mere almindelige faldgruber, som folk kunne undgå, hvis de bare tænker bedre igennem dette?

Tep Chantra: Nogle af de almindelige faldgruber er bare - jeg formoder, som du nævnte tidligere - planlægning af dine sikkerhedskopier. Der har været tidspunkter, hvor jeg har set folk forsøge at udnytte, for eksempel vores politikker, politikker, politikker, du udfører en masse sikkerhedskopier og baserer det på LSM. Og i nogle tilfælde har jeg set, at nogle mennesker også har nogle andre værktøjer, der udfører sikkerhedskopier på deres databaser, som i virkeligheden ødelægger deres logforsendelsespolitikker, fordi sikkerhedskopieringer i det væsentlige laves uden for SQL Safe, og vi er ikke opmærksomme på dem. Det er hovedsageligt bare at planlægge ting forude, det er her, faldgruben kommer fra.

Eric Kavanagh: Overrasker mig ikke. Nå, folkens, dette har været en god gennemgang af nogle af de blokeringer og tackle, der er nødvendigt for at holde din virksomhed glad, for at holde dine kunder glade. Jeg vil gerne takke alle, Tep Chantra fra IDERA, træder ind her, laver nogle live demoer, det er altid interessant - det er altid lidt risikabelt at udføre live demo, men jeg synes, det gik ret godt. Du ved, det er basale ting, men det er den slags ting, hvis du ikke gør det, vil du have alle slags problemer. Så dette er de vigtige ting, som virksomhederne har nogle mennesker gør.

Så Tep, tak for din tid. Folk, vi arkiverer alle disse webcasts til senere visning, så du kan normalt komme tilbage inden for en time eller to og tjekke arkivet. Men endnu en gang, gode ting her, vi forsøger at hjælpe virksomheden med at blive på toppen af ​​tingene, vi værdsætter al din tid og opmærksomhed, folk derude. Vi får dig op næste gang. Du har lyttet til Hot Technologies. Pas på, folkens. Hej hej.

Skudsikker: hvordan dagens forretningsførere forbliver på toppen