So are your services and admin URL the same? This is how the DR tool behaves during an import
1) Uses the PORTAL_ADMIN_URL to connect to the deployment you want to restore.
2) Determines that the "public" or front-facing URLs for the Portal and all federated Servers in the target deployment match the public URLs in the backup through the federation settings
3) Uses the admin URL in the federation settings to connect to the federated Servers to check the registered Data Stores as well as internal machine names for the Server machines
4) Finds the internal machine name for the Portal machines and runs a restore against the primary Portal machine after unregistering the standby
5) Runs a restore through the internal machine name for Server
At step 3, if your services and admin URL are the same, then it would resolve to the primary environment. You have three approaches:
1) Set up the web adaptor as described above
2) Use separate internal load balancers in each environment for the admin URLs
3) Restore the backup once there's a failure
In my opinion, they're in order of my recommendation, but I really wouldn't recommend 3 as you'd want the standby in a "warm" state. If you restore once there's a failure, then you're down for the amount of time required for the restore, which you've mentioned.
The first is ideal because you can connect to the deployment in your standby environment through the public URL to make sure all expected content and applications are accessible to mimic how your users will connect to it. If it works with the WA in place, it'll work if you need to failover, (after updating hosts files).