Сотрудники Techopedia, 7 июня 2017 г.
Вывод: ведущий Эрик Кавана обсуждает резервное копирование и восстановление с Tep Chantra IDERA в этом выпуске «Горячие технологии».
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Эрик Кавана: Хорошо, дамы и господа, сегодня среда в 4:00 по восточному времени. Для тех, кто находится в сфере корпоративных технологий, вы знаете, что это значит: пришло время для «Горячих технологий». Да, в самом деле. Меня зовут Эрик Кавана, я буду вашим модератором на сегодняшнем мероприятии под названием «Пуленепробиваемый: как сегодняшние лидеры бизнеса остаются на вершине». И, ребята, у нас сегодня будет приятный, интимный разговор; это будет Теп Чантра, и вы действительно принимаете этот разговор. Мы собираемся поговорить о множестве разных вещей, включая аварийное восстановление, резервное копирование и восстановление, но на самом деле термин, который мне нравится использовать в эти дни, - это устойчивость данных - я слышал это от джентльмена всего пару недель назад, и это действительно, это имеет большой смысл. Потому что это говорит о том, насколько важно иметь жизнеспособную информационную инфраструктуру под вашим бизнесом.
В наши дни это информационная экономика, что означает, что большинство компаний в той или иной степени зависят от информационных активов, от данных. Я имею в виду, что даже розничные компании, даже компании, занимающиеся производством оборудования, на самом деле любая организация в наши дни будет иметь какую-то информационную магистраль, или, по крайней мере, они собираются, если они в современном веке, если хотите. Есть несколько мамино-популярных магазинов, которые все еще могут этого избежать, но даже там, вы начинаете видеть гораздо большее распространение информационных систем, многие из которых, честно говоря, основаны на облачных вычислениях, но многие из них все еще существуют. для обработки транзакций клиентов, для того, чтобы быть в курсе событий, для того, чтобы знать, чего хотят ваши клиенты, для того, чтобы знать, что такое инвентарь, для того, чтобы знать, что это было, для понимания общей картины - в наши дни это действительно важно.
Итак, устойчивость данных - это термин, который мне нравится использовать; избыточность - это еще один термин, который приходит на ум. Но вы хотите убедиться, что независимо от того, что произойдет, ваши сотрудники и ваша организация получат информацию, необходимую для обслуживания ваших клиентов. Итак, я собираюсь пройтись, просто сформулировав аргумент, прежде чем Теп вступит и объяснит нам некоторые вещи, которые происходят в IDERA. Конечно, за последний год IDERA провели с нами немало веб-трансляций. Это очень, очень интересная компания, они сосредоточены на некоторых медных хитростях, блокирующих и решающих, по мере необходимости, выживание в информационной экономике. Мы как бы погрузимся.
Пуленепробиваемая инфраструктура - это на самом деле старая картина мейнфрейма, посмотрите на это, как в начале 1960-х из Википедии. Вы думаете о том, что в те дни, когда мэйнфреймы были не слишком много точек доступа для мэйнфреймов, безопасность была довольно простой, резервное копирование было довольно простым, вы могли понять, что нужно сделать, вам просто нужно было пойти и сделать Это. Конечно, тогда было не так много людей, которые знали, что делать, но те, кто знал, было совершенно ясно, что вы должны были сделать. И это не слишком беспокоило. У вас действительно была случайная проблема, но на самом деле это было не так уж часто.
Когда-то это было довольно легко - сегодня не так много. Итак, вот картинка - это на самом деле Геракл, сражающийся с Гидрой прямо здесь. Для тех из вас, кто не разбирается в мифологии, Гидра была очень неприятным существом в том смысле, что у нее было несколько голов, и каждый раз, когда вы отрубали одну, на ее месте появлялись еще две, так что она как бы говорит о вызове Работа с некоторыми проблемами, с которыми вы сталкиваетесь, особенно в этом контексте, была направлена на плохих парней. Вы убираете плохого парня, на его месте появляются еще двое. И вы как бы видите это в мире хакеров, честно говоря, это большая индустрия в наши дни, и это только одна из больших проблем, с которыми мы сталкиваемся.
Итак, вы думаете о том, если вы пытаетесь наметить свою стратегию устойчивости данных, о чем вам следует беспокоиться? Ну, есть о чем беспокоиться: бедствия, пожары, наводнения. Я провел много времени на юге, и, конечно, в Новом Орлеане есть несколько интересных историй, касающихся ураганов, наводнений и так далее. И много раз человеческая ошибка входит в игру, входит в картину, я должен сказать. И это имело место даже в Катрине в Новом Орлеане, потому что да, ураган прошел, это стихийное бедствие, как говорится, форс-мажор . Но, тем не менее, именно человеческая ошибка привела к урагану, который привел к нескольким нарушениям сборов. Таким образом, их было три, фактически, один был на промышленном канале, и проблема в том, что судно не было должным образом пришвартовано вниз по течению. И ураган вошел и оттолкнул его от причалов, и он фактически пронизывал иглу, идущую вокруг поворота, где река изгибается прямо за пределами Нового Орлеана, и он просто шел прямо по промышленному каналу и врезался в одну из этих стен. Так что, хотя, да, это было стихийное бедствие, тем не менее, это была человеческая ошибка, которая привела к этой огромной проблеме.
И то же самое произошло в другой части города, где был участок сбора, который так и не был завершен, по-видимому, потому, что город и армейский инженерный корпус никогда не договаривались о том, кто собирается за это платить. Ну, не нужно учёный-ракетчик, чтобы понять, что если у вас одна большая зияющая дыра в вашем налоге, это не очень эффективный налог. Итак, суть в том, что человеческая ошибка действительно играет в сценарий, где происходит бедствие. Таким образом, даже если это пожар, или это наводнение, или это землетрясение, или что-то в этом роде, есть вероятность, что кто-то мог и должен был подготовиться к такому событию. И конечно, это то, что мы традиционно называем аварийным восстановлением. Так что, да, бедствия случаются, но люди действительно должны видеть сквозь это и подготовиться соответствующим образом. Поговорим сегодня об этом с Тепом.
Итак, недовольные сотрудники - не стоит недооценивать ущерб, который может нанести недовольный сотрудник - они там, они повсюду. Я знаю людей, которые рассказывали мне истории просто по-настоящему неприятных вещей, которые случались, когда люди просто делают плохие вещи, они намеренно саботируют свою собственную организацию, потому что они несчастны. Может быть, они не получили повышение, или они были уволены, или кто знает, что случилось. Но об этом нужно помнить, и это очень важный компонент. В случае с лицензированием, также как и для вас, ребята. Одна из статистических данных, которую я услышал, была примерно 60% всех советов, которые компании-разработчики получают за невыплату лицензионных сборов, получают от бывших сотрудников. Итак, вы хотите убедиться, что вы купили это программное обеспечение и что вы получили его честно и справедливо. Корпоративный саботаж не происходит постоянно, но это случается. Проблемы конфиденциальности также входят в смесь; Вы должны быть осторожны с тем, что вы храните и как вы храните это, действительно продумайте все это.
И я всегда стараюсь напоминать людям с точки зрения регулирования, очень важно иметь план и выполнять его, потому что, когда наступает решающий момент или приходит какой-то аудитор или регулятор, вы хотите иметь возможность указать на свой имеющейся у вас политики, а затем объясните, каким образом вы решаете эту политику, когда происходят определенные вещи, например, катастрофа, например, проблема аудита или что-то в этом случае. Вы хотите знать, что вы делали, и иметь отчет об этом - это будет иметь большое значение для удержания аудитора и отстранения, и это просто хорошие вещи.
Итак, хакеры, конечно - я собираюсь поговорить пару минут о хакерах и почему они представляют такую угрозу. И, конечно, вымогатель, просто скажите весь этот случай с WannaCry, вымогателем WannaCry, который просто очень быстро покрыл планету, и, очевидно, некоторыми умными недружелюбными людьми для получения информации из АНБ, были инструменты взлома, которые использовались и подвергаются. Итак, я напоминаю людям, что есть старая басня Эзоповская Басня, в которой говорится, что мы часто даем нашим врагам инструменты нашего собственного уничтожения. Об этом нужно помнить, потому что опять эта технология была оцеплена АНБ, Ассоциацией национальной безопасности - на самом деле не могу вспомнить, что она обозначает. Но он был разоблачен и вылез в мир, и просто сеял хаос. Угадай, что? И многие компании не обновили свою среду Windows, так что это была старая, думаю, это была Windows XP, которая была скомпрометирована. Итак, еще раз, если вы прилежны, если вы остаетесь в курсе своих патчей и версий своих операционных систем, и если вы создаете резервные копии своих данных и восстанавливаете свои данные. Если вы делаете все то, что должны делать, такие вещи не являются большой проблемой. Но вы можете просто сказать людям, которые являются топорами: «Эй, угадай что? Нам все равно, выключите систему, перезагрузите ее, загрузите резервные копии ». И вы готовы к гонкам.
Итак, дело в том, что да, эти плохие вещи случаются, но есть вещи, которые вы можете с этим поделать - об этом мы и поговорим сегодня на шоу. Итак, я провел некоторое исследование - на самом деле, это было довольно интересно, если вы пойдете в Википедию и посмотрите на хакерство, то оно дойдет до 1903 года. Когда парень взломал систему для телеграфов и отправлял грубые сообщения через телеграф, Я полагаю, просто чтобы доказать, что он мог взломать это. Я думал, что это было довольно забавно. Дело в том, что хакеры в основном хороши в взломе и проникновении, это то, чем они занимались годами, годами и годами. Они как отмычки в современном интернет-мире.
И вы должны помнить, что любая система может быть взломана, она может быть взломана изнутри, она может быть взломана извне. Много раз, когда эти хаки происходят, они не показывают себя, или люди, которые взломают вашу систему, не будут делать много на некоторое время. Они ждут некоторое время; в этом задействована некоторая стратегия, и отчасти это происходит только потому, что деловая сторона их работы, потому что обычно то, что делают хакеры, это то, что они делают свою маленькую часть программы, так что многие ребята хорошо разбираются брандмауэры и проникающая информационная система, это то, что они делают лучше всего, и как только они проникают в систему, они поворачиваются и пытаются продать этот доступ кому-то. И это занимает время, поэтому часто бывает так, что кто-то за кулисами просто пытается продать доступ к любой системе, которую он взломал - потенциально к вашей системе, что не будет слишком весело - и они пытаются выяснить, кто на самом деле оплатить доступ к системе.
Таким образом, существует такая разобщенная сеть людей или организаций, которые объединяются и сотрудничают, чтобы использовать украденную информацию. Будь то кража личных данных или просто кража данных, делают ли они жизнь неприятной для компании - так обстоит дело с этим вымогателем, эти парни просто овладевают вашими системами и требуют денег, и если они получат деньги, возможно, или может быть, они не вернут ваши вещи. Конечно, это действительно страшная вещь, почему ты вообще хочешь заплатить этот выкуп? Откуда ты знаешь, что они собираются вернуть его? Они могут просто попросить двойной или тройной. Итак, опять же, все это говорит о важности продумывания вашей информационной стратегии, вашей устойчивости к вашим данным.
Итак, я провел еще несколько исследований, это старый 386; если вы такие же старые, как я, вы могли бы вспомнить эти системы. И они не были такими проблемными с точки зрения взлома; тогда не было много вирусов. В наши дни это другая игра, поэтому, конечно же, появляется Интернет и все меняется. Теперь все связано, есть глобальная аудитория, первые крупные вирусы начали атаковать, и действительно, индустрия хакерских атак начала откровенно развиваться.
Итак, немного поговорим о IoT, у нас уже есть хороший вопрос от аудитории: как защитить IoT-устройства с точки зрения уязвимости? Это большая проблема - прямо скажем, сейчас много усилий уделяется тому, как вы справляетесь с возможностью взлома IoT-устройств. Он очень полезен, обычные проблемы, на которых вы сосредоточены, например, защита паролем, тщательная настройка, установка собственного пароля. Часто люди просто оставляют там пароль по умолчанию, и это фактически приводит к уязвимости. Итак, это основной материал. Мы только что провели еще одно шоу по безопасности в начале этой недели, в нашем радио-шоу, где присутствовали несколько экспертов, и все они сказали, что 80–90 или более процентов проблем со взломом, будь то IoT, вымогатели или что-то еще, можно избежать, если вы просто разберитесь с основами, если вы просто позаботились о том, чтобы ваши базы были покрыты, вы сделали все основные вещи, которые, как вы знаете, должны делать, которые решают более 80 процентов всех проблем.
Итак, Интернет вещей, хорошо, IoT. Ну, если вы думаете о IoT, это не так уж и ново. Честно говоря, есть производители высшего класса, которые делают такие вещи 20 и 30 лет назад, а затем около 15, 20 лет назад, когда пришла радиочастотная идентификация - радиочастотные идентификационные метки - которые были чрезвычайно полезны для помощи очень большим организациям, таким как ритейлеры, например, судоходные компании, любая компания, производящая товары, которая перемещает товары по всей стране, по всему миру, чрезвычайно полезно иметь все эти данные, вы узнаете, куда идут ваши вещи; если что-то исчезнет, вы узнаете.
Конечно, это не надежное решение, на самом деле у меня был свой ноутбук, с которым я сбежал от 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-серверы, когда все эти устройства неожиданно начинают отправлять обратный вызов на определенную группу серверов, что не очень хорошо выглядит. И, честно говоря, о чем я всегда напоминаю людям в этих системах: всякий раз, когда у вас есть серьезная автоматизация в таких средах, всегда есть ручное переопределение, есть переключатель kill - вы хотите, чтобы там был запрограммирован какой-то переключатель kill, чтобы отключить эти вещи вниз
Итак, с этим я собираюсь нажать на первый слайд Тепа, он собирается сделать несколько демонстраций для нас. А потом я дам вам ключи от вкладки WebEx. Теперь, он идет вашим путем, и заберите его.
Теп Чантра: Хорошо, спасибо, Эрик. Меня зовут Теп Чантра, и я менеджер по продукту здесь, в IDERA. Сегодня я хотел поговорить о корпоративном решении резервного копирования IDERA, а именно о SQL Safe Backup. Для тех из вас, кто знаком с безопасным резервным копированием SQL, давайте кратко рассмотрим некоторые основные моменты продукта, извините. Итак, как вы уже могли догадаться, люди говорят, что резервное копирование, продукт резервного копирования и восстановления SQL Server, одной из ключевых функций SQL Safe является возможность быстрого создания резервных копий. И это важная особенность, учитывая, что большинство резервных копий должно быть сделано, и в большинстве случаев они должны быть сделаны очень быстро, за небольшой промежуток времени.
В настоящее время в некоторых средах выполнение этих окон резервного копирования может быть довольно сложной задачей, особенно если у вас есть несколько больших баз данных, для которых необходимо выполнить резервное копирование. Возможность SQL Safe для быстрого завершения операций резервного копирования позволяет конечным пользователям иметь доступ к этим окнам резервного копирования. Говоря о больших базах данных, резервное копирование этих больших баз данных, очевидно, больших файлов резервных копий. Еще одна особенность SQL Safe - это возможность сжатия файлов резервных копий. Используемый алгоритм сжатия может обеспечить до 90-95 процентов сжатия. Это означает, что вы можете хранить резервные копии дольше или обеспечить экономию средств с точки зрения потребностей в хранилище.
С другой стороны операций резервного копирования, у вас есть операции восстановления. Одна из битв, с которой администраторы баз данных должны бороться за восстановление баз данных, заключается в том, что эти базы данных должны быть восстановлены как можно быстрее. В случае больших баз данных полное восстановление файла резервной копии может занять несколько часов, что, очевидно, означает более длительное время простоя и, возможно, потерю прибыли. К счастью, в SQL Safe есть такая функция, как «Мгновенное восстановление», которая в основном сокращает время между началом восстановления и доступом к базе данных для конечных пользователей или даже приложений.
Я помню, как однажды разговаривал с клиентом, где он сообщил, что восстановление одной конкретной базы данных заняло 14 часов. Но благодаря функции мгновенного восстановления он смог получить доступ к этой базе данных в течение часа или меньше. Управление на основе политик - еще одна отличительная черта SQL Safe - возможность создавать политики и управлять операциями резервного копирования с помощью этих политик. Когда вы конфигурируете политику, вы в основном определяете, какие экземпляры должны быть скопированы или какие базы данных в этих экземплярах должны быть скопированы, какие операции резервного копирования должны выполняться, и даже график, в котором эти резервные копии должны выполняться.
Кроме того, вы также можете настроить уведомления о предупреждениях. Таким образом, вы можете получать уведомления о событиях, таких как резервное копирование успешно завершено, резервное копирование не удалось, может быть, он мог видеть это, но есть некоторые предупреждения, связанные с этой операцией. Вы также будете уведомлены, если резервное копирование не будет выполнено, как запланировано. Это важное уведомление, потому что тогда у вас может возникнуть риск того, что время резервного копирования не существует. А получение такого уведомления укажет вам, что вам нужно пойти туда и запустить резервное копирование, а затем, возможно, провести некоторое исследование, чтобы выяснить, почему резервное копирование не было запущено по расписанию.
Некоторые другие вещи, давайте посмотрим здесь, отказоустойчивое зеркалирование, это по сути означает, что у нас есть возможность создавать дубликаты файлов резервных копий в нескольких местах. Так, например, предположим, у вас есть целевой пункт назначения на вашем основном компьютере - каково ваше основное хранилище, куда идут все ваши файлы резервных копий. Однако у вас может возникнуть необходимость иметь копию того же файла резервной копии, например, на самом локальном компьютере, на случай, если вам потребуется провести дополнительное тестирование, убедитесь, что эту базу данных можно восстановить, в любом случае. Оптимизация виртуальной базы данных SQL - по сути, это то, что у нас есть еще один продукт, недавно интегрированный в SQL Safe, называемый виртуальной базой данных SQL.
Как я уже упоминал, он недавно интегрирован, и фактически включен в сам SQL Safe. Теперь, что виртуальная база данных SQL, по сути, позволяет вам сделать, это фактически создать виртуальную базу данных. (Смеется.) Я терпеть не могу использовать те же термины, что и определение, но по сути дела происходит то, что мы будем монтировать базу данных на основе файла резервной копии. Таким образом, в сущности происходит то, что SQL Server считает, что база данных действительно запущена и работает, в то время как она фактически читает данные из файла резервной копии, а не фактически создает саму базу данных в файловой системе.
Это очень полезно, потому что позволяет получить доступ к данным, находящимся в файле резервной копии, фактически не занимая дополнительное дисковое пространство, поэтому это очень удобно, особенно когда вы работаете с огромными базами данных, которые вам просто нужно получить, быстрый просмотр или поработайте над разработкой. Шифрование с нулевым воздействием - это означает, что когда мы выполняем резервное копирование этих баз данных, мы можем фактически зашифровать файлы резервных копий, а когда мы шифруем эти файлы резервных копий, мы не добавляем никакой дополнительной нагрузки к фактическому производительность системы. Так что это совершенно незначительно. Доставка журналов - это еще одна вещь, которую мы можем сделать, когда наши политики, как я упоминал ранее, и в отношении выгодного лицензирования - это, по сути, означает, что наши модели лицензирования позволяют перемещать модели лицензирования из одного экземпляра в другой, с несколько простых щелчков мыши.
Двигаясь дальше, давайте кратко рассмотрим архитектуру самого продукта. Таким образом, есть четыре основных компонента продукта. Начиная слева, мы видим консоль безопасного управления SQL и веб-консоль. Оба они по сути являются пользовательскими интерфейсами, один - клиент рабочего стола, а другой - веб-приложение. Оба этих пользовательских интерфейса извлекают данные из следующего компонента, который является базой данных безопасного хранилища SQL. База данных хранилища в основном хранит всю вашу историю операций, все операции резервного копирования и восстановления. Эти детали хранятся здесь. Все эти данные, которые находятся в хранилище, управляются службой безопасного управления SQL, которая является следующим компонентом. Служба управления отвечает за обновление базы данных хранилища и отправку уведомлений. Данные, относящиеся к операциям резервного копирования и восстановления, на самом деле поступают из агента безопасного резервного копирования SQL, который является последним компонентом справа.
Агент безопасного резервного копирования SQL - это компонент, который устанавливается на всех серверах, на которых размещаются экземпляры 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 сжатия; он смотрит на вашу систему, чтобы увидеть, сколько ресурсов ЦП и доступных ресурсов доступно, и выдает суждения о значительном сжатии, которое он должен использовать между уровнем 1 и уровнем 2.
ISize делает то же самое, за исключением Уровня 3 и Уровня 4. Здесь есть несколько других расширенных опций, например, сколько на процессоре мы должны использовать, вот вариант для создания данных отображения для Виртуальной базы данных SQL, а также наш функция мгновенного восстановления. Вы можете включить вход в базу данных и некоторые другие параметры, которые некоторые пользователи считают очень ценными, например генерировать из них проверки, чтобы они могли проверить это позже, чтобы убедиться, что файлы резервных копий исправны. Если мы перейдем к следующей странице, то здесь вы настроите свои уведомления. И вы можете увидеть различные варианты, которые у нас есть: уведомить, если резервное копирование не удалось, уведомить, если резервное копирование пропущено, по любой причине. Если резервное копирование отменено, или если резервное копирование завершается с предупреждением, и, если вы этого хотите, вы можете получить уведомление о том, что резервная копия чистая. В средах, где большое количество баз данных, возможно, вам не нужно включать, просто потому, что с большой вероятностью ваша резервная копия будет выполнена успешно, и вы будете переполнены электронными письмами.
На следующей странице вы можете просмотреть сводку того, что вы определили, потому что это операция резервного копирования. И если вы хотите, если все выглядит хорошо, вы можете пойти дальше и нажать кнопку резервного копирования, мы запускаем его. Прежде чем я нажму на резервную копию, позвольте мне пойти дальше и показать вам эту кнопку «Создать скрипт». Потому что то, что SQL Safe предлагает интерфейс командной строки, где вы можете запустить операцию резервного копирования или восстановления, что вы получаете через командную строку, приглашение DOS. Если вы нажмете здесь сценарий создания, он в основном предоставит вам фактический сценарий, который вы можете использовать, если вы хотите удалить резервную копию из командной строки.
Другая полезная вещь - это то, что мы также предлагаем расширенные процедуры хранения, и в этом случае мы создадим сценарий для вас, который будет выполнять ту же самую операцию резервного копирования с использованием расширенных процедур хранения - всего лишь небольшой небольшой фрагмент, которым я хотел поделиться. Итак, давайте пойдем и начнем эту резервную копию. И вы можете видеть, что резервное копирование уже запущено. И эта база данных немного велика, поэтому это может занять некоторое время. Вы можете видеть, что раньше я бегал здесь несколько раз, так что это займет у меня от одной минуты до трех минут. Это уровень 4, так что я предполагаю, что это будет между этими двумя моментами.
Пока это работает, давайте очень быстро рассмотрим политики. Как я упоминал ранее, политики позволяют вам настраивать запланированные операции резервного копирования на вашем предприятии, поэтому у меня здесь есть политика, уже настроенная заранее, и вместо того, чтобы создавать новую, давайте продолжим и рассмотрим детали этой. Приносим свои извинения, моя виртуальная машина работает на моем персональном ноутбуке, и, кажется, вентилятор работает довольно сильно. (Смеется)
Эрик Кавана: Это хорошо - вы знаете, я собирался задать вам вопрос, пока мы будем смотреть это здесь. Использует ли IDERA много изменений данных с точки зрения резервного копирования, или вы делаете целые резервные копии каждый раз? Как это работает, вы знаете?
Теп Чантра: Скажи это еще раз, прости?
Эрик Кавана: Да, так вы знаете, использует ли IDERA CDC, меняет ли технология захвата данных для создания меньших резервных копий, или она делает полные резервные копии каждый раз?
Теп Чантра: Я не верю в это. Я помню, что видел это раньше, в нескольких билетах. И если я правильно помню, нет, мы не используем CDC, мы, честно говоря, мы фактически позволяем SQL Server выполнять резервное копирование, мы просто собираем промежуточные данные и сжимаем их, что приводит к резервный файл создается. Итак, по сути, используя это. Да.
Итак, теперь, когда у меня загружена моя политика - извините, у вас есть еще один вопрос?
Эрик Кавана: Нет, все. Преуспевать.
Tep Chantra: Хорошо, теперь, когда у меня загружена моя политика, вы можете увидеть некоторые быстрые вещи здесь: имя, описание, вы можете установить, какую политику вы собираетесь создавать, будь то политика, которой нужно управлять расписание будет управляться агентом SQL Server, или расписание будет управляться агентом резервного копирования SQL Server. В большинстве случаев вы захотите использовать агент SQL Server, потому что это обычно то, что в любом случае работает в вашей системе, поэтому может также использовать то, что вам доступно. На вкладке членства вы указываете экземпляры в резервных базах данных, для которых вы хотите выполнить резервное копирование. И в этом случае вы можете видеть, что я добавил все свои зарегистрированные экземпляры и указал конкретную базу данных, для которой нужно выполнить резервное копирование. Теперь, если бы я захотел, я мог бы отредактировать их и сказать: «Я хочу сделать резервную копию всех баз данных или только пользовательских баз данных, или даже системных баз данных». Приятно, что я также могу использовать подстановочные знаки и создавать определенные базы данных.
Я не собираюсь вносить это изменение здесь, просто потому, что я не хочу вносить какие-либо большие изменения в мои настройки. Итак, вернемся к вариантам. Что касается параметров, здесь вы определяете, какие резервные копии вы собираетесь выполнять, и если вы посмотрите здесь, у меня есть полные резервные копии, настроенные разностные резервные копии и большие резервные копии. И для каждой из этих резервных копий я могу определить, хочу ли я использовать определенную степень сжатия или включить шифрование. Точно так же, как параметры, которые вы бы нашли в специальном мастере. И на местах, вы также можете определить место назначения этих операций резервного копирования. Одно из преимуществ политик состоит в том, что вы также можете определить, хотите ли вы продолжить и удалить эти старые файлы резервных копий, исходя из количества дней или недель, которое у вас есть.
И это настраивается для каждого типа резервного копирования. Итак, вы можете видеть здесь, у меня есть полные резервные копии, чтобы удалить через одну неделю. Мой дифференциал удаляется через два дня, и я хочу, чтобы мои резервные копии удалялись через один день. Это очень хорошо, потому что он автоматизирует обработку сценариев, старых файлов резервных копий, сохраняя только те, которые вам действительно нужны, основываясь на времени. На следующей странице вы определяете расписание, и, опять же, расписание может быть индивидуальным для каждого типа операции резервного копирования, которую вы собираетесь выполнить, поэтому для моего полного, я запускаю его еженедельно, мой дифференциал, я запускаю его каждые шесть часов Мои журналы я запускаю каждые 30 минут. На следующей странице вы настраиваете уведомления, и это по существу те же типы уведомлений, которые вы нашли в резервном копировании ad hoc, единственное отличие состоит в том, что у вас есть этот новый, другой вариант, где он может сообщить вам, если резервное копирование не запускается как запланировано. Здесь вы можете быть предупреждены о ситуациях, когда ваши резервные копии не запускались. Это действительно важно, особенно в тех случаях, когда у вас есть определенные SLA, чтобы убедиться, что у вас есть резервные копии в то время, когда они вам нужны. И на следующей странице вы можете просмотреть резюме. Если бы я внес какие-либо изменения, если я нажму кнопку «Готово», он выйдет и внесет эти изменения, сохранит его и, например, сохранит его в хранилище заданий агента SQL Server.
И просто для того, чтобы быстро показать вам очень быстро, вот политика и работа, которую я создал для этой конкретной политики. И вы можете видеть, что он создал три разных задания: по одному для каждого типа резервной копии. Теперь, очень быстро, позвольте мне кратко взглянуть на интерфейс HUD и, как я уже упоминал ранее, виртуальную базу данных, которую мы использовали для интеграции в SQL Safe. Теперь, как я уже говорил, это в основном обманывает SQL Server, полагая, что реальная база данных была восстановлена, когда на самом деле мы просто читаем файл резервной копии. Итак, позвольте мне идти вперед и не очень быстро для вас, ребята. Позвольте мне взять файл резервной копии. Здесь, позвольте мне взять четыре прямо здесь. Процесс завершен, и очень быстро, если я обновлю свои базы данных здесь, вы увидите, что база данных доступна, и SQL Server считает, что она работает, но на самом деле мы просто считываем данные из базы данных.
Некоторые другие функции, которые являются новыми для этого выпуска, - это возможность выполнять резервное копирование с использованием последнего формата резервного копирования. Это очень удобно для тех клиентов, которым необходимо использовать наше управление на основе политик, но они хотят сохранить формат файла SQL Server по любой причине. Теперь я знаю, что у нас заканчивается время, поэтому я думаю, что я хотел бы пойти дальше и остановить эту презентацию, просто чтобы мы могли ответить на некоторые вопросы или еще что-то.
Эрик Кавана: Да, конечно. Итак, я думаю, что один из ключей действительно заключается в управлении политикой, верно? Как думать об оптимальной политике и на чем вы основываетесь? Очевидно, что в некоторых случаях существуют правила, о которых нужно беспокоиться, но в бизнесе, возможно, это не очень строго регулируется; вам просто нужно найти оптимальное время для создания резервных копий, а затем, я полагаю, вы получите несколько отчетов о том, сколько времени это заняло и насколько это дорого с точки зрения вычислительной мощности и так далее. Что входит в определение оптимальной политики?
Теп Чантра: Это действительно в каждом конкретном случае, каждая среда будет иметь свою собственную политику в отношении того, когда эти резервные копии должны выполняться. Кроме того, и это может повлечь за собой тип выполняемых резервных копий, расписание, в котором они выполняются, и это действительно определяет, действительно, также зависит от их потребностей в восстановлении, я полагаю, это ответ.
Эрик Кавана: Хорошо, да. И вы говорили о том, что вы можете делать разные виды резервных копий, а полоса была одним из вариантов. Это что-то вроде горячих и холодных данных, или какова логика «раздевания», а не какого-то другого метода?
Теп Чантра: Итак, я думаю, что лучший ответ, который я могу дать, это то, что полосатые файлы, что мы, по сути, делаем, это записываем содержимое резервной копии в несколько различных файлов. Я полагаю, что идея использования чередующихся файлов заключается в том, что таким образом вы, возможно, сможете записывать резервные копии быстрее. Например, вы можете иметь каждый отдельный файл, идущий в другое место. Это также стоит средствам безопасности сервера, поскольку вы распределяете файлы резервных копий в разных местах.
Эрик Кавана: И есть какие-то крутые, новые вещи с точки зрения возможностей восстановления, верно? Потому что, скажем, есть какое-то событие, будь то стихийное бедствие или вымогатель, в любом случае. Вам не нужно просто иметь один вариант для восстановления, верно? Можете ли вы установить приоритеты в отношении того, что восстанавливается и какие виды данных? Можете ли вы рассказать о вариантах там?
Tep Chantra: Что касается восстановления, я уже упоминал ранее, что мы предоставляем возможность мгновенного восстановления, что существенно ускоряет получение данных пользователями, верно? И просто для демонстрации, я сделал один ранее, так что вы можете увидеть здесь, что опять же, эта база данных не очень большая, это та, которая работает на моем ноутбуке. Итак, я думаю, что это может быть размером в два гигабайта, но эта база данных завершилась за 37 секунд. Актуальное восстановление. Итак, мне потребовалось 37 секунд, прежде чем я смог получить доступ к своим данным, поэтому с мгновенным восстановлением я смог получить доступ к своей базе данных в течение двух секунд. Итак, вы можете себе представить, как бы выглядело это, если бы ваша база данных была намного больше.
Эрик Кавана: Да, хорошая мысль. И конечно, мы говорили об этом перед шоу; вы потратили много времени на линии фронта, оказывая поддержку людям, а затем перешли в область управления продуктами, так что это немного иная задача, я полагаю. Но вы были на переднем крае - я думаю, что это очень хорошее место, чтобы узнать, где люди ошибаются и каковы некоторые из проблем. Что вы видите в качестве наиболее распространенных ловушек, которых люди могли бы избежать, если бы они просто лучше продумали этот материал?
Теп Чантра: Некоторые из распространенных ошибок - это, как я уже говорил, планирование ваших резервных копий. Было время, когда я видел, как люди пытаются использовать, например, наши политики, политики, политики, которые вы выполняете, создавая множество резервных копий и основывая их на LSM. И в некоторых случаях я видел, что у некоторых людей также есть какая-то другая утилита, выполняющая резервное копирование своих баз данных, которое фактически портит их политики доставки журналов, потому что резервные копии создаются в основном вне SQL Safe, и мы не знаем о них. В основном это просто планирование вещей впереди, отсюда и подводные камни.
Эрик Кавана: меня не удивляет. Ну, ребята, это был отличный обзор некоторых из блокировок и решений, которые необходимы, чтобы сделать ваше предприятие счастливым, чтобы ваши клиенты были довольны. Я хочу поблагодарить всех, Tep Chantra из IDERA, зашел сюда, сделал несколько живых демо, это всегда интересно - всегда немного рискованно делать живое демо, но я думаю, что все прошло довольно хорошо. Вы знаете, это базовые вещи, но это такие вещи, где, если вы этого не сделаете, у вас будут все виды проблем. Таким образом, это важная вещь, которую компании делают некоторые люди.
Так что, Теп, спасибо, что уделили время. Ребята, мы архивируем все эти веб-трансляции для последующего просмотра, поэтому обычно вы можете вернуться через час или два и проверить архив. Но, опять же, отличные вещи здесь, мы пытаемся помочь предприятию оставаться на вершине, мы ценим все ваше время и внимание, ребята. Мы встретимся с вами в следующий раз. Вы слушали Hot Technologies. Береги себя, ребята. Пока-пока.
