This is an archive version of the document. To get the most up-to-date information, see the current version.

How File Share Backup Works

Veeam Backup & Replication performs file share backup to the backup storage in the following way:

  1. When a new backup job session starts, Veeam Backup & Replication assigns a file proxy to process the file share data.
  2. The file proxy enumerates files and folders on the file share and creates a cyclic redundancy check (CRC) tree.
  3. The file proxy transfers the CRC tree to the cache repository.
  4. The cache repository saves the CRC tree.

When the cache repository receives a new CRC tree structure from the proxy, it compares it with the CRC tree created during the previous run of the backup session. If any files or folders of the file share have changed since the previous backup session run, the cache repository instructs the file proxy to start reading changed data from the source file share.

  1. The file proxy reads new data from the file share.
  2. The file proxy creates data packages and transfers them to the target backup repository.

Data packages comprise backup data files (each 64 Mb in size) and metadata files that contain names and versions of backup files and allocation of data in backup files.

  1. Veeam Backup & Replication checks file versions in the backup repository against retention settings and moves backup data from the backup repository to the archive repository if necessary.

How File Share Backup Works 

Retention Scenarios

There can be a number of backup retention scenarios depending on the configuration of backup and archive repositories. Below you can find example cases that illustrate NAS backup retention with different settings.

Case 1

Only 1 file version is created. The file does not change.

File version 1 remains in the backup repository and is not moved to the archive repository even if it is enabled and configured.

How File Share Backup Works 

Case 2

Retention for the backup repository is set to 5 days. No archive repository is configured. The file changes once a day. The backup is performed once a day.

On day 6, file version 6 is added to the backup repository, file version 1 is deleted by retention.

How File Share Backup Works 

 

Case 3

Retention for the backup repository is set to 3 days. The file changes every hour. The backup is performed 2 times a day.

On day 4, versions 7 and 8 are added to the backup repository, file versions 1 and 2 added to the backup repository on day 1 are deleted by retention.

How File Share Backup Works 

Case 4

Retention for the backup repository is set to 3 days. The file changes once a day.

On day 3, the source file is deleted from the source share, the backup repository considers file version created on this day as deleted.

How File Share Backup Works 

On day 4, the backup repository still detects the file as deleted, file version 1 is deleted from the backup repository by retention.

How File Share Backup Works 

On day 5, the backup repository still detects the file as deleted, file version 2 is deleted from the backup repository by retention.

How File Share Backup Works 

Thus, no file versions are stored in the backup repository for this file any longer.

Case 5

Retention for the backup repository is set to 5 days. The archive repository is enabled with default settings. The file changes every day. The backup is performed once a day.

On day 6, file version 6 is added to the backup repository, file version 1 is moved to the archive repository by retention.

How File Share Backup Works 

Case 6

Retention for the backup repository is set to 3 days. The archive repository is enabled with DOCX files to be excluded from archiving. The files change once a day. The backup is performed once a day.

On day 4, file versions created on day 1 are removed from the backup repository. File version 1 for DOCX file is deleted, file version 1 for XLSX file (non-DOCX) is moved to the archive repository.

How File Share Backup Works 

Case 7

Retention for the backup repository is set to 4 days. The archive repository is enabled and configured to keep 3 versions of active files and 2 versions of deleted files.

On day 8, file version 8 is added to the backup repository, file version 4 is moved from the backup repository to the archive repository to keep file versions for 4 days, file version 1 is deleted from the archive repository to keep 3 file versions of the active file (versions 2, 3, 4).

How File Share Backup Works 

On day 9, the file is removed from the source, file version 9 (denoting the missing file) is added to the backup repository, file version 5 is moved from the backup repository to the archive repository, file versions 2 and 3 are deleted from the archive repository to keep 2 file versions of the deleted file (versions 4 and 5).

How File Share Backup Works 

On day 10 and 11, file versions 6 and 7 are successively moved from the backup repository to the archive repository. File versions 4 and 5 are deleted from the archive repository.

On day 12, file version 8 (the last file version) is moved from the backup repository to the archive repository, file version 6 is deleted from the archive repository. After that, versions 7 and 8 are stored in the archive repository further on.

How File Share Backup Works