0

I coulnd't find an easy documentation on what the limitations are.

Does Data Loader CLI support All objects custom and standard?

Does it support metadata and files?

Does it support static resources?

Does it support apex classes, triggers, visualforce pages, lightning components, etc?

Is there anything that someone new to it should know before attempting to set up a scheduled backup?

1 Answer 1

3

Does Data Loader CLI support All objects custom and standard?

It supports all "normal" standard objects and all custom objects. It does not support some types of metadata exist as sObjects that can't be queried. You need to check the documentation for your specific object. Most objects are supported, but a few are not.

Does it support metadata and files?

Files are exposed as things you can query, but not metadata. Use Salesforce DX for that purpose.

Does it support static resources?

Yes, but you might consider using Salesforce DX instead, as you'll get actual files instead of base-64 encoded body strings. Again, if you have questions about a specific object, consult the documentation. You can't deploy static resources from the file you extract, so it would be more hassle than it's worth.

Does it support apex classes, triggers,

Yes, but you can't deploy Apex Classes or Triggers that are exported this way. Use Salesforce DX instead.

visualforce pages, lightning components, etc?

No. Use Salesforce DX.

Is there anything that someone new to it should know before attempting to set up a scheduled backup?

Don't use the Data Loader for metadata. It's very limited, as its purpose is not to back up metadata, just normal data. Use Salesforce DX instead. In addition, "org-based development" is so 2016. You should be using a repository-based development model.

This means that instead of backing up your org, your org is a "backup" of the original "source of truth". This has many positive benefits, including being able to quickly make changes, test them in Scratch Orgs, and then deploy those changes to production.

Also, this means there's no need to "schedule a backup". You have to update the Source of Truth in order to make any deployments using this model, so you're automatically backed up. Neat, eh?

Also, for normal data, consider the Data Export Service. THis has the distinct benefit of making sure you get a consistent snapshot. For example, with the data loader model, a user could edit one table while another is being backed up, and you'll have an inconsistent data state. Using this service mostly eliminates those issues. It also supports files and attachments. And you can schedule them. There's not much of a reason to use Apex Data Loader this way, as opposed to using the correct tools for the job.

2
  • So by that logic you would need to schedule a deployment(or make a deployment) once a week to be "backed up"? Thanks for the response by the way. I just did platform app builder and remember their being a question about using Dataloader cli to schedule backups of data
    – ThatGuy
    Nov 6, 2020 at 0:20
  • @theNewGuy No, your back up is the repository, you just deploy whenever you make changes (e.g. if you do biweekly deployments, or bimonthly, etc). Then you only need to worry about the data exports.
    – sfdcfox
    Nov 6, 2020 at 1:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .