Tenant Export/Import

[RADSr]

If I need to make a change to a schema I can export, make the change, and then re-import.  ( the change is removing a join which references a child table that no longer exists -- I don't know how it happened as it pre-dates me, but I dislike getting error messages 😉  ) 

If I do the same thing but with a tenant export ( doing that so I can use the Notepad++ "find in files" across all objects ) do I lose anything w/ the round trip?  It looks like the data source credentials are stored encrypted in the file(s) so I shouldn't lose that, anything else to worry about?   

Since I'll have the export ZIP file in case I mess up the XML edits,  is there any reason *not* do this? 

[dylanwan · Accepted solution]

If you just want to restore the previous state of a given object, currently the best practice is to restore the tenant in a separate tenant, and export the given object from the backup tenant.  I will not restore the entire tenant for recovering a specific object.  Tenant level restore will lose all user specific objects such as the bookmark, personalization, etc, as well as all audit info, such as job histories, actions, etc.  

[RADSr]

Thanks - that's a huge caveat and it hadn't occurred to me to spin up a new tenant to import over.   I guess you'd have to modify the export XML somewhere so you don't wind up w/ two tenants of the same name?  

[DustinB]

Hi Randy, you can rename the tenant export when you import it, no XML modification necessary. Here's a list of data that is not contained in a tenant export:

• Schema notifications and history
• Dashboard edit history
• Schema drafts
• Schema & table load history and details
• Low-level details like compaction and parquet versions