Співробітники компанії «Техопедія», 7 червня 2017 року
Винос: Ведучий Ерік Кавана обговорює резервне копіювання та відновлення з програмою IDERA Tep Chantra в цьому епізоді Hot Technologies.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Гаразд, панове, це середа о 4:00 східного періоду, для тих, хто на підприємницькому просторі технологій, ви знаєте, що це означає: пора гарячих технологій. Так, справді. Мене звуть Ерік Кавана, я буду вашим модератором сьогоднішньої події під назвою "Куленепробивна: як сьогоднішні бізнес-лідери залишаються на вершині". І люди, сьогодні ми будемо мати приємну, інтимну розмову; це буде Tep Chantra і твій справді приймає цю розмову. Ми будемо говорити про цілий ряд різних речей, включаючи відновлення після аварій, резервне копіювання та відновлення, але насправді термін, який я люблю використовувати в ці дні, є стійкістю даних - я чув це від джентльмена лише пару тижнів тому, і це дійсно, це має багато сенсу. Тому що це говорить про те, як важливо мати стійку інформаційну інфраструктуру під своїм бізнесом.
Це інформаційна економіка в наші дні, а це означає, що більшість компаній у певному сенсі покладаються на інформаційні активи, дані. Я маю на увазі, що навіть у роздрібних компаніях, навіть апаратних компаніях, справді будь-яка організація в наші дні матиме якусь інформаційну основу, або, принаймні, вони збираються, якщо вони в сучасну епоху, якщо ви хочете. Є декілька магазинів для мам та поп, які все ще можуть уникнути цього, але навіть там ви починаєте бачити набагато більше поширення інформаційних систем, багато з них, засновані в хмарі, відверто кажучи, але багато з них все ще знаходяться в приміщенні, поводження з операціями з клієнтами, триматись над речами, знати, що хочуть ваші клієнти, знати, що таке товарний запас, знати, що це було, вміти зрозуміти велику картину - це справді важливі речі.
Отже, стійкість даних - це термін, який я люблю використовувати; надмірність - ще один термін, який приходить на думку. Але ви хочете переконатися, що незалежно від того, що станеться, ваші працівники та ваша організація матимуть інформацію, необхідну для обслуговування ваших клієнтів. Отже, я пройдуся, лише сформулювавши аргумент, перш ніж Теп вступить і пояснить нам деякі речі, які відбувається в IDERA. Звичайно, IDERA зробила з нами досить багато веб-трансляцій за останній рік. Це дуже, дуже цікава компанія, вони зосереджені на деяких латунних заходах, блокуючи і вирішуючи, якщо потрібно, щоб вижити в інформаційній економіці. Ми наче зануримось.
Пуленепроникна інфраструктура - це насправді стара картина мейнфрейму, дивіться на це, це як на початку 1960-х з Вікіпедії. Ви думаєте про те, як повернутись назад, в дні мейнфрейму не було багато точок доступу для мейнфреймів, тому безпека була настільки легкою, резервне копіювання було досить простим, ви могли зрозуміти, що потрібно робити, просто потрібно було зайти і зробити це. Звичайно, тоді було не так багато людей, які знали, що робити, але ті, хто це робив, було абсолютно зрозуміло, що ти повинен робити. І цього не було занадто багато. У вас були випадкові випуски, але насправді це не все було так часто.
Ще в цей час цей матеріал був досить легким - сьогодні не так вже й багато. Отже, ось малюнок - це насправді Геракл, який бореться з гідрою саме там. Для тих із вас, хто не є великим в міфології, гідра була дуже неприємною істотою тим, що мала кілька головок, і кожного разу, коли ви відрубали одну, на її місце підійшли ще дві, тож це начебто говорить на виклик вирішення деяких питань, які ви зустрічаєте в житті, зокрема в цьому контексті, було дійсно орієнтовано на поганих хлопців. Ти виймаєш поганого хлопця, на їх місці з'являються ще двоє. І ви начебто це бачите в хакерському світі, відверто кажучи, це велика галузь в наші дні, і це просто одна з великих проблем, яка стоїть перед нами.
Отже, ви думаєте про те, якщо ви намагаєтеся скласти свою стратегію стійкості даних, про що ви повинні турбуватися? Ну, є багато чого турбуватися: катастрофи, пожежі, повені. Я провів багато часу на Півдні та Новому Орлеані, звичайно, є цікаві історії про урагани та повені тощо. І багато разів людська помилка вступає в п’єсу, потрапляє в картину, я повинен сказати. Так було навіть у Катріні в Новому Орлеані, адже так, ураган пройшов, це божий акт, як то кажуть, форс-мажор . Але, тим не менш, людська помилка призвела до урагану, що призвело до кількох порушень стягнення. Так, їх було троє, насправді один був на індустріальному каналі, і проблема там, коли корабель не був пришвартований належним чином, вниз по річці. І ураган увійшов, відштовхнувши його від причалу, і він фактично пронизав голку, минаючи за вигин, де річка загинається прямо за межами Нового Орлеана, і вона просто пішла прямо по індустріальному каналу і врізалася через одну з цих стін. Тож, хоча, це було стихійним лихом, все ж саме людська помилка спричинила цю величезну проблему.
І те ж саме сталося з іншого боку міста, де був розділ збору, який так і не був завершений, мабуть, тому, що місто та армійський корпус інженерів ніколи не домовлялися, хто збирається платити за це. Ну, не потрібно ракетному вченому, щоб зрозуміти, що якщо у вас є одна велика зелена дірка у вашому зборі, це не дуже ефективний збір. І так, справа в тому, що людська помилка дійсно грає в сценарій, де стикаються катастрофи. Тож, навіть якщо це вогонь, чи повінь, чи землетрус, чи будь-який випадок, можливо, хтось міг би і мав би зробити, щоб підготуватися до такої події. І звичайно, це те, що ми традиційно називаємо відновленням після аварій. Так, так, трапляються катастрофи, але люди повинні реально бачити це і готуватися відповідно. Ми трохи поговоримо про це сьогодні з Тепом.
Отже, незадоволені працівники - не варто недооцінювати шкоду, яку може заподіяти незадоволений працівник - вони там, вони скрізь. Я знаю людей, які розповідали мені історії справді неприємних речей, що трапилися, де люди просто роблять погані речі, вони навмисно саботують власну організацію, тому що вони нещасні. Можливо, вони не отримали підвищення, або їх звільнили, або хто знає, що сталося. Але це варто пам’ятати, і це дуже важлива складова. У випадку з ліцензуванням, також, як і колись вигадка, люди. Один із статистичних даних, які я чув, був приблизно на зразок 60 відсотків усіх порад, які отримують програмні компанії за несплату ліцензійних платежів від колишніх співробітників. Отже, ви хочете переконатися, що ви придбали це програмне забезпечення, і щоб ви отримали його справедливим і квадратним. Корпоративний саботаж не відбувається постійно, але він трапляється. Питання конфіденційності також входять в суміш; ви повинні бути обережними щодо того, що ви зберігаєте і як ви його зберігаєте, по-справжньому продумуйте ці речі.
І я завжди намагаюся нагадати людям з точки зору регулювання, це дуже важливо мати план і виконувати цей план, тому що, коли натискання приходить, або якийсь аудитор приходить або регулятор, ви хочете мати можливість вказати на ваш Політика, яку ви маєте, а потім поясніть, як саме ви вирішуєте цю політику, коли трапляються певні речі, наприклад, катастрофа, наприклад, питання, що підлягають аудиту, або в будь-якому випадку. Ви хочете знати, що ви робили, і мати це - це пройде довгий шлях, щоб утримати ревізора, і це просто хороші речі.
Отже, хакери, звичайно - я збираюся поговорити пару хвилин про хакерів і чому вони створюють таку загрозу. І звичайно викупне програмне забезпечення, просто скажіть, що це весь випадок із WannaCry, викупним обладнанням WannaCry, який просто покрив планету в дуже короткому порядку, і, мабуть, деякі розумні недоброзичливі люди для купу інформації з АНБ, там були інструменти для злому, які використовувались піддаються впливу. Отже, я нагадую людям, є стара байка, байка Езопа, яка говорить, що ми часто надаємо ворогам інструменти власного знищення. Про це слід пам’ятати, адже, знову ж таки, ця технологія була окупована АНБ, Асоціацією національної безпеки - насправді не пам'ятаю, для чого вона виступає. Але це було викрито, і вийшло у світ, і просто принесло хаос. Вгадай що? І багато компаній не модернізували своє середовище Windows, тому це було старим, думаю, що це Windows XP, що було поставлено під загрозу. Отже, знову ж таки, якщо ви старанно ставитеся, якщо ви залишаєтеся поверх своїх патчів та версій вашої операційної системи та якщо ви створюєте резервну копію даних та відновляєте свої дані. Якщо ви робите все, що ви повинні робити, подібні речі не є великою проблемою. Але ви можете просто сказати людям, які є аксемами: «Гей, здогадайся? Нас не хвилює, закриваємо систему, перезавантажуємо її, завантажуємо резервні копії. ”І ви їдете на гонки.
Тож справа в тому, що ці погані речі трапляються, але є речі, які ви можете зробити з цим - ось про що ми сьогодні поговоримо на шоу. Отож, я провів деякі дослідження - насправді це було цікаво, якщо ви переходите до Вікіпедії і шукаєте злому, це стосується аж до 1903 року. Коли хлопець зламав систему для телеграфів і посилав грубі повідомлення через телеграф, просто щоб довести, що він міг би зламати це, я думаю. Я думав, що це досить кумедно. Справа в тому, що хакери в основному хороші в злому і в'їзді, це те, що вони роблять роками і роками. Вони схожі на вибирачі замків у сучасному світі Інтернету.
І ви повинні пам’ятати, що будь-яку систему можна зламати, її можна зламати зсередини, її можна зламати ззовні. Багато разів, коли ці хаки трапляються, вони не проявлятимуть себе, або люди, які втручаються у вашу систему, не збираються багато часу робити. Вони чекають деякий час; Існує трохи стратегії, і почасти це просто тому, що ділова сторона їх роботи, тому що, як правило, те, що хакери роблять, це те, що вони просто виконують свою маленьку частину програми, тому багато хлопців, які добре проникають брандмауери та проникаюча інформаційна система. Ну, це те, що вони роблять найкраще, і як тільки вони проникають в систему, то вони обертаються і намагаються продати цей доступ комусь. А для цього потрібен час, тому часто трапляється так, що хтось за лаштунками просто намагається продати доступ до будь-якої системи, яку вони зламали - потенційно до вашої системи, яка б не надто весела - і намагається з'ясувати, хто насправді оплатити доступ до системи.
Отже, існує така різнорідна мережа людей чи організацій, які об'єднують і співпрацюють, щоб скористатися викраденою інформацією. Незалежно від того, чи це крадіжка особи, чи просто крадіжка даних, чи роблять вони життя неприємним для компанії - це справа з цим викупчиком, ці хлопці просто заволодівають вашими системами і вимагають гроші, і якщо вони отримають гроші, можливо, або можливо вони не повернуть ваші речі. Звичайно, це справді страшно, чому ви хочете навіть платити за цей викуп? Звідки ти знаєш, що вони збираються повернути його? Вони можуть просто попросити подвійний або потрійний. Отже, знову ж таки, це все говорить про важливість дійсно продумати вашу інформаційну стратегію, вашу стійкість до своїх даних.
Отже, я провів ще кілька досліджень, це старе 386; якщо ви такі, як я, ви могли б запам'ятати ці системи. І вони не були такими проблемними з точки зору злому; тоді ще не було багато вірусів. У наші дні це вже інша гра, тому, звичайно, приходить Інтернет, і все змінюється. Все зараз пов’язано, там є глобальна аудиторія, перші основні віруси почали атакувати, і справді хакерська індустрія почала балотуватись, відверто кажучи.
Отже, ми трохи поговоримо про IoT, у нас є гарне запитання вже від учасника аудиторії: Як захистити пристрої IoT від точки зору вразливості? Це велика проблема - відверто кажучи, зараз потрібно докласти чимало зусиль для того, як ти розбираєшся з можливістю злому пристроїв IoT. Це велика користь, звичайні проблеми, на які ви зосереджуєтесь, захист паролем, наприклад, проходження процесу ретельної настройки, встановлення власного пароля. Багато разів люди просто залишать там пароль за замовчуванням, і це фактично призведе до вразливості. Отже, це основні речі. Ми щойно провели ще одне шоу про безпеку на початку цього тижня, на нашому радіошоу, де було декілька експертів, і всі вони сказали, що 80–90 або більше відсотків проблем з злому, будь то IoT чи викуплене програмне забезпечення, чи будь-що інше, можна уникнути, якщо ви Ви просто розібралися з основами, якщо ви просто переконалися, що у вас є основи, ви зробили всі основні речі, які ви знаєте, що вам належить зробити, що вирішують понад 80 відсотків усіх проблем там.
Отже, Інтернет речей, гаразд, IoT. Ну, якщо ви думаєте про IoT, це не все так нове. Відверто кажучи, є виробники високого класу, які роблять подібні речі 20 і 30 років тому, а потім приблизно 15, 20 років тому, саме тоді з'явився RFID - радіочастотні ідентифікаційні теги - що було надзвичайно корисно в допомозі дуже великим такі організації, як роздрібні торговці, наприклад, транспортні компанії, будь-яка товарна компанія, яка переміщує речі по всій країні, по всьому світу, надзвичайно корисно мати всі ці дані, ви дізнаєтесь, куди відправляються ваші речі; якщо щось зникає, ви дізнаєтесь.
Звичайно, це не дурне рішення. Насправді у мене ноутбук, з яким Apple врятувався, з аеропорту Атланти - аеропорту Атланта Хартсфілд - хтось просто взяв мій мішок із моїм комп’ютером. Я думав, вони більше не крадуть мішки; вони завжди знаходять сумки - неправильно. Хтось викрав мішок, і тоді він з’явився приблизно через місяць, він прокинувся, я отримав невелике повідомлення від Apple, від iCloud, що він прокинувся приблизно за сім-десять хвилин на південь від аеропорту Атланта Хартсфілд; хтось просто вирішив зайнятися цим. Вони просто сиділи на ньому близько місяця, і я пройшов досить неприємний процес усвідомлення, ну добре, я знаю приблизно, де це, можливо, в цьому будинку, в цьому будинку, будинку через дорогу, це було просто тимчасово. Що ти робиш? Мовляв, наскільки ця інформація корисна для вас?
Тож, хоч щось і навчишся, іноді ти не можеш багато зробити з цим. Але, все-таки, цей світ з підтримкою IoT, я повинен сказати, я думаю, що ми не зовсім готові до цього, якщо чесно. Я думаю, у нас є випадок, коли там є багато хороших технологій, і ми можемо занадто швидко рухатись, щоб скористатися цими речами, оскільки загроза така значна. Ми просто думаємо про кількість пристроїв, які зараз є частиною загрози, оскільки люди говорять про це, це величезна величезна хвиля пристроїв, що надходять на наш шлях.
Деякі з великих хак, що траплялися нещодавно, зриваючи DNS-сервери, мали відношення до того, що пристрої IoT були кооптовані та повернуті проти серверів DNS, просто класичні хаки DDoS, розповсюджена відмова в обслуговуванні, де буквально ці пристрої перепрограмовані на виклик на DNS-сервері з блискучим темпом, де ви отримуватимете сотні тисяч запитів, що надходять на цей DNS-сервер, і просто задихається, збивається і гине. Це та річ, де історія чудового на не дуже популярному веб-сайті сервери просто розбилася - вони просто не створені для такого трафіку.
Отже, IoT - це щось, про що слід пам’ятати, знову ж таки, якщо ми маємо справу із створенням резервного копіювання та відновленням, важливо пам’ятати, що будь-яка з цих атак може статися в будь-який момент часу. І якщо ви до цього не готові, то ви втратите багато клієнтів, бо ви зробите багато людей дуже нещасними. І ви будете мати таке управління репутацією, щоб мати справу. Це один з нових термінів, який там плаває, «управління репутацією». Варто пам’ятати і цінувати, що репутація може зайняти роки, а також витратити хвилини і навіть секунди. Отже, просто майте це на увазі, коли ви плануєте свою інформаційну стратегію.
Отже, тут є вся ця концепція гібридної хмари. У мене є один із моїх старих, улюблених фільмів з дитинства, «Острів доктора Моро», де вони створили ці напівлюдини, напівживі речі, подібні до гібридної хмари. Отже, локальні системи будуть тут роками - не помиляйтесь, це займе багато часу, щоб завершити ці локальні центри обробки даних - і навіть у малому бізнесі ви матимете багато даних про клієнтів у ваших системах та ваших накопичувачах, і чим складніша ситуація стає, тим важче буде залишатися на вершині. Однак, консолідація в одній базі даних також завжди є справжньою проблемою, особливо, наприклад, у такій системі, як MySQL.
Намагатись збити все в одній системі ніколи не було дуже просто. Як правило, коли це робиться, виникають проблеми, ви отримуєте проблеми з продуктивністю. Отже, знову це буде проблемою вже досить давно. Спадкова інфраструктура там, в центрах обробки даних, і, звичайно, в бізнесі. Це була проблема WannaCry, чи є у вас всі ці системи XP - Microsoft більше не підтримує XP. Таким чином, просто дивно, як деякі з цих проблем, які стають настільки гострими та настільки болючими грошово і в іншому випадку, можна уникнути за допомогою основного обслуговування та обслуговування. Основні речі.
Отже, буде розрив у вміннях; ці прогалини у навичках з часом будуть зростати, тому що знову ж таки хмара - це майбутнє - я не думаю, що в цьому є жодних сумнівів - хмара - це те, куди йдуть справи; у хмарі вже є центр ваги. І все, що ви збираєтеся бачити, - це все більше компаній, все більше організацій, які дивляться в хмару. Таким чином, це дозволить залишити деякі прогалини у навичках на приміщенні; його ще немає, але він приходить. І навіть думати про амортизацію, тому багато великих компаній, вони не можуть просто перейти до хмари - вони могли, але це не мало би великого сенсу, витратно, тому що вони амортизують усі ці активи три, п'ять, сім років, можливо.
Це створює досить значне вікно часу, протягом якого вони збираються мігрувати подалі від хмарочосу та до хмарного середовища. І, чесно кажучи, ми дійшли до того, що локальні місця, ймовірно, менш безпечні, ніж хмара. Смішно, тому що це був великий стук протягом тривалого часу: компанії турбувалися про те, щоб перейти до хмари з міркувань безпеки, вони переживали за те, що хмара сприйнятлива для хаків. Ну, все одно, звичайно, але якщо ви подивитеся на великих хлопців: Amazon, Microsoft, навіть зараз SAP та Google, всі ці хлопці, вони досить добре в цьому, вони досить добре забезпечують хмару себе.
І тоді, звичайно, нарешті, на попередній стороні, датовані системи: ці програми в наші дні досить швидко проникають в зуб. Я почув жарт один раз: визначення застарілого програмного забезпечення - це будь-яке програмне забезпечення, яке виробляється. (Сміється) Я думаю, що це щось смішно. Отже, до хмарних систем я згадав про основних гравців, вони просто зростають з кожним днем. AWS все ще домінує в цьому просторі, хоча Microsoft, на їхню думку, дійсно розібрався з деякими речами, і вони зосереджені дуже ретельно. Так само і SAP, хмара SAP HANA, це називають платформу HANA Cloud - це величезна зона фокусування для SAP і з очевидних причин. Вони знають, що хмара зараз має силу тяжіння, вони знають, що хмара - це відмінна бойова зона для технологій.
Отже, те, що ви бачите, це консолідація навколо хмарних архітектур, і ви будете мати багато роботи в наступні два роки над міграцією хмари в хмару. Навіть головне управління даними в хмарах стане великою проблемою. А Salesforce - дивіться, наскільки великим став Salesforce - це абсолютна сила, з якою слід рахуватися. Також маркетингові системи знаходяться в хмарі; зараз є щось на зразок 5000 компаній з маркетингових технологій - 5000! Це божевілля. І ви бачите більше зусиль на цій одній скляній панелі, щоб мати можливість керувати мульти хмарними середовищами. Отже, останній слайд від мене, і тоді я передаю його Тепу, щоб дати нам поради, як ми можемо залишитися попереду гри, тут.
Про це ми говорили на моєму радіошоу раніше цього тижня, модель хмари спільної відповідальності. Отже, те, про що вони говорять, - це те, як AWS відповідав за безпеку хмари, тобто безпеку хмари. Можливо побачити магазини обчислень, мережі баз даних тощо. Але замовник відповідає за дані та безпеку в хмарі. Ну, це було смішно, оскільки вони використовують цей термін "поділена відповідальність", і що я начебто зібрався з гостей на нашому шоу, це те, що він насправді не поділений. Ідея полягає в тому, що це ваша відповідальність, тому що шанси є, якщо наштовхнеться, і хтось заразить ваше оточення, AWS, ймовірно, не несе відповідальності, ви.
Отже, це якийсь дивний світ, я думаю, це дещо неоднозначний термін, "спільна відповідальність", бо справді це щось не так, це все одно ваша відповідальність залишатися на вершині всього цього. Отже, з цим, і я знаю, я трохи поговорив про IoT - у нас було одне хороше питання про те, як захистити пристрої IoT - з'явиться абсолютний спектр технологій, які зможуть впоратися з цим. Очевидно, що у вас є якесь програмне забезпечення для деяких прошивок на самих пристроях IoT, тому це потрібно пам’ятати; ви повинні турбуватися про те, який протокол автентифікації ви повинні використовувати для цих матеріалів. Але, як я кажу, основи, ймовірно, переживають більшу частину неприємностей, з якими ви зіткнетеся, просто захистившись паролем, зробивши зміну паролів і по-справжньому залишаючись на цьому - моніторинг цих речей та перегляд .
Багато технологій, що застосовуються для моніторингу шахрайства, наприклад, або недоброзичливої активності в мережах, справді зосереджені на людях, і це те, в чому машинне навчання насправді дуже добре, в кластеризації та спостереженні за людьми, що спостерігають за дивними моделями поведінки. Відверто кажучи, те, що ми побачили під час цієї недавньої атаки DDoS на DNS-сервери, де раптом усі ці пристрої починають надсилати зворотний дзвінок на певну жменю серверів, добре, що це не виглядає добре. І, чесно кажучи, про що я завжди нагадую людям із цими системами: У будь-який час у вас є серйозна автоматизація в таких умовах, завжди маєте ручне переопрацювання, перемикач на знищення - ви хочете, щоб там був запрограмований якийсь перемикач убивств, щоб закрити ці речі вниз.
Отже, я маю наштовхнути перший слайд Тепа, він робитиме демонстрації для нас. І тоді я піду вперед і дам вам ключі на вкладці WebEx. Тепер він іде на ваш шлях, і забирайте його.
Теп Чантра: Добре, дякую, Еріку. Мене звуть Теп Чантра, і я тут менеджер продуктів у компанії IDERA. Сьогодні хотіли поговорити про рішення щодо резервного копіювання даних компанії IDERA, а саме про безпечне резервне копіювання SQL. Для тих, хто вам знайомий із безпечним резервним копією SQL, давайте коротко розглянемо деякі основні моменти продукту, які - вибачте. Отже, як ви вже здогадалися, люди кажуть, що резервне копіювання, резервне копіювання та відновлення продукту SQL Server, однією з ключових особливостей SQL Safe є можливість виконувати швидкі резервні копії. І це важлива особливість, враховуючи, що більшість резервних копій потрібно зробити, і в більшості випадків вони повинні бути зроблені дуже швидко, за невеликим вікном часу.
Зараз у деяких середовищах зустріч з цими вікнами резервного копіювання може бути досить складною проблемою, особливо коли у вас є кілька великих баз даних, які потрібно створити резервну копію. Здатність SQL Safe швидко виконувати операції з резервного копіювання дозволяє кінцевим користувачам мати можливість зустрітися з цими вікнами резервного копіювання. Якщо говорити про великі бази даних, то резервне копіювання цих великих баз даних, очевидно, великих файлів резервного копіювання. Ще одна особливість, де SQL Safe світить - це можливість стиснення резервних файлів. Використовуваний алгоритм стиснення може досягти приблизно 90–95 відсотків стиснення. Це означає, що ви можете зберігати резервні копії довше або дозволяти заощадити витрати з точки зору потреб у сховищі.
Що стосується операцій із резервного копіювання, у вас є операції відновлення. Однією з битв, з якою доводиться боротись АПД при відновленні баз даних, є те, що ці бази потрібно відновити якнайшвидше. У випадках великих баз даних повне відновлення файлу резервного копіювання може зайняти кілька годин, що, очевидно, означає триваліший час простою та, можливо, втрату доходу. На щастя, SQL Safe має цю функцію під назвою «Миттєве відновлення», яка в основному скорочує час між початком відновлення і тим, коли базі даних можуть бути доступні кінцеві користувачі або навіть додатки.
Я пам’ятаю, як один раз говорив із замовником, де він повідомив про відновлення однієї конкретної бази даних за 14 годин. Але завдяки функції миттєвого відновлення він зміг отримати доступ до цієї бази даних протягом години або менше. Управління на основі політики - ще одна важлива особливість SQL Safe - це можливість створювати політики та керувати своїми резервними операціями за допомогою цих політик. Коли ви налаштовуєте політику, ви в основному визначаєте, які екземпляри потрібно створити, або які бази даних щодо цих екземплярів слід створити резервну копію, які операції з резервного копіювання потрібно виконувати і навіть графік, за яким ці резервні копії мають відбуватися.
Крім того, ви також можете налаштувати сповіщення про сповіщення. Таким чином, ви можете отримувати сповіщення про такі події, як резервна копія успішно завершена, резервні копії не вдалися, можливо, це може побачити, але є деякі попередження, пов'язані з цією операцією. Ви також отримаєте сповіщення, якщо резервна копія не виконується, як було заплановано. Це важливе сповіщення, тому що ви, можливо, ризикуватимете вікном часу, коли резервної копії не існувало. І отримавши таке повідомлення, вам буде вказано, що вам потрібно вийти туди і зробити цю резервну копію, а потім, можливо, провести деякі дослідження щодо того, чому ця резервна копія не виконувалася, як було заплановано.
Деякі інші речі, давайте подивимось тут, дзеркальне відображення відмов, що по суті означає, що ми маємо можливість створювати дублікати файлів резервної копії в більш ніж одному місці. Наприклад, скажімо, у вас є основне цільове місце призначення як основне - головне сховище, куди збираються всі ваші резервні файли. Однак у вас може знадобитися копія одного і того ж файлу резервної копії, наприклад, на локальній машині, на всякий випадок, якщо вам потрібно зробити додаткове тестування, переконайтеся, що цю базу даних можна відновити, незалежно від конкретного випадку. Оптимізація віртуальної бази даних SQL - що, по суті, полягає в тому, що у нас є ще один продукт, який нещодавно був інтегрований у SQL Safe, під назвою SQL Virtual Database.
Як я вже згадував, це те, що нещодавно інтегровано, так це те, що фактично включено всередину самого SQL Safe. Тепер, що SQL Virtual Database по суті дозволяє вам зробити, це фактично створити віртуальну базу даних. (Сміється) Я ненавиджу, використовуючи ті самі терміни, що і визначення, але, по суті, трапляється те, що ми змонтуємо базу даних і базуємося на файлі резервної копії. Отже, що по суті відбувається, це те, що SQL Server вважає, що база даних насправді працює і працює, тоді як вона насправді зчитує дані з резервного файлу, а не створює власне базу даних у файловій системі.
Це справді корисно, оскільки дозволяє отримати доступ до даних, що знаходяться у файлі резервного копіювання, фактично не витрачаючи додаткового місця на диску, тому це дуже зручно, особливо коли ви маєте справу з величезними базами даних, які вам просто потрібно отримати, швидко перегляньте або виконайте якусь розробку. Шифрування нульового впливу - що, по суті, означає, що там, де ми виконуємо резервні копії цих баз даних, ми можемо фактично зашифрувати файли резервного копіювання, і коли ми шифруємо ці файли резервного копіювання, ми не додаємо додаткового навантаження до фактичного продуктивність системи. Отже, це зовсім незначно. Доставка вантажу журналів - це ще одна річ, яку ми можемо зробити, коли наша політика, як я вже згадувала раніше, і стосовно вигідного ліцензування - що, по суті, означає, що наші ліцензійні моделі дозволяють переміщувати ліцензійні моделі з одного примірника в інший, кілька простих клацань миші.
Переходимо далі, давайте коротко розглянемо архітектуру самого продукту. Отже, в основному є чотири основні компоненти продукту. Ми починаємо зліва, консоль безпечного управління SQL та веб-консоль. Вони по суті є інтерфейсами користувача, один - клієнт настільних ПК, а другий - веб-додаток. Обидва ці інтерфейси користувача витягують дані з наступного компонента - бази даних безпечного сховища SQL. База даних репозиторію в основному зберігає всю вашу операційну історію, всі операції з резервного копіювання та відновлення. Ці дані зберігаються тут. Усіма цими даними, що знаходяться у сховищі, керується Службою безпечного управління SQL, що є наступним компонентом. Служба управління відповідає за оновлення бази даних сховища та надсилання сповіщення про сповіщення. Дані щодо операцій із резервного копіювання та відновлення фактично надходять від агента безпечного резервного копіювання SQL, який є останнім компонентом, в крайній правій частині.
Агент резервного копіювання SQL Safe - це компонент, який встановлюється на всіх серверах, на яких розміщені екземпляри SQL Server, якими ви намагаєтесь керувати за допомогою SQL Safe. І це служба, яка насправді відповідає за виконання резервних копій та стиснення їх. Тепер на цьому слайді є також п'ятий компонент, який не зовсім необхідний, але це приємна річ. І це наші RDL-файли служб звітування SQL Server. Це, в основному, дозволяє вам зробити, це розгорнути деякі RDL-файли до служби звітування SQL Server, щоб ви могли запускати звіти проти нашої бази даних репозиторію. У нас є цілий ряд різних звітів, таких як востаннє запуску резервного копіювання, відомості про операції з резервного копіювання, що у вас є.
І вибачте мене. Давайте продовжимо та подивимось на сам SQL Safe. Дайте мені секунду тут. І дайте мені секунду, щоб увійти. Як бачите, я зараз завантажив веб-додаток, але, по-перше, я хотів би поглянути на настільний додаток. Отже, дозвольте мене швидко звільнити. І це настільний додаток SQL Safe, коли він вперше завантажується, він переводить вас у режим перегляду SQL Safe сьогодні. Це, по суті, перелічує всі операції з резервного копіювання або відновлення операцій, які відбулися на сьогодні. Це також дає вам швидкий статус вашого оточення, як ви бачите тут, в ньому йдеться про те, що в моїх політиках є одна політика, яка знаходиться в нормальному стані, що добре, тому що я маю лише одну політику, і я сподіваюся, що це не . Також надається підсумок операцій, які були успішними, будь-яких операцій, які можуть бути невдалими. В цілому я в хорошій формі: тільки швидко оглянувшись, можна побачити всю зелень; нам добре піти.
Зліва тут ви бачите всі сервери, які ви зареєстрували в SQL Safe, та сервери, якими ви керуєте. Якщо розгорнути його, ви побачите список баз даних у цій системі. Якщо ви вибрали певну базу даних, ви зможете переглянути історію експлуатації цієї конкретної бази даних. Немає нічого більшого пояснення, окрім того, що ви можете продовжувати та виконувати спеціальні резервні копії з цього вікна, і це справді швидко і просто. І дозвольте мені це швидко продемонструвати. Ви просто клацніть правою кнопкою миші по ньому і виберіть операцію, яку хочете зробити. І для цього я піду і виберу резервну базу даних. І відкриється майстер безпечного резервного копіювання SQL. Звідси ви отримуєте це, як, наприклад, на якому екземплярі, для якого потрібно виконати резервне копіювання, і вибираєте, до яких баз даних ви хочете створити резервну копію. У цьому випадку я попередньо обрав апарат HINATA та цю базу даних Contoso Retail, тому що саме це я виділив, коли вибрав варіант. Я продовжу і залишаю це наразі, але у вас є можливість фактично вибрати більше баз даних, так що, якщо ви хочете створити резервну копію всієї вашої бази даних, наприклад, ви можете вибрати цю перемикач, і вона буде попередньо обрана для всіх ті. Дозвольте мені йти далі і просто продовжувати це.
Перейти до наступної сторінки майстра. Тут я можу вибрати тип резервного копіювання, який я хочу виконати, і у вас є кілька різних варіантів. Це - я впевнений, що вони є у всіх утилітах резервного копіювання, наприклад, ви можете виконати повне резервне копіювання, диференціальне резервне копіювання, резервне копіювання журналу транзакцій, або ви можете просто просто створити резервну копію самого файлу бази даних. Ви також маєте можливість створити резервну копію лише для копіювання, яка в основному використовується, коли ви не хочете возитися з LSM. Я зараз виберу "ні". А також у вас є можливість перевірити резервну копію після завершення резервного копіювання - таким чином ви переконаєтесь у тому, що ваша резервна копія є доброю та її можна буде використовувати згодом. Це завжди одна з тих функцій, яку ви хочете переконатись у наявності, просто щоб дати вам трохи впевненості, що резервна копія корисна.
Тут ви знайдете ім'я та опис даних. Це, по суті, метадані, за допомогою яких ви можете легко визначити, для чого використовувалася резервна копія, тому я збираюся сказати тут демонстраційну мету. І використовуйте резервну копію вашої бази даних для демонстрації. Далі, тут ми визначаємо, куди ми хочемо зберегти наш резервний файл, і у вас є кілька різних варіантів тут: Ви можете зберегти його в одному файлі, ви можете створити файли смужок, у вас є можливість вибрати тут цільове призначення, ми також підтримують домен даних. І це, хмара Amazon ST, якщо ви хочете зберегти свою інформацію.
Я перейду до одного файлу для цієї демонстрації, це дозволить забезпечити стійкість мережі. Це дійсно приємна функція в SQL Safe в тому сенсі, що якщо ви створюєте резервну копію в мережевому розташуванні - що я тут роблю, ви можете бачити з основного архіву - якщо ви створюєте резервну копію в мережевому розташуванні, є ймовірність, що ви можете зіткнутися з деякими мережними ікотами. У деяких випадках, якщо ваші мережеві гики протистоять, операція резервного копіювання повністю розпродається. Що ж, увімкніть опцію стійкості мережі, що вона, по суті, полягає в тому, якщо виникає мережна іконка, що, по суті, робить SQL Safe, чи робить паузу резервної копії та чекає певної кількості часу та повторює спробу розташування мережі. І якщо він зможе підключитися, він просто відновить резервну копію прямо там, де вона припинилася. Таким чином, ви не витрачаєте години на час, намагаючись запустити цю резервну копію, і правильно, коли вона наближається до завершення, зустрічається мережева гикавка - ми не продаємо операцію відразу, ми просто почекаємо трохи і спробуємо щоб виконати його ще раз.
Існують деякі інші параметри при налаштуванні цього. Тепер це, в основному, тягне за собою інтервал, через який ми повторюємося, тому в цьому сенсі, якщо ми стикаємося з мережевою гикавкою, вона спробує знову отримати доступ до мережевого розташування за десять секунд. Другий варіант тут, в основному, говорить вам про те, що якщо ми стикаємося з мережевими ікотами, він говорить тут 300 секунд - так що, всього п'ять хвилин, - ми просто продаємо операцію резервного копіювання. І це п’ять хвилин послідовно, тож якщо ми повторимо знову і знову, і протягом цих п'яти хвилин ми все одно не зможемо відновити мережеве з'єднання, тоді ми повністю продаємо операцію. Ця сама остання операція тут в основному протягом усієї тривалості резервного копіювання, тому якщо ви втратите тут десять секунд, відновіть підключення, а потім знову втратите з’єднання, якщо це в основному повторюється протягом 60 хвилин, то ця операція буде розпродана. І вони налаштовані, як ви бачите, так що ви можете налаштувати його до свого середовища.
Цей параметр архівного дзеркала тут, про що я говорив раніше, маючи дзеркальне відбиття. Тут ви можете вказати інше місце резервного копіювання, на випадок, якщо вам це захочеться. Я зараз залишаю це без перевірки, лише тому, що я хотів би йти вперед і продовжувати. У цих вікнах параметрів ви можете визначити такі речі, як тип стиснення, який ми хочемо використовувати для цієї операції резервного копіювання, і чи хочемо ми включити шифрування для файлу резервної копії. Ми пропонуємо декілька різних варіантів стиснення, навіть не включаючи жодного, якщо ви вирішите, що взагалі не хочете стискатись. Отже, просто швидко перебрати ці варіанти.
Висока швидкість, як правило, намагається виконати резервну копію якомога швидше, включаючи деяку кількість стиснення. ISize більш орієнтований на включення якомога більшого стиснення, але це може - оскільки ми намагаємось його так стиснути - це може зайняти трохи більше часу, і, ймовірно, використовувати трохи більше процесора. Рівень 1 по суті означає найменший обсяг стиснення аж до рівня 4, найбільшу кількість стиснення, яку ми можемо додати. Отже, це трохи детальніше, як правило, iSpeed - що це за слово? Діапазон між стисненням 1 та 2 рівня; він повинен переглянути вашу систему, щоб побачити, скільки CPU і доступних ресурсів доступні, і приймати рішення про сильне стиснення, він повинен використовувати між рівнем 1 і рівнем 2.
ISize робить те ж саме, за винятком рівня 3 та рівня 4. Тут є деякі інші вдосконалені параметри, як багато в CPU, який ми повинні використовувати, ось варіант створення даних зіставлення для віртуальної бази даних SQL, а також нашого функція миттєвого відновлення. Ви можете включати входи в базу даних та деякі інші параметри, які деякі користувачі вважають дуже цінними, так як, наприклад, генерувати чеки, щоб вони могли перевірити це згодом, щоб переконатися, що файли резервного копіювання хороші. Якщо ми перейдемо до наступної сторінки, саме тут ви налаштуєте свої сповіщення. І ви можете побачити різні варіанти, які ми маємо тут: сповістити, якщо резервне копіювання не вдалося, сповістити, якщо резервна копія пропущена, з будь-якої причини. Якщо резервна копія скасована або якщо резервна копія завершена попередженням, і якщо ви цього хочете, ви можете бути сповіщені, чи є резервна копія чистою. Для середовищ, де велика кількість баз даних, можливо, це не те, що ви хочете ввімкнути, просто тому, що це більш ніж ймовірно, що ваша резервна копія буде успішною, і ви будете залиті електронною поштою.
На наступній сторінці ви можете переглянути короткий зміст того, що ви визначили, оскільки це резервне копіювання. І якщо ви хочете, якщо все виглядає добре, ви можете піти вперед і натиснути резервну копію, ми починаємо це. Перш ніж натиснути резервну копію, дозвольте мені продовжити і покажу вам цю кнопку "створити сценарій". Тому що те, що SQL Safe пропонує інтерфейс командного рядка, де ви можете фактично розпочати операцію резервного копіювання чи відновлення, що ви маєте, через командний рядок, DOS-рядок. Якщо ви натиснете сюди сценарій генерації, він в основному надає вам фактичний сценарій, який ви можете використовувати, якщо ви хочете зняти резервну копію з командного рядка.
Інша акуратна річ полягає в тому, що ми також пропонуємо розширені процедури зберігання, і в цьому випадку ми створюємо для вас скрипт, який виконає цю саме операцію резервного копіювання, використовуючи розширені процедури зберігання, - лише невеликий швидкий підказки, яким я хотів поділитися. Тож підемо і розпочнемо цю резервну копію. І ви можете бачити, що резервне копіювання вже запущене. І ця база даних трохи велика, тому може зайняти трохи часу. Видно, що раніше я кілька разів бігав сюди, тому це займе мене десь від однієї хвилини до трьох хвилин. Це рівень 4, тому я здогадуюсь, що це буде між цими двома разів.
Поки це працює, давайте по-справжньому швидко розглянемо політику. Як я вже згадував раніше, політики дозволяють налаштувати заплановані операції з резервного копіювання на вашому підприємстві, тому в мене тут є політика, попередньо налаштована вже, а не створення нової, давайте продовжимо та розглянемо деталі цього. Вибачте, мій VM працює на моєму персональному ноутбуці, і, здається, працює вентилятор досить важко. (Сміється)
Ерік Кавана: Це добре - ви знаєте, я збирався задати вам питання, поки ми спостерігаємо це тут. Чи використовує IDERA багато змін змін у плані резервного копіювання, або ви робите цілі резервні копії кожного разу? Як це працює, ви знаєте?
Теп Чантра: Скажи це ще раз, пробач?
Ерік Кавана: Так, то чи знаєте ви, чи IDERA використовує CDC, змінить технологію збору даних для того, щоб робити менші резервні копії, або це робить повне резервне копіювання кожного разу?
Теп Чантра: Я не вірю в це. Я пам’ятаю, як це раніше бачив у ряді квитків. І якщо я пам'ятаю правильно, ні, ми не використовуємо CDC, ми, чесно кажучи, ми по суті дозволяємо SQL Server виконувати резервну копію, ми просто фіксуємо дані між ними і стискаємо їх, в результаті чого створюється резервний файл. Отже, по суті, використовуючи це. Так.
Отже, тепер, коли я завантажив свою політику - о, вибачте, у вас було інше питання?
Ерік Кавана: Ні, це все. Іди вперед.
Теп Чантра: Гаразд, тепер, коли я завантажив свою політику, ви можете побачити деякі швидкі речі тут: ім'я, опис, ви можете встановити, яку політику ви збираєтесь створити, чи це буде політика, якою потрібно керувати., графіком керуватиме агент SQL Server, або розкладом керуватиме резервний агент SQL Server. У більшості випадків ви хочете скористатися агентом SQL Server, оскільки це, як правило, щось, що працює у вашій системі, так що ви також можете використовувати те, що вам доступно. На вкладці членства тут ви вказуєте екземпляри в резервних базах даних, які ви хочете створити резервну копію. І в цьому випадку ви бачите, що я додав усі зареєстровані екземпляри і вказав конкретну базу даних, яку слід створити резервну копію. Тепер, якщо я цього хотів, я міг би продовжувати редагування цих даних і говорити: "Я хочу створити резервну копію всіх баз даних або просто баз даних користувачів, або навіть системних баз даних". Приємним у цьому є те, що я також можу використовувати символи та створювати символи певні бази даних.
Я не збираюся вносити ці зміни тут, просто тому, що я не хочу вносити жодних великих змін у свої налаштування. Отже, повернемося до варіантів. І в цьому варіанті ви визначаєте, який тип резервного копіювання ви збираєтеся виконувати, і якщо ви подивитесь тут, у мене налаштовані повні резервні копії, диференційні резервні копії та великі резервні копії. І для кожної з цих резервних копій я можу визначити, чи хочу я використовувати певну кількість стиснення або включити шифрування. Так само, як і варіанти, які ви знайшли б у спеціальному майстрі. А на місцях ви також можете визначити призначення цих операцій із резервного копіювання. Однією з хороших речей щодо політики є те, що ви також можете визначити, чи хочете ви продовжувати чи видаляти ті старі файли резервного копіювання, залежно від кількості днів X або тижнів, що у вас є.
І це налаштовується для кожного типу резервного копіювання. Отже, ви можете побачити тут, я маю повну резервну копію для видалення через тиждень. Мій диференціал видаляється через два дні, і я хочу, щоб резервні копії видалялися через один день. Це справді приємно, оскільки воно автоматизує сценарій обробки старих резервних файлів, зберігаючи лише ті, які вам справді потрібні, залежно від часу. На наступній сторінці ви визначаєте розклад, і знову, графік може бути конкретним для кожного типу операцій резервного копіювання, які ви збираєтеся виконати, тому для моєї повної, я запускаю її щотижня, мій диференціал, я запускаю її кожні шість годин, мої журнали я біжу кожні 30 хвилин. На наступній сторінці, де ви налаштовуєте сповіщення, і це, по суті, ті самі типи сповіщень, які ви знайшли в спеціальній резервній копії, одна різниця полягає в тому, що у вас є цей новий, інший варіант, де він може повідомити вам, чи не вдалося запустити резервну копію. за графіком Тут ви можете попередити про ситуації, коли ваші резервні копії не працювали. Справжнє важливо, особливо у випадках, коли у вас є певні угоди про домовленість, щоб переконатися, що у вас є резервні копії, коли вони вам потрібні. А на наступній сторінці ви можете переглянути резюме. Якби я вніс будь-які зміни, якщо я натиснув кнопку закінчення, вони вийдуть і внесуть ці зміни, збережіть їх, наприклад, збережу їх у сховищі завдань агента SQL Server.
А щоб швидко показати вам справді швидко, ось політика та робота, яку я створив для цієї конкретної політики. І ви можете бачити, що він створив три різні завдання: по одному для кожного типу резервного копіювання. Тепер, дуже швидко, дозвольте мені короткий погляд на HUD-інтерфейс і різновид - як я вже згадував раніше, віртуальна база даних раніше була інтеграцією в SQL Safe. Тепер, як я вже згадував, це в основному обманює SQL Server вважати, що фактична база даних була відновлена, коли насправді ми просто читаємо файл резервної копії. Отже, дозвольте мені продовжити і не один справжній швидкий для вас, хлопці. Дозвольте мені взяти файл резервного копіювання. Ось, дозвольте взяти чотири прямо тут. Процес завершено, і дуже швидко, якщо я оновив свої бази тут, ви побачите, що база даних доступна, і SQL Server вважає, що вона живе, але насправді ми просто читаємо дані з бази даних.
Деякі інші функції, які є новинками цього випуску, - це можливість виконувати резервні копії, використовуючи останній формат резервного копіювання. Це дуже зручно для тих клієнтів, яким потрібно скористатися нашим управлінням на основі політики, але вони хочуть зберегти формат файлу SQL Server з будь-якої причини. Тепер я знаю, що у нас не вистачає часу, тому я думаю, що я хотів би продовжити цю зупинку і зупинити цю презентацію, просто для того, щоб ми могли взяти якісь запитання чи що.
Ерік Кавана: Так, звичайно. Отже, я думаю, що один із ключів насправді полягає в управлінні політикою, правда? Як в думці про оптимальну політику і на чому ви базуєтесь? Очевидно, що в деяких випадках є правила, про які слід турбуватися, але, можливо, у бізнесі це не дуже регульовано; вам просто потрібно знайти оптимальний час для створення резервного копіювання, а потім, я здогадуюсь, ви отримаєте кілька звітів про те, як тривало це і наскільки дорого це було з точки зору обчислювальної потужності тощо. Що входить у визначення оптимальної політики?
Теп Чантра: Це дійсно окремо для кожного випадку, в кожному середовищі буде проводитися різна політика щодо того, коли ці резервні копії повинні запускатися. Крім того, і це може спричинити за собою тип резервних копій, графік, за яким вони виконуються, і це дійсно визначає, що також залежить від їх потреб відновлення, я думаю, це відповідь.
Ерік Кавана: Добре, так. І ви говорили про те, що можна робити різні види резервного копіювання та смужок - один із варіантів. Це для сортів гарячих і холодних даних, або в чому логіка руху смуги на відміну від іншого методу?
Теп Чантра: Отже, я вважаю, що найкраща відповідь, яку я можу надати, полягає в тому, що так, смугасті файли, що ми, по суті, робимо, - це написати резервний вміст для кількох різних файлів. Я вважаю, що ідея використання смугастих файлів полягає в тому, що ви можете, можливо, швидше писати резервні файли. Наприклад, у вас може бути кожен інший файл, який переходить в інше місце. Це теж коштує для захисту сервера, оскільки ви поширюєте резервні файли в різних місцях.
Ерік Кавана: І є кілька цікавих нових речей щодо можливостей відновлення, правда? Тому що скажімо, що є якась подія, будь то стихійне лихо чи викупництво, незалежно від випадків. Не потрібно мати лише один варіант відновлення, правда? Чи можете ви встановити пріоритети щодо того, що відновиться та які дані? Чи можете ви поговорити про варіанти там?
Теп Чантра: Ну, що стосується відновлення, я вже згадував, що ми надаємо можливість виконувати миттєві відновлення, що, по суті, швидше залучає користувачів до даних, правда? І лише щоб продемонструвати, я зробив це раніше, так що ви можете побачити тут, що знову ж таки, ця база даних не дуже величезна, це та, яка працює на моєму ноутбуці. Отже, я думаю, що це, можливо, як два концерти, але ця база завершилася протягом 37 секунд. Фактичне відновлення. Отже, мені знадобилося 37 секунд, перш ніж я зміг отримати доступ до своїх даних, тому з миттєвим відновленням я зміг отримати доступ до своєї бази даних протягом двох секунд. Отже, ви можете уявити, як це виглядало б, якби ваша база була значно більшою.
Ерік Кавана: Так, добре. І звичайно, ми говорили про це перед шоу; Ви витратили багато часу на передовій, роблячи підтримку для людей, а потім перейшли до простору управління продуктом, тож я думаю, це трохи інше завдання. Але ви були на передовій - я думаю, що це досить гарне місце, щоб дізнатися, де люди йдуть не так і які проблеми. Що ви бачите, як деякі з найпоширеніших підводних каменів, яких люди могли б уникнути, якби вони просто роздумували над цими матеріалами краще?
Теп Чантра: Деякі з загальних підводних каменів - це, напевно, як ви вже згадували раніше, - планувати свої резервні копії. Були випадки, коли я бачив, як люди намагаються використовувати, наприклад, нашу політику, політику, політику, яку ви виконуєте безліч резервних копій і базуєте їх на LSM. І в деяких випадках я бачив, що деякі люди також мають іншу утиліту, яка виконує резервні копії на своїх базах даних, що фактично змінює їх політику доставки журналів, оскільки резервні копії виробляються по суті поза SQL Safe, і ми про них не знаємо. Це головне лише планування речей вперед, ось звідки береться підводний камінь.
Ерік Кавана: Не дивує мене. Ну, люди, це був чудовий огляд деяких блокувань та вирішення, які необхідні для того, щоб підтримувати ваше підприємство щасливим, щоб ваші клієнти були щасливими. Я хочу подякувати всім, Теп Чантра з IDERA, зайшов сюди, робив кілька демо-версій, що завжди цікаво - це завжди трохи ризиковано робити демо-версію, але я думаю, що це пройшло досить добре. Ви знаєте, це основні речі, але це та річ, де, якщо цього не зробити, у вас виникнуть всілякі проблеми. Отже, це важливий матеріал, який деякі компанії роблять.
Отже, Теп, дякую за витрачений час. Люди, ми архівуємо всі ці веб-трансляції для подальшого перегляду, тому зазвичай ви можете повернутися протягом години або двох і перевірити архів. Але, знову ж таки, чудові речі тут, ми намагаємось допомогти підприємству залишатись над собою, ми цінуємо весь ваш час та увагу, люди там. Ми наздоженемо вас наступного разу. Ви слухали Hot Technologies. Бережіть, люди. Бувай.
