> ## Documentation Index > Fetch the complete documentation index at: https://docs.flexagon.com/llms.txt > Use this file to discover all available pages before exploring further. # FlexDeploy Clone from Production to Test > Many customers install FlexDeploy in Test (or Stage) and Production environments. The purpose of the Test environment is to try various patches or bet Many customers install FlexDeploy in Test (or Stage) and Production environments. The purpose of the Test environment is to try various patches or beta capabilities of plugins, or even trying some complex workflows and/or custom plugins. The FlexDeploy test environment may be restricted for use to by select members of the team. It is good idea to periodically (mostly when applying major FlexDeploy upgrade/patch) clone FlexDeploy Production configuration/execution data to FlexDeploy Test environment, which will allow you to easily validate new FlexDeploy upgrades and patches. **These steps are provided as guidelines and extreme care must be taken to not disrupt your production environments.** > [!NOTE] > > This process should only be followed to perform a clone of FlexDeploy Production environment to the Test environment. Make sure that Test environment is restricted for use by very few members of your team to avoid confusion, as the purpose of the Test environment is only for validating FlexDeploy itself and is not used for actual build/deploy activities. You will do some build/deploy activities, but strictly for validation purposes. > > **The Source and Target version of FlexDeploy must be same, although you can clone and then upgrade to validate a FlexDeploy Release.** # Make sure Target FlexDeploy is Ready * Make sure target environment is ready. * Keep target FlexDeploy down for this process. * Prefer a cold export from Production (stop Production FlexDeploy briefly, or use a consistent backup / Flashback if available) so database and file-system copies align. # Export Import Database & Copy Artifacts, Plugins, and InfluxDB data > [!NOTE] > > FlexDeploy uses Database tables to track all activities & configurations, and Artifact Repository folder to store build artifacts. So you must copy both items to target for successful clone. * Export data from Production FlexDeploy database. * You should export FD,FF and FD\_ADMIN. * Use your DBA-standard tooling. Examples: **Oracle (Data Pump)** ``` expdp system/**** schemas=FD,FF,FD_ADMIN directory=DATA_PUMP_DIR dumpfile=flexdeploy_prod.dmp logfile=flexdeploy_prod_exp.log ``` **PostgreSQL** ``` pg_dump -U postgres -Fc -n fd -n ff -n fd_admin -f flexdeploy_prod.dump your_db_name ``` * Take backup of artifact repository folder using tar/zip commands on Production FlexDeploy server. (Optional if you won’t be deploying any old artifacts, they are not needed) For example, * cd /flexdeploy/artifacts * tar -czvf /app/backup/flexdeploy\_artifacts\_prod.tar.gz \* * Take backup of plugins folder using tar/zip commands on Production FlexDeploy server. Plugins folder is under server working directory. You can determine working folder by looking at flexagon.fd.application.root system property on server command line. For example, * cd /flexdeploy/application/plugins * tar -czvf /app/backup/flexdeploy\_plugins.tar.gz \* * Take backup of vsm folder (InfluxDB) * cd /flexdeploy/application/vsm * tar -czvf /app/backup/flexdeploy\_vsm\_prod.tar.gz \* * Make sure Test FlexDeploy is now stopped for import process. * Import data in to target FlexDeploy database. **Make sure to run this on Test environment only.** * Run the following sql command for the appropriate database that will generate many drop table, view and procedure statements as output.  Once this sql is complete, copy all of the output and execute that against the test database.  This method will drop all of the data but maintain table spaces, quotas and passwords for the given schemas.  This will also maintain the same password that is stored in the context.xml file. **Oracle DB: Drop tables, views and procedures without dropping user** ``` select 'drop table ' || owner ||'.' || table_name || ' cascade constraints PURGE;' from dba_tables where owner in ('FD','FD_ADMIN','FF') union all select 'drop view ' || owner || '.' || view_name || ';' from dba_views where owner in ('FD','FD_ADMIN','FF') union all select 'drop procedure ' || owner || '.' || object_name || ';' from dba_objects where owner in ('FD','FD_ADMIN','FF') and object_type = 'PROCEDURE'; ``` If recycle bin is enabled, also run: ``` purge dba_recyclebin; ``` You can verify remaining object types with: ``` select object_type, count(1) from dba_objects where owner in ('FD','FF','FD_ADMIN') group by object_type order by 1; ``` **PostgreSQL DB: Drop tables and views without dropping user** ``` select 'drop table ' || table_schema ||'.' || table_name || ' cascade ;' from information_schema.tables where upper(table_schema) in ('FD','FD_ADMIN','FF') and table_type = 'BASE TABLE' union all select 'drop view ' || table_schema ||'.' || table_name || ' cascade ;' from information_schema.tables where upper(table_schema) in ('FD','FD_ADMIN','FF') and table_type = 'VIEW'; ``` **Import the Production dump into Test. Examples:** **Oracle (Data Pump)** ``` impdp system/**** schemas=FD,FF,FD_ADMIN directory=DATA_PUMP_DIR dumpfile=flexdeploy_prod.dmp logfile=flexdeploy_prod_imp.log table_exists_action=REPLACE ``` **PostgreSQL** ``` pg_restore -U postgres -d your_db_name --clean --if-exists flexdeploy_prod.dump ``` * Make sure there are no errors in import process. If there are errors, make corrections appropriately and restart import process. * At this point, the Test FlexDeploy database should be copy of Production database. * Copy artifacts zip file to Test FlexDeploy server and extract it in the artifact repository folder. You can determine Artifact Repository folder by looking at **flexagon.fd.repository.root** system property on server command line. **Make sure to run this on Test environment only.** * cd /flexdeploy/artifacts * tar -czvf /app/backup/flexdeploy\_artifacts\_test.tar.gz \* * rm -rf \* * tar -xzvf /app/backup/flexdeploy\_artifacts\_prod.tar.gz * Now FlexDeploy artifact repository is also copied. * Copy plugins tar/zip file to Test FlexDeploy server and extract it in the plugins directory under working directory. You can determine working folder by looking at flexagon.fd.application.root system property on server command line. * cd /flexdeploy/application/plugins * rm -rf ./\* * tar -xzvf /app/backup/flexdeploy\_plugins.tar.gz * Now FlexDeploy plugins are also copied. # Copy Influx DB To sync your influx db between prod and test, follow these steps: In TEST (Target) 1. cd /flexdeploy/application/vsm 2. tar -czvf /app/backup/flexdeploy\_vsm\_test.tar.gz \* 3. rm -rf ./\* 4. tar -xzvf /app/backup/flexdeploy\_vsm\_prod.tar.gz * Now FlexDeploy InfluxDB data is also copied. * If after startup you see an InfluxDB unauthorized notification, see [InfluxDB in FlexDeploy](https://flexagon.atlassian.net/wiki/spaces/SHAR/pages/10198024211/InfluxDB+in+FlexDeploy#Resolving-unauthorized-access-Issue). # Update Target Database as Necessary * Now make various updates to make sure to limit access to the FlexDeploy Test environment and limit what FlexDeploy Test can do against various endpoints. You can customize any of these steps as per your needs. **Make sure to run this on Test environment only**. * Disable external realm and users, so access to FlexDeploy is very limited. Update SQL as appropriate for your setup. For example, **Inactivate Security Setup to restrict access** ``` update FD.FD_REALM set is_active='N'; update FF.FLX_USER set is_active='N' where local_user='N'; -- update as appropriate commit; ``` * Disable endpoints so Test FlexDeploy cannot run executions until an Administrator explicitly enables selected endpoints. Also update base directory so enabled endpoints do not conflict with Production paths. For example, **Update Endpoints for Test environment** ``` update FD.ENDPOINT set is_active='N'; update FD.ENDPOINT set base_directory = base_directory || 'fdtest'; commit; ``` If you prefer to disable only remote SSH endpoints and leave localhost endpoints alone: ``` update FD.ENDPOINT set is_active='N' where connection_type='SSH'; update FD.ENDPOINT set base_directory = base_directory || 'fdtest'; commit; ``` * If you have workflows that perform tags on Source Control Systems, make sure to update the workflows before running builds, so you do not conflict with tags created by Production FlexDeploy. You can do this by simply running this SQL also. Adjust according to your requirements. **Update version syntax** ``` update FD.PROJECT_STREAM set version_syntax = version_syntax || ' + ".fdtest"'; commit; ``` * Delete all Continuous Integration triggers. **Delete CI Triggers** ``` delete from FD.PROJECT_TRIGGER_CONFIG; delete from FD.PROJECT_TRIGGER; commit; ``` * Disable production environment. so Test FlexDeploy can not run any executions even for testing against Production environment. For example, **Disable Production environment** ``` update FD.ENVIRONMENT set is_active='N' where environment_code='PROD'; -- update as appropriate commit; ``` * Consider whether you should change or remove outgoing webhooks, incoming webhook/listener configuration, scheduled tasks/blackouts that would fire against real systems, and Integration Instance connection details that still point at Production systems. * Now start Test FlexDeploy and validate it. * You can make necessary adjustments to Realm, User, Groups to validate setup and perform tests as necessary. This is necessary as we disabled user and realms in previous steps. * You can activate specific Endpoints that you want to be included in Test environment validations. * Update System Settings as appropriate. * Change FD\_SERVER\_BASE\_URL. * Change SMTP\_FROM\_ADDRESS (and review SMTP host/credentials if Test should not use the Production mail path). * Review Integration Instances, OAuth apps/tokens, and any other credentials copied from Production.