A Snapshot vs a Backup

A Snapshot vs a Backup

Many have not understood what is a snapshot? What are the differences? Which is better? Today, we are here to explain to you the differences, the pros and cons of the backups and the snapshots.

Snapshot is only available to a VM. Whether they are called VPS or something else. If the instance is virtualized, a snapshot is possible. Backup is installing an agent into the guest OS or the dedicated server, transfer the partition or files into a backup storage device.

Snapshot takes an image of the instance of its current state and dumped into a compressed file format like LZO. It is only possible to restore the entire VM. to restore files, you will have to extract files after you have restored the VM to another instance which is very time-consuming.

However, you can restore files from a backup. Even a bootable partition for some backup solutions. To restore a partition, you must have a temp portable partition on the memory to restore the restored bootable partition backup. This is a very slow process especially the restoration involved a huge partition.

Files restoration is the fastest and if you need to roll back the entire server, a snapshot restoration is much faster than restoring a bootable partition. However, if your backup retention is longer, you will need lesser space on your backup devices.

Most snapshot use NFS. It is cheaper to build an NFS storage than a proprietary backup solution. Nowadays, VM snapshot uses LVM-Thin to conserve disk space, it helps reduce disk space usage significantly. There is a drawback using LVM-Thin, the server must have a faster write and read space especially restoration, otherwise, it will affect the speed on other guest machines on the same server.

VPS ran out of space, are you informed?

Many users are tied up in their day-to-day routines. It is difficult for them to find time to check disk usage on their VPS on a daily basis, until one day they come to realize server has stopped working, website is down and emails are not sending.

Putting the customer at the heart of our business at Vastspace is our objective. To help customers to save time and ensuring good up-time of their VPS, our monitoring system collects daily disk usage statistic from each VPS. Engineers will identify the VPS have consumed 90% of the total disk storage and inform the customers in a timely manner.

How to schedule a backup Job on Cloud Server

Each Cloud Server comes with 2 free backup instances at no cost regardless of backup size. Additional backup instances can be ordered at only $10 /monthly. This is a useful feature to customers make changes to their files often and requires a rollback in case of any mishaps.

To perform a manual backup and scheduled backups are very easy tasks with our control panel, just a few clicks away and the hassle-free backup feature will send you an email notification if whether the backup is successful or unsuccessful that requires attention and rectification.

 

 

 

 

 

 

Backup for SSD Cloud Server

Many Cloud Server subscribers have missed out the important feature “Backup” which is FREE add-on of the latest SSD Cloud Server. Have you forgotten to schedule a backup? Sign in to https://my.vastspace.net now and follow the steps show in these video tutorials.

VPS with Ploop

To understand the benefits of having PLOOP On OpenVZ container (Linux VPS), we need to knows what are the limitations of the traditional file system on VPS.

  • Since containers are living on one same file system, they all share common properties of that file system (it’s type, block size, and other options). That means we can not configure the above properties on a per-container basis.
  • One such property that deserves a special item in this list is file system journal. While journal is a good thing to have, because it helps to maintain file system integrity and improve reboot times (by eliminating fsck in many cases), it is also a bottleneck for containers. If one container will fill up in-memory journal (with lots of small operations leading to file metadata updates, e.g. file truncates), all the other containers I/O will block waiting for the journal to be written to disk. In some extreme cases we saw up to 15 seconds of such blockage.
  • Since many containers share the same file system with limited space, in order to limit containers disk space we had to develop per-directory disk quotas (i.e. vzquota).
  • Since many containers share the same file system, and the number of inodes on a file system is limited [for most file systems], vzquota should also be able to limit inodes on a per container (per directory) basis.
  • In order for in-container (aka second-level) disk quota (i.e. standard per-user and per-group UNIX dist quota) to work, we had to provide a dummy file system called simfs. Its sole purpose is to have a superblock which is needed for disk quota to work.
  • When doing a live migration without some sort of shared storage (like NAS or SAN), we sync the files to a destination system using rsync, which does the exact copy of all files, except that their i-node numbers on disk will change. If there are some apps that rely on files’ i-node numbers being constant (which is normally the case), those apps are not surviving the migration
  • Finally, a container backup or snapshot is harder to do because there is a lot of small files that need to be copied.

 

In order to address the above problems OpenVVZ decided to implement a container-in-a-file technology, not different from what various VM products are using, but working as effectively as all the other container bits and pieces in OpenVZ.

The main idea of ploop is to have an image file, use it as a block device, and create and use a file system on that device. Some readers will recognize that this is exactly what Linux loop device does! Right, the only thing is loop device is very inefficient (say, using it leads to double caching of data in memory) and its functionality is very limited.

Benefits

  • File system journal is not bottleneck any more
  • Large-size image files I/O instead of lots of small-size files I/O on management operations
  • Disk space quota can be implemented based on virtual device sizes; no need for per-directory quotas
  • Number of inodes doesn’t have to be limited because this is not a shared resource anymore (each CT has its own file system)
  • Live backup is easy and consistent
  • Live migration is reliable and efficient
  • Different containers may use file systems of different types and properties

In addition:

  • Efficient container creation
  • [Potential] support for QCOW2 and other image formats
  • Support for different storage types

 

This article is extracted and found at : https://openvz.org/Ploop/Why