Content Replication and Archiving

Content replication and archiving enables synchronization of objects between vaults. This helps in ensuring that data is up to date between various specified vaults. Replication and archiving can be carried out by using the export and import operations available in M-Files Admin.

The replication features in M-Files Admin.
Note: Accessing these settings requires you to log in to the server with a login account that has the System administrator server role. Vault users with the Full control of vault rights are allowed to manage cloud storage based replication jobs.

Ways to utilize replication and archiving

With content replication and archiving, you can, for instance:

  • Archive data from an actively used vault to an archive vault.
  • Archive data for long-term preservation in XML or PDF/A form in compliance with standards.
  • Collect data from several M-Files vaults within a single, centralized vault.
  • Use specific vaults for each of the various operations of the company.
  • Publish certain documents for interest groups, such as partners, customers, or subcontractors.
  • Perform backups.
  • Restore the system after an error reliably (as in disaster recovery).
You can, for example, replicate documents from a production vault to a publication vault according to given property values of documents. For instance, a document may be replicated to a publication vault when the property Published is set to Yes.

For a more extensive presentation on replication and archiving, see M-Files Replication and Archiving User's Guide.

Important remarks

  • For association and synchronization of objects and their metadata between separate vaults, the metadata definitions must also be associable between vaults. For more information, see Associating the Metadata Definitions.
  • It is advisable to check the permissions of confidential imported objects in the target vault after an import operation is complete, especially if the source and the target vaults have differing users or user groups.
  • If M-Files is installed on several servers, each server must have a unique server license installed.
  • All M-Files Server instances in a replication setup must have the same build number. For example, 12628 in 23.5.12628.4.
  • Two-directional replication of metadata structure is highly discouraged as the structure of the target vault is always overwritten with the structure in the content package, even if the metadata structure of the vault is more recent than the one in the content package. Thus, if two-directional replication of metadata structure is enabled, it may overwrite changes made to the metadata structure of any vault in the replication scheme.

    An exception to the above recommendation are value list items, as they are provided with timestamp information to indicate when they have been created or modified. Therefore replicating value list items does not have the same shortcomings as replicating other metadata structure items, as value list timestamps assure that the most recent value list items are always preserved during replication.

  • Replication from a vault to another vault is not supported if the vaults have the same GUID. Two vaults must never share the same GUID. It is possible to generate such a situation, for example if a copy or a backup of a vault is attached to another server using the original GUID.
  • It is highly discouraged to compress M-Files content packages using the ZIP archive format. ZIP archives do not specify the character encoding that is used for the file names stored in the archive, and therefore it may not be possible to import content packages that have been compressed using ZIP to systems that use different system language and code page settings than the system from which the content package was exported. If you wish to compress the content package, it is recommended to use a format that retains the character encoding information of file names, such as 7Z.