A DBA manages an 8 TB transactional database with a recovery time objective of four hours. A colleague proposes replacing the nightly physical backups with nightly logical dumps because the dump files are portable. How should the DBA evaluate the proposal?
Select an answer to reveal the explanation.
Short Explanation
Restoring a big logical dump is like rebuilding a house from blueprints; restoring a physical backup is like moving the finished house. At 8 TB with a four-hour clock, you want the house. Dumps are handy for portability, just not as your main lifeline here.
Full Explanation
Physical and logical backups serve different purposes. A physical backup copies the database's data pages and files, so restoring it is largely a bulk copy back to disk, followed by log replay where applicable; restore time scales mainly with storage throughput. A logical dump stores statements or row data that must be re-executed, which means inserting every row, rebuilding every index and revalidating constraints. For a multi-terabyte database, that reload commonly runs far longer than a physical restore, so relying on dumps would put the four-hour recovery time objective at serious risk. Physical backups therefore remain the primary recovery method, while logical dumps are useful for migrations, copying individual objects and moving data across versions. The claim that dumps restore faster at any size reverses the usual relationship at scale. The claim that dumps include index pages is incorrect: a logical dump contains index definitions, not index structures, so indexes are rebuilt during load. Storage snapshots on the same array share the fate of that array; they are useful rollback points but not a backup strategy for site or array loss. Exam caveat: the right method depends on the stated objective, here restore time. Operational check: time a full physical restore and a dump reload on test hardware and compare both against the four-hour objective.