Bobcares

How we setup reliable backups in a server virtualization solution

PDF Header PDF Footer

In the online world, data loss can happen due to many reasons. Human errors, hardware issues or even natural calamities can end up causing a business downtime. Maintaining server backups is a preventive measure to minimize the business downtime due to such mishaps.

When we setup a server virtualization solution for a VPS hosting provider, maintaining reliable backups was an important consideration in our design. In our server virtualization system, individual VPS instances were hosted in LXC containers. Here is a walk-through of how we configured backups for these VPS servers.

Backup solution for LXC server virtualization

In our solution, the backup of each container was taken using a feature called ‘snapshot’. By default, snapshots are stored in the host server itself. But storing the backups locally, made them vulnerable to data loss, in case of a hard disk failure. For redundancy, we copied these backups to an external backup server daily.

Our backup solution included a system for creating container backups, syncing the backups to the backup server and restoring containers from these backups. This helped us to ensure that the services could be restored in no time. We automated the entire process to save time.

1. Creating backups

Backups of containers were created first, using ‘lxc-snapshot’ command. The container backup (aka ‘snapshot’) contained all the information of the container at any moment. Using this snapshot, we could restore the container at a later stage.

root@host:~# lxc-snapshot --name Ubuntu-01
lxc-snapshot: lxccontainer.c: do_lxcapi_snapshot: 3209 Snapshot of directory-backed container requested.
lxc-snapshot: lxccontainer.c: do_lxcapi_snapshot: 3210 Making a copy-clone.  If you do want snapshots,then
lxc-snapshot: lxccontainer.c: do_lxcapi_snapshot: 3211 please create an aufs or overlayfs clone first,snapshot that
lxc-snapshot: lxccontainer.c: do_lxcapi_snapshot: 3212 and keep the original container pristine.

2. Storing the backups

By default, snapshots are stored inside the container’s private folder with generic names such as snap0, snap1 etc. For instance, the first snapshot for the container ‘Ubuntu-01’ was named ‘snap0’ and was stored in ‘/var/lib/lxc/Ubuntu-01/snaps’ folder.

root@host:~# lxc-snapshot --name Ubuntu-01  --list
 snap0 (/var/lib/lxc/Ubuntu-01/snaps) 2016:01:19 10:00:40
root@host:/var/lib/lxc/Ubuntu-01/snaps# ls
 snap0

 

For redundant storage purposes, we setup an external backup server. To automate the backup process, we synced the backups from containers to the backup server. This was done using daily cron jobs.

Since our backup solution stored backups of the entire VPS containers into an external backup server, we wrote a custom script that renamed the backups to include date and time of backup, along with the container name. This enabled us to easily identify the snapshots, with their container name and date, for restoring them later on.

3. Automating the backups

Manually doing backups of the LXC containers was a time-consuming process, which was not feasible in our solution. For efficient and fast backups, we automated the backup process with a custom script. The script would stop each container at off-peak hours, take its snapshot, start the container and verify its running fine.

The script then labelled the backups with appropriate identifiers and copied the snapshot files to our external backup server over the network. The backup script was scheduled considering the factors like importance of data, storage space requirements, frequency of data changes etc. Backups were audited regularly to ensure its adequacy and rotated on a monthly basis to save storage space.

4. Restoring the backups

The main aim of a backup solution is to ensure that the backed up data is identical to the original data. We validated the backups by performing test restores of the container from these snapshots.

root@host:~# lxc-stop -n Ubuntu-01
root@host:~# lxc-snapshot -n Ubuntu-01 -r snap0

The LXC backup design we implemented, helped to provide an affordable and reliable solution for continuous data protection. Backup management involves both backup configuration and restoration solutions. Bobcares helps VPS providers minimize business downtime with our backup management services, which range from formulating the backup and recovery plan to restoring the data within no time.

 

  • No: of servers used in this solution : 2
  • Time taken for design and implementation : 8 hrs
  • System administration plan : Value Administration Plan
  • Hourly administration charges : $27/hr
Are you looking for a similar solution?

WE CAN HELP YOU

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

server management

Spend time on your business, not on your servers.

TALK TO US

Or click here to learn more.

Speed issues driving customers away?
We’ve got your back!

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF