Skip to main content
File server backup workflow
Updated over a week ago

Enterprise Workloads Editions: βœ… Business | βœ… Enterprise | βœ… Elite


πŸ“ Note


​ If you restart or reboot your servers during backups, the backup operation is aborted. Enterprise Workloads agent starts a fresh backup following the backup schedule. Alternatively, you can start a manual backup at any time.


File servers with Windows operating system

This topic explains how data flow during data backup from the File servers with Windows operating system.

Backup workflow

Step

Operation

Step 1

A backup request is initiated and forwarded to the Enterprise Workloads agent.

Druva checks if Enterprise Workloads agent is running.

  • If the agent is running, Druva performs the backup operation.

  • If the agent is not running, Druva performs the backup operation based on the type of backup job.

    • For a backup now job, Druva fails the backup request.

    • For a scheduled job, Druva waits until the expiry window of the backup request, else fails the backup request.

Step 2

Druva determines the type of backup.

If you or another administrator initiates the first backup, Druva performs a full backup. All subsequent backups triggered by administrators are incremental backups.

Step 3

Enterprise Workloads agent verifies that the VSS service is running. If the VSS service is not running, the Enterprise Workloads agent starts the VSS service and instructs VSS to create a recovery point.

Enterprise Workloads agent validates if recovery points are created successfully.

Step 4

Enterprise Workloads agent estimates the files and data to back up.

Step 5

  1. If recovery points are created successfully, Enterprise Workloads agent uses the VSS recovery points as the filesets for data backup to Druva Cloud.

  2. If the recovery points are not created successfully, Enterprise Workloads agent scans the live files and folders to create filesets for data backup to Druva Cloud.


πŸ“ Note


​ In case of VSS recovery points, Druva includes the locked files in the backup. However, in case of live folders and files scan, Druva considers locked files as missed files, and attempts to back up such files at the time of the next scheduled backup.


Step 6

After the backup completes, Enterprise Workloads agent deletes the created VSS recovery points.

File servers with Linux operating system

This topic explains how data flow during data backup from the File servers with Linux operating system.

Backup workflow

Step

Operation

Step 1

A backup request is initiated and forwarded to the Enterprise Workloads agent.

Druva checks if Enterprise Workloads agent is running.

  • If the agent is running, Druva performs the backup operation.

  • If the agent is not running, Druva performs the backup operation based on the type of backup job.

    • For a backup now job, queues the backup request. The backup request is executed after Enterprise Workloads agent starts.

    • For a scheduled job, skips the backup request.

Step 2

Druva determines the type of backup.

If you or another administrator initiates the first backup, Druva performs a full backup. All subsequent backups triggered by administrators are incremental backups.

Step 3

Enterprise Workloads agent performs the full scanning of live files and folders on the File server.

Step 4

Enterprise Workloads agent estimates the files and data to back up.

Step 5

Enterprise Workloads agent uses the scanned folders and files as the fileset for data transmission.


πŸ“ Note

  • Druva considers locked files as missed files, and attempts to back up such files at the time of the next scheduled backup.

  • Druva supports valid UTF-8 encoded file names and filepaths. Files with filenames encoded in a format other than UTF-8 are skipped from backups. You can find a list of all the skipped files in the Phoenix-<job_id>-MissedFiles.log file at the following location

    • /var/log/Phoenix/FS/backup/<backupset_id> (for agent version prior to 7.0.0)

    • /var/log/Druva/EnterpriseWorkloads/nas/backup/<backupset_id> (for agent version 7.0.0 and later)


Did this answer your question?