Hem säkerhet Bulletproof: hur dagens företagsledare är på topp

Bulletproof: hur dagens företagsledare är på topp

Anonim

Av Techopedia Staff, 7 juni 2017

Takeaway: Värd Eric Kavanagh diskuterar säkerhetskopiering och återhämtning med IDERAs Tep Chantra i detta avsnitt av Hot Technologies.

Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.

Eric Kavanagh: OK, mina damer och herrar, det är onsdag klockan 4:00 Eastern, för de som är på företagets teknologirum, vet ni vad det betyder: Det är dags för Hot Technologies. Ja verkligen. Jag heter Eric Kavanagh, jag kommer att vara din moderator för dagens evenemang med titeln "Bulletproof: How Today's Business Leaders Stay on Top." Och folkens, vi har en trevlig, intim konversation här idag; det kommer att bli Tep Chantra och din är värd för den här konversationen. Vi kommer att prata allt om ett antal olika saker, inklusive katastrofåterställning, säkerhetskopiering och återställning, men verkligen den termen jag gillar att använda i dessa dagar är datapåverkan - jag hörde det från en gentleman för bara ett par veckor sedan, och det verkligen, det är mycket meningsfullt. Eftersom det talar för hur viktigt det är att ha en elastisk informationsinfrastruktur under ditt företag.

Detta är informationsekonomin idag, vilket innebär att de flesta företag är beroende i någon eller annan mening av informationstillgångar, på data. Jag menar, även detaljhandelsföretag, till och med hårdvaruföretag, verkligen någon form av organisation i dag kommer att ha någon form av information ryggraden, eller åtminstone de kommer att, om de är i modern tid, om du vill. Det finns några mamma- och popbutiker som fortfarande kan undvika det, men även där börjar du se mycket mer spridning av informationssystem, många av dem molnbaserade, ärligt talat, men många av dem fortfarande på premiss, för att hantera kundtransaktioner, hålla koll på saker, för att veta vad dina kunder vill ha, för att veta vad lagret är, för att veta vad det var, att kunna förstå den stora bilden - det är verkligen viktiga grejer i dessa dagar.

Så, datapåverkan är en term som jag gillar att använda; redundans är en annan term som kommer till minnet. Men du vill se till att oavsett vad som händer, dina anställda och din organisation kommer att ha den information den behöver för att betjäna dina kunder. Så jag kommer att gå igenom, bara på att inrama argumentet, innan Tep går in och förklarar för oss några saker som IDERA har pågått. Naturligtvis har IDERA gjort en hel del webbsändningar med oss ​​under det senaste året eller så. Det är ett väldigt, väldigt intressant företag, de är inriktade på några av mässingstopparna och blockerar och hanterar vid behov för att överleva i informationsekonomin. Vi dyker in.

Bulletproof infrastruktur - det är faktiskt en gammal bild av en stordator, se på det, det är som i början av 1960-talet från Wikipedia. Du tänker på vägen tillbaka då, mainframe-dagar var inte många åtkomstpunkter för stordatorerna, så säkerheten var ganska lätt, säkerhetskopieringen var ganska enkel, du kunde förstå vad som måste göras, du måste bara gå in och göra den. Naturligtvis var det inte så många som visste vad de skulle göra, men de som gjorde det, det var ganska tydligt vad du hade att göra. Och det var inte alltför mycket oro över det. Du hade enstaka problem, men det var egentligen inte så vanligt.

Tillbaka på dagen var det här ganska enkelt - idag, inte så mycket. Så här är bilden - det är faktiskt Hercules som kämpar mot Hydra där. För er som inte är stora med mytologin, var Hydra en väldigt irriterande varelse genom att den hade flera huvuden, och när du hackade en av dem kom två till på sin plats, så det berättar typ för utmaningen att att hantera några av de frågor du hittar i livet, särskilt i det sammanhanget, var verkligen inriktade på skurkar. Du tar ut en dålig kille, två kommer till på deras plats. Och du ser det här i den hackande världen, helt uppriktigt sagt, det är en stor industri idag och det är bara en av de stora utmaningarna som står inför oss.

Så du tänker på om du försöker kartlägga din datakraftsstrategi, vad måste du oroa dig för? Det finns många saker att oroa sig för: katastrofer, bränder, översvämningar. Jag tillbringade mycket tid i södra och New Orleans har naturligtvis några intressanta berättelser om orkaner och översvämningar och så vidare. Och många gånger mänskliga misstag kommer in i spelet, kommer in i bilden, skulle jag säga. Och så var fallet även i Katrina i New Orleans, för ja, en orkan kom igenom, det är en handling från Gud, som de säger, en force majeure . Men ändå var det mänskliga misstag som ledde fram till orkanen som resulterade i flera avbrott i avgifterna. Så det fanns tre av dem, i själva verket fanns det en på industrikanalen, och problemet med att ett fartyg inte hade förtöjts ordentligt, nedför floden. Och orkanen kom in och drev den från sina förtöjningar, och den gängade faktiskt nålen och gick runt svängen, där floden böjer sig precis utanför New Orleans och den gick bara ner i industrikanalen och kraschade genom en av dessa murar. Så även om det var en naturkatastrof, det var mänskliga misstag som resulterade i det enorma problemet.

Och samma sak inträffade på andra sidan staden, där det fanns ett avsnitt av avgiften som aldrig hade slutförts, tydligen för att staden och arméns korps av ingenjörer aldrig hade kommit överens om vem som skulle betala för det. Det krävs inte en raketforskare att räkna ut att om du har ett stort gapande hål i din avgift, så är det inte en mycket effektiv avgift. Och så, poängen är att mänskliga misstag verkligen spelar in i scenariot där katastrofen slår till. Så även om det är eld, eller om det är en översvämning, eller om det är en jordbävning, eller vad som än är fallet, finns det troligtvis någon som kunde ha och borde ha gjort för att förbereda sig för en sådan händelse. Och naturligtvis är det vad vi traditionellt kallar katastrofåterställning. Så, ja, katastrofer inträffar, men människor bör verkligen se igenom dessa saker och förbereda sig därefter. Vi pratar lite om det idag med Tep.

Så missnöjda anställda - underskatt inte skadan som en missnöjd anställd kan göra - de är där ute, de är överallt. Jag känner människor som har berättat för mig historier om riktigt obehagliga saker som har hänt, där människor bara gör dåliga saker, de saboterar avsiktligt sin egen organisation, för de är olyckliga. De kanske inte fick en höjning, eller de fick sparken, eller vem vet vad som hände. Men det är något att tänka på, och det är en mycket viktig komponent. När det gäller licensiering, också, precis som en FYI där ute, folk. En av statistiken som jag hörde var något som 60 procent av alla tips som mjukvaruföretag får för att inte betala licensavgifter kommer från tidigare anställda. Så du vill se till att du köpte den programvaran och att du fick den rättvisa och fyrkantiga. Företagssabotage händer inte hela tiden, men det händer. Sekretessfrågor kommer också in i blandningen; du måste vara försiktig med vad du lagrar och hur du lagrar det, verkligen tänka igenom dessa saker.

Och jag försöker alltid påminna människor när det gäller reglering, det är verkligen viktigt att ha en plan och att genomföra den planen, för när push kommer att skjuta eller någon revisor kommer in eller en regulator, vill du kunna peka på din policy som du har, och sedan förklara hur det är att du hanterar den policyn, när vissa saker händer, som en katastrof till exempel, som en fråga om att granskas eller vad som än är fallet. Du vill veta vad du gjorde och ha en redogörelse för det - det kommer att gå långt för att hålla revisoren och viken, och det är bara bra grejer.

Så, hackare, naturligtvis - Jag kommer att prata ett par minuter om hackare och varför de utgör ett sådant hot. Och naturligtvis ransomware, säg bara detta hela fallet med WannaCry, WannaCry ransomware, som bara täckte planeten i mycket kort ordning, och tydligen några smarta ovänliga människor för en massa information från NSA, det var hackverktyg som användes och utsatt. Så jag påminner människor om att det finns en gammal fabel, Aesops fabel, som säger att vi ofta ger våra fiender verktygen för vår egen förstörelse. Det här är något att tänka på, för återigen stängdes denna teknik av NSA, av National Security Association - kan inte komma ihåg vad den står för, faktiskt. Men den blev utsatt och kom ut i världen och utbröt bara förödelse. Gissa vad? Och många företag hade inte uppgraderat sin Windows-miljö, så det var en gammal, tror att det var Windows XP, som komprometterades. Så igen, om du gör flit, om du håller dig uppe på dina korrigeringar och dina versioner av ditt operativsystem och om du säkerhetskopierar dina data och återställer dina data. Om du gör alla saker du borde göra är sådana saker inte så stora problem. Men du kan bara berätta för folk som är axmän, ”Hej, gissa vad? Vi bryr oss inte, stäng av systemet, starta om det, ladda upp säkerhetskopiorna. ”Och du är på väg till tävlingarna.

Så poängen är ja, dessa dåliga saker händer, men det finns saker du kan göra åt det - det är vad vi ska prata om på showen idag. Så jag gjorde en del undersökningar - det var faktiskt lite intressant, om du går till Wikipedia och letar upp hacking, går det hela vägen till 1903. När en kille hackade ett system för telegrafer och skickade oförskämda meddelanden genom telegrafen, bara för att bevisa att han kunde hacka det antar jag. Jag tyckte att det var ganska underhållande. Poängen är att hackare i princip är bra på att bryta och gå in, det är vad de har gjort i år och år och år. De är som låsplockarna i den moderna internetvärlden.

Och du måste komma ihåg att alla system kan hackas, det kan hackas från insidan, det kan hackas från utsidan. Många gånger, när dessa hacks inträffar, kommer de inte att visa sig, eller de människor som hackar in i ditt system kommer inte att göra mycket på ett tag. De väntar ett tag; det finns lite av strategin inblandad, och delvis beror det bara på att affärssidan av deras verksamhet, för vad som hackare vanligtvis gör är att de bara gör sin lilla del av programmet, så många killar som är bra på att penetrera brandväggar och penetrerande informationssystem, det är det som de gör bäst, och när de väl tränger igenom ett system, så vänder de sig och försöker sälja den åtkomsten till någon. Och det tar tid, så ofta är det så att någon bakom kulisserna bara försöker sälja åtkomst till vilket system de har hackat - ditt system, potentiellt, vilket inte skulle vara för roligt - och de försöker räkna ut vem som faktiskt kommer att betala för åtkomst till systemet.

Så det finns den här typen av osammanhängande nätverk av individer eller organisationer där ute, som sammanfaller och samarbetar för att använda stulen information. Oavsett om det är identitetsstöld, eller bara datastöld, om de gör livet obehagligt för ett företag - det är fallet med den här ransomware, dessa killar tar bara tag i dina system och de kräver pengar, och om de får pengar, kanske eller kanske de inte kommer att ge dina saker tillbaka. Naturligtvis är det den verkliga läskiga saken, varför skulle du ens vilja betala det lösen? Hur vet du att de kommer att ge det tillbaka? De kan bara be om dubbla eller tredubbla. Så igen, detta talar allt till vikten av att verkligen tänka genom din informationsstrategi, din resiliency för dina data.

Så jag gjorde lite mer forskning, det är en gammal 386; om du är gammal som jag kan du komma ihåg dessa system. Och de var inte så problematiskt vad gäller hacking; det fanns inte en hel del virus då. Dessa dagar är det ett annat spel, så naturligtvis kommer internet med och förändrar allt. Allt är anslutet nu, det finns en global publik där ute, de första stora virusen började attackera, och verkligen började hackbranschen att ballong, helt uppriktigt.

Så vi pratar lite om IoT, vi har en bra fråga redan från en publikmedlem: Hur skyddar jag IoT-enheter från ett sårbarhetssynpunkt? Det är en stor fråga - helt uppriktigt sagt, det är en stor ansträngning som läggs in just nu, i hur du hanterar potentialen för IoT-enheter som hackas. Det är mycket att använda, de vanliga frågorna som du fokuserar på, lösenordsskydd till exempel, gå igenom processen att sätta upp det noggrant, att ställa in ditt eget lösenord. Många gånger lämnar människor bara ett standardlösenord där inne, och det kommer faktiskt att leda till sårbarheten. Så det är de grundläggande sakerna. Vi hade bara en ny show om säkerhet tidigare den här veckan, på vår radioprogram, med flera experter där och de sa alla att 80–90 eller fler procent av hackingproblem, vare sig det är IoT eller ransomware, eller vad som helst, skulle undvikas om du hanterade bara grunderna, om du bara såg till att du hade dina grunder täckt, gjorde du alla grundläggande grejer, som du vet att du ska göra, som hanterar över 80 procent av alla problem där ute.

Så, tingenes internet, OK, IoT. Om du tänker på IoT är det inte så nytt. Ärligt talat finns det avancerade tillverkare som gör denna typ av saker för 20 och 30 år sedan, och sedan för cirka 15, 20 år sedan, det var när RFID kom in - identifieringstaggar för radiofrekvens - som hade varit oerhört användbart för att hjälpa mycket stora organisationer, som detaljister, till exempel rederier, alla produktföretag som flyttar saker runt om i landet, runt om i världen, det är oerhört användbart att ha all den informationen, du får reda på vart dina saker går; om något försvinner, får du reda på det.

Naturligtvis är det inte en idiotsäker lösning, jag hade faktiskt min bärbara dator, mitt Apple gick bort från, från Atlanta flygplats - Atlanta Hartsfield Airport - någon tog bara min väska, med min dator. Jag trodde att de inte stjäl väskor längre; de hittar alltid väskor - fel. Någon stal påsen och sedan dök den upp ungefär en månad senare, den vaknade, jag fick ett litet meddelande från Apple från iCloud att den vaknade ungefär sju till tio minuter söder om Atlanta Hartsfield Airport; någon bestämde sig bara för att gå in på det. De hade precis satt på det i ungefär en månad och jag genomgick den ganska frustrerande processen att inse, ja, OK, jag vet ungefär var det är, det kan vara i det här huset, det huset, huset tvärs över gatan, det var bara där tillfälligt. Vad gör du? Hur är den informationen användbar för dig?

Så även om du lär dig något kan du ibland inte göra en hel del åt det. Men ändå, denna IoT-aktiverade värld, jag måste säga, jag tror att vi inte är helt redo för det, för att vara ärlig. Jag tror att vi har ett fall där det finns mycket bra teknik där ute och vi kanske rör oss för snabbt för att dra nytta av dessa saker, eftersom hotet är så betydande. Vi tänker bara på antalet enheter nu som är en del av hotbilden, när människor pratar om det, det är en enorm, enorm våg av enheter som kommer till vårt sätt.

Några av de stora hacks som har inträffat nyligen, som tagit ner DNS-servrar, hade att göra med att IoT-enheter koopererades och vändes mot DNS-servrar, bara klassiska DDoS-hacks, distribuerade serviceavslagningar, där bokstavligen är dessa enheter omprogrammerade för att ringa på en DNS-server i en bländande takt, där du får hundratusentals förfrågningar som kommer in på denna DNS-server och bara kväver och kraschar och dör. Det är den typen där historien om det stora på en inte så populär webbplats som servrarna just kraschade - de är bara inte gjorda för den typen av trafik.

Så IoT är bara något att tänka på, återigen, om vi har att göra med säkerhetskopiering och återställning, är det bara viktigt att komma ihåg att något av dessa attacker kan hända vid en viss tidpunkt. Och om du inte är beredd på det, kommer du att förlora många kunder, för du kommer att göra många människor mycket olyckliga. Och du har det ryktehanteringen att hantera. Det är en av de nya termerna som har svävat där, "ryktehantering." Det lönar sig att komma ihåg och uppskatta att rykte kan ta år att bygga och minuter eller till och med sekunder att slösa. Så håll bara det i åtanke när du planerar din informationsstrategi.

Så, så finns det hela konceptet med hybridmolnet. Jag har fått en av mina gamla, favoritfilmer från barndomen, The Island of Dr. Moreau där, där de skapade dessa halva djur, halva varelser, det är på samma sätt som hybridmolnet. Så de lokala systemen kommer att vara här i flera år - gör inga misstag med det, det kommer att ta lång tid att avveckla dessa lokala datacenter - och till och med i små företag kommer du att ha en mycket kunddata i dina system och dina enheter, och ju mer komplex den situationen blir, desto svårare kommer det att vara på topp. Som sagt är konsolidering i en databas alltid en verklig utmaning, särskilt med ett system som MySQL, till exempel.

Att försöka klämma ner allt i ett system har aldrig varit så enkelt att göra. Vanligtvis när det är gjort finns det problem, du får prestandaproblem. Så igen, det kommer att bli en fråga under ganska lång tid nu. Äldre infrastruktur där ute i datacentra och i företag, naturligtvis. Det var problemet med WannaCry, har du alla dessa XP-system - Microsoft stöder inte XP längre. Så det är bara fantastiskt hur några av dessa problem som blir så allvarliga och så smärtsamma monetärt och annars skulle kunna undvikas med grundläggande underhåll och underhåll. Grundläggande grejer.

Så det kommer att bli en kompetensgap; dessa färdighetsklyftor kommer att växa med tiden, för återigen är molnet framtiden - jag tror inte att det finns några tvivel om det - molnet är där saker och ting går; det finns redan ett tyngdpunkt i molnet. Och vad du kommer att se är fler och fler företag, fler och fler organisationer som tittar på molnet. Så det kommer att lämna vissa färdighetsgap på platsen; den är inte där ännu, men den kommer. Och till och med tänka på amortering, så många stora företag, de kan inte bara flytta till molnet - de kunde, men det skulle inte vara mycket meningsfullt, kostnadsmässigt, eftersom de amorterar alla dessa tillgångar över tre, till fem, till sju år, kanske.

Det skapar ett ganska betydande tidsfönster, under vilket de kommer att flytta bort från start och mot molnmiljön. Och ärligt talat har vi nått punkten där lokalt förmodligen är mindre säkert än molnet. Tyvärr roligt, eftersom det var den stora banan under lång tid: Företag var oroliga för att gå till molnet av säkerhetsskäl, de var oroliga för att molnet var mottagligt för hacks. Tja, det är fortfarande, säkert, men verkligen om du tittar på de stora killarna: Amazon, Microsoft, även nu SAP och Google, alla dessa killar, de är ganska bra på det där, de är ganska bra på att säkra molnet sig.

Och så, naturligtvis, äntligen på förhand-sidan, daterade system: dessa applikationer blir långt i tanden ganska snabbt i dag. Jag hörde ett skämt en gång, definitionen av äldre programvara är all programvara som är i produktion. (Skrattar) Jag tycker att det är ganska roligt. Så, till molnsystemen, nämnde jag de stora aktörerna, de växer bara med dagen. AWS dominerar fortfarande det utrymmet, även om Microsoft till deras kredit verkligen har räknat ut några saker och de är fokuserade väldigt intryckt. Så är SAP, SAP HANA Cloud, det är HANA Cloud-plattformen de kallar det - det är ett enormt fokusområde för SAP och av uppenbara skäl. De vet att molnet nu har allvar, de vet att molnet är ett utmärkt kampsatsområde för teknik.

Så, vad du ser är denna konsolidering kring molnarkitekturer, och du kommer att ha mycket arbete under de kommande två åren om migration från moln till moln. Till och med masterdatahantering över molnen kommer att bli en stor fråga. Och Salesforce - se hur stor Salesforce har blivit - det är en absolut kraft att räkna med. Dessutom är det ett marknadsföringssystem är i molnet; det finns något som 5 000 marknadsföringsteknologiföretag nu - 5 000! Det är galet. Och du ser mer ansträngning på den här enda rutan med glas för att kunna hantera miljöer med flera moln. Så en sista glid från mig, och sedan överlämnar jag den till Tep för att ge oss några råd om hur vi kan hålla oss före spelet, här.

Detta, vi talade om på min radioprogram tidigare denna vecka, molnmodellen med delat ansvar. Så vad de pratar om är hur AWS var ansvarig för att säkra molnet, så säkerheten för molnet. Kunde se datoraffärer, databasnätverk, etc. Men kunden är ansvarig för data och säkerhet i molnet. Tja, det var roligt eftersom de använder det här uttrycket “delat ansvar” och vad jag slags samlade från gästerna på vår show är att det inte riktigt delas alls. Tanken är att det är ditt ansvar, eftersom oddsen är om push kommer att skjuta och någon infekterar din miljö, AWS kommer förmodligen inte att hållas ansvarig, det är du.

Så det är typ av en konstig värld, jag tror att det är lite av ett dubbelartat begrepp, "delat ansvar" eftersom det verkligen är typ av inte, det är liksom ditt ansvar att hålla sig uppe på allt det där. Så med det, och jag vet att jag har pratat lite om IoT - vi hade en bra fråga om hur man säkra IoT-enheter - kommer det att finnas ett absolut utbud av tekniker som kommer att kunna hantera det. Uppenbarligen har du viss mjukvara på vissa firmware på IoT-enheterna själva, så det är något att tänka på; du måste oroa dig för vilket autentiseringsprotokoll du måste använda för det. Men som jag säger, grunderna, kommer förmodligen att komma igenom de flesta problem som du kommer att stöta på, bara göra lösenordsskydd, göra ändringar av lösenord och verkligen vara ovanpå det - övervaka dessa saker och titta på .

Många av de tekniker som används för att övervaka bedrägerier, till exempel, eller besvärlig aktivitet i nätverk, fokuserar verkligen på outliers, och det är något som maskininlärning faktiskt är ganska bra på, att klustera och titta på outliers, leta efter konstiga beteendemönster. Som ärligt talat, vad vi såg med den senaste DDoS-attacken på DNS-servrar, där plötsligt alla dessa enheter börjar skicka ett återuppringning till en viss handfull servrar, det ser inte bra ut. Och uppriktigt sagt, vad jag alltid påminner människor om med dessa system: Varje gång du har allvarlig automatisering i sådana miljöer, alltid ha den manuella åsidosättningen, ha kill-omkopplaren - du vill ha någon slags kill-switch programmerad där inne för att stänga dessa saker ner.

Så med det kommer jag att trycka på Teps första bild, han kommer att göra några demonstrationer för oss. Och sedan ska jag gå vidare och ge dig nycklarna till fliken WebEx. Nu kommer det din väg och ta bort det.

Tep Chantra: Okej, tack, Eric. Jag heter Tep Chantra och jag är produktansvarig här på IDERA. Idag ville prata om IDERAs lösning för företagskopiering, nämligen SQL Safe Backup. För dig som är bekant med SQL Safe Backup, låt oss ta en snabb titt på några höjdpunkter i produkten som - ursäkta mig. Så, som du kanske redan har gissat, säger folk säkerhetskopiering, SQL Server-säkerhetskopiering och återställning av en produkt, en av nyckelfunktionerna i SQL Safe är förmågan att utföra snabba säkerhetskopior. Och det är en viktig funktion, med tanke på att de flesta säkerhetskopior måste göras och i de flesta fall måste de göras mycket snabbt, i ett litet tidsfönster.

I vissa miljöer kan det vara en utmaning att möta dessa säkerhetsfönster, särskilt när du har flera stora databaser som måste säkerhetskopieras. SQL Safe: s förmåga att slutföra säkerhetskopieringsoperationerna gör det möjligt för slutanvändare att kunna möta dessa säkerhetsfönster. På tal om stora databaser, säkerhetskopiera de stora databaser, uppenbarligen större säkerhetskopior. En annan funktion där SQL Safe lyser är förmågan att komprimera säkerhetskopior. Den använda komprimeringsalgoritmen kan uppnå likadana 90–95 procent komprimering. Detta innebär att du kan lagra säkerhetskopior längre, eller tillåta kostnadsbesparingar när det gäller lagringsbehov.

På baksidan av säkerhetskopieringsoperationerna har du återställningsoperationer. En av striderna som DBA måste kämpa för att återställa databaser är att dessa databaser måste återställas så snabbt som möjligt. I fall av stora databaser kan en fullständig återställning av en säkerhetskopieringsfil ta flera timmar, vilket uppenbarligen innebär längre driftstopp och eventuellt inkomstbortfall SQL Safe har lyckligtvis den här funktionen som heter "Instant Restore", som i grund och botten minskar tiden mellan när du startar en återställning och när databasen kan nås av slutanvändare eller till och med applikationer.

Jag minns att jag talade med en kund en gång, där han rapporterade att återställningen av en viss databas hade tagit 14 timmar. Men med funktionen för omedelbar återställning kunde han få åtkomst till den databasen inom en timme eller mindre. Politikbaserad hantering, en annan höjdpunkt i SQL Safe är förmågan att skapa policyer och hantera dina säkerhetskopior genom dessa policyer. När du konfigurerar en policy definierar du i princip vilka instanser som ska säkerhetskopieras eller vilka databaser på dessa instanser som ska säkerhetskopieras, vilken typ av säkerhetskopieringsoperationer som ska utföras och till och med schemat för vilka säkerhetskopior ska ske.

Dessutom kan du också konfigurera varningsmeddelanden. På så sätt kan du bli meddelad om händelser som säkerhetskopieringen har slutförts, säkerhetskopiorna misslyckades, kanske den kunde se detta, men det finns några varningar som är kopplade till den operationen. Du kommer också att meddelas om en säkerhetskopia inte körs som schemalagd. Det är en viktig meddelande, eftersom du kanske riskerar ett fönster för tid där en säkerhetskopia inte fanns. Och att få ett sådant meddelande kommer att indikera dig att du måste gå ut och göra den säkerhetskopian och sedan eventuellt göra en del undersökningar om varför den säkerhetskopian inte kördes som schemalagd.

Några av de andra sakerna, låt oss se här, feltolerant spegling, som i allt väsentligt betyder att vi har möjligheten att skapa duplicerade säkerhetsfiler på mer än en plats. Så, till exempel, låt oss säga att du har en måldestination i din primära som - vad din huvudsakliga lagring är, där alla dina säkerhetskopieringsfiler går. Men du kan ha behov av att ha en kopia av samma säkerhetskopia till exempel på den lokala maskinen, bara om du behöver göra några ytterligare tester, se till att databasen kan återställas, oavsett fall. SQL Virtual Database Optimize - vad det egentligen är är att vi har en annan produkt som nyligen integrerades i SQL Safe, kallad SQL Virtual Database.

Som jag nämnde är det som nyligen integrerats så som faktiskt ingår i själva SQL Safe. Vad SQL Virtual Database egentligen tillåter dig att göra är att skapa en virtuell databas. (Skrattar) Jag hatar att använda samma termer som definitionen, men vad som egentligen händer är att vi kommer att montera en databas och basera på säkerhetskopian. Så, vad som egentligen händer är att SQL Server tror att databasen faktiskt är igång, medan den faktiskt läser data från säkerhetskopian, snarare än att skapa själva databasen i filsystemet.

Detta är verkligt användbart eftersom det ger dig tillgång till de data som finns i säkerhetskopian utan att faktiskt konsumera ytterligare diskutrymme, så det kommer i praktiskt praktiskt, särskilt när du har att göra med enorma databaser som du bara behöver få, se snabbt, eller gör något dev-arbete på. Nollpåverkande kryptering - vad det egentligen innebär är att där vi utför säkerhetskopior av dessa databaser kan vi faktiskt kryptera säkerhetskopieringsfilerna, och när vi krypterar dessa säkerhetskopieringsfiler lägger vi inte till någon extra belastning på den faktiska systemets prestanda. Så det är helt försumbart. Loggfrakt är en annan sak som vi kan göra, där vår policy, som jag nämnde tidigare, och när det gäller den fördelaktiga licensieringen - vad det egentligen betyder är att våra licensmodeller tillåter dig att flytta licensmodeller från en instans till en annan instans, med några enkla musklick.

Gå vidare, låt oss ta en snabb titt på själva produktens arkitektur. Så det finns i princip fyra huvudkomponenter till produkten. Vi har startat från vänster, SQL Safe Management Console och Web Console. Båda dessa är i huvudsak användargränssnitt, en är desktopklienten och den andra är en webbapplikation. Båda dessa användargränssnitt drar data från nästa komponent, som är SQL Safe Repository-databasen. Förvaringsdatabasen lagrar i princip all din operativa historia, alla säkerhetskopierings- och återställningsoperationer. Dessa uppgifter lagras här. All denna information som finns i förvaret hanteras av SQL Safe Management Service, som är nästa komponent. Ledningstjänsten ansvarar för uppdatering av databasen och skickar varningsmeddelanden. Uppgifterna om säkerhetskopierings- och återställningsoperationerna kommer faktiskt från SQL Safe Backup Agent, som är den sista komponenten, längst till höger.

SQL Safe Backup Agent är en komponent som är installerad på alla servrar som är värd för SQL Server-instanser som du försöker hantera med SQL Safe. Och detta är den tjänst som faktiskt ansvarar för att utföra säkerhetskopiorna och komprimera dem. Nu på denna bild finns också en femte komponent, som inte helt krävs, men det är en trevlig sak att ha. Och det är våra SQL Server Reporting Services RDL-filer. Vad detta i princip tillåter dig att göra är att distribuera några RDL-filer till SQL Server Reporting Service så att du kan köra rapporter mot vår databas. Och vi har ett antal olika rapporter, som förra gången din säkerhetskopia kördes, information om säkerhetskopiering, vad har du.

Och ursäkta mig. Låt oss gå vidare och titta på SQL Safe själv. Ge mig en sekund här. Och ge mig en sekund att logga in. Som ni ser, jag har laddat just nu är webbapplikationen, men först vill jag faktiskt ta en titt på skrivbordsapplikationen. Så låt mig avfyra det riktigt snabbt. Och detta är SQL Safe-skrivbordsapplikationen, när den först laddas tar den dig till vyn SQL Safe idag. Detta är i huvudsak listar alla säkerhetskopieringsoperationer eller återställningsåtgärder som har hänt idag. Det ger dig också en snabb status på din miljö, som du kan se här säger den att min politik har en politik, som är i ett OK tillstånd, vilket är bra, för jag har bara en politik och jag hoppas att det är inte . Ger dig också en sammanfattning av de operationer som var framgångsrika, alla operationer som kan ha misslyckats. Totalt sett är jag i god form: Bara genom att ta en snabb titt kan du se alla gröna; vi är bra att gå.

Till vänster här kan du se alla servrar som du har registrerat med SQL Safe och de som du i princip hanterar. Om du utökar den får du se listan över databaser på det systemet. Om du väljer en viss databas kan du se driftshistoriken för den aktuella databasen. Det finns inte mycket mer att förklara, annat än att du kan gå vidare och utföra ad hoc-säkerhetskopior från detta fönster också, och det är verkligen snabbt och enkelt. Och låt mig visa det för dig verkligen snabbt. Du högerklickar bara på den och väljer den åtgärd du vill göra. Och för detta ändamål ska jag gå vidare och välja säkerhetsdatabas. Och SQL Safe Backup Wizard öppnas. Härifrån får du detta, som vilken instans du vill utföra säkerhetskopian mot, och välja vilka databaser du vill säkerhetskopiera. I det här fallet valde jag HINATA-maskinen och denna Contoso Retail-databas i förväg, för det var det som jag lyfte fram när jag valde alternativet. Jag kommer att gå vidare och lämna det för nu, men du har möjligheten att faktiskt välja fler databaser så att om du vill säkerhetskopiera all din användardatabas till exempel kan du välja den här alternativknappen och den kommer att välja ur alla de där. Låt mig gå vidare och fortsätt med det.

Vidare till nästa sida i guiden. Det är här jag kan välja vilken typ av säkerhetskopia jag vill utföra, och du har ett antal olika alternativ här. Det är- Jag är säker på att du hittar alla säkerhetskopieringsverktyg, till exempel kan du utföra en fullständig säkerhetskopia, en differentiell säkerhetskopia, transaktionslogg-säkerhetskopia, eller så kan du bara säkerhetskopiera själva databasfilen. Du har också möjligheterna att skapa en kopia som bara är kopierad, som i princip används när du inte vill röra dig med LSM: erna. Jag ska välja "nej" för tillfället. Och du har också möjlighet att verifiera säkerhetskopian efter att säkerhetskopieringen är klar - på så sätt ser du till att säkerhetskopieringen är bra och kan användas senare. Det är alltid en av dessa funktioner som du vill se till att du har, bara för att ge dig lite försäkran om att säkerhetskopian är användbar.

Här hittar du namn och databeskrivning. Det här är i huvudsak metadata som du enkelt kan hjälpa dig att identifiera vad säkerhetskopian användes för, så jag kommer att säga demoändamål här. Och använd din databas backup för demo. Därefter definierar vi var vi vill spara vår säkerhetskopia till, och du har flera olika alternativ här: Du kan spara den i en enda fil, du kan skapa stripfiler, du har möjlighet att välja här måldestinationen, vi stöder också datadomän. Och det, Amazon ST-moln, om det är där du vill spara din information till.

Jag kommer att fortsätta med den enda filen för den här demonstrationen, detta möjliggör nätverksförmåga, detta är en riktigt fin funktion inom SQL Safe i den meningen att om du gör säkerhetskopiering till en nätverksplats - vilket är vad jag gör här, kan du se från det primära arkivet - om du säkerhetskopierar nätverksplatsen finns det chansen att du kan stöta på nätverkshickingar. I vissa fall om dina nätverkshickar motverkas kommer säkerhetskopieringen helt att sälja ut. Tja, aktivera alternativet för nätverksförmåga, vad det i huvudsak gör är om ett nätverk hicka, vad SQL Safe väsentligen gör, är det pausar säkerhetskopian och väntar på en viss tid och försöker nätverksplatsen igen. Och om den kan ansluta, kommer den bara att återuppta säkerhetskopian precis där den slutade. På så sätt tillbringar du inte timmar åt gången för att försöka köra den här säkerhetskopian och precis när det är nära att bli slut, har ett nätverkshick uppstått - vi säljer inte operationen direkt, vi väntar bara lite och försöker för att slutföra det igen.

Det finns några andra alternativ när du konfigurerar detta. Nu innebär det i princip det intervall vi försöker på nytt, så i detta avseende, om vi stöter på ett nätverkshick, kommer det att försöka komma åt nätverksplatsen igen om tio sekunder. Det andra alternativet här berättar i princip att om vi stöter på nätverkshickar för det står 300 sekunder här - så vad, fem minuter, totalt - så kommer vi bara att sälja säkerhetskopieringen helt. Och det är fem minuter i följd, så det är om vi försöker om och om igen och inom dessa fem minuter kan vi fortfarande inte återupprätta nätverksanslutningen, så säljer vi operationen helt. Den här sista åtgärden här är i princip hela säkerhetskopieringens varaktighet, så om du tappar tio sekunder här, återupprättar anslutningen och sedan förlorar anslutningen igen, om det i princip upprepas i 60 minuter, kommer den operationen att bli slut. Och dessa är konfigurerade, som du ser, så att du kan skräddarsy den efter din miljö.

Det här spegelarkivalternativet här, det var det jag talade om tidigare med feltoleranta speglingar. Det är här du kan ange en annan plats för säkerhetskopiering, om du någonsin skulle vilja. Jag kommer att lämna det här avmarkerat just nu för att jag vill gå vidare och fortsätta. I dessa alternativfönster kan du definiera saker som din typ av komprimering som vi vill använda för den här säkerhetskopieringen eller om vi vill aktivera kryptering för säkerhetskopian. Vi erbjuder ett antal olika alternativ för komprimering, även inget, om du väljer att du inte vill ha någon komprimering alls. Så det är bara att snabbt gå igenom dessa alternativ.

Hög hastighet försöker i grund och botten att slutföra säkerhetskopian så snabbt som möjligt, samtidigt som du inkluderar viss kompression. ISize är mer fokuserad på att inkludera så mycket komprimering som möjligt men det kan - eftersom vi försöker komprimera det så mycket - det kan ta lite längre tid och sannolikt använda lite mer CPU. Nivå 1 betyder egentligen den minsta mängden komprimering hela vägen till nivå 4, den största mängden komprimering som vi kan lägga till. Så detta är lite mer detaljerat, iSpeed ​​vanligtvis - vad är ordet? Spänner mellan nivå 1 och nivå 2-komprimering; det tar en titt på ditt system för att se hur mycket CPU och tillgängliga resurser finns tillgängliga och gör bedömningar om mycket komprimering, det bör använda mellan nivå 1 och nivå 2.

ISize gör samma sak, utom med nivå 3 och nivå 4. Det finns några andra avancerade alternativ här, som hur många som finns på CPU: n som vi ska använda, här är alternativet för att skapa kartläggningsdata för SQL: s virtuella databas och även vår funktion för omedelbar återställning. Du kan inkludera databasinloggningar och vissa andra alternativ som vissa användare tycker är mycket värdefulla, så som att generera kontroller från detta, så att de kan kontrollera det senare, för att se till att säkerhetskopiorna är bra. Om vi ​​fortsätter till nästa sida är det här du ställer in dina aviseringar. Och du kan se de olika alternativen vi har här: meddela om säkerhetskopian misslyckas, meddela om säkerhetskopian hoppas över, oavsett anledning. Om säkerhetskopian avbryts, eller om säkerhetskopian slutförs med varning, och om du så önskar, kan du bli meddelad om att säkerhetskopian är ren. För miljöer där ett stort antal databaser, det kanske inte är något du vill aktivera, bara för att det är mer än troligt att din säkerhetskopia kommer att lyckas och du blir översvämmad av e-postmeddelanden.

På nästa sida kan du se en sammanfattning av vad du har definierat, orsak till den här säkerhetskopieringen. Och om du vill, om allt ser bra ut kan du gå vidare och klicka på säkerhetskopiering, vi sparkar av det. Innan jag klickar på säkerhetskopiering, låt mig gå vidare och visa dig den här knappen "generera skript". Eftersom vad SQL Safe erbjuder ett kommandoradsgränssnitt där du faktiskt kan starta en säkerhetskopiering eller återställa operation, vad har du, via en kommandorad, DOS-prompt. Om du klickar på generera skriptet här ger det dig i själva verket det faktiska skriptet som du kan använda, om du ville ta bort säkerhetskopian från kommandoraden.

En annan snygg sak är att vi också erbjuder utökade butiksprocedurer, och i detta fall genererar vi ett skript för dig som kommer att utföra exakt samma säkerhetskopieringsoperation med utvidgade butiksprocedurer - bara en liten snabb lurv som jag ville dela. Så låt oss gå och starta den här säkerhetskopian. Och du kan se att säkerhetskopian redan har startat. Och den här databasen är lite stor, så det kan ta lite tid. Du kan se att jag sprang några gånger här tidigare, så det kommer att ta mig var som helst från en minut till tre minuter. Detta är en nivå 4 så jag antar att det kommer att vara mellan dessa två gånger.

Medan det går, låt oss ta en snabb titt på policyer. Som jag nämnde tidigare, gör det möjligt för policyer att konfigurera schemalagda säkerhetskopieringsoperationer i ditt företag, så jag har en policy här, redan förkonfigurerad och snarare än att skapa en ny, låt oss gå vidare och titta på detaljerna i den här. Beklagar, min VM körs på min personliga bärbara dator och det verkar köra fläkten ganska hårt. (Skrattar)

Eric Kavanagh: Det är bra - du vet, jag skulle ställa en fråga medan vi tittar på det här. Använder IDERA mycket datafångst när det gäller säkerhetskopiering, eller gör du hela säkerhetskopior varje gång? Hur fungerar det, vet du?

Tep Chantra: Säg det en gång till, jag är ledsen?

Eric Kavanagh: Ja, så vet du om IDERA använder CDC, ändrar datafångstteknologi för att göra mindre säkerhetskopior, eller gör det fullständiga säkerhetskopior varje gång?

Tep Chantra: Jag tror inte det. Jag minns att jag såg det tidigare på ett antal biljetter. Och om jag minns korrekt, nej, vi utnyttjar inte CDC, vi är, för att vara ärliga, vi låter i grunden SQL Server utföra säkerhetskopieringen, vi fångar bara upp data mellan och komprimerar det, vilket resulterar i en reservfil skapas. Så, i princip använda det. Ja.

Så nu när jag har laddat min policy - åh, jag är ledsen, hade du en annan fråga?

Eric Kavanagh: Nej, det är det. Varsågod.

Tep Chantra: OK, så nu när jag har laddat min policy kan du se några snabba saker här: namn, beskrivning, du kan ange vilken typ av policy du ska skapa, vare sig det är en policy som ska hanteras, schemat kommer att hanteras av SQL Server Agent, eller schemat kommer att hanteras av SQL Server Backup Agent. I de flesta fall kommer du att vilja använda SQL Server Agent, för det är vanligtvis något som körs på ditt system, så kan också utnyttja det som är tillgängligt för dig. På fliken medlemskap är det här du anger instanser i säkerhetskopieringsdatabaserna som du vill säkerhetskopiera. Och i det här fallet kan du se att jag har lagt till alla mina registrerade instanser och jag har angett en specifik databas som ska säkerhetskopieras. Nu, om jag ville, kunde jag gå vidare och redigera dessa och säga, "Jag vill säkerhetskopiera alla databaser eller bara användardatabaser, eller till och med systemdatabaser." Det trevliga med detta är att jag också kan använda jokertecken och skapa vissa databaser.

Jag kommer inte att göra den förändringen här, bara för att jag inte vill göra några stora ändringar i mina inställningar. Så låt oss gå tillbaka till alternativen. Och på alternativen är det här du definierar vilken typ av säkerhetskopior du ska utföra, och om du tar en titt här har jag fullständiga säkerhetskopior, differentiella säkerhetskopior och stora säkerhetskopior konfigurerade. Och för var och en av dessa säkerhetskopior kan jag definiera om jag vill använda en viss mängd komprimering eller aktivera krypteringen. Precis som de alternativ du skulle ha hittat i ad hoc-guiden. Och på platser kan du också definiera destinationen för dessa säkerhetskopieringsoperationer. En av de goda sakerna med policyer är att du också kan definiera om du vill gå vidare och ta bort de gamla säkerhetskopiorna, baserat på X-antal dagar eller veckor, vad har du.

Och det är konfigurerbart för varje säkerhetskopia. Så du kan se här, jag har mina fullständiga säkerhetskopior att ta bort efter en vecka. Min differentiella radering efter två dagar, och jag vill att mina säkerhetskopior ska raderas efter en dag. Det här är väldigt trevligt, för det automatiserar hanteringsscenariot, gamla säkerhetskopieringsfiler och behåller bara de du verkligen behöver, baserat på tid. Nästa sida du definierar schemat, och igen, schemat kan vara specifikt för varje typ av säkerhetskopiering du ska slutföra, så för min fulla, jag kör det varje vecka, min differentiering jag kör det var sjätte timme, mina loggar jag kör var 30: e minut. På nästa sida är där du ställer in aviseringar och det är väsentligen samma typer av meddelanden som du har hittat i ad hoc-säkerhetskopiering, en skillnad är att du har det här nya, andra alternativet där det kan berätta om säkerhetskopian inte lyckas starta som planerat. Det är här du kan bli varnad om situationer där dina säkerhetskopior inte kördes. Verkligen viktigt, särskilt i fall där du har vissa SLA: er för att se till att du har säkerhetskopior tillgängliga vid de tillfällen du behöver dem. Och nästa sida kan du se sammanfattningen. Om jag hade gjort några ändringar, om jag klickade på finish, skulle det gå ut och göra dessa ändringar, spara det och till exempel spara det i arkivet för SQL Server Agent-jobb.

Och bara för att snabbt visa dig riktigt snabbt, här är en policy och ett jobb som jag skapade för just den politiken. Och du kan se att det skapades tre olika jobb: ett för varje säkerhetskopieringstyp. Nu, verkligen snabbt, låt mig ta en snabb titt på HUD-gränssnittet och typ av - som jag nämnde tidigare, virtuell databas brukade vara ett till som vi har integrerat i SQL Safe. Som jag nämnde nu, narrar det i grunden SQL Server att tro att en faktisk databas har återställts när vi i själva verket bara läser säkerhetskopian. Så låt mig gå vidare och inte en riktig snabb för er. Låt mig ta en säkerhetskopia. Låt mig ta en fyra här. Processen är klar och verkligen snabb, om jag uppdaterar mina databaser här kan du se att databasen är tillgänglig och SQL Server tycker att den är live, men i själva verket läser vi bara data från databasen.

Några andra funktioner som är nya för den här utgåvan är förmågan att utföra säkerhetskopior med det senaste säkerhetskopieringsformatet. Det är riktigt praktiskt för de kunder som behöver använda vår policybaserade hantering, men de vill behålla SQL Server-filformatet av någon anledning. Nu vet jag att vi har slut på tiden, så jag tror att jag skulle vilja gå vidare och stoppa denna presentation, bara så att vi kan ta några frågor, eller vad inte.

Eric Kavanagh: Ja, säkert. Så jag tror att en av nycklarna verkligen ligger i policyhantering, eller hur? Som att tänka på den optimala politiken och vad baserar du på det? Uppenbarligen finns det i vissa fall förordningar att oroa sig för, men i ett företag kanske det inte är mycket reglerat; du behöver bara hitta de optimala tiderna för att göra dina säkerhetskopior och sedan antar jag att du får några rapporter om hur lång tid det tog och hur dyrt det var när det gäller beräkningskraft och så vidare. Vad går det att definiera den optimala politiken?

Tep Chantra: Det är verkligen fall för fall, varje miljö kommer att ha en annan policy när det gäller när dessa säkerhetskopior ska köras. Också, och det kan innebära vilken typ av säkerhetskopior som körs, schemat som de kör, och det avgör verkligen, verkligen också beroende på deras återställningsbehov, antar jag, det är svaret.

Eric Kavanagh: OK, ja. Och du pratade om att kunna göra olika typer av säkerhetskopior och ränder var ett av alternativen. Är det för typ av heta och kalla data, eller vad är logiken bakom att gå stripe, i motsats till någon annan metod?

Tep Chantra: Så jag tror att det bästa svaret jag kan ge för det är att så, randiga filer, vad vi egentligen gör är att skriva backup-innehållet över ett antal olika filer. Jag tror att tanken på att använda randiga filer är att du möjligen kan skriva dina säkerhetskopior snabbare, på det sättet. Till exempel kan du ha varje annan fil till en annan plats. Det kostar servern också säkerhet eftersom du distribuerar dina säkerhetskopior till olika platser.

Eric Kavanagh: Och det finns några coola, nya saker när det gäller återställningsfunktioner, eller hur? För låt oss säga att det finns någon form av händelser, oavsett om det är en naturkatastrof eller ransomware, oavsett fall. Du behöver inte bara ha ett alternativ för att återställa, eller hur? Kan du fastställa prioriteringar för vad som återställs och vilken typ av data? Kan du prata om alternativen där?

Tep Chantra: Tja, när det gäller återställning, nämnde jag tidigare att vi ger möjlighet att utföra omedelbara återställningar, vilket i huvudsak får användare till informationen snabbare, eller hur? Och bara för att demonstrera, gjorde jag en tidigare, så att du kan se här, att igen, denna databas är inte särskilt stor, det här är den som körs på min bärbara dator. Så jag tror att det kanske är som två spelningar i storlek, men den här databasen slutfördes inom 37 sekunder. Faktisk återställning. Så det tog mig 37 sekunder innan jag skulle kunna komma åt mina data, så med omedelbar återställning kunde jag komma åt min databas inom två sekunder. Så du kan föreställa dig hur det skulle se ut om din databas var mycket större.

Eric Kavanagh: Ja, bra poäng. Och naturligtvis pratade vi om detta före showen; du har tillbringat mycket tid på frontlinjerna för att stödja människor och sedan flyttat över till produkthanteringsutrymmet, så det är lite annorlunda utmaning, antar jag. Men du var i frontlinjen - jag tycker att det är en ganska bra plats att lära sig var människor går fel och vad några av problemen är. Vad ser du som några av de vanligare fallgroparna som människor kan undvika om de bara tänker igenom det här?

Tep Chantra: Några av de vanliga fallgroparna är bara - jag antar som du nämnde tidigare - schemalägga dina säkerhetskopior. Det har varit tider där jag har sett att människor försöker utnyttja, till exempel vår policy, policy, policy du utför en hel del säkerhetskopior och baserar det på LSM. Och i vissa fall har jag sett att vissa människor också har några andra verktyg som utför säkerhetskopior på sina databaser, vilket i själva verket krossar deras loggförsändelsespolicy, eftersom säkerhetskopior görs väsentligen utanför SQL Safe och vi är inte medvetna om dem. Det är främst bara att planera saker framåt, det är där fallgropen kommer från.

Eric Kavanagh: Förvånar mig inte. Tja, folkens, detta har varit en bra recension av några av de blockeringar och hanteringar som är nödvändiga för att hålla ditt företag lyckligt, för att hålla dina kunder lyckliga. Jag vill tacka alla, Tep Chantra från IDERA, går in här, gör några live-demonstrationer, det är alltid intressant - det är alltid lite riskabelt att göra live-demo, men jag tror att det gick ganska bra. Du vet, det är grundläggande grejer, men det är den typen där om du inte gör det kommer du att ha alla slags problem. Så detta är de viktiga saker som företag har vissa människor gör.

Så Tep, tack för din tid. Folk, vi arkiverar alla dessa webbsändningar för senare visning, så vanligtvis kan du komma tillbaka inom en timme eller två och kolla in arkivet. Men än en gång, bra grejer här, vi försöker hjälpa företaget att hålla oss uppe på saker, vi uppskattar all din tid och uppmärksamhet, folk där ute. Vi kommer att komma ikapp dig nästa gång. Du har lyssnat på Hot Technologies. Var försiktig, folkens. Hejdå.

Bulletproof: hur dagens företagsledare är på topp