# Restore fails due to disk space on migration because of 70M calendar events

**URL:** https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584
**Category:** Support
**Tags:** events
**Created:** [9 februari 2026 om 19:36 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584 "2026-02-09T19:36:22Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12 februari 2026 om 14:20 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/7 "2026-02-12T14:20:30Z")

</div>

Using `du` and `df` I watched the size of postgres\_data as it grew from 25g to 90g and the space on the disk go to (near) zero before it failed.

I guess i need to find a way to track what query is running the next time.

I’ve seen it on at least two sites. One with an upgrade and one on a restore. Both had more free space than the size of the database to start.

---

_[View the full topic](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584)._
