Posts

How to create a Failover Cluster in Windows Server 2019

This article gives a short overview of how to create a Microsoft Windows Failover Cluster (WFC) with Windows Server 2019 or 2016. The result will be a two-node cluster with one shared disk and a cluster compute resource (computer object in Active Directory).

Windows server 2019 failover cluster

Preparation

It does not matter whether you use physical or virtual machines, just make sure your technology is suitable for Windows clusters. Before you start, make sure you meet the following prerequisites:

Two Windows 2019 machines with the latest updates installed. The machines have at least two network interfaces: one for production traffic, one for cluster traffic. In my example, there are three network interfaces (one additional for iSCSI traffic). I prefer static IP addresses, but you can also use DHCP.

failover cluster 02

Join both servers to your Microsoft Active Directory domain and make sure that both servers see the shared storage device available in disk management. Don’t bring the disk online yet.

The next step before we can really start is to add the “Failover clustering” feature (Server Manager > add roles and features).

Reboot your server if required. As an alternative, you can also use the following PowerShell command:

Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools

After a successful installation, the Failover Cluster Manager appears in the start menu in the Windows Administrative Tools.

After you installed the Failover-Clustering feature, you can bring the shared disk online and format it on one of the servers. Don’t change anything on the second server. On the second server, the disk stays offline.

After a refresh of the disk management, you can see something similar to this:

Server 1 Disk Management (disk status online)


Server 2 Disk Management (disk status offline)

Failover Cluster readiness check

Before we create the cluster, we need to make sure that everything is set up properly. Start the Failover Cluster Manager from the start menu and scroll down to the management section and click Validate Configuration.

Select the two servers for validation.

Run all tests. There is also a description of which solutions Microsoft supports.

After you made sure that every applicable test passed with the status “successful,” you can create the cluster by using the checkbox Create the cluster now using the validated nodes, or you can do that later. If you have errors or warnings, you can use the detailed report by clicking on View Report.

Create the cluster

If you choose to create the cluster by clicking on Create Cluster in the Failover Cluster Manager, you will be prompted again to select the cluster nodes. If you use the Create the cluster now using the validated nodes checkbox from the cluster validation wizard, then you will skip that step. The next relevant step is to create the Access Point for Administering the Cluster. This will be the virtual object that clients will communicate with later. It is a computer object in Active Directory.

The wizard asks for the Cluster Name and IP address configuration.

As a last step, confirm everything and wait for the cluster to be created.

The wizard will add the shared disk automatically to the cluster per default. If you did not configure it yet, then it is also possible afterwards.

As a result, you can see a new Active Directory computer object named WFC2019.

You can ping the new computer to check whether it is online (if you allow ping on the Windows firewall).

As an alternative, you can create the cluster also with PowerShell. The following command will also add all eligible storage automatically:

New-Cluster -Name WFC2019 -Node SRV2019-WFC1, SRV2019-WFC2 -StaticAddress 172.21.237.32

You can see the result in the Failover Cluster Manager in the Nodes and Storage > Disks sections.

The picture shows that the disk is currently used as a quorum. As we want to use that disk for data, we need to configure the quorum manually. From the cluster context menu, choose More Actions > Configure Cluster Quorum Settings.

Here, we want to select the quorum witness manually.

Currently, the cluster is using the disk configured earlier as a disk witness. Alternative options are the file share witness or an Azure storage account as witness. We will use the file share witness in this example. There is a step-by-step how-to on the Microsoft website for the cloud witness. I always recommend configuring a quorum witness for proper operations. So, the last option is not really an option for production.

Just point to the path and finish the wizard.

After that, the shared disk is available for use for data.

Congratulations, you have set up a Microsoft failover cluster with one shared disk.

Next steps and backup

One of the next steps would be to add a role to the cluster, which is out of scope of this article. As soon as the cluster contains data, it is also time to think about backing up the cluster. Veeam Agent for Microsoft Windows can back up Windows failover clusters with shared disks. We also recommend doing backups of the “entire system” of the cluster. This also backs up the operating systems of the cluster members. This helps to speed up restore of a failed cluster node, as you don’t need to search for drivers, etc. in case of a restore.


This article was provided by our service partner : Veeam

How to properly load balance your backup infrastructure

Veeam Backup & Replication is known for ease of installation and a moderate learning curve. It is something that we take as a great achievement, but as we see in our support practice, it can sometimes lead to a “deploy and forget” approach, without fine-tuning the software or learning the nuances of its work. In our previous blog posts, we examined tape configuration considerations and some common misconfigurations. This time, the blog post is aimed at giving the reader some insight on a Veeam Backup & Replication infrastructure, how data flows between the components, and most importantly, how to properly load balance backup components so that the system can work stably and efficiently.

Overview of a Veeam Backup & Replication infrastructure

Veeam Backup & Replication is a modular system. This means that Veeam as a backup solution consists of a number of components, each with a specific function. Examples of such components are the Veeam server itself (as the management component), proxy, repository, WAN accelerator and others. Of course, several components can be installed on a single server (provided that it has sufficient resources) and many customers opt for all-in-one installations. However, distributing components can give several benefits:

  • For customers with branch offices, it is possible to localize the majority of backup traffic by deploying components locally.
  • It allows to scale out easily. If your backup window increases, you can deploy an additional proxy. If you need to expand your backup repository, you can switch to scale-out backup repository and add new extents as needed.
  • You can achieve a High Availability for some of the components. For example, if you have multiple proxies and one goes offline, the backups will still be created.

Such system can only work efficiently if everything is balanced. An unbalanced backup infrastructure can slow down due to unexpected bottlenecks or even cause backup failures because of overloaded components.

Let’s review how data flows in a Veeam infrastructure during a backup (we’re using a vSphere environment in this example):

veeam 1

All data in Veeam Backup & Replication flows between source and target transport agents. Let’s take a backup job as an example: a source agent is running on a backup proxy and its job is to read the data from a datastore, apply compression and source-side deduplication and send it over to a target agent. The target agent is running directly on a Windows/Linux repository or a gateway if a CIFS share is used. Its job is to apply a target-side deduplication and save the data in a backup file (.VKB, .VIB etc).

That means there are always two components involved, even if they are essentially on the same server and both must be taken into account when planning the resources.

Tasks balancing between proxy and repository

To start, we must examine the notion of a “task.” In Veeam Backup & Replication, a task is equal to a VM disk transfer. So, if you have a job with 5 VMs and each has 2 virtual disks, there is a total of 10 tasks to process. Veeam Backup & Replication is able to process multiple tasks in parallel, but the number is still limited.

If you go to the proxy properties, on the first step you can configure the maximum concurrent tasks this proxy can process in parallel:

veeam 2

For normal backup operations, a task on the repository side also means one virtual disk transfer.

On the repository side, you can find a very similar setting:

veeam 3

For normal backup operations, a task on the repository side also means one virtual disk transfer.

This brings us to our first important point: it is crucial to keep the resources and number of tasks in balance between proxy and repository.  Suppose you have 3 proxies set to 4 tasks each (that means that on the source side, 12 virtual disks can be processed in parallel), but the repository is set to 4 tasks only (that is the default setting). That means that only 4 tasks will be processed, leaving idle resources.

The meaning of a task on a repository is different when it comes to synthetic operations (like creating synthetic full). Recall that synthetic operations do not use proxies and happen locally on a Windows/Linux repository or between a gateway and a CIFS share. In this case for normal backup chains, a task is a backup job (so 4 tasks mean that 4 jobs will be able to generate synthetic full in parallel), while for per-VM backup chains, a task is still a VM (so 4 tasks mean that repo can generate 4 separate VBKs for 4 VMs in parallel). Depending on the setup, the same number of tasks can create a very different load on a repository! Be sure to analyze your setup (the backup job mode, the job scheduling, the per-VM option) and plan resources accordingly.

Note that, unlike for a proxy, you can disable the limit for number of parallel tasks for a repository. In this case, the repository will accept all incoming data flows from proxies. This might seem convenient at first, but we highly discourage from disabling this limitation, as it may lead to overload and even job failures. Consider this scenario: a job has many VMs with a total of 100 virtual disks to process and the repository uses the per-VM option. The proxies can process 10 disks in parallel and the repository is set to the unlimited number of tasks. During an incremental backup, the load on the repository will be naturally limited by proxies, so the system will be in balance. However, then a synthetic full starts. Synthetic full does not use proxies and all operations happen solely on the repository. Since the number of tasks is not limited, the repository will try to process all 100 tasks in parallel! This will require immense resources from the repository hardware and will likely cause an overload.

Considerations when using CIFS share

If you are using a Windows or Linux repository, the target agent will start directly on the server.  When using a CIFS share as a repository, the target agent starts on a special component called a “gateway,” that will receive the incoming traffic from the source agent and send the data blocks to the CIFS share. The gateway must be placed as close to the system sharing the folder over SMB as possible, especially in scenarios with a WAN connection. You should not create topologies with a proxy/gateway on one site and CIFS share on another site “in the cloud” — you will likely encounter periodic network failures.

The same load balancing considerations described previously apply to gateways as well. However, the gateway setup requires an additional attention because there are 2 options available — set the gateway explicitly or use an automatic selection mechanism:

Any Windows “managed server” can become a gateway for a CIFS share. Depending on the situation, both options can come handy. Let’s review them.

You can set the gateway explicitly. This option can simplify the resource management — there can be no surprises as to where the target agent will start. It is recommended to use this option if an access to the share is restricted to specific servers or in case of distributed environments — you don’t want your target agent to start far away from the server hosting the share!

Things become more interesting if you choose Automatic selection. If you are using several proxies, automatic selection gives ability to use more than one gateway and distribute the load. Automatic does not mean random though and there are indeed strict rules involved.

The target agent starts on the proxy that is doing the backup. In case of normal backup chains, if there are several jobs running in parallel and each is processed by its own proxy, then multiple target agents can start as well. However, within a single job, even if the VMs in the job are processed by several proxies, the target agent will start only on one proxy, the first to start processing. For per-VM backup chains, a separate target agent starts for each VM, so you can get the load distribution even within a single job.

Synthetic operations do not use proxies, so the selection mechanism is different: the target agent starts on the mount server associated with the repository (with an ability to fail over to Veeam server if the mount server in unavailable). This means that the load of synthetic operations will not be distributed across multiple servers. As mentioned above, we discourage from setting the number of tasks to unlimited — that can cause a huge load spike on the mount/Veeam server during synthetic operations.

Additional notes

Scale-out backup repositorySOBR is essentially a collection of usual repositories (called extents). You cannot point a backup job to a specific extent, only to SOBR, however extents retain some of settings, including the load control. So what was discussed about standalone repositories, pertains to SOBR extents as well. SOBR with per-VM option (enabled by default), the “Performance” placement policy and backup chains spread out across extents will be able to optimize the resource usage.

Backup copy. Instead of a proxy, source agents will start on the source repository. All considerations described above apply to source repositories as well (although in case of Backup Copy Job, synthetic operations on a source repository are logically not possible). Note that if the source repository is a CIFS share, the source agents will start on the mount server (with a failover to Veeam server).

Deduplication appliances. For DataDomain, StoreOnce (and possibly other appliances in the future) with Veeam integration enabled, the same considerations apply as for CIFS share repositories. For a StoreOnce repository with source-side deduplication (Low Bandwidth mode) the requirement to place gateway as close to the repository as possible does not apply — for example, a gateway on one site can be configured to send data to a StoreOnce appliance on another site over WAN.

Proxy affinity. A feature added in 9.5, proxy affinity creates a “priority list” of proxies that should be preferred when a certain repository is used.

If a proxy from the list is not available, a job will use any other available proxy. However, if the proxy is available, but does not have free task slots, the job will be paused waiting for free slots. Even though the proxy affinity is a very useful feature for distributed environments, it should be used with care, especially because it is very easy to set and forget about this option. Veeam Support encountered cases about “hanging” jobs which came down to the affinity setting that was enabled and forgotten about. More details on proxy affinity.

Conclusion

Whether you are setting up your backup infrastructure from scratch or have been using Veeam Backup & Replication for a long time, we encourage you to review your setup with the information from this blog post in mind. You might be able to optimize the use of resources or mitigate some pending risks!


This article was provided by our service partner veeam.com

Incident Response

6 Steps to Build an Incident Response Plan

According to the Identity Theft Research Center, 2017 saw 1,579 data breaches—a record high, and an almost 45 percent increase from the previous year. Like many IT service providers, you’re probably getting desensitized to statistics like this. But you still have to face facts: organizations will experience a security incident sooner or later. What’s important is that you are prepared so that the impact doesn’t harm your customers or disrupt their business.

Although, there’s a new element that organizations—both large and small—have to worry about: the “what.” What will happen when I get hacked? What information will be stolen or exposed? What will the consequences look like?

While definitive answers to these questions are tough to pin down, the best way to survive a data breach is to preemptively build and implement an incident response plan. An incident response plan is a detailed document that helps organizations respond to and recover from potential—and, in some cases, inevitable—security incidents. As small- and medium-sized businesses turn to managed services providers (MSPs) like you for protection and guidance, use these six steps to build a solid incident response plan to ensure your clients can handle a breach quickly, efficiently, and with minimal damage.

Step 1: Prepare

The first phase of building an incident response plan is to define, analyze, identify, and prepare. How will your client define a security incident? For example, is an attempted attack an incident, or does the attacker need to be successful to warrant response? Next, analyze the company’s IT environment and determine which system components, services, and applications are the most critical to maintaining operations in the event of the incident you’ve defined. Similarly, identify what essential data will need to be protected in the event of an incident. What data exists and where is it stored? What’s its value, both to the business and to a potential intruder? When you understand the various layers and nuances of importance to your client’s IT systems, you will be better suited to prepare a templatized response plan so that data can be quickly recovered.

Treat the preparation phase as a risk assessment. Be realistic about the potential weak points within the client’s systems; any component that has the potential for failure needs to be addressed. By performing this assessment early on, you’ll ensure these systems are maintained and protected, and be able to allocate the necessary resources for response, both staff and equipment—which brings us to our next step.

Step 2: Build a Response Team

Now it’s time to assemble a response team—a group of specialists within your and/or your clients’ business. This team comprises the key people who will work to mitigate the immediate issues concerning a data breach, protecting the elements you’ve identified in step one, and responding to any consequences that spiral out of such an incident.

As an MSP, one of your key functions will sit between the technical aspects of incident resolution and communication between other partners. In an effort to be the virtual CISO (vCISO) for your clients’ businesses, you’ll likely play the role of Incident Response Manager who will oversee and coordinate the response from a technical and procedural perspective.

Pro Tip: For a list of internal and external members needed on a client’s incident response team, check out this in-depth guide.

Step 3: Outline Response Requirements and Resolution Times

From the team you assembled in step two, each member will play a role in detecting, responding, mitigating damage, and resolving the incident within a set time frame. These response and resolution times may vary depending on the type of incident and its level of severity. Regardless, you’ll want to establish these time frames up front to ensure everyone is on the same page.

Ask your clients: “What will we need to contain a breach in the short term and long term? How long can you afford to be out of commission?” The answers to these questions will help you outline the specific requirements and time frame required to respond to and resolve a security incident.

If you want to take this a step further, you can create quick response guides that outline the team’s required actions and associated response times. Document what steps need to be taken to correct the damage and to restore your clients’ systems to full operation in a timely manner. If you choose to provide these guides, we suggest printing them out for your clients in case of a complete network or systems failure.

Step 4: Establish a Disaster Recovery Strategy

When all else fails, you need a plan for disaster recovery. This is the process of restoring and returning affected systems, devices, and data back onto your client’s business environment.

A reliable backup and disaster recovery (BDR) solution can help maximize your clients’ chances of surviving a breach by enabling frequent backups and recovery processes to mitigate data loss and future damage. Planning for disaster recovery in an incident response plan can ensure a quick and optimal recovery point, while allowing you to troubleshoot issues and prevent them from occurring again. Not every security incident will lead to a disaster recovery scenario, but it’s certainly a good idea to have a BDR solution in place if it’s needed.

Step 5: Run a Fire Drill

Once you’ve completed these first four steps of building an incident response plan, it’s vital that you test it. Put your team through a practice “fire drill.” When your drill (or incident) kicks off, your communications tree should go into effect, starting with notifying the PR, legal, executive leadership, and other teams that there is an incident in play. As it progresses, the incident response manager will make periodic reports to the entire group of stakeholders to establish how you will notify your customers, regulators, partners, and law enforcement, if necessary. Remember that, depending on the client’s industry, notifying the authorities and/or forensics activities may be a legal requirement. It’s important that the response team takes this seriously, because it will help you identify what works and which areas need improvement to optimize your plan for a real scenario.

Step 6: Plan for Debriefing

Lastly, you should come full circle with a debriefing. During a real security incident, this step should focus on dealing with the aftermath and identifying areas for continuous improvement. Take is this opportunity for your team to tackle items such as filling out an incident report, completing a gap analysis with the full team,  and keeping tabs on post-incident activity.

No company wants to go through a data breach, but it’s essential to plan for one. With these six steps, you and your clients will be well-equipped to face disaster, handle it when it happens, and learn all that you can to adapt for the future.


This article was provided by our service partner : Webroot

 

Disaster Recovery Planning

How to build a disaster recovery plan with Veeam

Here’s a true story from one of our customers. A gas explosion resulted in a major power failure downtown, which in turn left the company’s primary data center offline for a week. This is a classic example of an IT Disaster – unexpected and unpredictable, disrupting business continuity and affecting Always-On operations. We can only imagine how much it could cost that company to stay offline for a week (as much as losing their business, I’d say), if they didn’t have a reliable disaster recovery plan and an Availability solution to execute this plan.

A solid disaster recovery plan makes your company resilient to IT disruptions and able to restore your services in case of disaster with minimal to no impact on users and business operations. It’s not just making regular backups, but a complex IT infrastructure assessment and documenting (including hardware, software, networks, power and facilities), business impact analysis of applications and workloads and planning on staff, roles and risk assessment. And above all, there’s an essential testing and exercising of your disaster recovery plan. If you don’t test, how would you know that it works as expected?

Unlike physical infrastructures with all their complexity, virtualization gives more flexibility in management and processes allowing you to do more with less. For virtualized data centers, Veeam delivers joint capabilities of enabling data Availability and infrastructure management. By using Veeam Availability Suite, you cover multiple points in your DR plan at once and get:

  • Offsite replication with traffic optimization and advanced capabilities
  • Easier disaster recovery orchestration and recovery testing
  • Infrastructure assessment and documentation
  • Capacity planning and “What if” modelling
  • Backup and virtual infrastructures monitoring and reporting

These also address compliance audit needs by providing you with up-to-date information on backed-up workloads, backups reliability and actual data recovery time versus your SLAs. If staying compliant and ready for audits is important for you, I recommend you read the new white paper by Hannes Kasparick, Mastering compliance, audits and disaster recovery planning with Veeam.

Replication as a core disaster recovery technology

DR planning includes defining the lowest possible RTO to minimize the disruption of business operations. In terms of ability to restore failed operations in minutes, replication mechanism wins the game allowing you to instantly switch the failed workload to its ready-to-use “clone” to get the lowest-possible RTO. For DR purposes, standby replicas of production VMs are stored on a remote secondary site or in the cloud. Even if the production site goes down, like in my example with a major power failure, a remote site remains unaffected by the disaster and can take the load.

Test your disaster recovery plan!

All data security and management standards (ISO family is not an exception) imply DR plan testing as a mandatory exercise. You can never know if everything will work as expected in cases of real disasters until you try it and run the planned procedures in advance. DR simulation will also allow you to ensure that your personnel are well-prepared for extreme IT situations and everyone mentioned in your DR plan is aware of the activities they need to perform. If you discover any drawbacks during DR testing – either human or software-related – you’ll have a good chance to fix your DR plan accordingly and thus potentially avoid serious disruptions in your business continuity.

Automated recovery verification for backups and replica restore points built in Veeam Backup & Replication (for no additional fees!) will save you much time and additional resources for testing. SureReplica allows to boot replicated VMs (VMware only for v9) to the necessary restore point in an isolated Virtual Lab and automatically perform heartbeat, ping and application tests against them. Also, you have an option to run your own customized tests – all without any impact on your production.

Final word

Disaster recovery planning is not just another bureaucracy, but a set of measures to maintain an organization’s business continuity. Built in compliance with international regulations and standards, a DR plan gives your customers a high level of confidence in your non-stop services, data security and Availability. Veeam helps you to stay compliant with both internal and external IT regulations, be ready for audit and be able to restore any system or data in minutes.


This article was provided by our service partner : veeam.com

veeam

Best practices from Veeam support on using tape

When speaking about backup storage strategies, Veeam’s recommendation is to keep the initial backup chain short (7 – 14 points) and use general purpose disk that will allow you to recover data in the shortest amount of time. The long-term retention should come from secondary and tertiary storage, which typically boasts a much lower storage cost per TB, but at a trade-off, the RTO when restoring from such storage can take much longer time. Here’s the graphics, which illustrates this scenario:

veeam support

Additionally, with many new features of Veeam, the tape support now includes putting vSphere, Hyper-V, and Veeam Agents for Microsoft Windows and Linux backups on tape.

One of the most popular choices for backup archival is tape. It is cheap, reliable and offers protection against crypto viruses and hacker attacks. Additionally, it’s offline when not in a tape loader.

With Veeam, IT administrators can use flexible options to create copies of backups and store them on a different media, following the 3-2-1 Rule for the backup and disaster recovery. This blog post provides advice and considerations that will help you create a robust tape archival infrastructure.

How to deploy a tape library and use it with Veeam

When planning and implementing your deployment project, follow the recommendations below:

  1. It is recommended to configure the tape library for use exclusively by Veeam Backup & Replication. Using it together with any third-party tape-recording software (for example, in your evaluation lab) may prevent other software from recording.
  2. To streamline the workflow, use tapes with barcodes. Please check the integrity of the barcodes before you start using the tapes, and make sure the barcode reader is turned on. If you have multiple libraries, ensure that the barcodes are unique throughout the infrastructure.
  3. For increased capacity, use the latest LTO. Since Veeam Backup & Replication 9.5 Update 3, Veeam now supports the LTO-8 format.
  4. If you plan to use encryption for archived data, consider using hardware encryption (implemented in LTO-4 and later). Software encryption can decrease performance.
  5. Do not use hardware compression with compressed Veeam backups. Double compression will not give any benefits and can even increase the size of the file on tape.
  6. Install and check the following:
  • The latest drivers for your tape library. Remember that only the original (OEM) drivers are supported. Drivers supplied with Microsoft Windows are not recommended.
  • The latest changer and controller firmware. Changers working via SCSI are supported.

You will need a tape server that will perform most data transfer tasks during archiving to tape. Check the following prerequisites:

  • This should be a physical machine or a VM connected through iSCSI, since direct pass-through is not supported.
  • Using a Windows 2008 R2 machine for a tape server is not recommended due to the possibility of performance degradation. Instead, use Windows Server 2012 or later to achieve better performance and seamless operation.
  • Best practice is to provide a direct connection from tape server to the repository to improve the performance and specify this preferred repo in tape server connections.
  • If you plan to create synthetic backups, using a deduplication storage is not recommended.

One thing to also consider is to use GFS media pools with the tape support in Veeam. This feature allows longer-term retention to be set easily for tape backups as shown in the picture below:

veeam support

If you plan to perform file-to-tape archiving for a large number of files (more than 500,000 per job), consider using any commercial edition of SQL Server for Veeam configuration database to support these operations. Configuration database stores information about all files backed up by Veeam Backup & Replication, and using SQL Server Express edition (with its 10 GB limit for a database size) may lead to significant performance degradation. If database size reaches 10 GB, all Veeam operations will stop.

To load or get the tapes from the library, use the import-export slots. If you need to perform these operations manually, remember to stop tape jobs, stop tape server, perform manual operation, start server, rescan or run inventory for the library (to recognize the uploaded tapes) and then restart the tape job.

  • If the tapes have barcodes, then you can perform the rescan.
  • If the tapes do not have barcodes, then you should perform the inventory.

What to consider before starting the upgrade

If you are upgrading your Veeam deployment, then you should first upgrade the Veeam backup server.

The tape server will be upgraded after that, using the automated steps of the Upgrade wizard that opens after the first launch of Veeam Backup & Replication console. However, you can choose to upgrade it manually by starting the Upgrade wizard at any time from the main Veeam Backup & Replication menu.

If you are upgrading your tape library, consider the following:

  1. To streamline the process and skip the catalogue step, you can add the new library to the existing media pools, and after the old library is switched off, remove it from the media pools.
  2. After connecting the new library to Veeam server, you should load the existing tapes with their barcodes to that new library and perform the rescan. Then you can switch the old library to the offline state (detach it from Veeam server) and then delete it from Veeam Backup & Replication configuration.

What to consider when planning for tape jobs

Before you start configuring Veeam jobs for tape archiving, consider the following factors:

  1. What entities will you need to archive? Will these be files and folders, or VM backups? Do you need to archive full backups only, or both full and incremental backups?
  2. What is the estimated data size?
  3. How often will you need to archive data?
  4. What will be the retention policy for your data?
  5. How often will the tapes be changed? Will they be exported?
  6. What is the tape capacity?
  7. What tape device will be used for archiving?

After these considerations, it is recommended that you double your estimated number of tapes when planning for the resources.

Conclusion

In this blog post, we’ve talked mainly about tape infrastructure. We recognize that when setting up tape jobs, the learning curve can be quite steep. Instead of explaining all the concepts, we chose a different approach. We’ve prepared a list of settings and a well-defined result that will be achieved. You can choose to use them as they are or as a basis for your personal setup. Check out this Secondary Copy Best Practices Veeam guide for more details.


This article was provided by Veeam.com

Disaster Recovery Planning

Disaster Recovery Planning

It seems like it’s almost every day that the news reports another major company outage and as a result, the massive operational, financial and reputational consequences experienced, both short- and long-term. Widespread systemic outages first come to mind when considering disasters and threats to business and IT service continuity. But oftentimes, it’s the overlooked, “smaller” threats that regularly occur. Human error, equipment failure, power outages, malicious threats and data corruption can too bring an entire organization to a complete standstill.

It’s hard to imagine that these organizations suffering the effects of an outage don’t have a disaster recovery plan in place — they most certainly do. But, why do we hear of and experience failure so often?

Challenges with disaster recovery planning

Documenting

At the heart of any successful disaster recovery plan is comprehensive, up-to-date documentation. But with digital transformation placing more reliance on IT, environments are growing larger and more complex, with constant configuration changes. Manually capturing and documenting every facet of IT critical to business continuity is neither efficient or scalable, sending to us our first downfall.

Testing

Frequent, full-scale testing is also critical to the success of a thorough disaster recovery plan, again considering the aforementioned scale and complexity of modern environments — especially those that are multi-site. Paired with the resources required and potential end-user impact of regular testing, the disaster recovery plan’s viability is often untested.

Executing

The likelihood of a successful failover — planned or unplanned — is slim if the disaster recovery plan continues to be underinvested in, becoming out-of-date and untested quickly. Mismatched dependencies, uncaptured changes, improper processes, unverified services and applications and incorrect startup sequences are among the many difficulties when committing to a failover, whether it’s a single application or the entire data center.

Compliance

While it is the effects of an IT outage that first come to mind when considering disaster recovery, one aspect tends to be overlooked — compliance.

Disaster recovery has massive compliance implications — laws, regulations and standards set in place to ensure an organization’s responsibility to the reliability, integrity and Availability of its data. While what constitutes compliance varies from industry to industry, one thing holds true — non-compliance is not an option and brings with it significant financial and reputational risks.

 

5 Steps to a Stronger Backup Disaster Recovery Plan

Between catastrophic natural events and human error, data loss is a very real threat that no company is immune to. Businesses that experience data disaster, whether it’s due to a mistake or inclement weather, seldom recover from the event that caused the loss.

The saddest thing about the situation is that it’s possible to sidestep disaster completely, specifically when it comes to data loss. You just have to take the time to build out a solid backup disaster recovery (BDR) plan.

Things to consider when developing your BDR plan include: structural frameworks, conducting risk assessments and impact analysis, and creating policies that combine data retention requirements with regulatory and compliance needs.

If you already have a BDR plan in place (as you should), use this checklist to make sure you’ve looked at all the possible angles of a data disaster and are prepared to bounce back without missing a beat. Otherwise, these steps chart out the perfect place to start building a data recovery strategy.

 

1. Customize the Plan

Unfortunately, there’s no universal data recovery plan. As needs will vary per department, it’ll be up to you, and the decision makers on your team, to identify potential weaknesses in your current strategy, and decide on the best game plan for covering all of your bases moving forward.

2. Assign Ownership

Especially in the case of a real emergency, it’s important that everyone on your team know and understand their role within your BDR plan. Discuss the plan with your team, and keep communication open. Don’t wait until the sky turns gray to have this conversation.

3. Conduct Fire Drills

The difference between proactive and reactive plans comes down to consistent checkups. Schedule regular endpoint reviews, alert configuration and backup jobs. Test your plan’s effectiveness with simulated emergency. Find out what works, and what needs improvement, and act accordingly.

4. Centralize Documentation

You’ll appreciate having your offsite storage instructions, vendor contracts, training plans, and other important information in a centralized location. Don’t forget to keep track of frequency and maintenance of endpoint BDR! Which brings us to point 5.

5. Justify ROI

Explore your options. There are many BDR solutions available on the market. Once you’ve identified your business’ unique needs, and assembled a plan of action, do your research to find out what these solutions could do to add even more peace of mind to this effort.

Or, if you’re an employee hoping to get the green light from management to implement BDR at your company, providing documentation with metrics that justify ROI will dramatically increase your likelihood of getting decision-makers on board.

Outside of these 5 components, you should also think about your geographical location and common natural occurrences that happen there. Does it make more sense for you to store your data offsite, or would moving to the cloud yield bigger benefits?

One thing is certain: disaster could strike at any time. Come ready with a plan of action, and powerful tools that will help you avoid missing a beat when your business experiences data loss. At LabTech® by ConnectWise®, we believe in choice, and offer several different BDR solutions that natively integrate to help you mitigate threats and avoid costly mistakes.

This article was provided by our partner Labtech

 

The 10-step guide to a Disaster Recovery plan

Problem: You need a plan for responding to major and minor disasters to let your company restore IT and business operations as quickly as possible.

1. Review Your Backup Strategy

  • Full daily backups of all essential servers and data is recommended.
  • Incremental and differential backups may not be efficient during major disasters, due to search times and hassle
  • If running Microsoft Exchange or SQL servers, consider making hourly backups of transaction logs for more recent restores
  • Store at least one tape off site weekly, and store on-site tapes in a data-approved fireproof safe
  • Have a compatible backup tape drive

2. Make Lots of Lists

  • Document Business Locations
  • Addresses, phone numbers, fax numbers, building management contact information
  • Include a map to the location and surrounding geographic area.
  • Equipment Lists
  • Compile an inventory listing of all network components at each business location. Include: model, manufacturer, description, serial number, and cost
  • Application List
  • Make a list of business critical applications running at each location
  • Include account numbers and any contract agreements
  • Include technical support contact information for major programs
  • Essential Vendor List
  • List of essential vendors, those who are necessary for business operations
  • Establish lines of credit with vendors incase bank funds are no longer readily available after disasters
  • Critical Customer List
  • Compile a list of customers for whom your company provides business critical services
  • Designate someone in the company to handle notifying these customers
  • Draw detailed diagrams for all networks in your organization, including LANs and WANs

3. Diagram Your Network

  • LAN Diagram: Make a diagram that corresponds to the physical layout of the office, as opposed to a logical one
  • Wireless access using Wi-Fi Protected Access security (WPA2) in order to operate in a new location

4. Go Wireless
5. Assign a Disaster Recovery Administrator

  • Assign Primary and Secondary disaster recovery administrators.· Ideally, each admin should live close to the office, and have each other’s contact information. Administrators are responsible for declaring the disaster, defining the disaster level, assessing and documenting damages, and coordinating recovery efforts. When a major disaster strikes, expect confusion, panic, and miscommunication. These uncontrollable forces interrupt efforts to keep the company up and running. By minimizing these challenges through planning with employees, efficiency increases. Assign employees into teams that carry out tasks the Disaster Recovery Administrator needs performed.

6. Assemble Teams

Damage Assessment/Notification Team

  • Collects information about initial status of damaged area, and communicates this to the appropriate members of staff and management
  • Compiles information from all areas of business including: business operations, IT, vendors, and customers

Office Space/Logistics Team

  • Assists in locating temporary office space in the event of a Level Four disaster
  • Responsible for transporting co-workers and equipment to the temporary site and are authorized to contract with moving companies and laborers as necessary

Employee Team

  • Oversees employee issues: staff scheduling, payroll functions, and staff relocation

 

 

Technology Team

  • Orders replacement equipment and restores computer systems.
  • Re-establishes connection to telephone service and internet/VPN connections

Public Relations TeamSafety and Security Team

  • Ensures safety of all employees during the recovery process.
  • Decides who will and who will not have access to any areas in the affected location.

Office Supply Team

7. Create a Disaster Recovery Website

  • A website where employees, vendors, and customers can obtain up-to-date information about the company after a disaster could be vital.· The website should be mirrored and co-hosted at two geographically separate business locations.
  • On the website, the disaster recovery team should post damage assessments for business locations, each location’s operational status, and when and where employees should report for work.
  • The site should allow for timestamped-messages to be posted by disaster recovery administrators. SSL certificates should be assigned to the website’s non-public pages.

8. Test Your Recovery Plan

  • Most IT professionals face level one or level two disasters regularly, and can quickly respond to such events. Level three and four disasters require a bit more effort. To respond to these more serious disasters, your disaster plan should be carefully organized.· Plan to assign whatever resources you do have control over in such situations. Test the plan after revisions, and discuss what worked and what didn’t.

9. Develop a Hacking Recovery Plan

  • Hacks attacks fall under the scope of disaster recovery plans.
  • Disconnect external lines. If you suspect that a hacker has compromised your network, disconnect any external WAN lines coming into the network. If the attack came from the Internet, taking down external lines will make it harder for the hacker to further compromise any machines and with luck prevent the hacker from compromising remote systems.
  • Perform a wireless sweep. Wireless networking makes it relatively simple for a hacker to set up a rogue Access Point (AP) and perform hacks from the parking lot. You can use a wireless sniffer perform a wireless sweep and locate APs in your immediate area.

10. Make the DRP a Living Document

  • · Review your disaster recovery plans at least once a year. If your company network changes frequently, you should probably create a semi-annual review. It’s best to know that an out-of-date disaster plan is almost as useless as having none.
  • WAN Diagram: Include all WAN locations and include IP addresses, model, serial numbers, and firmware revision of firewalls