M-FILES CORPORATION

M-FILES BACKUP POLICY

LAST UPDATED 9 DECEMBER 2022

VERSION 1.2
Contents
1. Introduction ......................................................................................................................................................................... 3

2. Backup Types ........................................................................................................................................................................ 3

2.1 Master Database ........................................................................................................................................................ 3

2.2 Document Vaults ........................................................................................................................................................ 4

2.2.1 Embedded Firebird SQL Database ..................................................................................................................... 4

2.2.2 Microsoft SQL Server......................................................................................................................................... 5

2.3 Items Not Included in Backups ................................................................................................................................... 7

2.4 Backing Up the Index Files .......................................................................................................................................... 7

3. Best Practices for Backups.................................................................................................................................................... 8

3.1 Protection Against a Hardware Disaster .................................................................................................................... 8

3.2 Protection Against Logical Errors ............................................................................................................................... 8

3.3 Snapshot Backups....................................................................................................................................................... 8

4. Sample Backup Plans ............................................................................................................................................................ 8

4.1 Full Backups Only ....................................................................................................................................................... 9

4.2 Combination of Full and Differential Backups ............................................................................................................ 9

4.3 Verifying the Scheduling of the Backup Jobs .............................................................................................................. 9

5. Testing and Restoring Backups ........................................................................................................................................... 10

6. Change History ................................................................................................................................................................... 10

Page 2 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
1. Introduction

The purpose of this document is to introduce guidelines and best practices for backing up M-Files Server and the data
controlled by it. As every M-Files deployment is potentially different and the particular backup procedures vary across
customers, the recommendations presented here should be treated as informative rather than normative.

The scope of this document is limited to on-premises deployments of M-Files, as M-Files Cloud Vaults are maintained and
backed up by M-Files Corporation according to separate guidelines. The basic procedures described in this document apply
both in situations where M-Files Server, its SQL database, and object files are deployed to a single server, and in situations
where they are distributed across multiple servers.

The document is targeted to M-Files employees and authorized partners and customers. The steps about configuring backup
jobs are discussed in the Administrator Track of M-Files Academy.

2. Backup Types

In general, there are two types of M-Files backups:

• Master database backups (server-specific data)

• Document vault backups (vault-specific data)
o Full backups
o Differential backups

In this section, we will cover the main aspects of and items included in both of these backup types. According to the
customer's needs, backup jobs can either be scheduled to run periodically at specific intervals, or performed manually by
system administrators.

Best practices are covered in section 3 and sample backup plans in section 4.

2.1 Master Database

M-Files server-specific data is always stored in the embedded Firebird SQL database regardless of the chosen deployment or
configuration type. It is very important to regularly create master database backups, not only vault backups.

The backup includes this server-specific data:

• Information on transactions since the last backup

• Login accounts
o M-Files login passwords
o Personal information
o License types
o Server-level roles
• Scheduled jobs

Page 3 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
 • Notification settings
• Licenses
• M-Files Web settings

You can restore master database backups with M-Files Admin (see the M-Files user guide). After the backup has been
restored, it is usually a good idea to verify its integrity by reviewing the restored server-level items in M-Files Admin.

2.2 Document Vaults

It is possible to perform either a full or differential backup on the vault-specific data. M-Files currently supports two
different database technologies for storing vault-specific data:

• Embedded Firebird SQL database

o Vault metadata stored in the database
o Object files always stored in the file system
o Supports full and differential backups
• Microsoft SQL Server
o Vault metadata stored in the database
o Object files stored either in the database or in the file system
o Supports full and differential database backups

Full backups include all object files and the vault metadata:

• Objects with their version history, files, and metadata (for instance documents, customers, and so on)
• Value lists, property definitions and classes
• Metadata structure
• Users, user groups and named access control lists
• User permissions and vault roles
• Workflows
• Connections to other systems
• Event log
• Vault applications and scripts

Differential backups contain changes since the last full backup, thus reducing the amount of disk space needed for storing
backups. In order to perform a successful restore operation, the latest full and the latest differential backup (if one exists)
are needed.

In addition to vault backups, it is crucial to also regularly create master database backups.

2.2.1 Embedded Firebird SQL Database

When using the embedded Firebird SQL database engine, vault metadata is stored in the database and object files are
always stored in the file system (can be a network folder as well).

Page 4 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
Figure 1: With Firebird, metadata is stored in the database and object files are stored in the file system.

M-Files Server locks the files of online vaults, and these files should not be accessed directly. These vaults can be backed up
using Scheduled Jobs in M-Files Admin. The tool creates a single backup file of each document vault. Therefore,
administrators do not need to backup object files from the file system separately.

2.2.2 Microsoft SQL Server

When using Microsoft SQL Server as the database engine, administrators can choose to store file data either in the database
or in the file system. Accessing and modifying M-Files vault databases directly using Microsoft SQL Server Management
Studio or similar is not recommended.

Notice that the components in Figure 2 can be deployed on a single physical server machine or distributed across multiple
servers. This has no effect on how and in which order the backups are taken.

Page 5 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
Figure 2: With Microsoft SQL, file data can be stored either in the database or in the file system.

When using the first option, where files are stored in the database, only one database per vault needs to be backed up.
When using the second option, where file data is stored in the file system, administrators must back up both the Microsoft
SQL database and the files in the file system separately.

Important: Always back up the SQL database first and then the file system data in order to avoid references to
non-existing object files.

The procedure to be followed in this case is as follows:

1. Back up the Microsoft SQL database (metadata) first.

2. Do NOT run M-Files Server optimization at this point, as this would remove files that might have been marked for
destruction after step 1 was performed.
3. Back up file system data (object files).

Microsoft SQL Server is backed up using the tools provided by Microsoft (such as SQL Server Management Studio) or any
compatible tools from 3rd parties. With Microsoft SQL Server, administrators can choose to take full backups and differential
backups on the database itself.

File system data can be backed up using any suitable backup system and with any backup method supported by that system
(for example using incremental backups or similar). Choosing these tools and backup methods is out of the scope of this
document.

Whichever tool set is used for creating the backups, the same tool set should be used when testing and restoring them.

Page 6 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
2.3 Items Not Included in Backups

Regardless of the database used, M-Files Server creates certain secondary data for each vault. This data is stored on the hard
drive of the M-Files server machine. M-Files Server re-recreates the secondary data after the vault backup has been
restored. The secondary data includes:

• Index files
• PDF renditions for hit-highlighting and preview
• Thumbnails

Keep in mind that rebuilding, for instance, the search index of a large document vault can take a significant amount of time
(see Backing Up the Index Files further below).

In addition to secondary data, the behavior of the system may have been modified via various Windows registry key values.
These settings can be exported to a text file and backed up separately as these settings are not included in the vault or
master backups. Also, for example, notification message templates, the M-Files Web user interface and other aspects of the
system may have been configured by editing files in the M-Files Server installation folder. These files must be backed up
manually.

2.4 Backing Up the Index Files

In large vaults, where the index recreation could take a significant amount of time, it is recommended to back up the index
as well. If the default M-Files search engine (dtSearch) is used, backing up the index is as simple as taking a file system level
copy of the Indexes subfolder under the data location of the vault on the server (for example C:\Program Files\M-
Files\Server Vaults\<vault name>\Indexes). The index itself stores its state, and your backup of the index does
not need to be as new as the vault backup. The index begins catching up with the vault automatically.

For example, you could at any time:

1. Take a vault offline.

2. Delete the Indexes subfolder and replace it with an older backup copy.
3. Bring the vault online.

This would result in the indexing to begin catching up until it is completely up to date. If the Indexes subfolder is completely
empty, the indexing process needs to start from scratch and will take a lot longer.

If you are using Micro Focus IDOL as your search engine, contact M-Files for instructions on backing up the index files.

Page 7 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
3. Best Practices for Backups

Taking regular backups of the M-Files system is important. The backup interval depends on the use case and the criticality of
the system. The recommended minimum level is described in this section.

M-Files backups are taken for two reasons:

• To protect against a hardware disaster

• To protect against logical errors

A hardware disaster or logical errors might not be noticed during the same day that they occur. Therefore, it is important to
store enough restore points of the system and always store backup files in a secure off-site location.

3.1 Protection Against a Hardware Disaster

To protect the system against a hardware disaster, using redundant hardware, such as RAID (redundant array of
independent disks) is recommended. Please refer your IT hardware provider for guidance on redundant hardware.

3.2 Protection Against Logical Errors

Built-in document control features, including version history and soft-deleting eliminate the need of restoring backups in
multiple scenarios. These features do not, however, protect against logical errors caused by administrators or system errors.

3.3 Snapshot Backups

Do not back up an active M-Files system with a snapshot of the file system where its data is stored. This can create a
damaged or unusable backup because writes to files, most importantly the database engine files, can be ongoing and thus
incomplete.

If you use full virtual machine (VM) snapshots for backups, make sure that the VM software fully supports creation of
snapshots of an active system. This means that the software can restore the system to exactly the same state, including the
memory and CPU states.

4. Sample Backup Plans

We recommend designing the backup system in such a way that the system can be restored to reflect the situation of any of
the previous 14 days. This can be achieved by taking either full backups only, or a combination of full and differential
backups.

Additionally, we recommend storing monthly, quarterly and annual backup files separately.

Page 8 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
4.1 Full Backups Only

If possible, it is recommended to always take full backups of both the master database and the vault data, keeping the last
14 backups stored securely in an off-site location:

• Take a full backup of the master database every day.

o Create 14 distinct backup jobs for the master database.
o Name each backup file as, for example, “M-Files Master Backup X”, where X is the sequential number of the
backup job (for instance a number between 1 and 14).
• Take a full backup of each document vault every day in a similar fashion.
o Name the backup files as, for example, “M-Files <vault name> Y” where Y is the sequential number of the
backup job (for instance a number between 1 and 14).

4.2 Combination of Full and Differential Backups

In larger systems, the "full backups only" method is naturally not feasible, in which case we recommend using a combination
of full and differential backups as follows:

• Take a full backup of the master database every day.

o Create 14 distinct backup jobs for the master database.
o Name each backup file as, for example, “M-Files Master Backup X”, where X is the sequential number of the
backup job (for instance a number between 1 and 14).
• Take a full backup of each document vault at least once a week.
o Create two distinct backup jobs. Name the backup files as, for example, “M-Files <vault name> FB <Y>” where
Y is the sequential number of the full backup job (either 1 or 2).
• Take a differential backup of each document vault every day except during those days when you take the full backup.
o Name the backup files as, for example, “M-Files <vault name> DIFF <N>_<Z>” where N refers to the order of
the full backup job and Z is the sequential number of the differential backup
o This way, you end up having the following naming conventions: 1_1, 1_2, 1_3, 1_4, 1_5, 1_6 and 2_1, 2_2,
2_3, 2_4, 2_5, 2_6.

4.3 Verifying the Scheduling of the Backup Jobs

It is recommended to verify that the different master database and vault database jobs are scheduled to run on consecutive
days in a logical order. You can see a list of the scheduled backup jobs in M-Files Admin by selecting Scheduled Jobs under
the server connection node in the left-side tree view. In the example scenario described in section 4.2, you should have the
following backup jobs on the list:

Master database: • M-Files Master Backup 6

• M-Files Master Backup 1 • M-Files Master Backup 7
• M-Files Master Backup 2 • M-Files Master Backup 8
• M-Files Master Backup 3 • M-Files Master Backup 9
• M-Files Master Backup 4 • M-Files Master Backup 10
• M-Files Master Backup 5 • M-Files Master Backup 11

Page 9 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION
 • M-Files Master Backup 12 • M-Files <vault name> DIFF 1_5
• M-Files Master Backup 13 • M-Files <vault name> DIFF 1_6
• M-Files Master Backup 14 • M-Files <vault name> FB 2
• M-Files <vault name> DIFF 2_1
Vault:
• M-Files <vault name> DIFF 2_2
• M-Files <vault name> FB 1
• M-Files <vault name> DIFF 2_3
• M-Files <vault name> DIFF 1_1
• M-Files <vault name> DIFF 2_4
• M-Files <vault name> DIFF 1_2
• M-Files <vault name> DIFF 2_5
• M-Files <vault name> DIFF 1_3
• M-Files <vault name> DIFF 2_6
• M-Files <vault name> DIFF 1_4

5. Testing and Restoring Backups

Testing and verifying the integrity of a backup can be done using any computer with M-Files Server installed. This should be
done regularly to ensure the backup jobs are functioning correctly. We recommend testing your backups two to four times a
year, at minimum.

If the embedded Firebird SQL database is used, refer to M-Files user guide for instructions on how to restore backups (see
Backing Up and Restoring the Master Database and Restoring a Document Vault). If Microsoft SQL Server is used, refer to
the documentation of the backup tools you are using for creating the backups.

6. Change History

The table below describes the essential changes by document version.

VERSION DATE ESSENTIAL CHANGES

1.0 – Initial released version.

1.1 2018/05/23 Updated the document template. Added instructions on backing up index files (section 2.4).

1.2 2022/12/09 Added section 3.3.

Page 10 of 10

CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION