Backup Limitations

Skyvia performs backup and restore operations via API, provided by data sources, and thus, is sometimes limited to the corresponding API functionality. Here are Skyvia Backup limitations you need to consider:

Read-only Tables

In some of the supported data sources, some tables are read-only. For example, in Salesforce, the objects with name ending with “Feed” or “History” are read-only. Skyvia can back up such tables, but it cannot restore data to such tables, since they are read-only.

Tables That Don’t Allow Selecting All Data

In some of the supported data sources, some tables don’t support selecting all the records from them. They allow selecting records only by their IDs. There is a number of such tables in Salesforce - ContentFolderItem, ContentFolderMember, IdeaComment, Vote, ListViewChartInstance, etc. Skyvia cannot normally back up records from such tables, unless you specify IDs of the records to Back up in the filter settings. If a backup includes such objects, it will show the corresponding errors for them in your snapshots.

Tables with Limited DML Support

In some of the supported data sources, some tables support not all DML operations. For example, a table may support updating and deleting existing records, but not creating new records. The corresponding data source limitations apply to Skyvia Backup too. If a table does not support the INSERT operation, Skyvia cannot be able to restore deleted records, or if a table does not support UPDATE, Skyvia cannot undo record updates, etc.

Polymorphic Relations

Some cloud applications have polymorphic relations — foreign keys, when the same foreign key field can reference different kinds of objects. For example, in Salesforce the OwnerId field of the Case object can reference User or Contact object. Skyvia does not allow navigating such relations when viewing data and does not display the related records by such relations.

Additionally, in some cases Skyvia cannot restore such relations in a data source when performing a restore operation. It can restore such relations only if the corresponding foreign key field is not required (can have NULL values) and is updatable. For example, Skyvia cannot restore relations of the Dynamics 365 Connections table that has polymorphic relations on the record1id and record2id fields, which are required.

Relation Cycles

Skyvia does not fully support restoring relations in case the relations between backed up objects are cyclic.

For example, you back up objects A, B, and C. The A object has a reference (foreign key) to B, B has a reference to C, and C has a reference back to A. When Skyvia restores data with such cyclic foreign keys, it omits one of the keys to break the cycle. If there are multiple cycles, Skyvia may omit multiple foreign keys when restoring data.

This happens regardless of the number of objects in a cycle. The only exception is a cycle of one object, when the object references itself (for example, an account references a parent account). Skyvia supports restoring such relations.

A foreign key to break is selected automatically, based on objects and foreign keys structure. The only way to mitigate this limitation is to manually exclude fields of foreign keys that you prefer to break from the backup. In this way you can choose which relation from the cycle not to restore, instead of the automatic Skyvia choice. For this, edit the package, click the edit task link for the corresponding object and clear the checkbox for the corresponding foreign key field.