# Backups are duplicating and not respecting number to keep on disk
**URL:** https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427
**Category:** Self-hosting
**Created:** [1월 24, 2019, 3:30오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427 "2019-01-24T15:30:54Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2월 6, 2019, 11:08오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/42 "2019-02-06T23:08:45Z")
This is somewhat hard to untangle… search for directories called `optimized` and `_optimized` get the size of those directories.
```plaintext
/shared/uploads# find | grep optimized$
./default/optimized
./default/_optimized
./tombstone/default/optimized
./tombstone/default/_optimized
```
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2월 6, 2019, 11:12오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/43 "2019-02-06T23:12:30Z")
> [@Wingtip](#):
>
> Under the optimized uploads directory, 1X is 100MB, 2X is 4.2GB, and 3X is 9.4GB.
So there you go, you would save 13 or so gigs per backup if we did not back that data up (data that can be re-generated on demand)
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 7, 2019, 2:45오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/44 "2019-02-07T02:45:00Z")
Sure:
```
root@forum:/var/discourse/shared/standalone/uploads# find | grep optimized$
./tombstone/default/optimized
./default/optimized
root@forum:/var/discourse/shared/standalone/uploads# du -sh ./tombstone/default/optimized; du -sh ./default/optimized
4.5G ./tombstone/default/optimized
14G ./default/optimized
```
And yes, saving that 13GB would be lovely!
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 7, 2019, 6:27오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/45 "2019-02-07T18:27:43Z")
Backup appears to be running right now, I have a gzip process started at 13:24 ET.
`sam 30180 88.2 0.0 13232 2000 ? RN 13:24 0:07 gzip -5 /var/www/discourse/public/backups/default/quarter-to-three-forums-2019-02-07-181213-v20190130013015.tar`
Again I must stress that our backups are currently scheduled for 6:30AM UTC, which is 1:30AM ET. And yet, they’re running at 13:24 ET, which is 18:24 UTC.
Why? Wish I knew, really do wish I knew.
Had to kill it to fix notifications again.
From the log mailed to me. Backup started at 18:12. Why? Good question.
```plaintext
[2019-02-07 18:12:14] [STARTED]
[2019-02-07 18:12:14] 'system' has started the backup!
[2019-02-07 18:12:14] Marking backup as running...
```
---
### Author:  [@clay](https://meta.discourse.org/u/clay)
#### Post date: [2월 7, 2019, 6:39오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/46 "2019-02-07T18:39:52Z")
Any possibility that Discourse is grabbing the timestamp from inside the Docker container and it’s wrong there?
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 7, 2019, 6:46오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/47 "2019-02-07T18:46:12Z")
No.
root@forum-app:/var/www/discourse/public/backups/default# date
Thu Feb 7 18:45:59 UTC 2019
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 8, 2019, 4:23오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/48 "2019-02-08T04:23:37Z")
Hmm let’s see. From my instance on colocation, which has the default of `3:30` ..
`coding-horror-discussion-2019-02-06-033852-v20190130013015.tar.gz`
`coding-horror-discussion-2019-01-24-033540-v20190110201340.tar.gz`
`coding-horror-discussion-2019-01-17-033114-v20190110201340.tar.gz`
I am reading those times encoded in the filename as
`03:38:52`
`03:35:40`
`03:31:14 `
Seems correct to me? I guess those are the times the backup finished, since it started around 3:30.
Are you _absolutely 100% sure_ that the underlying operating system has UTC as the default timezone?
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 8, 2019, 4:36오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/49 "2019-02-08T04:36:06Z")
Yes, the backup I had to kill had started at 181213, 18:12:13 UTC, 6:12PM UTC, 1:12PM ET.
The host OS is in ET, not UTC. I mentioned that earlier in the thread. The docker container is in UTC, and it does have the correct time set (in UTC).
Does the host OS need to be in UTC for discourse? The install guides don’t say anything about that.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 8, 2019, 4:36오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/50 "2019-02-08T04:36:49Z")
What kind of animal uses a server where the default time zone isn’t UTC?
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 8, 2019, 4:38오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/51 "2019-02-08T04:38:18Z")
I always use ET so I don’t have to worry about converting timezones in my head.
If Discourse needs the host OS to be in UTC, that really should be in the install guide.
And when scheduling backups in the UI, it specifies “in UTC”.
And the docker container is set to UTC and its time is correct so I’m not sure why the host OS tz would matter in the first place. The whole thing runs inside the container, how would it even know?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 8, 2019, 6:24오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/52 "2019-02-08T06:24:57Z")
My guess is you’ll need to offset that backup time. It’s just plain _weird_ to have a server OS think of time in anything other than UTC, as God intended.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 8, 2019, 3:57오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/53 "2019-02-08T15:57:45Z")
OK, will make note of when the next backup runs and offset it. I do suggest you add it to the install guide.
Keep in mind that backups were scheduled for early morning UTC and yet they ran in early _afternoon_ ET. But UTC is 5 hours ahead. So it isn’t a simple offset that can be calculated beforehand.
Why does taking a backup break notifications for the duration? And it seemed like backups never ended before, they just kept restarting. I’ll take closer note of what happens when/if backups fail next.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 10, 2019, 4:52오전 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/54 "2019-02-10T04:52:15Z")
> [@codinghorror](#):
>
> If this double-compression step _can’t_ be avoided, the compression level should be set to “almost none” so it can go as fast as possible.
Any updates on this @gerhard? I’d really like to skip the double compression step because it is a) painful and b) pointless.
@wingtip we’re going to add the “skip retina thumbnail images in backups” setting soon, which should help. p.s. switch your server to UTC already, this is like sysadmin 101 stuff man.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 10, 2019, 5:01오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/55 "2019-02-10T17:01:31Z")
That would be helpful, thanks.
I work in IT, and putting servers in UTC is not a standard or even best practice across the industry. It’s just your app that has a problem, if indeed that is the problem. If it is, I’ll make the change of course.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [2월 10, 2019, 5:16오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/56 "2019-02-10T17:16:41Z")
> [@Wingtip](#):
>
> I work in IT, and putting servers in UTC is not a standard or even best practice across the industry.
Absolutely untrue. I’ve managed online environments globally for around 20 years and UTC has been a must from the outset.
The only places I’ve seen local timezones set are tinpot organisations who deal with customers in their region and can’t think beyond their immediate locality.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 10, 2019, 5:19오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/57 "2019-02-10T17:19:38Z")
I’ll just leave this here
> **[Yeller - The Worst Server Setup Mistake You Can Make](http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html)**
> Nearly every mature engineering organization runs all their servers on UTC, and you should too.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [2월 10, 2019, 5:22오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/58 "2019-02-10T17:22:07Z")
Exactly, why would you run a server on a local timezone if you have a global audience. Even for basic support any user reports would mean working with the difference between two timezones, rather than their UTC offset.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 10, 2019, 5:25오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/59 "2019-02-10T17:25:10Z")
Many of our global fortune 100 customers don’t use UTC. But lets not derail the topic.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 10, 2019, 5:33오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/63 "2019-02-10T17:33:45Z")
Well, you’re the one complaining that you don’t like random dates and times on your server. If you want predictable dates and times on your server, _use UTC_.
Otherwise your backup time can be affected by daylight savings, and so on.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [2월 10, 2019, 5:36오후 UTC](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427/64 "2019-02-10T17:36:27Z")
Absolutely, if that is causing our problem I’ll make the change and reboot the host to be sure. And not to beat a dead 🐎, but it should be in the install docs!
[이전 페이지](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427.md?page=2)
[다음 페이지](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427.md?page=4)