Vinchin Technical Support FAQ Center

Yes, you need to install the file plug-in on your file server first, license it with file module on your backup system, and then you can select the file server as the restore destination for the NAS restore job. Conversely, you can also restore from the file server to the NAS server.

No, there's no need to install any backup plugin for VMware.

Vinchin backup proxy is an optional backup infrastructure component dedicated for VMware virtual platform, it can utilize the HotAdd technology of the ESXi server for efficient VM backup.

If you are backing up your VMware virtual platform through LAN, and your Vinchin backup server is installed on a physical machine, you can choose to install a Vinchin backup proxy VM on the ESXi cluster for implementation of HotAdd backup.

If your Vinchin backup server is installed as a VM on the ESXi cluster, then Vinchin backup proxy installation is not required, because the backup proxy functionality is already built-in on the Vinchin backup server VM.

Usually, a standalone physical machine installed Vinchin backup server with recommended hardware configurations will support you backing up a virtual infrastructure with around 200 VMs or 50TB production data.

If you got a far more larger virtual infrastructure to be backed up, you could choose to deploy Vinchin backup node(s) to expand the Vinchin backup infrastructure for backing up your virtual infrastructure. The Vinchin backup node is also required to be installed on a physical machine. The hardware specification of the backup node can be lower or higher than the backup server, it depends on how much workload you wish to share with.

If your Vinchin backup server is installed as a VM, it's not recommended to install a Vinchin backup node VM to expand the backup infrastructure. You can choose to upgrade the backup server VM configurations, or to install backup node on a physical machine to expand the backup infrastructure.

BitDetector is a Vinchin unique feature which includes a set of sub-features:

*Exclude swap file blocks

*Exclude unpartitioned spaces and partition gaps

*Exclude deleted file blocks

With BitDetector, all the above mentioned data of the Windows VMs will be excluded from backing up. Except data deduplication and compression, it is another important feature which helps reducing the backup data size.

SpeedKit is a unique feature introduced by Vinchin for high-efficiency VM incremental backups. It is an alternative incremental backup technology to those hypervisors do not have CBT implementations yet. Currently SpeedKit can be used for incremental backups of XenServer (old versions without CBT support), Red Hat Virtualization (older than 4.4.7), oVirt (older than 4.4.7), Oracle Linux Virtualization Manager (OLVM), OpenStack and Sangfor HCI.

When SpeedKit is applied to an incremental backup job, there will be a snapshot kept in the production storage for each of the VMs included in the backup job. This is for rapid calculation of the data changes of the VMs. If you have adequate production storage, SpeedKit is recommended to be used for incremental backups.

CBT (Changed Block Tracking) is an incremental backup technology built-in in the virtual platforms for quicker VM backup process and smaller size of backup data. As a result, it can reduce the amount of time incremental backups take, and also reduces the storage space by saving the new and changed data only.

Vinchin Backup & Recovery v7.0 has now implemented CBT support for VMware vSphere, Citrix XenServer (7.3 and newer), Citrix Hypervisor, XCP-ng, Huawei FusionCompute KVM(6.5 or newer), RHV (4.4.7 or newer) and oVirt (4.4.7 or newer).

Retention policy is a set of rules for retaining backup, copy and archive data to meet the legal and business needs of the organizations. The restore points which exceeded the limit of retention policy, deletion or merging of restore points will be performed to comply with the user defined retention policy.

Full backup job

Each restore point is independent, so deletion of restore points will be performed when the retention policy has been triggered. 

Differential backup job

Each differential restore point depends on the previous full restore point. When retention policy has been triggered, Vinchin Backup & Recovery will start deleting the earliest differential restore points, when all the differential restore points between the first and the second full restore points had been deleted, and when retention policy has been triggered for the next time, the first full restore point will be deleted.

Incremental backup job

When the retention policy of an incremental backup job has been triggered, Vinchin Backup & Recovery will try to merge the first incremental restore point with the full restore point on the first backup chain, the full restore point will step forward and the first incremental restore point will be gone. It will run the same process until all incremental restore points had been merged with the first full restore point. After that when the retention policy had been triggered for the next time, the first full restore point will be deleted, and then the second backup chain becomes the first and the restore point merging process goes on the same way.

Forever incremental backup job

Different from incremental backup, forever incremental backup will only create one backup chain for each VM included in the job, when retention policy has been triggered, Vinchin Backup & Recovery will merge the first incremental reatore point with the only full restore point at the beginning of the backup chain, and the timestamp of the full restore point will keep stepping forward each time when the incremental restore point had been merged.

In addition, If you implemented GFS retention policy  which is a long-term data retention policy, Vinchin backup & recovery will follow GFS retention policy first. Refers to What is GFS rentention policy for more information. 

Backup copy is used to make duplicate version of your backup data to secondary storage or location, the copied data is usually of the same version, size and type of your original backup data. 

While backup archive feature is used to archive your backup data to a more cost-effective storage for long-term preservation. The archived backups are always full backup files (full restore points), no matter it is created from full, incremental or differential restore points.

Backup archive feature can be used to move your backup data from the backup storage to a more cost-effective storage for long term preservation. 

Your data which is no longer been used or is inactive but still has business values can be archived, this can make sure the data is still accessible when needed.

Vinchin Backup & Recovery supports archiving your backup data to onsite storages and cloud object storages. While cloud object storage is used for archiving, it is also an option of cloud DR (Disaster Recovery).

Although backup archive and backup copy can be used for disaster recovery, but they work in different ways. Backup copy will make an exactly the same copy of your backup data to another storage, while  a full restore point will be saved in the archive storage after each backup archive job session.

When the archive job session runs upon a full backup, all data blocks of the full backup will be directly transferred to the archive storage. When it runs upon an incremental/differential backup, required data blocks from all dependent restore points will be transferred to the archive storage and saved as a new full restore point.

So backup archive job should not be scheduled too frequently, otherwise there will be too much duplicated data written into the archive storage.

Backup copy is a feature which can be used to make duplicate versions of your backup data to secondary storage or location. The copied data is usually of the same version, size and type of your original backup data, and can be used to restore the backup data from any accidental deletion and corruption.

With Vinchin Backup & Recovery, you can copy your backup data to an onsite copy storage or to an offsite copy storage (offsite copy storage is a Vinchin Backup Server installed on remote site). 

The onsite backup copy data can be used to restore VMs directly if you have lost both the production data and backup data. 

If you had configured offsite backup copy, even if you have lost all data on primary site, the VMs can be restored on remote site to bring back the production VMs on the remote site virtual platform. 

Or after the primary site had been rebuilt, the offsite copy data can be restored back to the primary site Vinchin Backup Server for restoring production VMs and data on primary site.

As a conslusion, you can achieve offsite DR (Disaster Recovery) by using offsite copy feature of Vinchin Backup & Recovery.

A restore point is a backup file generated on a specific date and time the VM is backed up, it can be used to restore the VM to an earlier state of when the backup is taken. 

For Vinchin Backup & Recovery, a restore point can be a full, incremental or differential backup file. No matter which kind of backup it is, a restore point can be always used to restore a VM to an earlier working state.

On Vinchin Backup & Recovery, backup chains are usually created by incremental or forever incremental backup jobs. Each backup chain begins with a full restore point and ends with a series of incremental restore points. For VM recovery, all the incremental restore points on the backup chain are dependent on the full restore point, and each incremental restore point is dependent on the other incremental restore point(s) in front of it on the chain.

For the incremental backup, each VM included in the job will usually have several backup chains created in the backup storage. While for the forever incremental backup, each VM included in the job will have only one backup chain created in the backup storage.

Differential backup is the backup method which backs up the new and changed data since the previous full backup.

Forever Incremental backup will start with an initial full backup and then runs incremental backups without any further full backups. In other words, it always backs up the new and changed data blocks comparing to the previous backup.

When implementing retention policy, the outdated incremental backup point will always be merged with the initial full backup to keep up with retention policy.

Incremental backup is a backup method which backs up the new and changed data since the previous backup (full or incremental). Usually, it requires a full backup to be taken in longer time intervals, and then run the incremental backups in shorter time intervals.

Full backup is the most complete type of backup, it will create a full copy of the data assets to the backup repository. It is considered the simplest way for backup and recovery, but at the same time it is the most storage space occupation and time-consuming backup method. As a result, it is either scheduled with longer backup intervals or shorter retention time.

All other backup methods will all start with a full backup.

Vinchin Backup & Recovery supports Full, Incremental, Forever Incremental, and Differential backup methods.

Backup copy is a feature which can be used to make duplicate versions of your backup data to secondary storages or locations. The copied data is usually of the same version, size and type of your original backup data, and can be used to restore the backup data from any accidental deletion and corruption.

With Vinchin Backup & Recovery, you can copy your backup data to an onsite copy storage or to an offsite copy storage (offsite copy storage is a Vinchin Backup Server installed on remote site).

The onsite backup copy data can be used to restore VMs directly if you have lost both the production data and backup data. Even if you have lost all data on primary site, the VMs can be restored on remote site to bring back the production VMs on the remote site virtual platform. Or after the primary site has been rebuilt, the offsite copy data can be restored back to the primary site Vinchin Backup Server for restoring production VMs and data on primary site.