Ask Questions and Find Answers

For what use case were the LARs created?

We were thinking about using the LARs for disaster recovery. But you are right, they really break for seemingly no reason.

What does Liferay recommend to use the LARs for?

For DR, you're better w/ a full database backup and also replication to your remote DR database.

As far as the use cases for LARs, I think they are pretty small and rather narrow, although I don't think we have any official documentation for how to use them.

They can help move simple assets between environments, but even that can sometimes be challenging when there is an object graph (i.e. you have a web content with 5 embedded images, if you include all 5 it can load into a clean environment but it can be a challenge when loading into an environment that already has 3 of the 5 images).

Interestingly, staging is based on lar export/import, but there is enhanced logic in there for selecting the right assets to publish in conjunction with better conflict resolution...

Me, I've never seen a stable, long term process based on LAR export/import that didn't at some point end in serious failure... I don't advocate using them really at all because I just always expect disaster.

It's the reason that I wrote that "Content Creation is Not a Development Activity" blog post in order to share Liferay's view of how to handle content and steer folks away from trying to use LAR export/import...

What we need is an ability to restote not the whole Liferay installation, but a Liferay instance or a single site or a single assey for a single site, like a documnet library for a single site. How should we go about doing that?

Those kinds of things are not easy... A single instance or a single site, those are truly problematic...

The instance is an obvious fail - there is no way to export/import an instance because export/import only works at a site level. I would say that if you need to be able to restore individual instances, they should be in separate servers so you can just restore the server and the instance w/o impacting any others.

A single site, that is almost as hard. The LAR export/import is really the only option, but it is going to be an untrustworthy one at that, especially if you are not completely deleting the site before trying to import the LAR.

Individual assets? I'd likely restore the DB into a non-prod environ, find the individual asset and try the LAR export from there and import into the target environment, but again this is not something that is guaranteed to work and will require care setting up the environ to restore from since the LAR export/import requires that both sides be the exact same version, down to the last detail.

Document library for a single site? Well this is probably the ugliest of all because you have to coordinate the restore of whatever you're using as the underlying document store (i.e. your filesystem or S3 bucket or whatever) along with the DB restore before you can even think about a LAR export...

Ideally though if you are using Liferay the way Liferay intends, these kinds of things should not be required:

1. Web content and documents are versioned, so nothing is lost when you create new ones and you can always revert to an older version.
2. Workflow can be used to approve individual assets before they go live, so you have a chance to reject possible changes that you would otherwise have to restore later on.
3. Staging and publications can be used to preview page changes before they go live, so if you don't like or approve the changes, they won't go live and there's nothing to have to restore.
4. Finally, don't treat content like a development activity by creating it in non-prod environments and plan to move it to the production environment; do all of your content work directly in production.

When you can fully adopt The Liferay Way, your issues about restoring instances, sites, assets or document libraries all tend to fall away. And in cases where there is some asset to restore or a document to recover or something, these become outliers that point to a problem in your review process (or lack of review process).