Ask Questions and Find Answers

I wouldn't work with export/import because it only can be used for parts of the data. e.g. users aren't exported/imported.
I would simply clone the database and copy/rsync the Liferay server directory (maybe except logs, osgi/state, temp, work folders) to the disaster recovery server.
One thing: Uploads are stored in the data folder. It is possible that db and data folder get "out of sync" with that approach. So, you have to be careful. But in general, this works pretty well with rsync.
We usually update the integration system the following way, to have current data there:
- Stop integration system
- Overwrite INT DB with Prod DB
- Copy data folder from PROD to INT
- Start the int system
Note: We also have some scripts that fix things like the virtual host entries. Also, we have placed most of the osgi configuration into the filesystem (placed them in osgi/config) so that some config settings stay different.

But our usecase is different, if you are using it for disaster recovery only, you don't need to change anything, you just copy the servers.

Is there any automated way to sync production and disaster recovery servers? From what I google. Manual LAR import seems to be the only option, and LAR import is somewhat a manual approach.

This is not the Disaster Recovery Technique that you're looking for: LAR imports are for content, and would involve a lot of manual labor if you have multiple sites. Plus, they don't include the user database and detailed permission configuration (e.g. custom roles) outside of content realm.
However: Restoring your environment is just the classic backup/restore operation: In order to recover to a disaster recovery server, you first need a proper backup, and then procedures how to access it and make use of it. Especially for Disaster Recovery, I'd just go with the classic Code/Database/DocumentLibrary/SearchIndex backup and restore.
In preparation of Disaster Recovery, you should test if you can use "what you call your backup" to restore to a completely new server. And the disaster recovery server would be a good target. IMHO you may only name a "backup" a Backup, if you have recently demonstrated that you indeed are able to fully restore a fully functioning server from it.
The rest is automation and scripting. But as this very much depends on your server infrastructure (are the backup servers standing by? Which OS, database? Clusters? Application Servers? Other integrated backend systems?) there's not much that can be automated on the Liferay side. This is a function of your operations, or Devops, and can be implemented with whatever tool you are using. Containerization helps standardizing on certain paths to install new software instead of manual edits of files - but it's not a silver bullet and not required.
The level of automation depends on the time it takes to restore your backup and the acceptable downtime. Some organizations restore immediately, so that they only need to launch their backup servers. Some implement clusters, so that part of the infrastructure can go down (note: This is not a recovery strategy: it doesn't protect you from all failure scenarios and you should still have backup procedures in place). Some have hot-standby servers and just switch their loadbalancers to the new servers in case of a disaster. Which of these strategies is for you depends on your usecase.