SyFS (Syneto File System) is virtual machine aware thanks to the proprietary metadata layer that was built into it.

SynetoOS is strongly integrated with VMware ESXi hypervisor, when you perform a snapshot many operations are taken to ensure virtual machine consistency, in simple words, snapshots are files level versioning, or the way to revert a change in the whole system, then all your files or folders can be reverted back to the state they were at the time the snapshot was created, but they are not backups and can have many versions without using much space, only needs to save enough information to undo a change.

So, if you get a virus, a ransomware or apply wrong configuration you can just revert all your files, folders, or whole System volume and all VMDK attached to the VM (for single datastore) to the state it was before the change was made.

With a snapshot, you capture the state of the virtual machine settings, virtual disks and memory. These states are saved to files located in the virtual machine's owner datastore (.vmdk, -delta.vmdk, .vmsd, .vmsn) for more information please refer to bottom links.

From datastore protection schedule can choose mainly three types of snapshots :

• Crash consistent - it just makes a SyFS snapshot of the datastore, like in crashed state (IS LIKE PLUGGING OUT THE POWER CABLE), it records only data already written to the virtual disks, without saving data in RAM or pending I/O.

• Application consistent - uses several technologies to ensure data consistency, IT requireS installation of VMware tools on guest VM to use VSS and Application Hooks to flush writes to the disks.

• Live snapshot - preserves exact VM disk state + RAM, the virtual machine is suspended, RAM is dumped to the disk, then SyFS snapshot is taken.
  

By default, the protection level of a virtual machine is set to crash-consistent. To change it, click to the right of the virtual machine name, in the Protection level column. A dropdown will open where you can select the protection level you want.

Crash Consistent 

Just taking a simple snapshot of the virtual machine's disks without saving any data processed in RAM or in queue to be written on disks (pending I/O). Does not guarantee file system or application consistency. When the virtual machine is recovered or cloned, it will be powered off, and behave like it's power was lost.

This type of snapshot is very fast and doesn't disturb the virtual machine while the snapshot is taken. It does not require VMware tools to be installed and can be taken on all kind of OSs. There is no need to pause a workload and is preferred for workloads that don't accept pauses or file system freezes.

Crash consistent snapshots are good only for crash resilient operating systems and applications: file servers, DHCP servers, and print servers.

RECOMMENDED for virtual machines resilient to forced reboots. (ie. Linux or Solaris servers or workstations)
NOT RECOMMENDED for a database, or Active Directory services because it can lead to data corruption.

Application Consistent 

This snapshot method is a trade off between performance and data protection, when such snapshot is taken, SynetoOS instruct the applications running on the VM to flush their data to the disk. 

This is done by VSS in Windows or Application Hooks in UNIX world. 

Methods:

• Windows VSS only usable on Windows guest VM preferred with native VSS service instead of VMware tools VSS service.

• Windows VSS and hooks only usable on Windows guest VM in additional with hooks scripts.

• Hooks only usable on Windows guest VM and UNIX VM creating customised  backup scripts.

Windows VSS is system wide enabled on Microsoft guest virtual machines, and all applications that are VSS aware will respect the call and flush their data, the snapshot will be taken after the flush operation finishes. 

Drive consistency for the application supporting the protocol will be consistent. When restoring, the virtual machine will be in a state similar with a power off, sometimes there are some conflicts between VMware tools VSS service and native Windows VSS service, the links on bottom will help you to solve it.

Application hooks are customised scripts that run before and after the snapshotting process, they target specific applications, and instruct them to flush their data to the disk (usable on Windows and Linux VMs).

For the period of disk flushing (also known as quiesce), all applications will freeze, depending on the amount of data that needs to be written, this can be a couple of a seconds, or several minutes.

Once the data is consistent on the disk, a VMware snapshot will be taken then SynetoOS will perform a SyFS snapshot that will include the VMware snapshot as well and delete it from hypervisor, meaning that VM is consolidated in SyFS. 

RECOMMENDED for Linux Databases and Windows databases that do not have VSS integration.

End users must decide to use one or the other method to backup their virtual machines. We recommend using Syneto's SyFS snapshots because they are closely integrated with the HYPERSeries products and they offer the best speed, used disk space, and safety balance.

Hooks must be put on virtual machines that will be backed up, you have to add the path of the pre-freeze script and post-thaw script, and also provide the credentials which can connect and execute the scripts. To see how to add credentials, check configuring virtual machine credentials. 

They must be executable, when configuring Hooks only on HYPER, there will be two options to specify the path and name of these executable scripts:

1. Before snapshot hook

2. After snapshot hook

LINUX FILESYSTEM FREEZE HOOK EXAMPLE
Before snapshot:

  #!/bin/bash
  fsfreeze --freeze /mnt/important/application

After snapshot:

  #!/bin/bash
  fsfreeze --unfreeze /mnt/important/application

If you want to test the hooks configuration, click on Test button. This will only execute the scripts, not take a snapshot.

If the scripts are executed successfully, a green check will appear.

If one of the hooks fail, an error message will be displayed with the failure reason.

NOTE: If the hooks fail during a snapshot schedule run, the virtual machine snapshot will be crash consistent.

NOTE: Hooks must execute in less than 30 seconds. If they take longer than that, SynetoOS will kill the process.

Offer the highest virtual machine consistency and the fastest recovery time, but when performed it is slow and use higher space than other snapshotting methods.

When a Live Snapshot is taken, SynetoOS instructs ESXi hypervisor to take a snapshot that includes the state of the virtual machine's memory (RAM) and I/O queue in pending, this process is similar to how "hibernate" works on Windows, MacOS, or Linux desktop systems, all information from RAM is written to the disk before the VMware snapshot is taken.

During the snapshotting process the virtual machine will be temporarily frozen. While the RAM data is written to the snapshot files the virtual machine is not accessible. It will look as suspended for that time. This method does not require VMware tools to be installed and can be taken on any type of operating system.

NOT RECOMMENDED to do Live Snapshots of virtual machine with high RAM. It will lead to slow snapshotting process and lot of disk space used by snapshots (because saved RAM is different in every snapshot) and slow restore.

RECOMMENDED for highly sensitive virtual machines using only a small amount of RAM, and which need to be restored very fast. After a restore process, the virtual machine will be powered on and exactly in the state it was in when the snapshot was taken.

End users should consider the possible side effects when using other 3rd party backup software for virtual machines, In many cases these are also taking VMware snapshots, SynetoOS won't take or delete VMware snapshots if users or other applications already created snapshots of the VM directly in hypervisor environment, forgotten VMware snapshots will lead ever increasing VM disk usage, operational slowdowns and conflicts with Syneto File Recovery procedures.