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.
This is a massive area - so expect this question to be closed in fairly short order but, off the top of my head (as a former DBA on yuge databases):

**Mart/Repository**

You can mitigate some risk if you have a separate database for updates and a separate database that everyone uses. Then it is just a case of copying the data from one DB to the other once various checks have taken place. Mart/repository is how it is sometimes described but you might have primary/secondary, master/slave etc.

**Source code**

For everything that can change, have a source code which relates to *how* the data was updated. How many of these you have varies from DB to DB but you might have one for each user, role, data feed, code module etc.

**Create/update date**

Something that can assist greatly when tracking where things have gone wrong is having a creation and update data for every row. Then you can see at a glance which rows have been updated.

**ETL**

If the database update takes part as part of a data factory, you may be able to restore a previous vintage from flat files.

**Backup**

Full backups do of course take lots of space but the usual scenario is for a full backup to happen at regular intervals (says, weekly) and partial ones on a more frequent basis (daily etc).

**Point in time recovery**

Depending on which RDBMS you are using, some support point in time recovery. This allows you to roll back to the time when a good state was known. This does however require a large amount of storage which increases for how far you want to go back.

**Audit**

Having audit tables will tell you who (or what) made an update to a row. This can give you a good starting point for investigation.

**History**

For some critical tables, a copy of the pertinent row is taken at the time of the update so the data can be restored if need be.

**Data validation**

Ensure basic validation checks are carried out on the data before it is stored - over and above basic data type checks.

**Referential integrity**

Referential integrity isn't a silver bullet but it can help ensure the data is well structured.