The HA setup is available only for the MAX Edition.
The SnowMirror Backup agent runs as a service in your local environment. Both Windows and Linux operating systems are supported. According to the configured backup jobs, it downloads data changes from a ServiceNow instance and stores them as backup files onto a dedicated filesystem. No ServiceNow changes are needed; the backup uses out-of-the-box API available in every ServiceNow instance. The SnowMirror Backup service guarantees you to keep up with every new ServiceNow release. The only SnowMirror Backup installation requirements are a server to install the agent, and a ServiceNow user account with sufficient permissions as well as sufficient disk space for the backups.
Backup individual tables from the cloud instance onto a filesystem in your data center. Store the backups in one of the default ServiceNow formats (XML and CSV) to be prepared for sudden data losses or alterations. Schedule both full and incremental backups and configure backup retention to be in-line with your corporate policies.
It is a challenge to export data that exceeds the ServiceNow export limit settings. Create large data exports from a cloud instance by using SnowMirror Backup allowing you to export any number of rows from any of the database tables in ServiceNow.
Use existing backups from your ServiceNow production instance to restore selected tables in the sub-production instances. No need to clone the whole instance if you need only a couple of tables to perform test or development tasks.
Every backup run can be triggered manually at any time. However, the more common option is a scheduled backup job. The configurable scheduler allows you to define individual execution plans for every selected table so more critical tables can be scheduled for backup more often. It is possible to specify an interval between executions (e.g. every 60 minutes), schedule a daily replication, or use a cron expression. Both full backups and incremental backups can be configured separately. The first time a backup runs, it downloads all the data. However, every subsequent run is an incremental update adding only new records, updating changes and removing deleted items. These increments are usually small even for large ServiceNow instances so SnowMirror Backup proceeds quickly.
Simply define ServiceNow tables for backup – it is not necessary to back up all the tables available such as the system tables. Backup tables that are relevant. Specify a detailed filter query to restrict the amount of data for backup (e.g. backup open change requests only). SnowMirror Backup supports the ServiceNow encoded query notation so it is easy to copy-paste filter settings from ServiceNow into the backup setup. It is a good practice to limit the number of columns for data stored in CSV formats to reduce the space requirements. Each backup job has its own data retention policy to remove the backups automatically that are no longer needed.
ServiceNow data is vital to your organization, and as the single system of record it contains valuable business critical data that should be backed up daily, and it should be easy to restore it in case of data loss. ServiceNow does a great job to ensure that the data is secure and that the instances run with a high availability. The environments are backed up every day which covers critical errors or major data loss. However, the restore procedure takes several days and it recovers the instance as a whole, so there is no partial restoration.
All
MySQL, MariaDB, PostgreSQL
All
All
Silver 8 x 5
Silver 8 x 5
Gold 8 x 5
Platinum 24 x 7
30 days
3 years
3 years
3 years
Standard contract duration is 36 months or longer. Minimal contract lenght is 12 months.
All
All
Silver 8 x 5
30 days
FREE
Full feature specifications
All prices are monthly excluding VAT or other taxes. The monthly price is valid for minimum contract duration of 36 months or longer. Minimal contract lenght is 12 months.
MySQL, MariaDB, PostgreSQL
N/A
N/A
2
Silver 8 x 5
3 years
$990/month
Full feature specifications
All prices are monthly excluding VAT or other taxes. The monthly price is valid for minimum contract duration of 36 months or longer. Minimal contract lenght is 12 months.
All
$990/month
2
Modul
Gold 8 x 5
3 years
Custom
Full feature specifications
All prices are monthly excluding VAT or other taxes. The monthly price is valid for minimum contract duration of 36 months or longer. Minimal contract lenght is 12 months.
All
$990/month
Yes/Custom
All
Platinum 24 x 7
3 years
Custom
Full feature specifications
All prices are monthly excluding VAT or other taxes. The monthly price is valid for minimum contract duration of 36 months or longer. Minimal contract lenght is 12 months.
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
SnowMirror creates a ServiceNow read-replica in your own database. Having selected ServiceNow tables in your data center can have many benefits. These are the three most popular use cases:
Yes. If you need high availability there is a possibility to install several SnowMirror installations. Some of our customers even install one SnowMirror into their DRC centers. SnowMirror architecture is cluster-ready and if one node goes down the other node is still synchronizing the data. We usually support this kind of requirements individually and we cooperate on the customer cluster design.
The HA setup is available only for the MAX Edition.
No. The only mandatory requirement is to have a user account which has sufficient rights to access ServiceNow data and meta-data. However, if using the SOAP API, we recommend activating the Aggregate Web Services ServiceNow plug-in to improve the user experience, enable a few fancy features and add a small performance boost.
No. If you have several ServcieNow instances you have to install several SnowMirrors. The idea behind it is the same as for the MID servers.
Yes. And it is quite usual to run a mirror for a test ServiceNow instance and a development instance on one server. It is necessary to configure different ports and different Windows service names. Use the Custom Installation option if installing using the Windows installer. A similar approach applies to Linux systems.
SnowMirror in not resource intensive. It is a Java application running as a Windows service or a Unix daemon. It requires a server to be installed on. The server can be a small virtual or physical machine. The typical configuration is a dual core CPU server with 2 GB RAM and 5 GB HDD. We even recommend to install SnowMirror on the same machine as the ServiceNow MID server. You can save one server using this approach.
Read more about SnowMirror requirements in the admin guide: https://www.snow-mirror.com/doc/
The Aggregate Web Services plug-in is a small plugin adding the aggregate method into all direct web services in ServiceNow. SnowMirror is using this new operation to count the records to insert or update before the actual download starts. By activating the plugin the progress bars work better, the count buttons enable you to count records in tables and SnowMirror is able to optimize the downloading algorithm a bit.
The main database is the mirror DB where the ServiceNow data is being stored. However, SnowMirror requires to maintain its configuration in a second database. So-called config DB. The config DB is configured during the installation phase and it is using H2 embedded database by default. The mirror DB can be configured in SnowMirror Settings page.
See the picture of the whole SnowMirror architecture.
If your synchronization failed and you got an error similar to java.sql.BatchUpdateException: Data truncation, it can have two different root causes.
1) Something has changed on the ServiceNow side. Usually someone made a string field longer than before. For example your ServiceNow admin made incident short_description longer (max length) from 80 to 200. So it means the new incident subjects cannot fit into your varchar(80) in the mirror database. To fix this, either manually alter the mirror table (column) or re-create the whole synchronization and perform an initial data load.
2) ServiceNow does not always respect its own data constraints. E.g. try to synchronize the sys_perspective table and it fails by default because one column in this table is configured to have 40 chars as its max length however the longest string in the column has 125 characters by default. There is no other solution than to manually alter the mirror database table to reflect the real situation.
Auto Schema Update feature enables to modify the mirrored table automatically according to the changes on the ServiceNow side. If enabled all the table columns are being synchronized. If there is a new columns in ServcieNow, SnowMirror automatically adds it into the mirror table. The same applies for modified columns a removed ones.
ServiceNow enables to specify a parent for a table. It means all the columns in the parent table are used for the child table as well. For example the table task (parent) and incident (child). Many tables are derived from the task table. The whole CMDB is build on this inheritance design pattern. Etc.
SnowMirror enables two approaches when synchronizing inherited tables (e.g. incident)
1) Synchronize two tables. This is the way ServiceNow itself stores the data. You have to synchronize two tables (e.g. task and incident) and to obtain the incident record you have to join the tables using the sys_id primary key in both tables. The advantage of this approach is lower redundancy. If you are synchronizing several tables derived from the task table the situation is simpler to perform some type of queries.
2) Synchronize only one table with all parent inherited columns included. This is an approach that a typical user expects. To sync the data as it is displayed in the web application. Check the checkbox Include inherited columns in the synchronization settings to choose this approach.
To identify new or updated records in ServiceNow is a straightforward way. However to find the records deleted in a certain time window is not so simple. Most of the tables are audited so the default strategy search for deleted records in the system journals. You can choose different strategies if you need or if the table is not being audited. Truncate option means to perform Clean & Synchronize operation for every sync run (initial load every run). Diff is a good way to find the deleted records in a non-audited table and None ignores the deletes at all.
Please read more about the delete strategies in our user guide.
Please note that synchronization settings for Views do not contain the delete strategy choice at all. It always performs the Truncate option because there is no way how to achieve incremental updates.
SnowMirror does not access the database directly. ServiceNow does not allow neither customers not partners to access the underlying instance database. All the data is downloaded using the our-of-the-box API called Direct Web Services. Event the original ODBC driver uses this API which is the reason why the driver is so limited and slow.
SnowMirror distribution contains an optional ServiceNow dashboard application. If you have installed the update set into your ServiceNow instance enable this setting to start sending SnowMirror activity into the ServiceNow instance.
No. You pay only for every SnowMirror connected to your production ServiceNow instance. Test, UAT, development or sandbox instances are for free.
SnowMirror license is bound to a certain ServiceNow instance host name (e.g. yourcompany.service-now.com). So the ServiceNow host name you configure in Settings -> ServiceNow has to match the license host name. Please do not forget to restart SnowMirror after you change the instance in the Settings. In case of a trial license please feel free to generate yourself another trial license on our website if you need if for a different ServiceNow instance.
