Disaster Recovery | Breaking Cybersecurity News | The Hacker News

While cloud adoption has been top of mind for many IT professionals for nearly a decade, it's only in recent months, with industry changes and announcements from key players, that many recognize the time to make the move is now. It may feel like a daunting task, but tools exist to help you move your virtual machines (VMs) to a public cloud provider – like Microsoft Azure – with relative ease. Transitioning from VMware vSphere to Microsoft Azure requires careful planning and execution to ensure a smooth migration process. In this guide, we'll walk through the steps involved in moving your virtualized infrastructure to the cloud giant, Microsoft Azure. Whether you're migrating your entire data center or specific workloads, these steps will help you navigate the transition effectively. 1. Assess Your Environment: Before diving into the migration process, assess your current VMware vSphere environment thoroughly. Identify all virtual machines (VMs), dependencies, and resource

Super Low RPO with Continuous Data Protection: Dial Back to Just Seconds Before an Attack Zerto , a Hewlett Packard Enterprise company, can help you detect and recover from ransomware in near real-time. This solution leverages continuous data protection (CDP) to ensure all workloads have the lowest recovery point objective (RPO) possible. The most valuable thing about CDP is that it does not use snapshots, agents, or any other periodic data protection methodology. Zerto has no impact on production workloads and can achieve RPOs in the region of 5-15 seconds across thousands of virtual machines simultaneously. For example, the environment in the image below has nearly 1,000 VMs being protected with an average RPO of just six seconds! Application-Centric Protection: Group Your VMs to Gain Application-Level Control   You can protect your VMs with the Zerto application-centric approach using Virtual Protection Groups (VPGs). This logical grouping of VMs ensures that your whole applica

As a vCISO, you are responsible for your client's cybersecurity strategy and risk governance. This incorporates multiple disciplines, from research to execution to reporting. Recently, we published a comprehensive playbook for vCISOs, "Your First 100 Days as a vCISO – 5 Steps to Success" , which covers all the phases entailed in launching a successful vCISO engagement, along with recommended actions to take, and step-by-step examples.  Following the success of the playbook and the requests that have come in from the MSP/MSSP community, we decided to drill down into specific parts of vCISO reporting and provide more color and examples. In this article, we focus on how to create compelling narratives within a report, which has a significant impact on the overall MSP/MSSP value proposition.  This article brings the highlights of a recent guided workshop we held, covering what makes a successful report and how it can be used to enhance engagement with your cyber security clients.

More than a decade ago, the concept of the  'blameless'  postmortem changed how tech companies recognize failures at scale. John Allspaw, who coined the term during his tenure at Etsy, argued postmortems were all about controlling our natural reaction to an incident, which is to point fingers: "One option is to assume the single cause is incompetence and scream at engineers to make them 'pay attention!' or 'be more careful!' Another option is to take a hard look at how the accident actually happened, treat the engineers involved with respect, and learn from the event." What can we, in turn, learn from some of the most honest and blameless—and public—postmortems of the last few years? GitLab: 300GB of user data gone in seconds What happened : Back in 2017, GitLab experienced a painful 18-hour outage. That story, and GitLab's subsequent honesty and transparency, has significantly impacted how organizations handle data security today. The incident began when GitLab's secondary datab

Unsurprisingly, here at  Rewind , we've got a lot of data to protect (over 2 petabytes worth). One of the databases we use is called Elasticsearch (ES or Opensearch, as it is currently known in AWS). To put it simply, ES is a document database that facilitates lightning-fast search results. Speed is essential when customers are looking for a particular file or item that they need to restore using  Rewind . Every second of downtime counts, so our search results need to be fast, accurate, and reliable. Another consideration was disaster  recovery . As part of our  System and Organization Controls Level 2 (SOC2)  certification process, we needed to ensure we had a working disaster recovery plan to restore service in the unlikely event that the entire AWS region was down. "An entire AWS region?? That will never happen!" (Except for  when it did )  Anything is possible, things go wrong, and in order to meet our SOC2 requirements we needed to have a working solution. Specif