Introduction to Zmanda Backup and Recovery Solutions

What are the types of data you are familiar with or use in your business? Before you start to roll out your data management initiatives, be it Big Data Analytics, Master Data Management, Enterprise Data Warehouse, etc., you need to start by understanding the fundamental ingredient: the data.

Thoroughly understanding the different types of data and their characteristics will help you in the right way how to treat each of them.

According to The 2018 Data Value Report by SnapLogic, by using data more effectively in their organizations, enterprises expect to increase annual revenue by an average of $5.2 million. However, most businesses don’t always realize data’s potential or know how to utilize it properly for data-driven decisions: On average, organizations are using only half (51%) of the data they collect or generate, and data drives less than half (48%) of decisions.

Let’s get started with what are the types of data:

1. Transactional Data

Transactional data is the information that an agreement, exchange, or transfer that occurs between organizations or individuals. It is considered to be a special category of data as transactions have legal and commercial significance.

Examples of transactional data:

• Invoices: A bill of services or products.
• Trades: A trade that occurs in the market, eg. Stock market.
• Purchases: Customer purchases
• Returns: A record comprising of customer returned items and accepted by the seller.
• Payments: A payment towards debt or purchase.
• Credits: Fund added to an account, for example, an e-commerce site refunding the amount of a returned item.
• Debits: Funds removed fro an account, for instance, a bank customer withdraws money from his/ her account.

The list goes on with payroll, asset sales, interest, contracts, etc.

2. Master Data

Information that an organization can agree upon is known as master data. Often organizations have, unlike information sources that may duplicate similar data with little agreement on standard definitions. Master data represents an opportunity to govern and manage data as a single source of reference.

Examples of Metadata:

• Product data: A catalog with product specifications and information.
• Transactions: Purchases and stock trades
• Tickets: To track problems and customer interactions.
• Analytical Data: Data that supports decision making.

3. Customer Data

All the information associated with a customer is known as customer data. Customer data is information that is essential for the core business processes and decision-making tools.

Examples of customer data:

• Customer Record: The record comprises the name of the customer and customer id.
• Accounts: A customer having various accounts, such as departments that make separate purchases.
• Contacts: Corporate customers ought to have several contacts that include various levels and functions within the customer organization, such as engineering staff or purchasing managers.
• Services: List of current services that the customer is using, such as configurations.

Customer service tickets, feedback, locations, payment methods, offers, and quotes are a few more examples.

4. Machine Data

Data generated by machines without any human involvement is known as machine data. It is one of the important categories as machines create far more data when compared to humans.

Examples of machine data:

• Calculations: Data calculated from the other data. E.g., based on the market data, an algorithm calculates the risk estimate for an investment.
• Sensors: Devices that detect physical phenomena such as sound and light and turn into streams of data.
• Predictions: Artificial intelligence and algorithms that attempt to predict the future.
• Automation: Automated tasks that create data like controls, events, or commands.

5. Reference Data

Data used to structure and constrain other data is known as reference data. It is stable information with a known set of values that rarely change.

Examples of reference data:

• Science: List of known stars
• Geographical Locations: List of valid states for a country.
• Computing: List of standard computing values like HTTP status codes.
• Markets: List of currently valid stock tickers for a market.

6. Quantitative Data

Any data in numeric form is known as quantitative data. This data is often compared with qualitative data that includes information expressed in a natural language like English.

Examples of quantitative data:

• Measurements: Measurement of something physical like a food safety inspection that measures the temperature of food stored in a restaurant refrigerator.
• Quantification: Converting qualitative human judgments into numbers such as asking customers to rate their satisfaction level.
• Calculations: Calculating gross margin based on the monthly sales figure.
• Counts: Counting things.

Types of Data Wrap-Up!

The relentless stream of data that surrounds us today undeniably can transform the way that we do business. As we have access to unprecedented amounts of information about our competitors, clients, and prospects, we can steer our business forward in ways that we always dreamt about just a few years ago.

As Tim Berners-Lee rightly said, “Data is a precious thing and will last longer than the systems themselves.”

Now that you have an idea of what types of data there are, have you thought about how you want to back it up? Check out Rutgers Case Study: How the University Saved Tens of Thousands of Dollars with Zmanda Backup and Recovery.

MySQL Backup: ZRM for MySQL simplifies the life of a database administrator by offering an easy-to-use yet flexible and robust backup and recovery solution for MySQL servers.

Amazon Storage Gateway provides a storage gateway to the Amazon S3 Cloud by asynchronously replicating the volume in the data center to an Amazon Elastic Block Storage (EBS) volume in the cloud. Amazon Storage Gateway can be used to replicate the ZRM configuration and ZRM for MySQL backup images from the storage volume in the data center to the Amazon Cloud. The MySQL database restores can be performed from the backup data stored in the local data center for quick recovery of databases.

Watch the Step by Step Video Here

ZRM MySQL Backups and Amazon Storage Gateway

In case of catastrophic data center failures, the ZRM server configuration and backup data can be recovered to a physical or virtual machine in the local data center or to Amazon EC2 virtual machine in the cloud. After ZRM server recovery, all MySQL databases can be restored and brought online.

How to Find the Login Details for ZRM (MySQL Backup) on AWS?

Let’s have a look at the steps:

1. Login to AWS Console.
2. Click on the EC2 Service- Compute.
3. Click on instances–> Launch instance.
4. Type ZRM in the search tab.
5. Click on Zmanda Recovery Manager (ZRM) in AWS Marketplace.
6. Click Select.
7. Click Continue.
8. Select instance type àdefault t2.medium.
9. Set to default VPC.
10. Click to Add Storage à default= 30GB.
11. Next Click Add Tagsà provide a valid key-value pair.
12. Configure security groupà defaults ssh/22,http/80,https/443.
13. Click Review and Launch.
14. Create new key-pair or choose an existing key-pair with your private key.
15. Click Launch instances.

Note: Allow the instances to be launched and all status checks to be green.

16. Click on EC2 dashboard.
17. Click on the ZRM server that was launched previously

Note: The Public DNS (IPV4 IP address)

18. Launch the IP address in a new browserà It will redirect to a security page (Your connection is not private)à Click on Advanceà Click on Proceed.

Note: This will open you to the Zmanda Management Console web UI.

19. Open a command terminal on your Windows or Unix box.
20. ssh into the Zmanda server that was launchedà example:

ssh -i “zmanda.pem” zmanda@ec2-3-16-90-94.us-east-2.compute.amazonaws.com

Note: This should log you into the instance we just created.

21. vi /tmp/ MySQL ZRMpassword.txt
22. Copy password from this file.
23. Default User= admin

Default Password= What you retrieved from step 22.

Use these credentials to log into ZRM in AWS.

What Are The Other Features of ZRM for MySQL?

• Schedule full and incremental backups of your MySQL database.
• Start immediate backup or postpone scheduled backups based on thresholds defined.
• Choose to do more flexible logical or faster raw backups of your database.
• Perform backup that is the best match for your storage engine and your MySQL configuration.
• Backup your remote MySQL database through a firewall.
• Configure on-the-fly compression and/or encryption of your MySQL backups to meet your storage
  and security needs.
•  Get e-mail notification of the status of your backups and receive MySQL backup reports via RSS
  feed.
•  Monitor and browse your backups.
• Define retention policies and automatically delete backups that have expired.
• Recover a database easily to any point in time or to any particular transaction, e.g. just before a
  user made an error.
•  Parse binary logs to search and filter MySQL logs for operational and security reasons
• Snapshot live MySQL with Linux LVM, Windows VSS, Solaris ZFS, NetApp SnapManager, and Veritas
  VxFS to minimize locking on the database. This allows you to backup mission-critical MySQL
  production environments without interrupting online data access.
• Global management of backup and recovery of hundreds of MySQL databases from a single web-based Zmanda Management Console.

To learn more about ZRM and to see a comprehensive quick start guide click here.

Conclusion

Please follow the above steps to find Login Details for ZRM (MySQL Backup) on AWS. In case you get stuck in the process, kindly contact our team.

You can reach us @ Zsupport@betsol.com or call us @ 888-496-2632 (U.S.)/ 408-732-3208 (INTL)

Also, be sure to check out Rutgers Case Study: How the University Saved Tens of Thousands of Dollars

A disaster recovery plan (DRP) is a document you need to keep handy to handle unexpected incidents that could shut down your company’s IT systems and hinder its overall operation.
A DRP aims to get your business up and running as quickly as possible during a disaster or data breach. With an effective disaster recovery plan, there is less chance of you losing out on profits for too long. Also, it should have backups set in place to prevent sensitive data (social security numbers or credit card information) from getting compromised.

Does Your Business Have a Disaster Recovery Plan?

Data loss, downtime, and tech outrages are some of the new horror stories that even the top companies come across nowadays. Whenever a disaster strikes in a company, the engineering teams rush to repair the damage, and on the other hand, PR teams work overtime to restore customer confidence. Don’t you think it’s a time-consuming and expensive effort? Of course, it is! But some organizations manage these disasters most effectively and that too with less collateral damage. Wondering how? Simple, they have a comprehensive, easy-to-follow, and regularly tested disaster recovery plan.

Disasters come uninvited with loads of complex challenges, which organizations might take months or years to overcome. Cyber attacks, tornadoes, terrorist attacks, hurricanes, and floods are some of the disasters that can cause data breaches. A disaster plan is a long-term assurance of business operability as it is designed in such a way that it enables businesses to reduce damages of unpredicted outages.

Do you have a disaster recovery plan, or are you just beginning the process of creating one for your organization? In either of these cases, the disaster recovery plan checklist below will help you add all the crucial components in your plan.

1. Analyze Potential Threats and Possible Reactions

The first thing is to take time and analyze all the possible factors that can disturb your flow of business. Once you are done with the research, it’s time to create a different recovery plan for each of those scenarios. For instance, cyber attacks are becoming more prevalent and likely to occur, and unfortunately, the average firewall is not that strong enough to protect from most of them.

Thus look at the possibility of a cyber attack more intensely than you would, say, a tsunami. You might opt for encrypting data and securing hardware. Try to understand the vulnerabilities that are within your systems, as these are the points of entry a hacker will use to gain access.

The best way is to keep yourself updated about the many schemes hackers use. You can avoid the majority of phishing and malware infections.

2. Fix the Disaster Recovery Objectives

Disaster recovery helps you keep your business operating as usual, constantly, so you need to fix on IT services that are most critical to run your organization. Also, the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) required for these services/ machines. But are you aware of RTO and RPO?

RPO: The amount of time required to recover from a disaster after notification of business disruption. In case of any disaster, if your business is not able to withstand at least an hour of downtime without losing customers to your competitors, then it’s crucial. You need a reliable disaster recovery plan that comprises of a clearly-stated allowed RTO.

RPO: A window of time in which data is acceptable. After a disaster strike, if your business can only survive a data loss for four hours after a full day of business, this can lead to a catastrophic loss of important data, so your RPO would be four hours.

An organization’s RTO and RPO are sure to affect its recovery strategy and associated expenses. In order to reduce the total cost of the disaster recovery strategy, it is better to divide the applications into tiers. The highest tier reserved for mission-critical applications would require a disaster recovery technology based on real-time continuous data replication. The mid-level tier might require a snapshot-based application, and finally, the lowest tier may get by with a simple file-level backup system.

3. Recognize the Stakeholders in Your Disaster Recovery Plan

The next and crucial step is to identify those who need to be updated once disaster strikes. Engineers, support, executives, etc. will be involved in performing the actual disaster recovery. Still, you need to identify others too like vendors, members of the PR and marketing team, third party suppliers, and key customers. Most of the companies maintain a register of stakeholders in their project office documentation to notify in the case of a disaster.

4. Create a disaster recovery site

There are high chances that a disaster will severely damage your production center, thus making it impossible for you to resume operations at the primary site and thus migrating critical workloads to another location. According to the disaster recovery plan, the checklist you need to build a DR site to use in case of emergency relocation of critical data, staff, physical resources, ad applications. Also, you should equip the site with enough hardware and software to take on the essential workloads.

5. Gather Entire Infrastructure Documentation

When a disaster occurs everything goes for a toss, everyone is under pressure. Indeed, you have your engineering teams with the required skills and knowledge to activate disaster recovery procedures, but infrastructure documentation is mandatory. Even the highly proficient engineers while performing disaster recovery would prefer to go command by command from infrastructure documentation.

So what does this documentation comprise of? The entire setup of systems and their usage (installation, recovery procedures, applications running, OS and configuration), cloud templates, storage and databases (how and where the data is saved, how backups are restored, how the data is verified for accuracy) and all your mapped network connections (with functioning devices and their configuration).

6. Cherry-pick the Precise Technology

Disaster Recovery as a Service (DRaaS) and on-premise disaster recovery is not just the feasible solutions available for business continuity. The next option is to make use of cloud-based disaster recovery in order to spin up your disaster recovery site on a public cloud-like Microsoft Azure, AWS and Google Cloud in minutes using an automated disaster recovery solution.

Before you make a choice of solution, ensure to consider the total cost of ownership, maintenance requirements, scalability, recovery to the previous point in time, and ease of testing. Choices are many when it comes to disaster recovery solution, thus do you thorough research and choose wisely.

7. Launch Communication Channels

No one knows when disaster can knock your door, so being an organization, you must keep a list of teams (along with their roles and contact information) for disaster recovery. Try to establish a comprehensive chain of command which includes accountable individuals from each of the engineering teams (e.g., database, systems, network, storage) and relevant executive leadership. Also, set up dedicated communication channels and hubs, or an online information-sharing tool to use for instant messaging.

8. Outline an Incident Response Procedure

If you have a disaster recovery plan, then an “incident response procedure” is a must. Herein the companies will define in detail which events have to be declared as a disaster. For instance, if your system goes down, will you consider that as a disaster? Also, the plan should also indicate how to verify the disaster and how it will be reported— by an automatic monitoring system, raised by calls from site reliability engineering (SRE) teams, or reported by customers?

In order to verify that a disaster is really happening, you need to check the status of critical network devices, application logs, server hardware, or any other critical components in your production system, that you monitor proactively. If something is odd or not working, then for sure you have a disaster on your hands.

9. Outline an Action Response Procedure

Once disaster strikes, a disaster recovery environment needs to be activated as soon as possible. An action response procedure will outline how to failover to the disaster recovery site with all the required steps. No matter whether your recovery process is using DRaaS or a disaster recovery tool to launch your disaster site automatically, you need to prepare the action response procedure in writing to ensure how the necessary services will be started, verified, and controlled.

Additionally, spinning up production services in another location is not sufficient, ensuring that all the required data is in place, and all the required business applications are functioning properly, is also equally critical.

10. Get Ready for Failback to Primary Infrastructure

Failback is restoring operations at the primary production center once they have been transferred to a DR site during failover. DR sites are not designed to run daily operations; instead, they can be used only for emergency purposes. DR sites are built for a very short period (until the primary site is restored or until a new production center is built).

Once the disaster is over, a lot of effort is required to implement the moving of data and business services back to the primary location—plan for a potential partial disruption of your business during the revert process. Fortunately, there exists disaster recovery solutions that provide unified failback to the primary location, activated automatically or manually once you complete the verification of the primary IT location.

11. Report the incident to stakeholders

Once a disaster occurs, first notify not only those who are responsible for executing DR activities but also key stakeholders such as vendors, customers, members of the PR and marketing team, and third-party suppliers. Also, consider informing each of these groups and formulate answers for addressing their concerns. It is better to write a press release in advance to waste no time during an actual disaster and have it ready for publication.

12. Do the Extensive Tests

Testing your disaster recovery plan is mandatory but usually neglected. Failover tests are usually complex and lead to data loss and disruption of product services. Thus most companies don’t test their disaster recovery plan on a regular basis.

In order to understand how well your disaster recovery plan will work, you must schedule regular failover tests. Ignoring the disaster recovery plan tests can put your entire business at risk during a disaster strike, ending up either unable to recover in time or no recovery at all. Performance tests also help you to assess whether or not your secondary location is sufficient to withstand the business load.

13. Keep your Disaster Recovery Plan Updated

Last but not least, as disaster recovery plan testing is mandatory, so is keeping all the disaster recovery documents updated. At the end of each test, review what happened, how your teams handle the test, and document your findings.

Signing Off:

You can either choose to perform do-it-yourself disaster recovery (a cheap but error-prone option) or have a good disaster recovery plan handy to help your company recover all the lost data and hasten your organization’s return to normal business operations. In addition to that, it will also ensure that disaster will not trigger adverse financial consequences and major business disruptions.

Ensure you take into account every aspect of your organization (e.g., the number of employees, available budget, risk factors, size of IT infrastructure, etc.) to determine what will work best for you and your team.

Get Started with Zmanda Backup; check out Zmanda Recovery Manager- Quick Start-Up Guide