작성자 : Techopedia Staff, 2017 년 6 월 7 일
테이크 아웃 : 호스트 Eric Kavanagh는 이번 Hot Technologies 에피소드에서 IDERA의 Tep Chantra와의 백업 및 복구에 대해 논의합니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
Eric Kavanagh : 좋아요, 신사 숙녀 여러분, 수요일 오후 4시 (동부 표준시)에 엔터프라이즈 기술 분야의 사람들은 이것이 의미하는 바를 알고 있습니다. Hot Technologies의 시간입니다. 네 확실합니다. 제 이름은 Eric Kavanagh입니다. 오늘“Bulletproof : 오늘의 비즈니스 리더가 어떻게 지내는가?”라는 제목의 행사의 중재자가 되겠습니다. 여러분, 오늘 우리는 여기서 친근하고 친근한 대화를 나눌 것입니다. Tep Chantra와 여러분의 대화를 진심으로 환영합니다. 우리는 재난 복구, 백업 및 복원을 포함하여 여러 가지에 대해 이야기 할 것입니다.하지만 요즘 사용하고 싶은 용어는 데이터 복원력입니다. 불과 몇 주 전에 신사에게서 들었습니다. 정말 많은 의미가 있습니다. 비즈니스 아래에 탄력적 인 정보 인프라를 갖추는 것이 얼마나 중요한지 설명하기 때문입니다.
이것은 오늘날 정보 경제입니다. 이는 대부분의 회사가 어떤 의미에서나 정보 자산, 데이터에 의존한다는 것을 의미합니다. 요즘 소매 업체, 심지어 하드웨어 회사, 심지어 어떤 조직이든 요즘에는 어떤 종류의 정보 백본을 갖거나 적어도 현대인이라면 정보를 수집 할 것입니다. 여전히 그런 것들을 피할 수있는 엄마와 팝 샵이 있지만, 거기에서도 정보 시스템이 훨씬 더 많이 확산되기 시작했습니다. 많은 사람들은 클라우드 기반이지만 솔직하지만 여전히 많은 전제에 있습니다. 고객 거래 처리, 사물 관리, 고객이 원하는 것, 재고가 무엇인지, 재고가 무엇인지, 큰 그림을 이해할 수있는 것, 요즘에는 매우 중요합니다.
따라서 데이터 복원력은 제가 사용하고 싶은 용어입니다. 중복은 생각 나는 또 다른 용어입니다. 그러나 어떤 일이 발생하더라도 직원과 조직은 고객에게 서비스를 제공하는 데 필요한 정보를 보유하게됩니다. Tep가 들어 오기 전에 IDERA가 진행하고있는 것들에 대해 설명해 드리려고합니다. 물론, IDERA는 작년에 우리와 함께 몇 가지 웹 캐스트를했습니다. 매우 흥미로운 회사로, 정보 경제에서 살아 남기 위해 필요에 따라 놋쇠 압정에 중점을두고 있습니다. 우리는 일종의 다이빙을 할 것입니다.
방탄 인프라 – 실제로 메인 프레임의 오래된 그림입니다. Wikipedia의 1960 년대 초와 같습니다. 당시에는 메인 프레임 시대가 메인 프레임에 대한 액세스 포인트가 많지 않았기 때문에 보안이 쉬웠고 백업이 매우 간단했습니다. 수행해야 할 작업을 이해할 수있었습니다. 그것. 물론, 해야 할 일을 아는 사람들은 많지 않았지만, 그렇게 한 사람들은 당신이해야 할 일이 분명했습니다. 그리고 그것에 대해 너무 걱정하지 않았습니다. 가끔 문제가 있었지만 실제로 그렇게 일반적인 것은 아닙니다.
과거에는이 물건이 상당히 쉬웠습니다. 오늘날은 그리 많지 않았습니다. 여기에 그림이 있습니다. 실제로 허큘리스가 히드라와 싸우고 있습니다. 신화에 익숙하지 않은 사람들에게는 Hydra가 머리가 여러 개라는 매우 독재 적 인 생물이었고, 당신이 하나를 잘라낼 때마다 두 개가 대신 그 자리에 나타났습니다. 인생에서, 특히 그러한 맥락에서 발견되는 몇 가지 문제를 다루는 것은 실제로 나쁜 사람들을 중심으로 이루어졌습니다. 당신은 나쁜 사람을 꺼내고, 그 자리에서 두 번 더 자릅니다. 그리고 당신은 해킹 세계에서 이것을 보았을 것입니다. 솔직히 말해서, 그것은 요즘 큰 산업이며 우리에게 직면하는 큰 도전 중 하나 일뿐입니다.
따라서 데이터 복원 전략을 계획하려는 경우 어떤 점을 염려해야합니까? 재난, 화재, 홍수 등 걱정해야 할 것이 많이 있습니다. 나는 남부와 뉴 올리언스에서 많은 시간을 보냈으며 물론 허리케인과 홍수 등에 관한 흥미로운 이야기가 있습니다. 그리고 많은 경우 인간의 실수가 연극에 등장하고 그림에 등장합니다. 뉴 올리언즈의 카트리나에서도 마찬가지였습니다. 예, 허리케인이 나왔기 때문입니다. 그들이 말하듯이, 불가항력 은 말입니다. 그럼에도 불구하고 허리케인으로 이어지는 것은 인간의 실수였으며 그로 인해 부과금이 여러 번 위반되었습니다. 사실, 그들 중 3 개가 산업 운하에 있었고, 배가 강 아래로 제대로 정박하지 않은 문제가있었습니다. 그리고 허리케인이 들어 와서 계류장에서 밀어 내고 실제로 바늘이 굴곡 둘레를 돌면서 강이 뉴 올리언즈 바로 바깥쪽으로 구부러지고 산업 운하 바로 아래로 내려가 그 벽 중 하나를 뚫었습니다. 그럼에도 불구하고, 그것은 자연 재해 였지만 여전히 인간의 실수로 인해 큰 문제가 발생했습니다.
그리고 도시의 다른 쪽에서도 같은 일이 일어 났는데, 아직 완료되지 않은 부담금 부분이 있었는데, 그 이유는 도시와 엔지니어 군단이 누가 그것을 지불 할 것인지에 대해 합의한 적이 없었기 때문입니다. 글쎄, 당신이 당신의 부담금에 큰 구멍이 하나 있다면, 그것은 매우 효과적인 부담금이 아니라는 것을 알아내는 데 로켓 과학자가 필요하지 않습니다. 따라서 요점은 인적 오류가 실제로 재난이 발생하는 시나리오에서 발생한다는 것입니다. 따라서 화재 나 홍수, 지진 또는 기타 상황이 발생하더라도 누군가가 그러한 행사를 준비하기 위해 할 수 있었거나해야 할 일이있을 수 있습니다. 물론 우리는 전통적으로 재난 복구라고 부릅니다. 그렇습니다. 재앙이 발생하지만, 인간은 실제로 그러한 것들을보고 그에 따라 준비해야합니다. 우리는 오늘 Tep과 그것에 대해 조금 이야기 할 것입니다.
따라서 불만을 품은 직원은 불만을 품은 직원이 할 수있는 피해를 과소 평가하지 말고 외부에 있습니다. 나에게 정말 불쾌한 일에 대한 이야기를 들었던 사람들, 사람들이 단지 나쁜 일을하는 곳, 의도적으로 자신의 조직을 파괴하는 것은 불행하기 때문에 알고 있습니다. 어쩌면 그들은 인상을 얻지 못했거나 해고 당했거나 누가 무슨 일이 있었는지 알 것입니다. 그러나 이것은 명심해야 할 부분이며 매우 중요한 요소입니다. 라이센싱의 경우에도 FYI와 마찬가지로 사람들도 마찬가지입니다. 내가 들었던 통계 중 하나는 소프트웨어 회사가 라이센스 비용을 지불하지 못한 데 대한 모든 팁의 60 %와 같은 것입니다. 그래서, 당신은 당신이 그 소프트웨어를 구입하고 공정하고 정사각형을 가지고 있는지 확인하고 싶습니다. 기업 파괴 행위는 항상 일어나지 않지만 일어나고 있습니다. 프라이버시 문제도 혼합되어 있습니다. 저장하는 내용과 저장하는 방법에주의해야합니다.
저는 항상 규제 측면에서 사람들에게 상기 시키려고 노력합니다. 계획을 세우고 그 계획을 실행하는 것이 매우 중요합니다. 푸시가 밀려 오거나 일부 감사인이 들어 오거나 규제 기관이 오면 예를 들어 감사 문제 또는 사건과 같은 사건과 같은 특정 상황이 발생할 때 해당 정책을 어떻게 다루는 지 설명하십시오. 당신은 당신이하고있는 일을 알고 싶어하며 그 기록을 가지고 있습니다. 감사 자와만을 지키기 위해 먼 길을 갈 것입니다. 그것은 좋은 일입니다.
물론 해커들도 해커에 대해 몇 분 이야기하고 왜 그런 위협을 일으키는 지 이야기 할 것입니다. 물론 랜섬웨어는 지구를 매우 짧은 순서로 덮은 WannaCry 랜섬웨어 WannaCry와 NSA의 많은 정보에 대한 영리한 비우호적 인 사람들과 함께 해킹 툴이 사용되었습니다. 드러난. 저는 사람들에게 오래된 우화 인이 es 우화가 있다는 것을 상기시켜줍니다. 우리는 종종 적들에게 우리 자신의 파괴 도구를줍니다. 다시 한 번, 이 기술은 NSA와 국가 안보 협회 (National Security Association)에 의해 분리 되었기 때문에 실제로 기억해야 할 사항이 없기 때문에 명심해야합니다. 그러나 그것은 노출되어 세상에 나왔고 혼란에 빠졌습니다. 뭔지 맞춰봐? 그리고 많은 회사들이 Windows 환경을 업그레이드하지 않았기 때문에 오래된 환경은 Windows XP라고 생각했습니다. 다시 한 번 부지런하고 패치 및 운영 체제 버전을 유지하고 데이터를 백업하고 데이터를 복원하는 경우에도 마찬가지입니다. 해야 할 모든 일을하고 있다면 그런 문제는 그리 큰 문제가 아닙니다. 그러나 당신은 단지 도끼 인 사람들에게 말할 수 있습니다.“이봐 요? 우리는 신경 쓰지 않고, 시스템을 종료하고, 재부팅하고, 백업을로드합니다.”그리고 경쟁에 빠졌습니다.
요점은 그렇습니다. 이러한 나쁜 일들이 일어나지 만, 그것에 대해 할 수있는 일이 있습니다. 그것이 우리가 오늘 쇼에서 이야기 할 내용입니다. 그래서, 저는 약간의 연구를했습니다 – 실제로, 당신이 Wikipedia에 가서 해킹을 찾게되면, 그것은 1903 년까지 계속됩니다. 한 사람이 전신 시스템을 해킹하고 전신을 통해 무례한 메시지를 보낼 때, 그가 해킹 할 수 있다는 것을 증명하기 위해 나는 그것이 오히려 재미 있다고 생각했다. 요점은 해커가 기본적으로 침입하고 침입하는 데 능숙하다는 것입니다. 이것이 그들이 수년 동안 해왔 던 일입니다. 그들은 현대 인터넷 세계의 자물쇠 선택기와 같습니다.
그리고 모든 시스템이 해킹 될 수 있고 내부에서 해킹 될 수 있으며 외부에서 해킹 될 수 있음을 기억해야합니다. 이러한 해킹이 발생할 때 많은 시간이 지나면 스스로를 보여주지 않거나 시스템을 해킹하는 사람들은 한동안 많은 일을하지 않을 것입니다. 그들은 잠시 기다립니다. 약간의 전략이 관련되어 있으며, 부분적으로는 사업의 비즈니스 측면 때문입니다. 일반적으로 해커가하는 일은 프로그램의 작은 부분 만 수행하기 때문에 침투에 능숙한 많은 사람들이 방화벽과 침투 정보 시스템은 그것이 가장 잘하는 일입니다. 일단 시스템에 침투하면 돌아 서서 누군가에게 그 액세스 권한을 판매하려고 시도합니다. 그리고 시간이 걸리기 때문에 종종 배후에있는 누군가가 해킹 한 모든 시스템 (잠재적으로 재미 있지 않은 시스템)에 대한 액세스를 판매하려고하는 경우가 있습니다. 시스템 액세스 비용을 지불합니다.
따라서, 도난 된 정보를 이용하기 위해 연합하고 협력하는 이러한 종류의 분리 된 개인 또는 조직의 네트워크가 있습니다. 신원 도용이든 데이터 도난이든, 회사에 불쾌감을 주는지 여부 – 이것이 랜섬웨어의 경우 시스템을 잡고 돈을 요구하고 돈을 얻는다면 어쩌면 또는 아마 그들은 당신의 물건을 돌려주지 않을 것입니다. 물론, 그것은 정말로 무서운 일입니다. 왜 그 대가를 지불하고 싶습니까? 그들이 그것을 돌려 줄 것이라는 것을 어떻게 알 수 있습니까? 그들은 단지 두 배 또는 세 배를 요청할 수 있습니다. 다시 말하지만, 이 모든 것은 정보 전략, 데이터에 대한 탄력성을 통해 실제로 사고하는 것의 중요성을 나타냅니다.
그래서 저는 더 많은 연구를했습니다. 그것은 오래된 386입니다. 나처럼 나이가 들면이 시스템들을 기억할 수 있습니다. 그리고 그들은 해킹 측면에서 그렇게 문제가되지 않았습니다. 당시에는 바이러스가 많지 않았습니다. 요즘은 다른 게임이므로 인터넷은 물론 모든 것을 바꿉니다. 이제 모든 것이 연결되고 전 세계 관중이 생겼으며, 최초의 주요 바이러스가 공격하기 시작했으며 실제로 해킹 산업이 솔직히 시작되었습니다.
IoT에 대해 조금 이야기하겠습니다. 이미 청중으로부터 좋은 질문을 받았습니다. 취약성 관점에서 IoT 장치를 어떻게 보호합니까? 그것은 매우 큰 문제입니다. 꽤 솔직히 말하면 IoT 장치의 해킹 가능성을 처리하는 방법에 많은 노력을 기울이고 있습니다. 예를 들어 신중하게 설정하는 과정, 자신의 암호를 설정하는 과정을 거치는 등 암호 보호 기능이 많이 사용됩니다. 많은 경우 사람들은 기본 암호를 그대로두고 실제로 취약점을 만듭니다. 이것이 기본입니다. 우리는 이번 주 초에 라디오 쇼에서 보안에 관한 또 다른 전문가를 보았습니다. 그들은 IoT 또는 랜섬웨어 또는 기타 문제가 있다면 해킹 문제의 80-90 % 이상을 피할 것이라고 말했습니다. 기본을 다룰 때, 만약 당신이 당신의 기지를 덮 었는지 확인했다면, 당신은 당신이해야 할 것으로 알고있는 모든 기본적인 것들을했고, 거기에서 모든 문제의 80 % 이상을 처리했습니다.
사물 인터넷, 그래, IoT. 글쎄, 당신이 IoT에 대해 생각한다면, 그것은 새로운 것이 아닙니다. 솔직히 말해서 20 년과 30 년 전에 이런 종류의 일을하고있는 고가의 제조업체들이 있습니다. 그리고 15, 20 년 전에는 RFID가 들어 왔을 때 – 무선 주파수 식별 태그 – 매우 큰 도움을주는 데 매우 유용했습니다. 소매 업체와 같은 조직 (예 : 운송 회사), 전 세계로 물건을 옮기는 모든 제품 회사, 모든 데이터를 보유하는 것이 매우 유용합니다. 물건이 어디로 가는지 알아보십시오. 무언가가 사라지면 알게됩니다.
물론, 그것은 완벽한 솔루션이 아닙니다. 사실, 애틀랜타 공항 (애틀랜타 하트 필드 공항)에서 내 노트북으로 노트북을 꺼내어 누군가 내 컴퓨터를 가지고 가방을 가져갔습니다. 나는 그들이 더 이상 가방을 훔치지 않는다고 생각했다. 그들은 항상 가방을 찾습니다 – 잘못. 누군가가 가방을 훔친 후 약 한 달 후에 나타났습니다. 깨어 났고, iCloud에서 애플이 애틀란타 하트 필드 공항 남쪽에서 약 7-10 분 동안 일어났다는 작은 메시지를 받았습니다. 누군가 방금 들어가기로 결정했습니다. 그들은 약 한 달 동안 앉아 있었고, 나는 상당히 실망스러운 과정을 겪었습니다. 알았어요. 대략 그것이 어디에 있는지, 그것이이 집, 그 집, 길 건너편에있는 집, 그것은 단지 일시적으로 있었다. 너 뭐하니? 마찬가지로, 그 정보가 당신에게 어떻게 유용합니까?
따라서 무언가를 배우더라도 때때로 그것에 대해 많은 것을 할 수는 없습니다. 그럼에도 불구하고, 이 IoT 가능 세상은, 우리가 정직하게 말할 준비가되어 있지 않다고 생각합니다. 좋은 기술이 많이 존재하는 경우가 있다고 생각합니다. 위협이 너무 심각하기 때문에 이러한 것들을 활용하기에는 너무 빨리 움직일 수 있습니다. 우리는 사람들이 그것에 대해 이야기하면서 위협의 일부인 장치의 수를 생각합니다.
최근에 발생한 DNS 서버를 없애고, IoT 장치를 DNS 서버와 함께 사용하고, 고전적인 DDoS 해킹, 분산 된 서비스 거부, 문자 그대로 호출하도록 다시 프로그래밍하는 것과 관련하여 최근에 발생한 큰 해킹 이 DNS 서버에 수십만 건의 요청이 들어 오면 질식하고 충돌하고 죽을 것입니다. 인기가없는 웹 사이트에서 서버가 추락 한 위대한 이야기는 이런 종류의 트래픽을 위해 만들어진 것이 아닙니다.
따라서 IoT는 명심해야 할 사항입니다. 다시 한 번 백업 및 복원을 처리하는 경우 특정 시점에서 이러한 공격이 발생할 수 있음을 기억하는 것이 중요합니다. 준비하지 않으면 많은 고객을 잃게 될 것입니다. 왜냐하면 많은 사람들을 매우 불행하게 만들 것이기 때문입니다. 그리고 당신은 그 평판 관리를 할 것입니다. 그것은 "평판 관리"라는 새로운 용어 중 하나입니다. 명성을 쌓기까지 몇 년, 몇 분 또는 몇 초가 걸릴 수 있다는 점을 명심해야합니다. 정보 전략을 계획 할 때 명심하십시오.
그렇다면 하이브리드 클라우드라는 전체 개념이 있습니다. 어린 시절부터 가장 좋아하는 영화 중 하나 인 Dr. Moreau 박사는 반 동물, 반 생물을 만들었습니다. 하이브리드 클라우드와 같습니다. 따라서 온-프레미스 시스템은 수년간 여기에있을 것입니다. 실수하지 마십시오. 온 프레미스 데이터 센터를 정리하는 데 오랜 시간이 걸릴 것입니다. 심지어 소규모 기업에서도 시스템과 드라이브에 많은 고객 데이터가 있고 상황이 복잡할수록 더 많은 정보를 얻기가 더 어려워집니다. 즉, 하나의 데이터베이스에 통합하는 것은 특히 MySQL과 같은 시스템에서 항상 어려운 과제입니다.
모든 것을 하나의 시스템에 넣는 것은 결코 쉬운 일이 아닙니다. 일반적으로 완료되면 문제가 있으며 성능 문제가 발생합니다. 다시 한 번, 그것은 꽤 오랫동안 문제가 될 것입니다. 물론 데이터 센터와 비즈니스에 레거시 인프라가 있습니다. 이것이 WannaCry의 문제였습니다. 모든 XP 시스템이 있다는 것입니다. Microsoft는 더 이상 XP를 지원하지 않습니다. 따라서 이러한 문제 중 일부가 금전적으로 심각하고 고통스럽게되고 기본 유지 관리 및 유지 관리를 통해 피할 수있는 방법은 정말 놀랍습니다. 기본 물건.
따라서 기술 격차가 생길 것입니다. 이러한 기술 격차는 시간이 지남에 따라 점점 커질 것입니다. 다시 말하지만 클라우드는 미래이기 때문입니다. 의심의 여지가 없다고 생각합니다. 클라우드는 상황이 가고있는 곳입니다. 구름에는 이미 무게 중심이 있습니다. 그리고 앞으로 더 많은 기업이 점점 더 많은 조직과 클라우드를 찾고있는 조직을 보게 될 것입니다. 따라서 그것은 온-프레미스 측면에 약간의 기술 격차를 남길 것입니다. 아직은 없지만오고 있습니다. 할부 상환에 대해서도 생각하십시오. 따라서 많은 대기업들은 클라우드로 이동할 수 없습니다.하지만 할 수는 있지만, 모든 자산을 상각하기 때문에 비용 측면에서 의미가 없습니다. 아마도 3 년에서 5 년에서 7 년 정도입니다.
이는 상당히 중요한 시간 창을 만드는데, 이 기간 동안 온 프레미스에서 클라우드 환경으로 마이그레이션 할 것입니다. 솔직히 우리는 현재 온 프레미스가 클라우드보다 보안 성이 떨어지는 시점에 도달했습니다. 회사가 보안상의 이유로 클라우드로가는 것에 대해 걱정하고 클라우드가 해킹에 취약한 것에 대해 걱정했습니다. 글쎄, 여전히 그래도, 그러나 실제로 당신이 큰 사람들을 본다면, 아마존, 마이크로 소프트, 심지어는 지금 SAP와 구글, 이 모든 사람들은 그 것들에 꽤 뛰어나고, 클라우드 보안에 꽤 뛰어납니다. 그 자체.
그리고 물론, 최종적으로 온-프레미스 쪽의 날짜가 지정된 시스템에서 : 이러한 응용 프로그램은 요즘 꽤 빨리 치아에 오래 걸립니다. 한 번 농담을 들었습니다. 레거시 소프트웨어의 정의는 프로덕션 환경에있는 소프트웨어입니다. (웃음) 재미 있다고 생각합니다. 그래서 클라우드 시스템을 넘어서서 주요 플레이어를 언급했는데, 그들은 하루가지나면서 점점 커지고 있습니다. AWS는 여전히 그 공간을 지배하고 있지만 Microsoft는 자신의 신용을 실제로 파악하여 매우 집중적으로 집중하고 있습니다. SAP, SAP HANA Cloud, 이것이 바로 HANA 클라우드 플랫폼입니다. 이는 SAP와 명백한 이유로 큰 관심 영역입니다. 그들은 이제 클라우드에 중력이 있다는 것을 알고 있으며, 클라우드가 기술을위한 훌륭한 관리 영역이라는 것을 알고 있습니다.
따라서 현재보고있는 것은 클라우드 아키텍처를 통한 이러한 통합이며, 향후 2 년 동안 클라우드에서 클라우드로의 마이그레이션에 대해 많은 작업을 수행하게 될 것입니다. 클라우드 전체의 마스터 데이터 관리조차도 큰 문제가 될 것입니다. 그리고 Salesforce – Salesforce가 얼마나 커 졌는지 살펴보십시오. 이는 반드시 고려해야 할 사항입니다. 또한 클라우드에 마케팅 시스템이 있습니다. 현재 5, 000 개의 마케팅 기술 회사가 있습니다 – 5, 000! 미쳤어 그리고이 단일 창에서 멀티 클라우드 환경을 관리 할 수 있도록 더 많은 노력을 기울이고 있습니다. 마지막 슬라이드 하나를 Tep에 넘겨서 게임보다 앞서 나가는 방법에 대한 조언을 드리겠습니다.
우리는 이번 주 초 라디오 쇼에서 공유 책임 클라우드 모델에 대해 이야기했습니다. 따라서 이들이 말하는 것은 AWS가 클라우드 보안을 담당하는 방식이므로 클라우드 보안입니다. 컴퓨팅 스토어, 데이터베이스 네트워크 등을 볼 수 있습니다. 그러나 고객은 클라우드의 데이터 및 보안을 담당합니다. 그들이 "공동 책임"이라는 용어를 사용하기 때문에 재미 있었고, 우리 쇼의 손님으로부터 수집 한 것은 그것이 전혀 공유되지 않았다는 것입니다. 아이디어는 푸시가 밀리고 누군가가 환경을 감염시키는 경우, AWS가 책임을지지 않을 가능성이 높기 때문에 귀하의 책임입니다.
그래서 그것은 일종의 이상한 세계입니다. 저는 그것이“공유 된 책임”이라는 두 개의 단순한 용어라고 생각합니다. 왜냐하면 실제로는 그런 것이 아니기 때문입니다. 그것은 여전히 그 모든 것들의 위에 머물러있는 당신의 책임입니다. 그래서 저는 IoT에 대해 조금 이야기했습니다. IoT 장치를 보호하는 방법에 대한 좋은 질문이있었습니다.이를 처리 할 수있는 기술의 범위가 절대적으로 늘어날 것입니다. 분명히 IoT 장치 자체의 일부 펌웨어에 일부 소프트웨어가 있으므로 명심해야합니다. 해당 인증에 사용해야하는 인증 프로토콜에 대해 걱정해야합니다. 그러나 내가 말했듯이 기본 사항은 아마도 암호 보호, 암호 변경 및 실제로 그 위에 머물러있는 것들을 모니터링하고보고하는 대부분의 문제를 겪을 것입니다. .
예를 들어, 사기 또는 네트워크의 악의적 인 활동을 모니터링하는 데 사용되는 많은 기술은 실제로 특이 치에 중점을두고 있으며, 특이한 행동 패턴을 관찰하고 특이점을 군집화하고 감시 할 때 머신 러닝이 실제로 매우 유용합니다. 솔직히 말해서, DNS 서버에 대한 최근의 DDoS 공격에서 우리가 보았던 것과 같이 갑자기 모든 장치가 특정 소수의 서버에 콜백을 보내기 시작합니다. 솔직히 말해서, 나는 항상 이런 시스템을 사람들에게 상기시켜줍니다 : 당신이 그런 종류의 환경에서 진지한 자동화를하고, 항상 수동 오버라이드를하고, 킬 스위치를 가지고있을 때 – 당신은 어떤 종류의 킬 스위치를 종료 시키도록 프로그램하고 싶습니다 그런 것들.
이를 통해 Tep의 첫 번째 슬라이드를 진행할 것입니다. 그는 우리를 위해 몇 가지 데모를 진행할 것입니다. 그런 다음 WebEx 탭의 키를 제공하겠습니다. 이제, 그것은 당신의 길을오고있다.
Tep Chantra : 감사합니다. Eric. 저는 Tep Chantra이고 IDERA의 제품 관리자입니다. 오늘날 IDERA의 엔터프라이즈 백업 솔루션, 즉 SQL Safe Backup에 대해 이야기하고 싶었습니다. SQL 세이프 백업에 익숙한 분들을 위해, 실례가되는 제품의 주요 특징을 간단히 살펴 보겠습니다. 따라서 이미 짐작했듯이 사람들은 백업, SQL Server 백업 및 복원 제품을 말합니다. SQL Safe의 주요 기능 중 하나는 빠른 백업을 수행하는 기능입니다. 또한 대부분의 백업을 수행해야하며 대부분의 경우 짧은 시간 내에 매우 빠르게 백업해야한다는 점을 고려하면 중요한 기능입니다.
현재 일부 환경에서는 백업해야하는 큰 데이터베이스가 여러 개인 경우 백업 창을 만나는 것이 매우 어려울 수 있습니다. 백업 작업을 신속하게 완료 할 수있는 SQL Safe 기능을 통해 최종 사용자는 해당 백업 창을 충족 할 수 있습니다. 큰 데이터베이스에 대해서는 큰 데이터베이스를 백업하고 분명히 큰 백업 파일을 사용하십시오. SQL Safe가 빛나는 또 다른 기능은 백업 파일을 압축하는 기능입니다. 사용 된 압축 알고리즘은 최대 90-95 % 압축을 달성 할 수 있습니다. 즉, 백업을 더 오래 저장하거나 스토리지 요구 측면에서 비용을 절감 할 수 있습니다.
백업 작업의 반대편에는 복원 작업이 있습니다. DBA가 데이터베이스를 복원 할 때 반드시 해결해야하는 전투 중 하나는 데이터베이스를 최대한 빨리 복원해야한다는 것입니다. 큰 데이터베이스의 경우 백업 파일의 전체 복원에는 몇 시간이 걸릴 수 있으며, 이는 다운 타임이 길어지고 수익이 손실 될 수 있음을 의미합니다. SQL Safe에는 운 좋게도 "Instant Restore"라는이 기능이 있습니다.이 기능은 기본적으로 복원을 시작하는 시점과 최종 사용자 또는 응용 프로그램이 데이터베이스에 액세스 할 수있는 시점 사이의 시간을 줄입니다.
고객에게 한 번 이야기 한 것을 기억합니다. 한 특정 데이터베이스의 복원에 14 시간이 걸렸다 고보고했습니다. 그러나 인스턴트 복원 기능을 사용하면 1 시간 이내에 해당 데이터베이스에 액세스 할 수있었습니다. 정책 기반 관리, SQL Safe의 또 다른 특징은 이러한 정책을 통해 정책을 생성하고 백업 작업을 관리하는 기능입니다. 정책을 구성 할 때 기본적으로 어떤 인스턴스를 백업하거나 해당 인스턴스의 어떤 데이터베이스를 백업해야하는지, 어떤 종류의 백업 작업을 수행해야하는지, 심지어 백업 일정을 정의해야합니다.
또한 경고 알림을 구성 할 수도 있습니다. 이렇게하면 백업이 성공적으로 완료되었거나 백업이 실패했거나이 메시지가 표시 될 수 있지만 해당 작업과 관련된 경고가있는 등의 이벤트에 대한 알림을받을 수 있습니다. 예약 된대로 백업이 실행되지 않은 경우에도 알림이 표시됩니다. 백업이 존재하지 않는 시간을 위험에 빠뜨릴 수 있다는 중요한 알림입니다. 그리고 그러한 알림을 받으면 거기서 나가서 백업을 실행 한 다음 해당 백업이 예약 된대로 실행되지 않은 이유에 대해 조사해야 할 것입니다.
결함 허용 미러링이라는 다른 것들 중 일부는 본질적으로 둘 이상의 위치에 중복 백업 파일을 생성 할 수 있음을 의미합니다. 예를 들어, 기본 저장소의 대상 위치가 모든 백업 파일이있는 기본 저장소라는 대상 저장소가 있다고 가정 해 보겠습니다. 그러나 일부 추가 테스트를 수행해야하는 경우를 대비하여 로컬 시스템 자체에 동일한 백업 파일의 사본이 필요할 수 있습니다. 경우에 상관없이 데이터베이스를 복원 할 수 있는지 확인하십시오. SQL 가상 데이터베이스 최적화 – 본질적으로 우리는 최근 SQL 가상 데이터베이스라고하는 SQL Safe에 통합 된 다른 제품을 보유하고 있습니다.
앞서 언급했듯이 최근 통합되어 SQL Safe 자체에 실제로 포함되어 있습니다. 이제 SQL 가상 데이터베이스에서 본질적으로 할 수있는 것은 실제로 가상 데이터베이스를 만드는 것입니다. (웃음) 정의와 같은 용어를 사용하는 것이 싫지만 기본적으로 데이터베이스를 마운트하고 백업 파일을 기반으로합니다. 따라서 본질적으로 발생하는 일은 SQL Server가 데이터베이스가 실제로 가동되어 실행되고 있다고 생각하는 반면 실제로는 파일 시스템에서 실제 데이터베이스 자체를 만드는 것이 아니라 백업 파일에서 실제로 데이터를 읽는 것입니다.
이것은 실제로 추가 디스크 공간을 소비하지 않고 백업 파일 내에있는 데이터에 액세스 할 수있게 해주므로 특히 유용합니다. 특히 방금 가져와야하는 거대한 데이터베이스를 처리 할 때 빠르게 볼 수 있습니다. 또는 일부 개발 작업을 수행하십시오. 영향을받지 않는 암호화 – 본질적으로 이러한 데이터베이스의 백업을 수행하는 위치에서 실제로 백업 파일을 암호화 할 수 있으며 이러한 백업 파일을 암호화 할 때 실제에 추가로드를 추가하지 않습니다. 시스템 성능. 따라서 완전히 무시할 수 있습니다. 로그 전달은 앞서 언급 한 정책과 유리한 라이센싱과 관련하여 우리가 할 수있는 또 다른 일입니다. 즉, 라이센싱 모델을 통해 라이센싱 모델을 사용하여 라이센싱 모델을 한 인스턴스에서 다른 인스턴스로 이동할 수 있습니다. 마우스를 몇 번만 클릭하면됩니다.
계속해서 제품 자체의 아키텍처를 간단히 살펴 보겠습니다. 따라서 제품에는 기본적으로 네 가지 주요 구성 요소가 있습니다. 왼쪽부터 SQL Safe Management Console과 Web Console을 시작했습니다. 둘 다 본질적으로 사용자 인터페이스이며, 하나는 데스크톱 클라이언트이고 다른 하나는 웹 응용 프로그램입니다. 이 두 사용자 인터페이스는 다음 구성 요소 인 SQL Safe Repository Database에서 데이터를 가져옵니다. 저장소 데이터베이스는 기본적으로 모든 운영 히스토리, 모든 백업 및 복원 조작을 저장합니다. 이러한 세부 사항은 여기에 저장됩니다. 저장소에있는이 모든 데이터는 다음 구성 요소 인 SQL Safe Management Service에서 관리합니다. 관리 서비스는 리포지토리 데이터베이스를 업데이트하고 경고 알림을 보냅니다. 백업 및 복원 작업과 관련된 데이터는 실제로 가장 오른쪽에있는 마지막 구성 요소 인 SQL Safe Backup 에이전트에서 가져옵니다.
SQL Safe Backup 에이전트는 SQL Safe로 관리하려는 SQL Server 인스턴스를 호스팅하는 모든 서버에 설치되는 구성 요소입니다. 그리고 이것은 실제로 백업을 수행하고 압축하는 역할을하는 서비스입니다. 이제이 슬라이드에는 다섯 번째 구성 요소도 있습니다.이 구성 요소는 완전히 필요한 것은 아니지만 사용하기 편리한 기능입니다. 이것이 바로 SQL Server Reporting Services RDL 파일입니다. 이것이 기본적으로 할 수있는 일은 리포지토리 데이터베이스에 대해 보고서를 실행할 수 있도록 일부 RDL 파일을 SQL Server Reporting Service에 배포하는 것입니다. 또한 백업을 마지막으로 실행 한 시간, 백업 작업에 대한 세부 정보, 보유한 것과 같은 다양한 보고서가 있습니다.
실례합니다 계속해서 SQL Safe 자체를 살펴 보겠습니다. 잠시만 기다려주세요. 그리고 로그인을 위해 잠시만 기다려주십시오. 보시다시피, 지금 웹 응용 프로그램을로드했지만 실제로는 데스크톱 응용 프로그램을 살펴보고 싶습니다. 그러니 정말 빨리 해보도록하겠습니다. 그리고 이것은 처음로드 될 때 SQL Safe 오늘보기로 이동하는 SQL Safe 데스크톱 응용 프로그램입니다. 이것은 본질적으로 오늘부터 발생한 모든 백업 작업 또는 복원 작업을 나열합니다. 또한 여기에서 볼 수 있듯이 환경에 대한 빠른 상태를 제공합니다. 여기에는 내 정책에 하나의 정책 만 있고 OK 상태에 있다는 것입니다. 이는 하나의 정책 만 있고 그 결과를 기대하기 때문입니다. 아닙니다. 또한 성공한 작업, 실패했을 수있는 작업에 대한 요약 정보를 제공합니다. 전반적으로, 나는 몸매가 좋았습니다. 간단히 살펴보면 모든 채소를 볼 수 있습니다. 우리는 잘 지내요.
왼쪽에는 SQL Safe에 등록한 모든 서버와 기본적으로 관리하는 서버가 있습니다. 확장하면 해당 시스템의 데이터베이스 목록이 표시됩니다. 특정 데이터베이스를 선택하면 해당 특정 데이터베이스의 작동 내역을 볼 수 있습니다. 이 창에서 계속해서 임시 백업을 수행 할 수 있다는 것 외에는 설명 할 것이 많지 않으며 실제로 빠르고 간단합니다. 그리고 당신에게 그것을 빨리 보여 드리겠습니다. 마우스 오른쪽 버튼으로 클릭하고 원하는 작업을 선택하십시오. 이를 위해 백업 데이터베이스를 선택하겠습니다. 그리고 SQL 안전 백업 마법사가 열립니다. 여기에서 백업을 수행하려는 인스턴스와 같은 정보를 얻고 백업 할 데이터베이스를 선택하십시오. 이 경우, HINATA 시스템과이 Contoso Retail 데이터베이스를 미리 선택했습니다. 옵션을 선택할 때 강조한 것이기 때문입니다. 계속하겠습니다.하지만 지금은 더 많은 데이터베이스를 선택할 수있는 옵션이 있습니다. 예를 들어 모든 사용자 데이터베이스를 백업하려는 경우이 라디오 버튼을 선택하면 모든 데이터베이스를 미리 선택할 수 있습니다. 그. 계속해서 진행하겠습니다.
마법사의 다음 페이지로 이동하십시오. 여기에서 수행하려는 백업 유형을 선택할 수 있으며 여기에 다양한 옵션이 있습니다. 즉, 모든 백업 유틸리티에서 찾을 수 있습니다. 예를 들어 전체 백업, 차등 백업, 트랜잭션 로그 백업을 수행하거나 실제로 데이터베이스 파일 자체 만 백업하면됩니다. 또한 복사 전용 백업을 작성하는 옵션도 있습니다.이 백업은 기본적으로 LSM을 사용하지 않으려는 경우에 사용됩니다. 지금은“아니오”를 선택하겠습니다. 또한 백업이 완료된 후 백업을 확인하는 옵션도 있습니다. 이렇게하면 백업이 양호하고 나중에 사용할 수있게됩니다. 항상 백업 기능을 사용할 수 있다는 약간의 확신을주기 위해 보유하고 싶은 기능 중 하나입니다.
여기에 이름과 데이터 설명이 있습니다. 이것은 본질적으로 백업이 사용 된 것을 쉽게 식별 할 수있는 메타 데이터이므로 여기서는 데모 목적을 설명하겠습니다. 데모를 위해 데이터베이스 백업을 사용하십시오. 다음으로 백업 파일을 저장할 위치를 정의하고 여기에 여러 가지 옵션이 있습니다. 단일 파일로 저장하거나 스트라이프 파일을 만들 수 있으며 여기에서 대상 대상을 선택할 수 있습니다. 또한 데이터 도메인을 지원합니다. 정보를 저장하려는 경우를 대비하여 Amazon ST 클라우드입니다.
이 데모를위한 단일 파일을 진행하겠습니다. 네트워크 복원을 가능하게합니다. 이는 네트워크 위치로 백업하는 경우 SQL Safe에서 정말 유용한 기능입니다. 기본 아카이브에서 볼 수 있습니다. 네트워크 위치로 백업하는 경우 일부 네트워크 문제가 발생할 수 있습니다. 경우에 따라 네트워크 딸꾹질이 카운터되면 백업 작업이 완전히 중단됩니다. 네트워크 복원 옵션을 활성화하십시오. 본질적으로 네트워크 딸꾹질이 발생하는 경우, SQL Safe는 본질적으로 백업을 일시 중지하고 특정 시간 동안 기다렸다가 네트워크 위치를 다시 시도하는 것입니다. 연결이 가능하면 중단 된 곳에서 바로 백업을 재개합니다. 이렇게하면이 백업을 실행하는 데 한 번에 몇 시간을 소비하지 않고 네트워크 히치가 발생했을 때 바로 백업을 수행 할 수 있습니다. 우리는 즉시 작업을 판매하지 않습니다. 조금만 기다리면됩니다. 다시 완료하십시오.
이를 구성 할 때 다른 옵션이 있습니다. 이제 기본적으로 다시 시도하는 간격이 수반되므로 네트워크 히치가 발생하면 10 초 후에 다시 네트워크 위치에 액세스하려고 시도합니다. 여기서 두 번째 옵션은 기본적으로 네트워크 장애가 발생하면 여기에 300 초 (총 5 분)가 표시되므로 백업 작업을 완전히 판매 할 것입니다. 그 순서는 5 분이므로 계속해서 다시 시도하고 5 분 안에 네트워크 연결을 다시 설정할 수 없으면 작업을 완전히 판매 할 것입니다. 이 마지막 작업은 기본적으로 전체 백업 기간 동안 수행되므로 여기에서 10 초를 잃고 연결을 다시 설정 한 다음 다시 연결을 끊으면 연결이 끊어집니다. 기본적으로 60 분 동안 반복되면 해당 작업은 매진됩니다. 보시다시피 환경에 맞게 구성 할 수 있습니다.
이 미러 아카이브 옵션은 바로 여기에서 내결함성이있는 미러링을 사용하여 이야기 한 것입니다. 원하는 경우 다른 백업 위치를 지정할 수 있습니다. 나는 이것을 체크하지 않은 채로 두겠습니다. 왜냐하면 나는 계속 진행하고 싶습니다. 이러한 옵션 창에서이 백업 작업에 사용할 압축 유형 및 백업 파일에 대한 암호화를 활성화할지 여부를 정의 할 수 있습니다. 압축을 원하지 않는 경우 압축을 포함하여 여러 가지 압축 옵션을 제공합니다. 따라서 이러한 옵션을 빠르게 넘어가는 것입니다.
고속은 기본적으로 약간의 압축을 포함하면서 가능한 빨리 백업을 완료하려고합니다. ISize는 가능한 한 많은 압축을 포함하는 데 더 중점을 두지 만 압축을 많이하기 때문에 시간이 조금 더 걸리고 CPU를 조금 더 사용할 수 있습니다. 수준 1은 기본적으로 추가 할 수있는 최대 압축 수준 인 수준 4까지의 압축률이 가장 낮음을 의미합니다. 그래서 이것은 iSpeed가 조금 더 자세합니다. 일반적으로 단어는 무엇입니까? 레벨 1과 레벨 2 압축 사이의 범위; 사용 가능한 CPU 및 사용 가능한 리소스의 양을 확인하기 위해 시스템을 살펴보고 많은 압축에 대한 판단을 내리므로 레벨 1과 레벨 2 사이에서 사용해야합니다.
ISize는 레벨 3 및 레벨 4를 제외하고 동일한 기능을 수행합니다. 여기에 사용해야하는 CPU의 수와 같은 다른 고급 옵션이 있습니다. 여기에는 SQL의 가상 데이터베이스에 대한 맵핑 데이터를 작성하는 옵션과 인스턴트 복원 기능. 데이터베이스 로그인 및 일부 사용자가 매우 중요하게 여기는 검사 생성과 같은 일부 옵션을 포함시켜 나중에 백업 파일이 양호한 지 확인할 수 있습니다. 다음 페이지로 넘어 가면 알림을 설정하는 곳입니다. 여기에있는 다양한 옵션을 볼 수 있습니다. 어떤 이유로 든 백업이 실패하면 알리고 백업을 건너 뛰면 알리십시오. 백업이 취소되었거나 백업이 경고와 함께 완료되고 원하는 경우 백업이 깨끗하다는 알림을받을 수 있습니다. 많은 수의 데이터베이스가있는 환경에서는 백업이 성공할 가능성이 높고 이메일이 넘칠 수 있기 때문에 사용하지 않을 수도 있습니다.
다음 페이지에서이 백업 작업으로 인해 정의한 내용의 요약을 볼 수 있습니다. 원하는 경우 모든 것이 좋아 보인다면 계속해서 백업을 클릭하면 시작됩니다. 백업을 클릭하기 전에이 "스크립트 생성"버튼을 보여 드리겠습니다. SQL Safe는 실제로 백업 또는 복원 작업을 시작할 수있는 명령 줄 인터페이스를 제공하기 때문에 명령 줄을 통해 DOS 프롬프트를 사용할 수 있습니다. 여기서 스크립트 생성을 클릭하면 명령 행에서 백업을 해제하려는 경우 기본적으로 사용할 수있는 실제 스크립트가 제공됩니다.
또 다른 좋은 점은 확장 저장 프로시 저도 제공한다는 것입니다.이 경우 확장 저장 프로 시저를 사용하여 정확히 동일한 백업 작업을 실행하는 스크립트를 생성합니다. 이제이 백업을 시작하겠습니다. 백업이 이미 시작되었음을 알 수 있습니다. 이 데이터베이스는 약간 크기 때문에 약간의 시간이 걸릴 수 있습니다. 이전에 여기에서 몇 번 달렸다는 것을 알 수 있습니다. 1 분에서 3 분 정도 걸립니다. 이것은 레벨 4 이므로이 두 번 사이에있을 것이라고 추측합니다.
그것이 실행되는 동안 정책을 실제로 살펴 보자. 앞에서 언급했듯이 정책을 사용하면 엔터프라이즈 전체에서 예약 된 백업 작업을 구성 할 수 있으므로 여기에 미리 구성된 새 정책을 만들지 않고 여기에 정책이 있으므로 계속 진행하여이 세부 정보를 살펴 보겠습니다. 사과하십시오. 내 VM이 개인 랩톱에서 실행 중이며 팬을 매우 열심히 실행하는 것 같습니다. (웃음)
Eric Kavanagh : 좋습니다. 우리가 여기서보고있는 동안 질문을하려고했습니다. IDERA는 백업 측면에서 많은 변경 데이터 캡처를 사용합니까 아니면 매번 전체 백업을 수행합니까? 어떻게 작동합니까?
Tep Chantra : 한 번 더 말씀 해주세요. 죄송합니다.
Eric Kavanagh : 예. IDERA가 CDC를 사용하는지, 더 작은 백업을 수행하기 위해 데이터 캡처 기술을 변경하는지 또는 매번 전체 백업을 수행하는지 알고 있습니까?
Tep Chantra : 믿지 않습니다. 나는 많은 티켓에서 이전에 그것을 본 것을 기억합니다. 그리고 내가 정확하게 기억한다면, 우리는 CDC를 활용하지 않고, 정직하게 말해서, SQL Server가 본질적으로 백업을 수행하게하고, 그 사이에 데이터를 캡처하고 압축하여 결과적으로 작성중인 백업 파일 따라서 본질적으로 사용합니다. 네.
이제 정책을로드했습니다. 죄송합니다. 다른 질문이 있습니까?
에릭 카바나 흐 : 아니, 그게 다야 . 어서
Tep Chantra : 알겠습니다. 이제 정책을로드했습니다. 이름, 설명, 관리 할 정책인지 여부에 따라 생성 할 정책의 종류를 설정할 수 있습니다. 일정이 SQL Server 에이전트에 의해 관리되거나 일정이 SQL Server 백업 에이전트에 의해 관리됩니다. 대부분의 경우 SQL Server 에이전트를 사용하려고합니다. 일반적으로 시스템에서 실행되는 것이기 때문에 사용 가능한 기능을 활용할 수도 있습니다. 멤버쉽 탭에서 백업하려는 백업 데이터베이스의 인스턴스를 지정합니다. 이 경우 등록 된 모든 인스턴스를 추가했으며 백업해야 할 특정 데이터베이스를 지정했습니다. 이제 원한다면 편집하고 "모든 데이터베이스 나 사용자 데이터베이스 또는 시스템 데이터베이스를 백업하고 싶습니다."라고 말할 수 있습니다. 이것에 대한 좋은 점은 와일드 카드를 사용하여 만들 수도 있다는 것입니다. 특정 데이터베이스.
설정을 크게 변경하고 싶지 않기 때문에 여기서 변경하지는 않겠습니다. 다시 옵션으로 돌아가 봅시다. 그리고 옵션에서 여기에 수행 할 백업 종류를 정의하고 여기에서 살펴보면 전체 백업, 차등 백업 및 대규모 백업이 구성되어 있습니다. 그리고 이러한 각 백업에 대해 특정 양의 압축을 사용할지 아니면 암호화를 켤지를 정의 할 수 있습니다. 애드혹 마법사에서 찾은 옵션과 동일합니다. 또한 위치에서 이러한 백업 작업의 대상을 정의 할 수도 있습니다. 정책에 대한 좋은 점 중 하나는 X 일 수 또는 몇 주를 기준으로 이전 백업 파일을 계속 삭제할지 여부를 정의 할 수 있다는 것입니다.
그리고 각 백업 유형마다 구성 할 수 있습니다. 보시다시피, 일주일 후에 전체 백업을 삭제할 수 있습니다. 이틀 후에 차등 삭제를하고 하루 후에 백업을 삭제하고 싶습니다. 시간에 따라 실제로 필요한 파일 만 유지하면서 시나리오, 오래된 백업 파일 처리를 자동화하기 때문에 정말 좋습니다. 다음 페이지에서는 일정을 정의하고 다시 일정은 완료하려는 각 백업 작업 유형에 따라 다를 수 있으므로 전체 일정에 대해 매주 실행되고 차등마다 6 시간마다 실행됩니다., 내 로그는 30 분마다 실행됩니다. 다음 페이지에는 알림을 설정하는 위치이며 기본적으로 애드혹 백업에서 찾은 것과 동일한 유형의 알림입니다. 한 가지 차이점은 백업이 시작되지 않는 경우 알려줄 수있는 새로운 옵션입니다. 예정대로. 여기에서 백업이 실행되지 않은 상황에 대해 경고 할 수 있습니다. 특히 필요할 때 백업을 사용할 수 있도록 특정 SLA가있는 경우 특히 중요합니다. 그리고 다음 페이지에서 요약을 볼 수 있습니다. 변경 한 경우 완료를 클릭하면 나가서 해당 변경을 수행 한 후 저장하여 예를 들어 SQL Server 에이전트 작업의 저장소에 저장합니다.
그리고 여러분에게 아주 빨리 보여 드리기 위해, 여기 특정 정책을 위해 만든 정책과 작업이 있습니다. 그리고 각 백업 유형마다 하나씩 세 가지 다른 작업이 생성 된 것을 볼 수 있습니다. 이제, 앞에서 언급했듯이 가상 데이터베이스는 우리가 SQL Safe에 통합했던 것과 같은 HUD 인터페이스와 종류를 간단히 살펴 보겠습니다. 앞에서 언급했듯이 실제로는 실제로 백업 파일을 읽을 때 실제 데이터베이스가 복원되었다고 믿는 SQL Server를 속입니다. 자, 여러분 께 한 가지 빠르지 않겠습니다. 백업 파일을 가져 오겠습니다. 여기, 여기 4 개를 가져 가겠습니다. 프로세스가 완료되었으며 실제로 데이터베이스를 새로 고치면 데이터베이스에 액세스 할 수 있고 SQL Server가 데이터베이스를 사용 중이라고 생각하지만 실제로는 데이터베이스에서 데이터를 읽는 중입니다.
이 릴리스의 새로운 기능 중 일부는 최신 백업 형식을 사용하여 백업을 수행하는 기능입니다. 정책 기반 관리를 사용해야하는 고객에게는 편리하지만 어떤 이유로 든 SQL Server 파일 형식을 유지하려고합니다. 이제 시간이 다되었다는 것을 알고 있으므로 질문을 할 수 있도록이 프리젠 테이션을 중단하고 싶습니다.
에릭 카바나 : 네. 그래서 저는 열쇠 중 하나가 실제로 정책 관리에 있다고 생각합니다. 최적의 정책에 대해 생각할 때 무엇을 기반으로합니까? 분명히 어떤 경우에는 걱정해야 할 규정이 있지만 비즈니스에서는 규제가 엄격하지 않을 수 있습니다. 백업을 수행하기위한 최적의 시간 만 찾으면 계산 시간 등의 계산 시간 및 비용에 대한 보고서를 얻을 수 있습니다. 최적의 정책을 정의하려면 어떻게해야합니까?
Tep Chantra : 실제로 모든 경우에 백업이 언제 실행되어야하는지에 대한 정책이 달라집니다. 또한 실행중인 백업 유형, 실행 일정을 수반 할 수 있으며 복구 요구 사항에 따라 실제로 결정됩니다. 이것이 정답입니다.
에릭 카바나 흐 : 예. 그리고 당신은 다른 종류의 백업과 줄무늬를 할 수 있다는 것에 대해 이야기했습니다. 일종의 뜨겁고 차가운 데이터에 대한 것인가, 아니면 다른 방법과 달리 스트라이프가되는 논리는 무엇입니까?
Tep Chantra : 제가 제공 할 수있는 가장 좋은 대답은 스트라이프 파일입니다. 본질적으로 우리가하는 일은 여러 다른 파일에 백업 내용을 작성하는 것입니다. 스트라이프 파일을 사용하는 아이디어는 백업 파일을 더 빨리 쓸 수 있다는 것입니다. 예를 들어, 각기 다른 파일을 다른 위치로 옮길 수 있습니다. 백업 파일을 다른 위치에 배포하기 때문에 서버 보안 비용도 발생합니다.
Eric Kavanagh : 복원 기능 측면에서 시원하고 새로운 것이 있습니까? 자연 재해이든 랜섬웨어이든 관계없이 어떤 종류의 사건이 있다고 가정 해 봅시다. 복원을위한 옵션이 하나만있을 필요는 없습니다. 복원 대상과 어떤 종류의 데이터에 대한 우선 순위를 설정할 수 있습니까? 옵션에 대해 이야기 할 수 있습니까?
Tep Chantra : 복원의 관점에서, 우리는 즉각적인 복원을 수행 할 수있는 기능을 제공한다고 언급했습니다. 그리고 증명하기 위해, 나는 이전에 한 가지를 했으므로 여기서 볼 수 있습니다. 다시, 이 데이터베이스는 그리 크지 않습니다. 이것은 내 랩톱에서 실행되는 데이터베이스입니다. 따라서 크기가 2 기가 같을 것이라고 생각하지만이 데이터베이스는 37 초 이내에 완료되었습니다. 실제 복원 따라서 데이터에 액세스 할 수있게되기까지 37 초가 걸렸습니다. 즉석 복원을 사용하면 2 초 내에 데이터베이스에 액세스 할 수있었습니다. 따라서 데이터베이스가 훨씬 큰 경우 어떻게 보일지 상상할 수 있습니다.
에릭 카바나 : 네, 좋은 지적입니다. 그리고 물론, 우리는 공연 전에 이것에 대해 이야기하고있었습니다. 사람들을 지원하는 전선에서 많은 시간을 보냈다가 제품 관리 영역으로 넘어 갔기 때문에 약간 다른 과제라고 생각합니다. 하지만 당신은 최전선에있었습니다 – 사람들이 잘못 가고있는 곳과 어떤 문제가 있는지 배우는 것이 좋은 곳이라고 생각합니다. 사람들이이 문제를 더 잘 생각하면 피할 수있는 가장 일반적인 함정 중 무엇이라고 생각하십니까?
Tep Chantra : 일반적인 함정 중 일부는 백업 일정을 세우는 것 입니다. 예를 들어 정책, 정책, 많은 백업을 수행하는 정책, LSM을 기반으로하는 정책 등 사람들이 활용하려는 경우가 있습니다. 그리고 어떤 경우에는 일부 사람들이 데이터베이스에서 백업을 수행하는 다른 유틸리티를 가지고 있다는 것을 보았습니다. 백업은 본질적으로 SQL Safe 외부에서 이루어지고 있기 때문에 로그 전달 정책을 엉망으로 만듭니다. 그것은 단지 미리 계획을 세우는 것입니다. 그 함정이 시작되는 곳입니다.
Eric Kavanagh : 놀랍지 않습니다. 자, 이것은 여러분의 기업을 행복하게하고 고객을 행복하게하는 데 필요한 차단 및 태클에 대한 훌륭한 검토였습니다. 저는 IDERA의 Tep Chantra에게 감사의 말씀을 전하고 싶습니다. 여기에 들어서서 몇 가지 라이브 데모를하는 것은 항상 흥미 롭습니다. 라이브 데모를하는 것은 항상 약간 위험하지만, 저는 꽤 잘 진행된 것 같습니다. 알다시피, 그것은 기본적인 것들이지만, 그렇게하지 않으면 모든 종류의 문제가 생길 것입니다. 따라서 이것은 회사에서 사람들이하는 중요한 일입니다.
테프, 시간 내 주셔서 감사합니다. 여러분은 나중에 볼 수 있도록 이러한 모든 웹 캐스트를 보관하므로 보통 1-2 시간 내에 다시 돌아와서 보관소를 확인할 수 있습니다. 그러나 다시 한 번, 여기서 중요한 것은, 우리는 기업이 일을 처리하는 데 도움을 주려고 노력하고 있습니다. 여러분의 시간과 관심에 감사드립니다. 다음에 연락 드리겠습니다. 당신은 핫 테크놀로지를 들었습니다. 조심해 사람들 안녕.