We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Backups not working.
Backups not working.
I have VestaCP running on one server fine. I just installed a new one, same OS, version, installer, config, but on this one the backups ran once and now no longer run.
In backup.log I get
In error.log I get
In the failure email I get
Where would defaults file be set, and why is it looking for /usr/local/vesta/conf/.mysql.localhost instead of /usr/local/vesta/conf/mysql.conf
In backup.log I get
Code: Select all
-- DB --
2017-12-01 07:00:03 admin_db1 (mysql)
sh: 0: getcwd() failed: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
sh: 0: getcwd() failed: No such file or directory
Error: dump admin_turkish failed
Code: Select all
2017-12-01 07:00:03 v-backup-user 'admin' 'yes' [Error 17]
Code: Select all
mysqldump: [ERROR] unknown variable 'defaults-file=/usr/local/vesta/conf/.mysql.localhost'
-
- Support team
- Posts: 1096
- Joined: Sat Sep 06, 2014 9:58 pm
- Contact:
- Os: Debian 8x
- Web: apache + nginx
Re: Backups not working.
check if you have enough disk space
Check Vesta logs in /var/log/vesta
Code: Select all
df -h
Re: Backups not working.
Yes, plenty of space. 20Gb free and a backup only takes 2Gb.
The backup worked once when I first installed, and then stopped working.
I did check the logs in /var/log/vesta and posted the relevant lines in my original post - see backup.log and error.log.
In other posts its been suggested that the environment is set wrong i.e. $VESTA and $PATH are not set up correctly. I've made sure the environment is the same as another machine where the backups are working.
The backup is fine up to the part where it starts dumping databases, and that's where it fails. Its unclear what Error 17 means, or whether that's generated from MYSQL or vesta. But it seems that it can't make the database connection because its not reading in $VESTA/conf/db.conf, but is looking at a file that doesn't exist instead. Where is that file referenced. If I can find that, I can probably fix it.
The backup worked once when I first installed, and then stopped working.
I did check the logs in /var/log/vesta and posted the relevant lines in my original post - see backup.log and error.log.
In other posts its been suggested that the environment is set wrong i.e. $VESTA and $PATH are not set up correctly. I've made sure the environment is the same as another machine where the backups are working.
The backup is fine up to the part where it starts dumping databases, and that's where it fails. Its unclear what Error 17 means, or whether that's generated from MYSQL or vesta. But it seems that it can't make the database connection because its not reading in $VESTA/conf/db.conf, but is looking at a file that doesn't exist instead. Where is that file referenced. If I can find that, I can probably fix it.
Re: Backups not working.
To my surprise there actually is a file at /usr/local/vesta/conf/.mysql.localhost ... I hadn't seen it before as its a dot file.
Anyway it contains the correct credentials, and they match the ones in mysql.conf
The format and contents of the file are the same as on a working server, and the file permissions are consistent.
So it seems that the problem isn't that the file doesn't exist, but just that mysqldump doesn't like the format of the command that's being thrown at it.
Well I seemed to have fixed it by downloading the latest copy of db.sh from Github and putting it in the func directory
https://raw.githubusercontent.com/sergh ... func/db.sh
I don't know what the problem was, but I have other stuff to fix this weekend, so I'm not dwelling on it now. But backups are now back (up).
Anyway it contains the correct credentials, and they match the ones in mysql.conf
The format and contents of the file are the same as on a working server, and the file permissions are consistent.
So it seems that the problem isn't that the file doesn't exist, but just that mysqldump doesn't like the format of the command that's being thrown at it.
Well I seemed to have fixed it by downloading the latest copy of db.sh from Github and putting it in the func directory
https://raw.githubusercontent.com/sergh ... func/db.sh
I don't know what the problem was, but I have other stuff to fix this weekend, so I'm not dwelling on it now. But backups are now back (up).