Manier om het zippen van back-ups uit te schakelen?

Ondersteuning
1

Is er een manier om het zippen van back-ups uit te schakelen?

Omdat ik weet dat ik uiteindelijk de grootte van mijn Digital Ocean-server zal moeten vergroten, maar aangezien dat de maandelijkse kosten in wezen verdubbelt, stel ik het zo lang mogelijk uit.

En na de laatste update (toen het overschakelde naar de nieuwe postgres), lijkt het erop dat ik het punt heb bereikt waarop mijn back-up kan worden gemaakt, maar vervolgens mislukt het zippen van de back-up. Ironisch.

Aangezien ik de back-up na het maken van de server kopieer en elders opsla, heeft de gzip geen echte waarde (iets langere overdrachtstijd) en kan ik deze zippen nadat ik deze van de server heb gehaald voor langdurige opslag. Bovendien zijn veel van de back-up de uploads, en de afbeeldingen en dergelijke zullen al gecomprimeerd zijn.

Maar momenteel, vanwege het gzip-proces, mislukt de volledige back-up.

Dus - is er een manier om gewoon te zeggen: niet de back-up zippen?

2

Heb je

./launcher cleanup

uitgevoerd
om de oude database te verwijderen?

Een andere optie is om block storage te gebruiken om ruimte toe te voegen.

3

See previous request/observation:

Reduce local disk space needs by not (redundantly) gzipping backups

2 likes
4

Wait, all that is needed is to add the --gzip flag to tar and it would avoid the issue altogether?

5

I had not, and that indeed gets back a nice chunk of space which will resolve my immediate problem.

Switching to using the --gzip option still seems a very good idea.

But at least I’ve put off doubling my monthly bill for another six months or more, so thanks.

6

Block storage is pretty cheap, I think. You could use it for just backups or also uploads. I think it might be a bit tricky to see that the block storage gets used for the temporary space used to build the backup.

7

Can I use block storage just for the backups? If so, that might be an option to extend the time until I have to double the server unless it first creates it locally and then copies it to S3 in which case that would not help at all.

8

Yes. It would be the same idea as I described for the uploads. The thing I can’t remember is where the temporary files get written. I think it may be in the backup logs. You’d just make sure that you have that directory mapped to the extra storage space in your app.yml

9

I think you’d do something like

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/dashboard/log/var-log
      guest: /var/log
  - volume:
      host: /bigExtraSpace/tmp
      guest: /shared/tmp
  - volume:
      host: /bigExtraSpace/backups
      guest: /shared/backups
2 likes
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.