Per personal de Techopedia, 7 de juny de 2017
Takeeaway: L' amfitrió Eric Kavanagh discuteix la còpia de seguretat i recuperació amb Tep Chantra d'IDERA en aquest episodi de Hot Technologies.
Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.
Eric Kavanagh: D' acord, senyores, és el dimecres a les 4:00 Eastern, per als que hi ha a l'espai tecnològic empresarial, ja sabeu què vol dir això: és hora de Hot Technologies. Sí, efectivament. Em dic Eric Kavanagh, seré el seu moderador per a l’esdeveniment d’avui que es titula “Bulletproof: How The Business Business Business leaders will be top”. I la gent, avui tindrem una conversa íntima i agradable; serà Tep Chantra i la vostra que realment acollirà aquesta conversa. Parlarem de diverses coses diferents, inclosa la recuperació, la còpia de seguretat i la restauració de desastres, però realment el terme que m’agrada fer servir aquests dies és la resiliència de dades: ho vaig sentir d’un senyor fa només unes setmanes i realment, té molt sentit. Perquè parla de l'important que és tenir una infraestructura d'informació resistent al vostre negoci.
Es tracta de l’economia de la informació en aquests dies, cosa que significa que la majoria de les empreses confien en algun sentit o altre en actius d’informació, en dades. Vull dir que, fins i tot les empreses de venda al detall, fins i tot les empreses de ferreteria, realment qualsevol tipus d’organització tindrà algun tipus d’informació vertebral, o almenys ho passaran, si són a l’època moderna, si ho fareu. Hi ha botigues de mama i pop que encara poden evitar aquestes coses, però fins i tot allà, ja comenceu a veure molta més proliferació de sistemes d'informació, molts d'ells basats en núvols, francament, però molts encara són premissos, per gestionar les transaccions de clients, mantenir les novetats, per saber què volen els vostres clients, per saber què és l’inventari, per saber què era, per poder entendre la imatge general - és realment important aquest tema.
Per tant, la resiliència de dades és un terme que m'agrada fer servir; la redundància és un altre terme que em ve al cap. Però voleu assegurar-vos que no importa el que passi, els vostres empleats i la vostra organització tindran la informació que necessita per atendre els vostres clients. Per tant, vaig a aprofundir, només per emmarcar l’argument, abans que Tep passi i ens expliqui algunes de les coses que ha passat per IDERA. Per descomptat, IDERA ha realitzat una sèrie de transmissions amb nosaltres durant l'últim any. És una empresa molt interessant, que es concentren en algunes de les grans plataformes, bloquegen i fan front, si cal, per sobreviure en l’economia de la informació. Ens endinsarem.
Infraestructura antillot: en realitat es tracta d’una imatge antiga d’un fotograma, fixeu-vos que és com a primers dels anys seixanta de la Viquipèdia. Penseu en el camí d’ençà, els dies del mainframe no eren molts punts d’accés per als quadres principals, de manera que la seguretat era fàcil, la còpia de seguretat era bastant senzilla, podríeu entendre què s’havia de fer, només calia entrar i fer. ella Per descomptat, llavors no hi havia molta gent que sabés què fer, però els que ho feien, estava bastant clar què havíeu de fer. I no hi havia molta preocupació per això. Teníeu el problema puntual, però no era tan comú.
En aquell moment, aquest tema era bastant fàcil, avui, no tant. Heus aquí la imatge: en realitat, Hèrcules lluita contra la Hidra. Per a aquells que no sou una gran mitologia, l’Hidra era una criatura molt fastigosa perquè tenia múltiples caps, i en qualsevol moment que us encavaves, en sortíeu dos més al seu lloc, de manera que parla del repte de tractar alguns dels problemes que trobeu a la vida, concretament en aquest context, estava realment orientat als nois dolents. Treus un noi dolent, dues persones més al seu lloc. I ho veieu al món de la pirateria, francament, és una gran indústria en aquests dies i és només un dels grans reptes que ens té davant.
Llavors, penseu si voleu dissenyar la vostra estratègia de resiliència de dades, de què us heu de preocupar? Bé, hi ha moltes coses per preocupar-se: desastres, incendis, inundacions. Vaig passar molt de temps al sud i a Nova Orleans, per descomptat, té algunes històries interessants sobre huracans i inundacions, etc. I hi ha moltes vegades que apareix un error humà, hauria de dir. I aquest va ser el cas fins i tot a Katrina a Nova Orleans, perquè sí, va passar un huracà, és a dir un acte de Déu, com diuen, una força major . No obstant això, va ser un error humà que va provocar l’huracà que va provocar diversos incompliments de les taxes. Així doncs, n’hi havia tres, de fet, n’hi havia un al canal industrial, i el problema que hi ha no tenia un vaixell amarrat correctament al riu avall. I l’huracà va entrar i empenyent-lo pels seus amarradors, i en realitat va filar l’agulla que girava al revolt, on el riu es doblegava a la part de fora de Nova Orleans i va sortir just al canal industrial i es va estavellar per una d’aquestes parets. Així que, tot i que sí que va ser un desastre natural, va ser un error humà el que va donar lloc a un gran problema.
I el mateix es va produir a l’altra banda de la ciutat, on hi havia una secció de l’impost que no s’havia completat mai, aparentment perquè la ciutat i el cos d’enginyers de l’exèrcit no havien acordat mai qui ho pagaria. Doncs bé, no és necessari que un científic coet esbrini que si teniu un gran forat a la vostra taxa, no és un impost molt efectiu. Per tant, la qüestió és que l'error humà realment entra en l'escenari on es produeix el desastre. Així que, fins i tot si es tracta d’un incendi, o si es tracta d’una inundació, o si es tracta d’un terratrèmol, o qualsevol que sigui el cas, és probable que algú pugui tenir i hauria d’haver fet per preparar-se per a un esdeveniment d’aquest tipus. I, per descomptat, això és el que tradicionalment anomenem recuperació de desastres. Per tant, sí, es produeixen desastres, però els éssers humans haurien de veure realment aquestes coses i preparar-se en conseqüència. Avui en parlarem una mica amb això.
Així doncs, els empleats descontents - no menystingueu els danys que un empleat descontent pot fer - estan fora, són a tot arreu. Conec persones que m’han explicat històries d’unes coses realment desagradables que han passat, on la gent només fa coses dolentes, saboteja intencionadament la seva pròpia organització, perquè no és feliç. Potser no van aconseguir una pujada o van acomiadar-se, o qui sap què va passar. Però això és molt a tenir en compte, i és un component molt significatiu. En el cas de la concessió de llicències, també, de la mateixa manera que la FYI hi ha, persones. Una de les estadístiques que he escoltat és semblant al 60% de tots els consells que les empreses de programari reben per no pagar els honoraris de llicència provenen d’ex-empleats. Per tant, voleu assegurar-vos que heu comprat aquest programari i que l'heu aconseguit just i quadrat. El sabotatge corporatiu no passa tot el temps, però sí. Els problemes de privadesa també entren en la barreja; heu d’anar amb compte amb el que emmagatzeneu i com s’emmagatzema, pensar realment a través d’aquestes coses.
I sempre intento recordar a la gent pel que fa a la regulació, és realment important tenir un pla i executar-lo, ja que quan es tracta d’empènyer o entra algun auditor o un regulador, voleu apuntar-vos al vostre política que tingueu i, a continuació, expliqueu com és que abordeu aquesta política quan passen determinades coses, com per exemple un desastre, com ara un problema de la vostra audició o qualsevol que sigui el cas. Voleu saber el que esteu fent i tenir un registre d’això: haurà de recórrer un llarg camí per mantenir l’auditor i la palma, i només són coses bones.
Per tant, els hackers, per descomptat, vaig a parlar un parell de minuts sobre els pirates informàtics i per què representen aquesta amenaça. I, per descomptat, ransomware, només cal dir tot aquest cas amb WannaCry, el ransomware WannaCry, que acabava de cobrir el planeta de forma molt curta i, aparentment, algunes persones poc simpàtiques per a un munt d’informació de la NSA, hi havia eines de pirateria que s’utilitzaven i exposat. Així que, recordo a la gent, hi ha una antiga faula, la Fàbula d’Esop, que diu que sovint donem als nostres enemics les eines de la nostra pròpia destrucció. Això és una cosa que cal tenir en compte, perquè, de nou, aquesta tecnologia va ser confonada per l'Agència Nacional de Seguretat de l'Agència Nacional de l'Associació Nacional de Seguretat (no pot recordar de què es refereix, en realitat). Però es va exposar, va sortir al món i només va causar estralls. Endevina què? I moltes empreses no havien actualitzat el seu entorn Windows, de manera que era un sistema antic, penseu que es tractava de Windows XP, que estava compromès. Una vegada més, si esteu diligent, si esteu al capdavant dels vostres pedaços i de les versions del vostre sistema operatiu i si feu una còpia de seguretat de les vostres dades i restauren les vostres dades. Si esteu fent totes les coses que hauríeu de fer, coses no són tan importants. Però només podeu dir a les persones que són axmen: "Eh, endevineu què? No ens importa, apagueu el sistema, reinicieu-lo, carregueu les còpies de seguretat. ”I sortireu a les carreres.
Per tant, la qüestió és que sí, aquestes coses dolentes passen, però hi ha coses que podeu fer al respecte - d'això parlarem avui a la programació. Així, doncs, vaig fer algunes investigacions, de fet, va ser una mica interessant, si aneu a la Viquipèdia i busqueu pirateria, va fins al 1903. Quan un tipus va piratejar un sistema per a telègrafs i va enviar missatges grollers a través del telègraf, Només per demostrar que el podria piratejar, suposo. Em va semblar divertit. La qüestió és que els pirates informàtics bàsicament són bons a l'hora de trencar i entrar, això és el que fan des de fa anys, anys i anys. Són com els bloquejadors del món modern d’internet.
I heu de recordar que qualsevol sistema es pot piratejar, es pot piratejar des de dins, es pot piratejar des de fora. Moltes vegades, quan es produeixen aquests hacks, no es mostraran, o les persones que entren al vostre sistema no faran gaire cosa durant un temps. Esperen una estona; Hi ha una mica de l'estratègia i, en part, només es deu al fet que els negocis funcionen, perquè normalment els pirates informàtics són que només fan la seva part del programa, de manera que molts nois que són capaços de penetrar tallafocs i sistema d’informació penetrant, així és el que fan millor i, un cop penetren un sistema, es donen la volta i intenten vendre aquest accés a algú. I això fa temps, de manera que sovint es dóna el cas que algú darrere de les escoles només intenta vendre accés a qualsevol sistema que hagin piratejat –el vostre sistema, potencialment, que no seria gaire divertit– i intenten esbrinar qui realment serà. pagar per l’accés al sistema.
Per tant, hi ha una mena de xarxa desvinculada d’individus o organitzacions que hi ha, que col·loquen i col·laboren per fer ús de la informació robada. Tant si es tracta d’un robatori d’identitat, com de robatori de dades, si la vida li resulta desagradable per a una empresa, aquest és el cas d’aquest ransomware, aquests nois només s’apodereu dels vostres sistemes i demanen diners, i si aconsegueixen diners, potser o potser no donaran les coses. Per descomptat, això és la veritable por, per què fins i tot voldríeu pagar aquest rescat? Com saps que el tornaran? Podrien simplement demanar el doble o el triple. Així que, de nou, tot això parla de la importància de pensar realment a través de la vostra estratègia d’informació, la vostra capacitat de resiliència per a les vostres dades.
Per tant, vaig fer algunes recerques més, és a dir un vell 386; si ets vell com jo, podries recordar aquests sistemes. I no eren tan problemàtics quant a pirateria; no hi havia molts virus en aquell moment. Actualment, és un joc diferent, per tant, Internet arriba i, tot canvia. Tot està connectat ara, hi ha una audiència global a fora, els primers grans virus van començar a atacar, i realment la indústria de la pirateria ha començat a globus, francament.
Així doncs, parlarem una mica sobre IoT, ja tenim una bona pregunta per part d’un membre d’audiència: Com puc protegir els dispositius IoT des del punt de vista de la vulnerabilitat? Aquest és un gran problema: francament, es fa un gran esforç en aquest moment en com afronteu el potencial de la pirateria dels dispositius IoT. És molt útil, els problemes habituals en els quals es centra, protecció de contrasenya, per exemple, passant pel procés d’instal·lar-lo amb cura, de configurar la vostra pròpia contrasenya. Moltes vegades la gent només deixarà una contrasenya per defecte i això de fet derivarà en la vulnerabilitat. Per tant, són coses bàsiques. Al nostre programa de ràdio, només teníem un altre programa de seguretat a principis d’aquesta setmana, amb diversos experts allà i tots van dir que s’evitarien el 80-90 o més per cent dels problemes de pirateria, ja fos IoT o ransomware, o qualsevol altra cosa. només heu tractat els fonaments bàsics, si només heu assegurat que teníeu les bases cobertes, heu fet totes les coses bàsiques, que sabeu que hauríeu de fer, i que suposa més del 80 per cent de tots els problemes que hi ha.
Per tant, Internet de les coses, està bé, IoT. Bé, si penseu en IoT, no és tota la novetat. Francament, hi ha fabricants de gamma alta que fan aquest tipus de coses fa 20 i 30 anys, i després fa uns 15, 20 anys, és quan va arribar la RFID (etiquetes d’identificació de freqüència de ràdio), que havien estat extremadament útils per ajudar molt grans. organitzacions, com els minoristes, per exemple, les empreses navilieres, qualsevol empresa de productes que traslladin coses per tot el país, arreu del món, és extremadament útil tenir totes aquestes dades, esbrineu cap a on van les vostres coses; si alguna cosa desapareix, t’assabentes.
Per descomptat, no és una solució insensible, de fet, tenia el meu ordinador portàtil, el meu Apple desconcertat, de l'aeroport d'Atlanta - l'aeroport de Hartsfield d'Atlanta, algú només em va agafar la bossa amb el meu ordinador. Vaig pensar que ja no roben bosses; sempre troben bosses, equivocades. Algú va robar la bossa i després va aparèixer un mes després, es va despertar, vaig rebre un petit missatge d’Apple, des d’i iCloud que despertava uns set a deu minuts al sud de l’aeroport d’Atlanta Hartsfield; algú només va decidir endinsar-s’hi. Acabaven d’estar al voltant d’un mes i vaig passar pel procés bastant frustrant d’adonar-me, bé, d’acord, sé aproximadament on és, pot ser que sigui en aquesta casa, aquella casa, la casa del carrer, només hi era temporalment. Què fas? Com, com és útil aquesta informació?
Així, tot i que encara que aprenguis alguna cosa, de vegades no pots fer-ho molt. Però, tot i així, he de dir que aquest món amb IoT crec que no estem prou preparats per a ser-ho sincer. Crec que tenim un cas on hi ha molta bona tecnologia i potser ens movem massa ràpidament per aprofitar aquestes coses, perquè l'amenaça és tan important. Només pensem en el nombre de dispositius que ara formen part del paisatge amenaçador, ja que la gent en parla, és una enorme onada de dispositius que ens surt.
Alguns dels grans hacks que s’han produït recentment, eliminant els servidors DNS, tenien a veure amb els dispositius IoT cooptats i girats contra servidors DNS, només els clàssics hacks DDoS, que denegen el servei, on, literalment, aquests dispositius es reprogramen per trucar. en un servidor DNS a un ritme contundent, on obtindreu centenars de milers de sol·licituds en aquest servidor DNS i només sufoca, es bloqueja i morirà. És el tipus de cosa en què es va estavellar la història del fantàstic en un lloc web no tan popular que els servidors només no estan dissenyats per a aquest tipus de trànsit.
Per tant, IoT és només una cosa que cal tenir en compte, una vegada més, si es tracta de còpies de seguretat i restauració, és important recordar que qualsevol d’aquests atacs es pot produir en un moment donat. I si no esteu preparat per això, perdreu molts clients, perquè faràs molta gent molt descontenta. I tindreu que gestionar la reputació. Aquest és un dels nous termes que flota per aquí, "gestió de la reputació". Val la pena recordar i apreciar que la reputació pot trigar anys a construir-se, minuts o fins i tot segons, a perdre's. Per tant, només cal tenir-ho en compte a mesura que planifiqueu la vostra estratègia d’informació.
Llavors, hi ha tot aquest concepte del núvol híbrid. Tinc una de les meves pel·lícules més antigues i preferides des de la infància, L’illa del doctor Moreau allà on van crear aquestes coses de mig animal i mitja criatura, que és com el núvol híbrid. Així, doncs, els sistemes locals estaran aquí durant anys (no us equivoqueu al respecte, trigarà molt a acabar els centres de dades en premissa i, fins i tot, a les empreses petites que tindreu moltes dades sobre els clients dels vostres sistemes i les vostres unitats, i com més complexa sigui aquesta situació, més difícil serà mantenir-se al capdamunt. Dit això, consolidar-se en una base de dades sempre és un repte real, especialment amb un sistema com MySQL, per exemple.
Mai és molt fàcil fer-ho per intentar incloure-ho en un sol sistema. Normalment, quan es fa, hi ha problemes, tenen problemes de rendiment. Llavors, de nou, ja serà un problema des de fa temps. Les infraestructures antigues existents als centres de dades i empreses, per descomptat. Aquest era el problema de WannaCry, és que teniu tots aquests sistemes XP: Microsoft ja no admet XP. Per tant, només és sorprenent com es podrien evitar alguns d'aquests problemes que es converteixen monetàriament en tan greus i tan dolorosos i d'una altra manera, amb el manteniment i el manteniment bàsics. Coses bàsiques.
Així doncs, hi haurà un desfasament de competències; aquestes llacunes en habilitats aniran augmentant amb el pas del temps, perquè el núvol és el futur, no crec que hi hagi cap dubte al respecte: el núvol és on van les coses; Ja hi ha un centre de gravetat al núvol. I el que veuràs és cada cop més empreses, cada vegada més organitzacions mirant al núvol. Per tant, això deixarà algunes llacunes en les habilitats al costat de la premissa; encara no hi és, però arriba. I fins i tot pensar en les amortitzacions, de manera que moltes empreses grans no poden simplement desplaçar-se al núvol. Podrien, però no tindria cap sentit, rendible, perquè amortitzen tots aquests actius. de tres, a cinc, a set anys, potser.
Això crea un període de temps força significatiu, durant el qual migraran lluny de les instal·lacions anticipades i cap a l'entorn del núvol. I, francament, hem arribat al punt, on local és probablement menys segur que el núvol. Molt divertit, perquè va ser el cop més important: les companyies estaven preocupades per anar al núvol per raons de seguretat, estaven preocupades perquè el núvol fos susceptible d’hacks. Bé, encara ho és, certament, però realment si ens fixem en els nois grans: Amazon, Microsoft, encara ara, SAP i Google, tots aquests nois, són molt bons amb aquestes coses, són força bons per assegurar el núvol. ella mateixa.
I, per descomptat, finalment al costat dels sistemes datats al costat prem: aquestes aplicacions s’allunyen molt a la dent avui dia. Vaig escoltar una broma una vegada, la definició de software heretat és qualsevol programari que es produeixi. (Riu) Crec que és una mica divertit. Per tant, sobre els sistemes de núvols, vaig esmentar els principals jugadors, que cada dia només creixen. AWS encara domina aquest espai, tot i que Microsoft segons el seu crèdit ha tingut en compte algunes coses i es concentren molt intensament. SAP, el SAP HANA Cloud, és la plataforma HANA Cloud que en diuen: és una enorme àrea d’atenció a SAP i per raons òbvies. Saben que el núvol ara té gravetat, saben que el núvol és una excel·lent zona de màssia per a la tecnologia.
Aleshores, el que veieu és aquesta consolidació entorn de les arquitectures del núvol i tindreu molt de treball en els pròxims dos anys sobre la migració núvol a núvol. Fins i tot la gestió de dades magistrals als núvols es convertirà en un gran problema. I Salesforce, mira el que s'ha convertit en Salesforce, és imprescindible tenir en compte. A més, es tracta de sistemes de màrqueting al núvol; Hi ha alguna cosa com ara 5.000 empreses de tecnologies de màrqueting: 5.000! És una bogeria. I esteu veient més esforços en aquest únic panell de vidre, per poder gestionar entorns multi-núvol. Una última diapositiva de mi, i després la lliuraré a Tep per donar-nos alguns consells sobre com podem estar al capdavant del joc, aquí.
Això, ja vam parlar al meu programa de ràdio a principis d’aquesta setmana, el model de núvol de responsabilitat compartida. Aleshores, del que parlen és de com AWS va ser responsable de la seguretat del núvol, de manera que la seguretat del núvol. Podria veure computar botigues, xarxes de bases de dades, etc. Però el client és responsable de les dades i la seguretat al núvol. Bé, va ser graciós perquè utilitzen aquest terme "responsabilitat compartida" i el que vaig recollir dels convidats del nostre programa és que realment no es comparteix. La idea és, és la vostra responsabilitat, perquè les probabilitats són si l’empenta arriba a evitar i algú infecta el vostre entorn, probablement AWS no serà responsable, ho és.
Per tant, és una mena estranya, crec que és un terme duplicat, “responsabilitat compartida” perquè realment no és, encara és la seva responsabilitat de mantenir-se al capdavant de totes aquestes coses. Així, amb això, i sé que he parlat una mica sobre el IoT: teníem una bona pregunta sobre com assegurar dispositius IoT - hi haurà una gamma absoluta de tecnologies per poder fer-ho. Evidentment, teniu algun programari en algun firmware dels mateixos dispositius IoT, així que cal tenir en compte; us heu de preocupar de qualsevol protocol d’autenticació que hagueu d’utilitzar per a aquestes coses. Però, com dic, els conceptes bàsics, probablement tindreu la major part dels problemes que us trobareu, només fent protecció de contrasenya, canviant les contrasenyes i realment mantingueu al capdavant, vigilant aquestes coses i vigilant .
Moltes de les tecnologies que s’utilitzen per controlar el frau, per exemple, o l’activitat nefasta a les xarxes se centren realment en els outliers, i això és una cosa que en realitat l’aprenentatge automàtic és bastant bo, a l’agrupament i a la vigilància dels outliers, vigilant estranys patrons de comportament. Com, francament, el que vam veure amb aquest recent atac de DDoS als servidors DNS, on de sobte tots aquests dispositius comencen a enviar una devolució de trucades a un determinat grapat de servidors, no es veu bé. I, francament, el que sempre recordo a la gent amb aquests sistemes: sempre que tingueu una automatització seriosa en aquest tipus d’ambients, sempre tingueu la substitució manual, tingueu l’interruptor de matança, voleu tenir programat un tipus d’interruptor de matança allà per tancar-se. aquestes coses estan a la baixa.
De manera que, amb això, tiraré la primera diapositiva de Tep, que farà algunes demostracions per a nosaltres. A continuació, us donaré les claus de la pestanya WebEx. Ara, arriba el vostre camí i traieu-lo.
Tep Chantra: Bé, gràcies, Eric. Em dic Tep Chantra i sóc responsable del producte aquí a IDERA. Avui, volia parlar de la solució de còpia de seguretat d’empresa IDERA, és a dir SQL Safe Backup. Si els que coneixeu el Backup segur de SQL us donem un cop d’ull a alguns aspectes destacats del producte que em disculpen. Així, tal com ja ho heu endevinat, la gent diu que la còpia de seguretat, el backup i el restauració del producte de SQL Server, una de les principals característiques de SQL Safe és la possibilitat de realitzar còpies de seguretat ràpides. I és una característica important, tenint en compte que la majoria de còpies de seguretat s’han de fer i, en la majoria dels casos, s’han de fer molt ràpidament, en una petita finestra.
Ara bé, en alguns entorns, trobar les finestres de còpia de seguretat pot ser un repte, sobretot quan teniu diverses bases de dades grans a les quals s’ha de fer una còpia de seguretat. La capacitat de SQL Safe de completar les operacions de còpia de seguretat permet als usuaris finals poder satisfer les finestres de còpia de seguretat. Parlant de grans bases de dades, fer còpies de seguretat de les grans bases de dades, òbviament fitxers de còpia de seguretat més grans. Una altra característica on brilla SQL Safe és la capacitat de comprimir fitxers de còpia de seguretat. L’algoritme de compressió utilitzat pot arribar a comprimir fins a un 90-95 per cent. Això significa que podeu emmagatzemar còpies de seguretat més temps o permetre un estalvi de costos en termes de necessitats d’emmagatzematge.
Al costat del flip de les operacions de còpia de seguretat, teniu operacions de restauració. Una de les batalles que han de lluitar els DBA per restaurar bases de dades és que cal recuperar les bases de dades el més ràpidament possible. En casos de grans bases de dades, la restauració completa d’un fitxer de còpia de seguretat pot trigar diverses hores, cosa que òbviament significa temps d’inici més llarg i possiblement pèrdua d’ingressos. SQL Safe, afortunadament, té aquesta característica anomenada "Restauració instantània", que bàsicament redueix el temps entre quan inicieu una restauració i quan els usuaris finals o fins i tot les aplicacions poden accedir a la base de dades.
Recordo que vaig parlar amb un client una vegada, on va informar que la restauració d’una base de dades en concret havia trigat 14 hores. Però, amb la funció de restauració instantània, va poder accedir a la base de dades en una hora o menys. La gestió basada en polítiques, un altre element més destacat de SQL Safe és la capacitat de crear polítiques i de gestionar les operacions de còpia de seguretat mitjançant aquestes polítiques. Quan configureu una política, bàsicament definiu quines instàncies es faran una còpia de seguretat o quines bases de dades en aquestes instàncies es volen fer una còpia de seguretat, quin tipus d’operacions de còpia de seguretat es realitzaran, i fins i tot la programació en què s’hauran de fer aquestes còpies de seguretat.
A més, també podeu configurar les notificacions d'alerta. D’aquesta manera es pot notificar sobre esdeveniments com ara la còpia de seguretat finalitzada amb èxit, les còpies de seguretat van fallar, potser es podrien veure, però hi ha alguns avisos associats a aquesta operació. També se us notificarà si una còpia de seguretat no s’executava tal com estava programat. Es tracta d’una notificació important, perquè és possible que tingueu en risc una finestra de temps on no existia una còpia de seguretat. I rebre una notificació així us indicarà que heu de sortir-hi i fer que aquesta còpia de seguretat s'executi i, possiblement, fer alguna investigació sobre el motiu pel qual aquesta còpia de seguretat no es va executar tal com estava previst.
Algunes d’altres coses, vegem aquí, la reflexió que tolera les errades, significa essencialment que podem crear fitxers de còpia de seguretat duplicats en més d’una ubicació. Així, per exemple, diguem que teniu una destinació de destinació a la vostra base principal: quin és el vostre emmagatzematge principal, on van tots els vostres fitxers de còpia de seguretat. Tanmateix, és possible que tingueu la necessitat de tenir una còpia del mateix fitxer de còpia de seguretat, per exemple a la màquina local, per si us cal fer alguna prova addicional, assegureu-vos que es pugui restaurar aquesta base de dades, sigui quin sigui el cas. Optimitzar la base de dades de SQL Virtual, el que és essencialment és que tenim un altre producte que s'ha integrat recentment a SQL Safe, anomenat base de dades virtual de SQL.
Com he esmentat, és que recentment s'ha integrat, i que s'inclou realment dins del propi SQL Safe. Ara, el que la base de dades virtual SQL us permet essencialment fer, és crear una base de dades virtual. (Riu) Odio utilitzar els mateixos termes que la definició, però el que passa essencialment és que muntarem una base de dades i basem el fitxer de còpia de seguretat. Per tant, el que passa essencialment és que SQL Server creu que la base de dades està en funcionament, mentre que en realitat està llegint dades del fitxer de còpia de seguretat, en lloc de crear la base de dades real en el sistema de fitxers.
Això és de gran ajuda perquè us permet accedir a les dades que hi ha dins del fitxer de còpia de seguretat sense consumir espai de disc addicional, de manera que us resultarà útil, sobretot quan es tracta de bases de dades enormes que només cal que tingueu una vista ràpida. o bé, es pot treballar amb alguns Xifratge d’impacte zero: el que significa essencialment és que quan realitzem còpies de seguretat d’aquestes bases de dades, realment podem xifrar els fitxers de còpia de seguretat i, quan xifrem aquests fitxers de còpia de seguretat, no afegim cap càrrega addicional al real. rendiment del sistema. Per tant, és completament menyspreable. L’enviament de registres és una altra cosa que podem fer, quan les nostres polítiques, com he esmentat anteriorment, i pel que fa a la concessió de llicències avantatjoses, el que significa essencialment és que els nostres models de llicències permeten moure models de llicències d’una instància a una altra instància, amb uns quants clics simples del ratolí.
Seguint, fem un cop d'ull a l'arquitectura del producte en si. Per tant, hi ha bàsicament quatre components principals del producte. Comencem per l’esquerra, la Consola de gestió segura SQL i la consola web. Ambdues són essencialment interfícies d’usuari, una és el client d’escriptori i l’altra una aplicació web. Ambdues interfícies d'usuari obtenen dades del següent component, que és la base de dades de dipòsits segurs SQL. La base de dades del dipòsit emmagatzema bàsicament tot l'historial operatiu, totes les operacions de còpia de seguretat i restauració. Aquests detalls es guarden aquí. Totes aquestes dades que es troben al dipòsit són gestionades pel Servei de gestió segura de SQL, que és el següent component. El Servei de Gestió s’encarrega d’actualitzar la base de dades del dipòsit i d’enviar notificacions d’alerta. Les dades relatives a les operacions de còpia de seguretat i restauració provenen realment de l'agent de còpia de seguretat de SQL, que és l'últim component, a l'extrem superior dret.
L’agent de còpia de seguretat de SQL és un component que s’instal·la a tots els servidors que allotgen les instàncies de SQL Server que intenteu gestionar amb SQL Safe. I aquest és el servei que és el responsable de realitzar les còpies de seguretat i comprimir-les. Ara, en aquesta diapositiva, també hi ha un cinquè component, que no és completament necessari, però és una cosa agradable. I aquest és el nostre fitxer RDL de SQL Server Reporting Services. Això bàsicament us permet fer és desplegar alguns fitxers RDL al Servei d’informació de SQL Server per poder executar informes amb la nostra base de dades de dipòsits. I tenim diversos informes com ara la darrera vegada que es va executar la còpia de seguretat, detalls sobre les operacions de còpia de seguretat, què hi ha.
I disculpeu-me. Anem endavant i fem una ullada a la pròpia SQL Safe. Doneu-me un segon aquí. Doneu-me un segon per iniciar la sessió. Com veieu, ara he carregat l’aplicació web, però primer, realment voldria fer una ullada a l’aplicació d’escriptori. Per tant, deixeu-me disparar molt ràpidament. I aquesta és l’aplicació d’escriptori SQL Safe, quan es carrega per primera vegada, us porta a la vista d’avui a SQL Safe. Es tracta bàsicament d’una llista de totes les operacions de còpia de seguretat o de restauració que han passat fins avui. També us proporciona un estat ràpid del vostre entorn, com podeu veure aquí, afirma que les meves polítiques tenen una política, que estan en un estat correcte, que és bo, perquè només tinc una política i espero que no ho és . També us proporciona un resum de les operacions que han tingut èxit, les operacions que podrien haver fallat. En general, estic en bon estat: només fent una ullada ràpida, podeu veure tots els verds; estem bé anar.
A l'esquerra, podeu veure tots els servidors que us heu registrat a SQL Safe i els que esteu gestionant bàsicament. Si l’amplieu, podreu veure la llista de bases de dades d’aquest sistema. Si seleccioneu una base de dades determinada, podeu veure l’historial d’operacions d’aquesta base de dades en concret. No hi ha molt més a explicar, a banda que puguis avançar i realitzar còpies de seguretat ad hoc també des d'aquesta finestra, i és real i senzill. Permeteu-me que us ho demostri ràpidament. Només cal fer clic dret sobre ella i seleccionar l’operació que voleu fer. Amb aquest propòsit, us avançaré a escollir la base de dades de còpia de seguretat. I s’obre l’assistent de còpia de seguretat de SQL. A partir d’aquí, obtindreu això, com a instància amb la qual voleu realitzar la còpia de seguretat, i seleccioneu quines bases de dades voleu fer una còpia de seguretat. En aquest cas, he preseleccionat la màquina HINATA i aquesta base de dades Contoso Retail, perquè és el que havia destacat quan vaig triar l'opció. Tinc endavant i deixaré això de moment, però teniu l’opció de seleccionar més bases de dades de manera que, si voleu fer una còpia de seguretat de tota la base de dades d’usuaris, per exemple, podeu seleccionar aquest botó de ràdio i la preseleccionarà tota aquells. Deixa'm avançar i continua amb això.
A la pàgina següent de l'assistent. Aquí és on puc seleccionar el tipus de còpia de seguretat que vull realitzar, i teniu aquí diverses opcions. Això és: estic segur que es troben a totes les utilitats de còpia de seguretat, per exemple, podeu realitzar una còpia de seguretat completa, una còpia de seguretat diferencial, una còpia de seguretat de registre de transaccions o, en realitat, simplement podeu fer una còpia de seguretat del fitxer de la base de dades. També teniu les opcions de crear una còpia de seguretat de només còpia, que s’utilitza bàsicament quan no voleu embolicar-vos amb els LSM. Ara seleccionaré "no". I també teniu l’opció de verificar la còpia de seguretat després de completar la còpia de seguretat. D’aquesta manera us assegureu que la vostra còpia de seguretat sigui bona i es pugui utilitzar més endavant. Sempre és una d'aquestes funcions que voleu assegurar-vos que teniu, només per garantir una mica de seguretat que la còpia de seguretat es pot utilitzar.
Aquí trobareu el nom i la descripció de les dades. Es tracta, bàsicament, de metadades que podeu ajudar a identificar fàcilment per a què es va fer servir la còpia de seguretat, així que vaig a dir el propòsit de demostració aquí. I utilitzeu la còpia de seguretat de la base de dades per a la demostració. A continuació, aquí definim on volem guardar el nostre fitxer de còpia de seguretat i aquí teniu diverses opcions: Podeu desar-lo en un sol fitxer, podeu crear fitxers de banda, podeu seleccionar aquí la destinació de la destinació, nosaltres també és compatible amb el domini de dades. I això, Amazon ST núvol, per si és allà on voleu guardar la informació.
Passaré amb el fitxer únic per a aquesta demostració, això permet la resiliència a la xarxa, aquesta és una característica molt agradable dins SQL Safe en el sentit que si feu una còpia de seguretat a una ubicació de xarxa, és el que faig aquí, es pot veure des de l'arxiu primari. Si hi feu una còpia de seguretat a la ubicació de la xarxa, és possible que tingueu algun problema de xarxa. En alguns casos, si es contraresta el singlot de la vostra xarxa, l'operació de còpia de seguretat esgotarà completament. Bé, activeu l’opció de resiliència de xarxa, el que fa fonamentalment és si es troba un singlot de xarxa, el que fa bàsicament SQL Safe, ja que fa una pausa de la còpia de seguretat i espera un temps determinat i torna a intentar la ubicació de la xarxa. I si és capaç de connectar-se, només reiniciarà la còpia de seguretat just allà on la va deixar. D’aquesta manera, no passeu hores alhora per intentar executar aquesta còpia de seguretat i just quan s’acabi, s’hi ha trobat un singlot de xarxa. No venem l’operació de seguida, només esperem una mica i intentarem per completar-lo de nou.
Hi ha altres opcions en configurar-ho. Ara, bàsicament comporta l’interval en què intentem tornar, així que, en aquest sentit, si ens trobem amb un singlot de xarxa, s’intentarà tornar a accedir a la ubicació de la xarxa en deu segons. La segona opció aquí bàsicament us diu que si ens trobem amb les fonts de la xarxa, aquí ens explica 300 segons, per tant, cinc minuts en total, només vendrem completament l'operació de còpia de seguretat. I això té cinc minuts de seqüència, per tant, si tornem a intentar una i altra vegada, i d’aquí a cinc minuts, encara no podem restablir la connexió de xarxa, i així vendrem l’operació completament. Aquesta última operació aquí és bàsicament per a tota la durada de la còpia de seguretat, així que si perds deu segons aquí, restablir la connexió i tornar a perdre la connexió, si es repeteix bàsicament durant 60 minuts, aleshores aquesta operació esgotarà. I aquests estan configurats, com podeu veure, de manera que podeu adaptar-lo al vostre entorn.
Aquesta opció d’arxiu de miralls aquí, és la que us parlava anteriorment, que té un emmagatzematge que tolera les errades. Aquí és on podeu especificar una altra ubicació de còpia de seguretat, en cas que ho desitgeu. Deixaré aquest moment desmarcat, només perquè voldria tirar endavant i continuar. En aquestes finestres d’opcions, podeu definir coses com ara el vostre tipus de compressió que volem utilitzar per a aquesta operació de còpia de seguretat i si volem o no activar el xifratge del fitxer de còpia de seguretat. Oferim diverses opcions de compressió, fins i tot cap inclosa, si escolliu que no voleu tenir cap compressió. Per tant, només cal superar aquestes opcions ràpidament.
L’alta velocitat bàsicament intenta completar la còpia de seguretat el més ràpidament possible, incloent alguna quantitat de compressió. ISize està més centrat a incloure tanta compressió com sigui possible, perquè, perquè intentem comprimir-la, pot trigar una mica més i probablement utilitzar una CPU més. El nivell 1 significa essencialment la menor quantitat de compressió fins al nivell 4, la quantitat més gran de compressió que podem afegir. Aleshores, és una mica més detallat, típicament iSpeed: quina és la paraula? Intervalles compreses entre el nivell 1 i el nivell 2; fa una ullada al sistema per veure quina CPU i recursos disponibles hi ha i fer judicis sobre molta compressió. Hauria d’utilitzar entre el nivell 1 i el nivell 2.
ISIZ fa el mateix, excepte amb el nivell 3 i el nivell 4. Hi ha algunes opcions avançades aquí, com quantes hi ha a la CPU que hauríem d’utilitzar, aquí teniu l’opció de crear dades de mapeig per a la base de dades virtuals de SQL i també la nostra funció de restauració instantània. Podeu incloure els inicis de sessió de la base de dades i algunes altres opcions que alguns usuaris consideren molt valuosos, com ara generar comprovacions a partir d’aquest, de manera que poden comprovar-ho més endavant, per assegurar-se que els fitxers de còpia de seguretat són bons. Si passem a la pàgina següent, aquí és on configureu les notificacions. I podeu veure les diverses opcions que tenim aquí: notificar si la còpia de seguretat falla, notificar si es fa saltar la còpia de seguretat, per qualsevol motiu. Si la còpia de seguretat es cancel·la o si la còpia de seguretat es completa amb un avís i si ho desitgeu, podeu notificar-vos que la vostra còpia de seguretat està neta. Per a entorns on hi ha un gran nombre de bases de dades, pot ser que no sigui una cosa que voleu activar, només perquè és molt probable que la vostra còpia de seguretat tingui èxit i us enviaran correus electrònics.
A la pàgina següent podeu veure un resum del que heu definit, perquè causa aquesta operació de còpia de seguretat. I, si voleu, podeu avançar i fer clic en còpia de seguretat. Abans de fer clic a la còpia de seguretat, deixa’m endavant i et mostraré aquest botó “genera script”. Perquè allò que SQL Safe ofereix una interfície de línia d’ordres on realment es pot iniciar una operació de còpia de seguretat o restaurar, què té, mitjançant una línia d’ordres, un missatge de comandes DOS Si feu clic aquí a generar l'script, bàsicament us proporciona l'script real que podeu utilitzar, si voleu treure la còpia de seguretat de la línia de comandaments.
Una altra cosa neta és que també oferim procediments de botiga estesa i, en aquest cas, generem un script que executi aquesta mateixa operació de còpia de seguretat mitjançant procediments de botiga estesa, només una mica d’entrada ràpida que volia compartir. Per tant, anem i iniciem aquesta còpia de seguretat. I podeu veure que la còpia de seguretat ja ha començat. I aquesta base de dades és una mica gran, de manera que pot trigar una estona. Podeu veure que vaig córrer algunes vegades aquí, anteriorment, així que em portarà a qualsevol lloc des d’un minut fins a tres minuts. Aquest és un nivell 4, així que suposo que serà entre aquestes dues vegades.
Si us plau, revisem les polítiques. Com he esmentat anteriorment, les polítiques us permeten configurar les operacions de còpia de seguretat programades a tota la vostra empresa, per tant, tinc una política aquí, preconfigurada ja en lloc de crear-ne una de nova, anem endavant i mirem els detalls d’aquesta. Disculpeu-vos, el meu VM funciona al meu ordinador portàtil personal i sembla que fa que el ventilador sigui bastant dur. (Riu)
Eric Kavanagh: És bo, ja ho sabeu, jo us faré una pregunta mentre ho mirem aquí. L’IDERA fa servir molta captura de dades de canvis en termes de còpies de seguretat, o feu còpies de seguretat senceres cada cop? Com funciona això, ja ho sabeu?
Tep Chantra: Ho dius una vegada més, ho sento?
Eric Kavanagh: Sí, doncs, sabeu si IDERA utilitza CDC, canvia la tecnologia de captura de dades per fer còpies de seguretat més petites, o bé fa còpies de seguretat completes cada cop?
Tep Chantra: No ho crec. Recordo haver-ho vist anteriorment, en diverses entrades. I si recordo correctament, no, no estem aprofitant el CDC, per ser sincer, bàsicament deixem que SQL Server realitzi la còpia de seguretat, només captem les dades pel mig i la comprimim, resultant en es crea un fitxer de còpia de seguretat. Per tant, essencialment utilitzant això. Sí.
Ara bé, ara que tinc la meva política carregada … oh, ho sento, tens alguna altra pregunta?
Eric Kavanagh: No, així és. Endavant.
Tep Chantra: D' acord, així que ara que tinc la meva política carregada, podeu veure algunes coses ràpides aquí: nom, descripció, podeu definir quin tipus de política creareu, si és una política que es gestionarà, la programació serà gestionada per l'agent de SQL Server o la planificació serà gestionada per l'agent de còpia de seguretat de SQL Server. En la majoria dels casos voldreu utilitzar l'agent de SQL Server, perquè normalment és una cosa que funciona en qualsevol cas al vostre sistema, així podreu aprofitar el que hi ha disponible. A la pestanya de membres, és aquí on especifiqueu les instàncies de les bases de dades de seguretat que voleu fer una còpia de seguretat. I en aquest cas, podeu veure que he afegit totes les meves instàncies registrades i he especificat una base de dades específica que s’hauria de fer una còpia de seguretat. Ara, si volgués, podria seguir endavant i editar-les i dir: "Vull fer una còpia de seguretat de totes les bases de dades, o només bases de dades d’usuaris, o fins i tot bases de dades del sistema". El més maco d’això és que també puc fer servir comodins i crear. determinades bases de dades.
No faré aquest canvi aquí només perquè no vull fer cap canvi important a la meva configuració. Per tant, tornem a les opcions. I a les opcions, aquí és on definiu quin tipus de còpies de seguretat realitzareu i, si feu un cop d'ull aquí, tinc configurades còpies de seguretat completes, còpies de seguretat diferencials i grans còpies de seguretat configurades. I per a cadascuna d’aquestes còpies de seguretat, puc definir si vull utilitzar una quantitat específica de compressió o bé activar el xifrat. Igual que les opcions que hauríeu trobat a l'assistent ad hoc. I a les ubicacions, també podeu definir la destinació d’aquestes operacions de còpia de seguretat. Una de les coses bones de les polítiques és que també podeu definir si voleu seguir endavant i suprimir aquests fitxers de còpia de seguretat antics, en funció del nombre X de dies o de setmanes, que disposeu.
I això es pot configurar per a cada tipus de còpia de seguretat. Així que, podeu veure aquí, tinc les còpies de seguretat completes per suprimir al cap d’una setmana. Elimina el diferencial al cap de dos dies i vull que les meves còpies de seguretat es suprimeixin un dia. Això és realment agradable, perquè permet automatitzar l'escenari de maneig, fitxers de còpia de seguretat antics, mantenint només els que realment necessiten en funció del temps. A la pàgina següent definiu la programació i, de nou, la programació pot ser específica per a cada tipus d’operació de còpia de seguretat que haureu de completar, així que, per completar-la, la vaig a executar setmanalment, el diferencial la faig cada sis hores., els meus registres corro cada 30 minuts. A la pàgina següent és on configureu les notificacions i és essencialment el mateix tipus de notificacions que heu trobat a les còpies de seguretat ad hoc, l’única diferència és que teniu aquesta nova, altra opció on us podreu dir si la còpia de seguretat no s’inicia. segons el previst. Aquí és on podeu alertar sobre situacions en què les vostres còpies de seguretat no es van executar. Realment important, sobretot en els casos en què teniu determinats SLA per assegurar-vos que teniu còpies de seguretat disponibles en els moments que els necessiteu. I a la pàgina següent podeu veure el resum. Si hagués fet algun canvi, si he fet clic a "Finalitzar", es realitzaria els canvis, el guardarà i, per exemple, el guardarà al dipòsit de les tasques de l'agent SQL Server.
I només per mostrar-vos de forma ràpida, aquí teniu una política i un treball que he creat per a aquesta política en concret. I podeu veure que va crear tres feines diferents: una per a cada tipus de còpia de seguretat. Ara, realment ràpid, permeteu-me fer una ullada ràpida a la interfície HUD i al tipus de com, com he esmentat anteriorment, la base de dades virtual solia ser una que hem integrat a SQL Safe. Ara, com he esmentat, bàsicament enganya a SQL Server en creure que s'ha restablert una base de dades real quan en realitat estem llegint el fitxer de còpia de seguretat. Per tant, deixeu-me anar endavant i no un autèntic ràpid per als vostres nois. Permetin-me prendre un fitxer de còpia de seguretat. Aquí, deixeu-me prendre un quatre aquí mateix. El procés s'ha completat, i realment ràpid, si actualitzo les meves bases de dades aquí, podeu veure que la base de dades és accessible i SQL Server creu que és en directe, però en realitat, només estem llegint les dades de la base de dades.
Algunes altres funcions noves en aquesta versió són la possibilitat de realitzar còpies de seguretat mitjançant el format de còpia de seguretat més recent. És real útil per a aquells clients que necessiten fer ús de la nostra gestió basada en polítiques, però volen mantenir el format de fitxer SQL Server per qualsevol motiu. Ara, sé que se'ns ha acabat el temps, així que crec que m'agradaria avançar i aturar aquesta presentació, només perquè puguem fer algunes preguntes o no.
Eric Kavanagh: Sí, segur. Així, doncs, crec que una de les claus està en la gestió de polítiques, oi? Com en pensar en la política òptima i en què es basa? Somebviament, en alguns casos hi ha regulacions per preocupar-se, però en un negoci potser no està molt regulat; només cal que trobeu els moments òptims per realitzar les vostres còpies de seguretat i, suposo que obtindreu alguns informes sobre el temps que va trigar i el cost que tenia en termes de potència computacional i així successivament. Què entra a definir la política òptima?
Tep Chantra: És realment un cas per cas, cada entorn tindrà una política diferent respecte a quan s'haurien d'executar aquestes còpies de seguretat. A més, i això pot comportar el tipus de còpies de seguretat que s’executen, la programació en què s’executen i, en realitat, també depèn de les seves necessitats de recuperació, suposo que aquesta és la resposta.
Eric Kavanagh: D' acord, sí. I heu parlat de poder fer diferents tipus de còpies de seguretat i ratlles era una de les opcions. És a dir una mena de dades calentes i fredes, o quina és la lògica que hi ha darrere d’anar per banda, en contraposició a algun altre mètode?
Tep Chantra: Per tant, crec que la millor resposta que puc proporcionar és que, així, els fitxers ratllats, el que fonamentalment fem és escriure el contingut de còpia de seguretat en diversos fitxers diferents. Crec que la idea d’utilitzar fitxers de ratlles és que possiblement pugueu escriure els vostres fitxers de còpia de seguretat més ràpidament. Per exemple, podríeu tenir cada fitxer diferent a una ubicació diferent. Això també costa els mitjans de seguretat del servidor, ja que distribuïu els fitxers de còpia de seguretat a diferents ubicacions.
Eric Kavanagh: Hi ha algunes coses noves i fresques en termes de capacitats de restauració, oi? Perquè diguem que hi ha algun tipus d’esdeveniment, ja sigui un desastre natural o un ransomware, sigui quin sigui el cas. No heu de tenir només una opció per restaurar, oi? Podeu establir prioritats sobre què es restaura i quins tipus de dades? Es pot parlar de les opcions que hi ha?
Tep Chantra: Bé, en termes de restauració, he esmentat anteriorment que proporcionem la possibilitat de fer restauracions instantànies, cosa que fa que els usuaris puguin obtenir les dades més ràpidament, oi? I només per demostrar, ho vaig fer un abans, així que podeu veure aquí, que de nou, aquesta base de dades no és gaire gran, aquesta és la que funciona al meu portàtil. Així doncs, crec que potser és com dos concerts, però aquesta base de dades s'ha completat en 37 segons. Restauració real Per tant, em van trigar 37 segons abans de poder accedir a les meves dades, de manera que amb la restauració instantània vaig poder accedir a la meva base de dades en dos segons. Així doncs, us podeu imaginar com seria si la vostra base de dades fos molt més gran.
Eric Kavanagh: Sí, bon punt. I, per descomptat, parlàvem d’això abans de l’espectacle; Heu dedicat molt de temps a les primeres línies donant suport a les persones i heu passat a l’espai de gestió de productes, per tant, suposo que és un repte diferent. Però estàveu a les primeres línies: crec que és un lloc força bo per aprendre on la gent va malament i quins són alguns dels problemes. Què veieu com alguns dels entrebancs més habituals que la gent podria evitar si només pensessin a través d'aquest tema?
Tep Chantra: Algunes de les interrupcions comunes són simplement - suposo que com heu comentat anteriorment - programar les vostres còpies de seguretat. Hi ha hagut moments que he vist gent que intenta aprofitar-se, per exemple, les nostres polítiques, polítiques, polítiques que realitzen moltes còpies de seguretat i basant-lo en LSM. I en alguns casos, he vist que algunes persones també tenen alguna altra utilitat que realitza còpies de seguretat a les seves bases de dades que, efectivament, envia les polítiques d’enviament de registres, perquè les còpies de seguretat s’estan fent bàsicament fora de SQL Safe i no en som conscients. Principalment es tracta de planificar les coses, d'aquí prové el problema.
Eric Kavanagh: No em sorprèn. Doncs bé, aquesta ha estat una gran revisió d'alguns dels bloqueigs i solucions necessàries per mantenir feliç la vostra empresa, per mantenir els vostres clients feliços. Vull donar un gran agraïment a tothom, Tep Chantra, d’IDERA, que va entrar aquí, fer demostracions en directe, sempre és interessant, sempre és una mica arriscat fer la demostració en directe, però crec que això va anar força bé. Ja ho sabeu, són coses bàsiques, però és el que passa si, si no ho feu, tindreu tot tipus de problemes. Per tant, aquestes són les coses importants que fan les empreses.
Així que, Tep, gràcies pel vostre temps. Folks, arxivem tots aquests transmissions web per a la seva posterior visualització, de manera que normalment pots tornar en una hora o dues hores i consultar l'arxiu. Però, una vegada més, grans coses aquí, estem tractant d’ajudar a l’empresa a estar al capdavant de les coses, agraïm tot el vostre temps i atenció, persones que hi ha. Ens posarem al dia amb la propera vegada. Heu estat escoltant Hot Technologies. Cuida't, gent. Adeu.
