Question: A typical advice before any production deployments is backup the DB first. This way, if the new update has some issue that can lead to potential data loss or logical data corruption, then you still have a backup to compare and correct old records. 

However, this can work well till DB size is in few GBs. Once the DB size is huge, backups take a long time complete. What are some best practices that should be followed in such situations, so as to avoid logical data corruption because of logical issues in a code deployment?

Answer: 
At that point, you should be using a commercial grade DB system that supports [snapshots](https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-snapshots-sql-server) (Oracles calls it [Flashback](https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm#g1026131)) - that's exactly the kind of thing they are for.

Keep in mind that you need a backup concept anyway - having more data doesn't mean you drop backups because they become difficult, quite the opposite. You need some kind of continuous backup, e.g. based on replication with automatic failover.
Many times if we are doing a "one shot" update we take a back up of production and restore it to a test server. Then we create a suit of tests and run the one shot. We verify the data has changed via the tests and become comfortable the that update will succeed and modify the data in a way that we expect it to. This is called a dry or trial run. I recommend doing this. 

This gives everyone a good sense that the one shot will succeed. We cannot guarantee 100% because the data will be updated from the date of the trial run, but we boost confidence and success factors. This also gives a real idea of any issues that will occur since we are using a copy of production. Now if for some reason the update fails, we can always go to the back run prior to restore if needed, but we should have found and remediated any issues with the dry run.

If you can't take the entire database (if really large) try and export a smaller sample size and run the update (small dry run) against the actual data. I'd prefer the entire data set if possible to ensure the test is as complete as possible.