Vesta: Fixing the backup script

Created on 22 Feb 2018 · 7Comments · Source: serghey-rodin/vesta

Operating System

Any OS that puts /tmp in memory (e.g. Debian 7, 8, 9)

VestaCP Version

0.9.8 rel 19

Installed Software

apache, nginx, mysql (But doesn't matter)

Steps to Reproduce

Run v-backup-user or v-restore-user on a user whose backup takes up more space than is available on /tmp

Related Issues/Forum Threads

https://forum.vestacp.com/viewtopic.php?f=17&t=15973

Other Notes

I'm generally fine with the idea of dropping files in /tmp temporarily while creating a backup. It's just a problem when you don't have enough memory to accommodate the size of the whole backup.

I suggested a solution (ish) on the forum, but it seems like I'd have to write here if something is to be done about it. As you can see in the thread, this is a huge issue for several people, and the only thing we can do to work around it is to directly modify the v-backup-user and v-restore-user scripts. Somehow VestaCP seemed to even update itself to this version, and patching files is not really any kind of solution if Vesta updates automatically (Which I would consider bad behaviour on a production server for anything except security patches).

Source

SteenSchutt

👍1

Most helpful comment

In the next release this problem will be fixed

anton-reutov on 23 Feb 2018

🎉3

All 7 comments

v-backup-user
on line 71 you can replace to this code

# Creating temporary directory
tmpdir=$(mktemp -p $BACKUP -d)

anton-reutov on 22 Feb 2018

the problem with the backup script is also that is just not deleting failing backups in /tmp, that is just causing a full run disk on some low space machines and is complete useless, i had many bad issues with the backup script, missing www. in front of domains stopped working the script and now after update it checked for nginx.ssl.conf, which was disabled on the domain, so it could not exists, but it just stopped doing it's job.

not reliable for me