OvalEdge Database Backup

A database backup is a process of taking a copy of your database and storing in a different location from the original. Database backup is essential for data recovery, business continuity, legal compliance, and disaster recovery.

This document explains the Ovaledge approach for Business Continuity, types of backup, backup frequency and time along with the recovery test.

OvalEdge Approach for Business Continuity

OvalEdge Strongly believes the Success of the client's business is core to the success of the platform that in turn the clients (Business).

As part of the Seamless continuation, the backup Strategy plays a vital role.

With the backup being mentioned/referred, what needs to be backed up, Frequency, and Rule set to follow are listed down.

Data backup and recovery processes are vital for business continuity. Every business and individual needs a plan and procedure to back up, protect, and restore their data.

What files to include in backups?

For any business to be successful data plays a vital role, Backing up of the database snapshots along with the deployed war are marked as critical. 

Next comes the Server configuration files along with the drivers and the binary of the Server version that has been installed needs to be saved to a location. (This is not part of the Backup but to revert back in case of the server is down because of a corrupted OS, etc. which impacts the application, for Faster Restoration needs to have the same version of the Server Artifacts, Server binary, server-related Config files and the Drivers (Critical to maintain with the version of the war that is installed)). The OS can always be installed. 

The above factor can be correlated to the MTTR (Mean Time of Recovery) which is very critical to the Business.

Types of backup

There are three ways to take database backup.

1. Full Backup
2. Incremental Backup
3. Differential Backup

Full Backup

The full backup involves copying the entire Database for backup. A full backup is also the safest, easiest, and most reliable way to restore, Full backups use more resources, however, and tend to take longer to complete. Because of this, they are not well suited for regular backups such as hourly or daily backups.

Incremental Backup

An Incremental backup copies the Delta of the DB that has been created or modified since the last Full or Incremental backup. Restoring an Incremental backup is difficult and time-consuming because each incremental backup must be merged with a full restore, and they must be restored in the right order.

Differential Backup

A Differential backup works similarly to an Incremental backup, but it copies new or changed DB base entries since the last Full backup. Restoring from a Differential backup is simpler when compared with the incremental backup as it only requires restoring from the last Full backup followed by a restore from a Differential backup.

Note: OE Suggests Full back up’s when compared with the Incremental and Differential as the restore time would be less. Taking Full backup can be a  Space consuming but when compared with the cost of the business impact because of the non-availability of the platform is more.

Versioning

With the versioning, a copy of the existing backup file is created and stored in the backup. In addition, it will keep the previous versions of the backups, so if the DB or the Server gets tampered, corrupted, or deleted, one can easily view and restore from a previous version.

While Versioning can be extremely useful, it, of course, uses more storage space to save the versions (This in turn can be restricted to the number of versions to be maintained).

Backup Integrity

A corrupted backup is not useful and it is similar to having no backup at all. Even if a valid backup is made, over time it can become corrupted due to other external factors, e.g. drive failure, viruses, hacking, etc.

A backup should be configured to keep integrity data on the state of the backups. This integrity data can later be used to verify the accuracy of the backups. 

In addition to regular backups, need to regularly check the integrity of backups to ensure having reliable and consistent backups for recovery. 

Note: The version rule that comes next defines the number of versions that need to be maintained but the Integrity check ensures the reliability of the backup.

Backup Frequency and Time

OvalEdge recommends running backups frequently to always ensure that your backup data is complete and accurate. The frequency of backups depends on the rate of changes and the criticality of data. 

Critical data that is changed continuously needs to be backed up more frequently, e.g. every X minutes or hours or days (e.g. 15 minutes or 1 hour or for every 3 days).

The data is marked critical not only with the frequency of the change but the kind of business (Financial Data, Healthcare, e-commerce, etc.)that are marked as critical needs to be ensured that data is critical with less frequent triggered backups.

Note: It is recommended to schedule the backup during off-peak hours.

The 3-2-1 backup principle

Storing backups in a single location is not enough to protect data and recover from data loss.

A well-known rule of thumb is that a comprehensive backup plan should use the 3-2-1 backup rule:

• Have 3 copies of data
• Save 2 backup copies at 2 different locations
• Keep 1 backup offsite

Note: 3-2-1 further explained to have 3 Copies of Your Data

With three backup copies, you greatly improve the chance of recovery and protect your data against different types of technology failures or environmental hazards.

You can accomplish this by creating 3 different profiles with the Source pointing to the location where your primary data is stored, and the Destination pointing to 3 different backup locations (such as an internal drive, NAS drive, external hard drive, Cloud, FTP, etc.). 

Next, put the profiles into a group and run the group to make three backup copies of your primary data. This can be fully automated by scheduling the group to run periodically, e.g. every day at 7 pm.

Save 2 Backup Copies at 2 Different Locations

If you save the primary data and its backup copies in the same location (for example: on different drives on the same computer), and if your computer crashes or is attacked with a virus, then you will lose your primary data as well as your backup copies at the same time. 

Therefore, it is recommended to save two of your backup copies at two different places, to reduce the risk of a single event destroying multiple copies.

Keep 1 Backup Offsite

If you keep all your backup copies in the same building or room, and if there is a fire, accident, or theft, then you will lose all your data. Hence, physical separation between copies is important and it is always recommended to store one backup offsite (for Example: cloud or FTP - that is away from the location where your primary backups are stored).

For the Business that operates on the internal network and not open to the internet, taking of the backup, and versioning along with where(the distance of the stored location) of the Backs up’s plays a vital role in retrieving time, this may at times proves to be costly.

Recovery Test

To check the validity and integrity of backups, you should regularly perform restoration tests to ensure the backup is working correctly and the backed-up data is complete and accurate. 

By performing a test restore you can identify any possible problems that may occur before you have to do a real restore.

Stick to the above OvalEdge Standard Business Continuity Guidelines without impact to the business or data loss.

Additional Information

Q1. How the OvalEdge Platform is restored back? In case of a corrupted VM or any other reason that would impact the OE deployed VM?

Ans: The Best practice Is to have the backup VM where the same version is deployed and will not be active(Not serving the traffic) the approach of warm-up Mode, in case the Primary (Active VM is corrupted and cannot be restored) the traffic can be routed to the Warm-up instance.

In case there is no warm-up instance being set up, the VM with a similar configuration has to be made ready in passive mode for hosting the OE, Elastic, and VM for Data Snapshot back recovery.

In any of the cases having the passive VM’s as Back up, the critical factor that impacts the RPO (Recovery Point Objective) and RTO (Recovery Time Objective)

The RPO factor will have an impact on data loss (which is bearable for an Organization)

Once the Active site is back the Data Snapshot (Delta) from the point of failure has to be restored back to the Active Site.

Copyright © 2023, OvalEdge LLC, Peachtree Corners GA USA