We are trying to clone our production Repository (File structure and DB) to a test server but unsure if there is a tool or the proper procedures to do so. Is there any documentation or something that can help us achieve this?
Question
Question
Clone/Export Production LF Repository to a Test Server instance
Replies
You can use the same steps for moving a repository documented here. Just replace all reference to "move" with "copy" and copy the volume files to the new server. Then in step 7, update all volume paths.
Be sure to use a separate Laserfiche Server. Cloning the repository to the same server is not supported.
Hi Miruna,
Does this apply only for the repository or apply to LF Forms/Workflow?
Thanks for the help. We are attempting the clone in the coming days but are trying to understand what to expect since we need to plan downtime to take the Repository offline and if it is absolutely necessary to offline the server.
I would not clone a Workflow or Forms database. The repository is static and copies are independent and nothing really happens without user activity. With Forms and Workflow, though, you have live instances of processes. So timers will go off, emails will go out, etc., so there could be duplicate emails and competing duplicate changes to the repository or other systems.
To establish a test instance for Forms or WF, export your processes from your production installation, set up a brand new Forms/Workflow instance with an empty database, connect it to your copy of the repository and import processes. The import will give you a chance to redirect connection profiles and other objects to your test versions. You may have to manually recreate some of the external connections to mail servers, web services, custom script references.
We have a payment process in workflow and forms that relies on uptime of the Laserfice server. Is taking the LF server offline necessary for just cloning a repository?
Shouldn't be. You'd use a backup of the repository's database and volumes. Attach SQL DB to a SQL Server, then register the repository to a new LFS server using the new SQL DB, then correct volume paths to point to where you've restored the volumes from backup.
Depending on what you're going to do with the cloned repository, you can skip restoring the volume data. Just be aware that documents won't open their pages or e-docs if the volume data is missing. You'd still want to fix volume paths so any new documents you create in this new repository have a place to go.
@████████, is there a way when copying a production repository database to a test environment to delete all or most of the entries? Our repository database is quite large, and we would like to get a copy of it so we have all of the same data, but don't necessarily need the document data in the database.
Completely untested: if you delete from toc table where etype=-2, that should cascade deletions and remove all documents and their contents and such.