I am not too clear on the assumption part. Do you mean all updates on the remote server as of a point in time should be reflected in the local (refreshed) server? Or that a process is updating both outside the refresh process?
If this is a pure Disaster Recovery purpose, you can look into things like Log Shipping (if you have SQL 2000 Enterprise edition), database mirroring (SQL 2005 SP1 only), or a third party hardware or software replication solution. If this is a reporting/snapshot solution, most of the third party replication schemes may not work for you, since the replicated copy will likely have to be offline.
Logshipping may make the transaction log backups (and more importantly restores) of the remote system a little difficult, so you will need to have a test system to play with. One of the downsides of logshipping is you will get the entire database, and all changes, which it sounds like you do not need.
Snapshot Replication is probably out, due to the size of the database you are looking at (if you are building cubes from it, it must be big).
Transactional Replication can give you either scheduled, or (near) continuous updates on the subscriber system. You can have the distribution job halted during the cube build.
Third party replication schemes (hardware or software) would work in this scenario. You would have to cut the replication and fire up the database, before the cube build, but that can probably be scripted easily enough.
If you have no control over the remote server, the transactional replication of key tables will probably be the easiest politcally.