How to Build a Backup and Recovery Plan for PHP Web Apps

Disasters happen fast. In the event your PHP-based infrastructure is impacted by failed hardware, user error, malicious attack, or other disaster, you will need to act quickly to recover any lost data and keep your mission-critical web applications running. However, efficient web application disaster recovery starts long before an actual disaster occurs.

In this blog, we walk through the basics of building a backup and recovery plan for PHP applications. We then discuss the six main steps for creating a web application disaster recovery protocol. Finally, we explore ZendHQ's new disaster recovery features, explaining how this new functionality can aid in recovering ZendHQ data as a part of your backup and recovery plan.

Web Application Disaster Recovery: Overview

Before building a backup and recovery plan for your PHP web application, it is critical to understand what backup and recovery means – both generally and in regard to your specific setup. No two organizations are exactly alike, and successful recovery will be dependent on you creating a solution that fits your team, workflow, and business demands.

Disaster Recovery vs. Backup

While disaster recovery and backup can be thought of as separate things, they are more often two sides of the same coin.

Backups are not only integral to recovering from a disaster, but the concept of disaster itself is one of the many situations where you implement your backups. Whether you need to revert to a backup due to a malicious attack, data corruption, or a significant bug that was pushed live – the solution for all of these is to roll back to a backup.

Dealing with a disaster where you have loss of facilities or control of your app is no different. You activate your plans to implement your most recent backup to recover lost data.

What Is a Backup and Disaster Recovery Strategy?

A backup and disaster recovery strategy is a plan put in place before disaster occurs, including knowing who is required to do what, where your backup data is kept, and what sort of environments need to be restored.

Simply having backups of all your code and data is not enough when you find yourself needing to recover from a problem. In addition to the above information, you should decide how, when, and what to backup before a disaster occurs.

Your backup and web application disaster recovery strategies should involve documents that explain where your backups are, what is needed to restore them, who is involved, and what steps are necessary. Determining this ahead of time can prevent a lot of grief and delay when the inevitable time comes to use your backups.

Considerations for Creating a Backup and Recovery Plan

When you are designing your web application disaster recovery plan, there are a few categories of issues to consider:

• What is it you are backing up?
• What PHP or other apps are there, and what environment do they run on?
• How is your application data structured?
• What system (mySQL, MongoDB, NoSQL, etc.) do you use to store your data?
• Who is responsible for which steps in the case of a disaster, and have they been informed and educated about their role?
• Have you developed a plan for how everyone involved in a full recovery should work together to restore the system?
• Does any of your software require licenses to reinstall, and are those licenses easily accessible?

While one might assume that a small group or individual who is knowledgeable can handle a disaster, unexpected issues can cause major delays.

The demo sheet below shows an example of some of the basic information you might want to gather when designing your web application disaster recovery strategy.

How to Establish a Backup and Recovery Plan for Critical PHP Apps

The best way to successfully recover critical web applications and data is to create a comprehensive plan before disaster occurs. These six steps are designed to help you and your team get started, but always remember to include details and information specific to your PHP infrastructure.

Additionally, at all steps of your plan, make sure to create and maintain thorough and in-depth documentation. After all, strong documentation is critical to successful web application recovery, and it guards against knowledge loss should employee turnover occur. While it is often impossible to document all aspects of every detail, take the time to be as exhaustive as possible to avoid unanswered questions during a crisis.

Step One: Service Discovery

What is it you are backing up? This can involve not just your web app, but details about it. What sort of environment does it run on? Beyond your PHP application itself, are there other libraries, extensions, and additional components in the environment that need to be considered? 

When it comes time to recreate your environment, all these details need to be known ahead of time. Ensuring these are all in your git repos and organized can save a lot of trouble.

Step Two: Know Where Your Data Is Stored

Just as vital to maintaining your repos are maintaining and understanding your database backups. You need to identify what type you use, such as Oracle, MySQL, MongoDB, or another option. Beyond this, how are your current backups being managed?

Knowledge of your backup schedule, such as how often backups are created, could aid in determining which to select when recovery is needed.

Step Three: Selecting Stakeholders

An integral part of making and managing your backups is to determine who is responsible for them. When you need to deploy to a new environment, who needs to speak to whom in order to make recovery happen?

Communication and prior planning will save a lot of time when a disaster occurs.

Step Four: Understanding Your Hosting and Environment

The next step is to identify your hosting setup. Do you run the machines yourself, rent space from another party, or something else? Who is in charge of setting your machines up, building host files, and pushing releases?

If new VMs must be put together, is there a well documented build process? While many places use an automated build process, not everyone does. Documentation can be critical as the people who know everything today might move on. When a problem occurs at some future date, it is important that the information is always available, so that anyone can react to the situation.

Step Five: Reinstalling PHP

When it comes time to actually reinstall your environment, it is important to know the specifics. Does your environment use multiple versions of PHP?

For example, if you were using ZendPHP instead of the community edition, do you have access to the credentials or installers to setup your PHP environment again? Is there documentation detailing where the repos and their keys are?

Step Six: PHP Testing

While PHP testing is the final item on this list, it can be said that it is the most important. Testing will verify your documentation – proving that it is correct, updated, and everyone understands it. It is unavoidable that changes to systems will be made over time, and it's possible those changes were missed in the documentation. For example, perhaps a library ceased publishing updates and needs to be replaced, but no note has been made.

Performing a dry run in a test environment will enable discovery of places where the documentation, and backup and recovery plan, is out of date. It will also ensure that everyone is prepared should a disaster occur.

Quickly Recover ZendHQ Data With Built-In Disaster Recovery Features

For those who deploy ZendPHP runtimes paired with the advanced ZendHQ extension, creating a backup and recovery plan has never been easier. As a part of a recent database expansion, ZendHQ now includes built-in features that make it simple to regain or migrate ZendHQ data in the event of a corrupted database, crash, or other disaster. 

Where prior versions of ZendHQ used SQLite, which was often difficult to backup as a part of a disaster recovery strategy, our new disaster recovery features allow your team to also use MariaDB and Postgres as their persistence store for ZendHQ. As you can now implement a relational database management system (RDBMS) for ZendHQ, your team can take full advantage of everything we've discussed in this blog. Simply establish a primary server with one or more replicas, and in the event the primary fails, promote a replica to regain lost ZendHQ data.

Step One: Install ZendHQ Server Daemon

Ensure you have your repo credentials for access to the ZendHQ repo. Install your current version of the ZendHQ server daemon from the Zend repos. In-depth ZendHQ installation information can be found in our documentation.

It can be useful to use the zendphpctl to manage the installation of repos and credential management of your data recovery process. Visit this documentation for details about managing installations with the zendphpctl tool.

Step Two: Configure ZendHQ With Your Database

By default, the ZendHQ server daemon stores data in a SQLite database, though MariaDB and Postgres are also options. By using MariaDB or Postgres, you can now include ZendHQ in your disaster recovery planning, implementing the same processes as you use to backup other applications with the same databases.

Restoration will need to include both the ZendHQ server database and its configuration file, which defaults to:

/opt/zend/zendphp/etc/zendhqd.ini

Step Three: Reinstall ZendHQ

The ZendHQ client UI can be reinstalled by downloading your version from the Zend repo. Once running, the ZendHQ UI can be used to restore your monitoring details. After restoring the previously backed up ZendHQ database, it is enough to restore the INI file to restore service. This is achievable as all relevant configurations will be stored in the database recovered during your disaster recovery effort.

More information can be found in our ZendHQ Monitoring Rules documentation.

Final Thoughts

Creating and maintaining a backup and recovery plan for your PHP web applications is the best way to keep your data protected against unexpected loss during a disaster. Be sure to keep all aspects well-documented, and regularly revisit your strategy to make sure it is relevant to your current business workflow.

Additionally, following best practices for PHP security can go a long way in preventing disasters from occurring in the first place. Always use supported and updated PHP versions, ensure your infrastructure is well-maintained and monitored, and take the time to properly train and educate all employees to follow correct security procedures.

As you build your backup and recovery plan and work to find security gaps, you may discover that your team doesn't have the resources, time, or skill set to address all aspects of your plan. That's where Zend comes in.

Make Our PHP Experts Your PHP Experts

Zend Professional Services are designed to support your mission-critical PHP applications. From providing custom consultations to conducting performance audits, we'll help you meet your goals and save time with our proven services.

Explore Professional Services

Additional Resources

• 101 Guide - PHP Security
• Free Trial - Try ZendPHP + ZendHQ Free for 30 Days
• On-Demand Webinar - Optimizing PHP Apps: Strategies to Gain a Competitive Edge
• Blog - Configuring ZendHQ and MariaDB for IBM i Disaster Recovery
• Blog - PHP Debugging With ZendHQ
• Blog - Getting Started With Web Application Monitoring
• Blog - PHP Upgrades: How to Plan and Execute Your Next Upgrade
• Blog - Why Good PHP Monitoring Matters