Timeline for Restore DB Backup with limited amount of disk space
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 19, 2019 at 8:32 | history | edited | John K. N. | CC BY-SA 4.0 |
answered questions; included restore example;
|
| Nov 18, 2019 at 15:46 | comment | added | John K. N. | @sepupic Yes, I'm still not denying that, but knowing your database has benefits. You can then make fact based assumptions. (ital. supposizione) | |
| Nov 18, 2019 at 15:39 | comment | added | sepupic | OP's database can have 1Tb log and 3Tb data file with only 60Gb of data inside. And it still requires 4Tb on disk, irrelevant to page copression | |
| Nov 18, 2019 at 15:15 | comment | added | John K. N. | @sepupic I never stated it couldn't be up to 4 TB size. I am writing this as an introduction into the specifics of database backups. I clearly show in my example that a 48 MB backup is 16 GB in size. I think your comment is irrelevant, unless you can state why it is relevant. If you know your database internally, then you can deduce how big you backup and/or restore might be. An already compressed backup cannot be reduced even further. However a non-compressed backup can be similar in size after a restore compared to a compressed backup. | |
| Nov 18, 2019 at 14:54 | comment | added | sepupic | >>>The database could be up to 300 GB in actual size<<< The database can be even 4Tb, you just cannot deduce it from backup size. >>>Does your database already contain compressed rows / pages?<<< This also is irrelevant. The only things that matters is the actula sizes of all db files | |
| Nov 18, 2019 at 14:27 | history | answered | John K. N. | CC BY-SA 4.0 |