We are happy to share our progress on adding a data import and export feature with a beta release today.
For developers and DevOps engineers who want to manage the data of their Strapi projects, the export/import allows you to operate backup & restore of your Strapi project data without acting manually and directly into the database.
In your Strapi project folder, launching from the CLI the command strapi export, an archive is produced containing all the existing data. Exports are automatically encrypted and compressed. You can disable the encryption and compression with the --no-encrypt and --no-compress options.
Once you have an exported archive, you can launch from the CLI the command strapi import -f <path_to_the_exported archive-with-file-extension> that will perform a restore of all your data.
In the very near future, we will provide a transfer command to directly migrate your data from your local instance of Strapi to a remote instance or vice versa.
You can test the feature by creating a project using npx create-strapi-app@4.6.0-beta.1 my-project --quickstart
Admin users should not be exported but users from the U&P plugin should be in the exported data. If you run into any issues let us know and I will make sure it is passed on to the devs.
Sounds good, question then.
If i import data. It wipes my previous data. Does it then force you to create a new admin ?
To access the data you had if that makes sense ?
Amazing! Thanks for sharing that!
Quick question… will the data export be agnostic from the Strapi version? Would that work across different Strapi future versions? e.g.: exporting v4 data, import v5 data?
or are the exports dependent from the version they were exported from?
Hi @Naazim_Khan Most of the team is off today. I will relay your message to the devs tomorrow. Could you post some of your system details (Strapi version of the import project/OS anything else you think could help).
With the default restore import strategy, only the exported data will be wiped before being inserted again.
Since admin users are not exported, they should not be erased in your targeted Strapi instance.
Hey & thanks for asking this, our goal was to make the exported data version agnostic (and basically, very generic), so that it can work regardless of the Strapi version, data source, etc…
On top of that, even if something isn’t really compatible data-wise, we have tools allowing us to filter & transform in-transit data (kind of like middleware but for your transfer processes), thus allowing everyone to adapt to their own needs.
We won’t promote those APIs & tools publicly while they’re not stable & ready to be used, but I’m sharing this information to let you know it’ll be possible
As I’ve already shared with the team, we need to improve the error handling & output on this feature (and we will). It’s not good enough right now in terms of DX.
I’ve some question to help you debug this one
Where did you run your export command? (app dirname + strapi version)
Where did you run your import command? (app dirname + strapi version)
(If you ran both commands in the same application, just say so)
Could you share with me the content of your metadata.json file in your export_xxxx.tar file?
Did you make changes in your app structure (like modifying the schemas file for example) between the export and the import?
Hi all, for anyone interested in some additional information about DEITS in v4.6.0 and the future I constructed a demo repo and some sample videos that show what is coming in v4.6.0 and v4.7.0 (experimental features).
If you have any feedback please feel free to share, thanks!
How do we manage zero/limited down time for content if we’re wiping data before inserting again? Likely not in scope question but it matters operationally. Similarly challenge will present for the Deits approach.
Good step in the right direction. Any plans for APIs equivalent to the CLIs? Appreciate this feature seems to be more backup/restore and devops focused but would be nice to wrap it in some CD tooling and keeps devops off the backend systems.
Deits sounds like it might help there. I’ll comment about desires for that elsewhere: content packages, change control, UX for content managers.
