Postgres Pro
Downloads
Home   >   mailing lists

Thread: Restoration query

Restoration query

From
Wasim Devale
Date:
Hi All,

After restoring data it shows 
data is 250 GB whereas production database has 352GB of data from where we took the backup.

Why this discrepancy? I have not run full vaccum on production database but it has been cleaned by vaccum and reindexing.

Please advise.

Thanks,
Wasim

Re: Restoration query

From
"David G. Johnston"
Date:
On Saturday, July 27, 2024, Wasim Devale <wasimd60@gmail.com> wrote:

After restoring data it shows 
data is 250 GB whereas production database has 352GB of data from where we took the backup.

Why this discrepancy? I have not run full vaccum on production database but it has been cleaned by vaccum and reindexing.


 Table and index bloat isn’t saved in a logical backup.

David J.

Re: Restoration query

From
Wasim Devale
Date:

It's a .dmp custom format dump from Azure pipeline and it is of 250GB only.

I ran reindexing and vacuum but not full vacuum. So there cannot be an index or table bloating.

On Sun, 28 Jul, 2024, 12:05 am David G. Johnston, <david.g.johnston@gmail.com> wrote:
On Saturday, July 27, 2024, Wasim Devale <wasimd60@gmail.com> wrote:

After restoring data it shows 
data is 250 GB whereas production database has 352GB of data from where we took the backup.

Why this discrepancy? I have not run full vaccum on production database but it has been cleaned by vaccum and reindexing.


 Table and index bloat isn’t saved in a logical backup.

David J.

Re: Restoration query

From
"David G. Johnston"
Date:
On Saturday, July 27, 2024, Wasim Devale <wasimd60@gmail.com> wrote:

It's a .dmp custom format dump from Azure pipeline and it is of 250GB only.

I ran reindexing and vacuum but not full vacuum. So there cannot be an index or table bloating.


If you didn’t run vacuum full there is most definitely table bloating.  Which, in this definition, is any space taken up in the data files that isn’t storing live data.

David J. 

Re: Restoration query

From
Wasim Devale
Date:

So the live data is not getting restored? Did not get you. I have checked the same data has been transferred to the tables rows match.

On Sun, 28 Jul, 2024, 9:39 am David G. Johnston, <david.g.johnston@gmail.com> wrote:
On Saturday, July 27, 2024, Wasim Devale <wasimd60@gmail.com> wrote:

It's a .dmp custom format dump from Azure pipeline and it is of 250GB only.

I ran reindexing and vacuum but not full vacuum. So there cannot be an index or table bloating.


If you didn’t run vacuum full there is most definitely table bloating.  Which, in this definition, is any space taken up in the data files that isn’t storing live data.

David J. 

Re: Restoration query

From
"David G. Johnston"
Date:
On Saturday, July 27, 2024, Wasim Devale <wasimd60@gmail.com> wrote:

So the live data is not getting restored? Did not get you. I have checked the same data has been transferred to the tables rows match.


If you aren’t comparing vacuum full tables in the source database why do you expect the sizes to match?

David J.

Re: Restoration query

From
Wasim Devale
Date:

I found some unusual it is not related to vaccum it is related to metadata stored in a table.

That table has only 1 lakh rows but it shows 97 GB of size anything you know about this?

On Sun, 28 Jul, 2024, 10:31 am David G. Johnston, <david.g.johnston@gmail.com> wrote:
On Saturday, July 27, 2024, Wasim Devale <wasimd60@gmail.com> wrote:

So the live data is not getting restored? Did not get you. I have checked the same data has been transferred to the tables rows match.


If you aren’t comparing vacuum full tables in the source database why do you expect the sizes to match?

David J.