* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download m-files backup policy - M
Entity–attribute–value model wikipedia , lookup
Microsoft Access wikipedia , lookup
Oracle Database wikipedia , lookup
Concurrency control wikipedia , lookup
Team Foundation Server wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational model wikipedia , lookup
ContactPoint wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Database model wikipedia , lookup
ID 168559 v 16 M-FILES CORPORATION M-FILES BACKUP POLICY VERSION 1.0 12/12/2014 Page 1 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 CONTENTS 1. Essential changes from previous version .................................................................................................................... 3 2. Purpose ....................................................................................................................................................................... 3 3. Scope .......................................................................................................................................................................... 3 4. Backup Types .............................................................................................................................................................. 3 Master Database Backup .................................................................................................................................. 3 Document Vault Backup .................................................................................................................................... 4 4.2.1 Embedded Firebird SQL Database ................................................................................................................ 5 4.2.2 MS SQL Server ............................................................................................................................................... 5 Items not Included in Backups .......................................................................................................................... 6 5. The Best Backup Practices .......................................................................................................................................... 7 Protection Against Hardware Disaster .............................................................................................................. 7 Protection Against Logical Errors ...................................................................................................................... 7 6. Sample Backup Plans .................................................................................................................................................. 7 Full Backups Only .............................................................................................................................................. 7 Combination of Full and Differential Backups ................................................................................................... 8 Verifying the Scheduling of the Backup Jobs..................................................................................................... 8 7. Testing and Restoring Backups ................................................................................................................................... 8 Page 2 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 1. ESSENTIAL CHANGES FROM PREVIOUS VERSION Version Essential changes 1.0 Initial version 2. PURPOSE 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. 3. SCOPE This document's scope is limited to on-premises deployment types 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 here apply regardless of whether the M-Files Server, its SQL database and object files are deployed to one single server, or distributed across multiple servers. The document is targeted at M-Files internal use, as well as authorized partners and customers. The steps to configure backup jobs are discussed in the Administrator Track of M-Files Academy. 4. BACKUP TYPES In general, there are two types of M-Files backups: Master database backup (server-specific data) Document vault backup (vault-specific data) o Full backup o Differential backup 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 be either scheduled to run periodically at specific intervals, or performed manually by system administrators. Recommended scheduling settings and certain best practices are covered in the Backup Guidelines section later in this document. MASTER DATABASE BACKUP M-Files server-specific data is always stored in the embedded Firebird SQL database regardless of deployment or configuration type chosen. Page 3 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 Master database backup is performed using the M-Files Server Administrator tool. This backup includes the following server-specific items: Login accounts o M-Files login passwords o Personal information o License types o Server-level roles Scheduled jobs Notification settings Licenses M-Files Web Access settings Restoring and testing the integrity of master database backups can be done using the M-Files Server Administrator tool. Refer to the M-Files User Guide for more details. DOCUMENT VAULT BACKUP 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 DB o Object files always stored on file system o Supports full and differential backups MS SQL Server o Vault metadata stored in DB o Object files stored either in DB or on file system o Supports full and differential database backups Full backups include all object files and metadata of the vault: Objects with version history, files and metadata (e.g. documents, customers, etc.) 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. Page 4 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 4.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 on the file system (can be a network folder as well). 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 the M-Files Server Administrator tool. This tool creates a single backup file of each document vault. Therefore, administrators do not need to backup object files from the file system separately. With Firebird, M-Files supports taking full backups and differential backups of the document vaults. Restoring and testing the integrity of Firebird document vault backups can be done using the M-Files Server Administrator tool. Refer to the M-Files User Guide for more details. 4.2.2 MS SQL SERVER When using MS SQL Server as database engine, administrators can choose to store file data either in the database or on file system. Accessing and/or modifying M-Files vault databases directly using MS SQL Server Management Studio or similar is not recommended. Notice that the components in the figure below 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 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 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 on file system, administrators must backup both the MS SQL database and the files on the file system separately. Important: always backup 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. 2. 3. Backup the MS SQL database first (metadata) 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 Backup file system data (object files) MS SQL Server is backed up using the tools provided by Microsoft (e.g. SQL Server Management Studio) or any compatible tools from 3rd parties. With MS 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 (e.g. using incremental backups or similar). Choice of such tool and/or backup method is out of scope for MFiles and this document. Whichever tool set is used for creating backups, the same tool set should be used when testing and restoring the backups. ITEMS NOT INCLUDED IN BACKUPS Regardless of the database used, M-Files Server creates also certain secondary data for each vault. This data is stored on the hard drive of the M-Files Server. M-Files Server re-recreates secondary data after the restoration of the vault backup. The secondary data includes: Index files PDF renditions for hit-highlighting and preview Thumbnails Page 6 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 Keep in mind that rebuilding e.g. the search index of a large document vault can take a significant amount of time. In addition to secondary data, the system may have been configured using different 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, Web Access UI and other aspects of the system may have been configured by editing files in M-Files Server installation folder. These files must be backed up manually. 5. THE BEST BACKUP PRACTICES Taking regular backups of the M-Files system is important. 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 hardware disaster To protect against logical errors Hardware disaster or logical errors might not be noticed the same day. Therefore it is important to store enough restore points of the system and always store backup files in a secure off-site location. PROTECTION AGAINST HARDWARE DISASTER To protect against hardware disaster, using redundant hardware, such as RAID (redundant array of independent disks) is recommended. Also, taking snapshots of the (virtual) M-Files application server is recommended. Please refer your IT hardware provider for guidance on redundant hardware. 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. 6. 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. 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: Page 7 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 Take a full backup of the master database every day. Create 14 distinct backup jobs for master database backups to ensure that you can store 14 separate master backup files. Name each backup file e.g. as “M-Files Master Backup <X>”, where X represent the sequence number of the job (i.e. 1 to 14). Also take a full backup of each document vault every day in similar fashion. Name the backup files e.g. as “M-Files <VAULT NAME> <Y>” where Y represents the sequence number of the job (i.e. 1 to 14). 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. Create 14 distinct backup jobs for master database backups to ensure that you can store 14 separate master backup files. Name each backup file e.g. as “M-Files Master Backup <X>”, where X represent the sequence number of the job (i.e. 1 to 14). Take a full backup of each document vault at least once a week. Create two distinct backup jobs. Name the backup files e.g. as “M-Files <VAULT NAME> FB <Y>” where Y represents the sequence number of the full backup job (i.e. 1 or 2). Take a differential backup of each document vault every day except during those days when you take the full backup. Name the backup files e.g. as “M-Files <VAULT NAME> DIFF <Y>_<Z>” where N stands for sequence number after the full backup (that is, 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). VERIFYING THE SCHEDULING OF THE BACKUP JOBS It is good to verify that the different master database and vault database jobs are scheduled to run on consecutive days in a logical order: 7. TESTING AND RESTORING BACKUPS Testing and verifying the integrity of a backup can be done using any computer with an 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. Page 8 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION ID 168559 v 16 If the embedded Firebird SQL database is used, refer to M-Files User Guide for details on how to restore backups. If using MS SQL Server, refer to the documentation of the tools used for creating the backups. Page 9 of 9 CONFIDENTIAL PROPERTY OF M-FILES CORPORATION, DO NOT COPY OR PUBLISH ONLINE WITHOUT AUTHORIZATION