I am trying to backup a couple joomla instances via the admin console. The one instance I tried last week got stuck in maintenance mode but we were able to find reference to deleting the files to get the web site back.
Trying on an joomla instance that is not in production I downloaded joomla15-1.1.13.sh per a posting on the forums. If I run the backup download now it appears to do something but no file is prompted for download. Nothing is found in /storage/backup so not sure if it actually ran the backup.
I downloaded the latest joomla/jumpbox and had no problem with pressing the backup button and getting a file to download.
I am trying to migrate our joomla data to the latest joomla/jumpbox but having trouble getting a backup for the first time. I do not have an external storage location configured.
Any suggestions?
Bundled Application: Joomla 1.5 - License
JumpBox Version: 1.1.9 - License - Attributions
JumpBox Platform Version: 1.1-214
Joomla 1.5 Version: 1.5.10
Owner: JumpBox
Joomla Backup
If a script has an app name and version number in it, I strongly recommend against running it on a version that doesn't match.
Austin
I looked at the script and it
I looked at the script and it looked like it was setting permissions so didn't think it would hurt
I added in S3 data for
I added in S3 data for external storage hoping that would fix any configuration issues.
Clicking the Run Backup Now button I get the following error message.
Error: No such file or directory - /jumpbox/application_portal/backup/jb-joomla15-1.1.9-busby-0cd4b0c41fcd11deb5965f768b8ec5d2-20100125134122.gz or /jumpbox/application_portal/backup/jb-joomla15-1.1.9-busby-0cd4b0c41fcd11deb5965f768b8ec5d2-20100125134122.tgz
I verified that the backup directory is empty. I do have a new folder on Amazon S3.
Joomla Backup - S3
Was there anything in the directory in S3?
Austin
No the backup to S3 also
No the backup to S3 also fails because it can't find the file it is looking for.
File is getting created but is being deleted
Trying to track down the problem if I run sudo ruby /jumpbox/application_portal/privileged_scripts/ubuntu/app.rb generate_backup
and then at the same time look in the temp directory that is being created I see a bu.tar file is created and growing. When the command stops the file and the temp directory are deleted. So it looks like some sort of backup is occuring but the rename step is failing.
-rw-r--r-- 1 root root 2662400 Jan 25 17:16 bu.tar
admin@busby:/jumpbox/application_portal/backup$ sudo ls -l *
total 2644
-rw-r--r-- 1 root root 2703360 Jan 25 17:16 bu.tar
admin@busby:/jumpbox/application_portal/backup$ sudo ls -l *
total 14372
-rw-r--r-- 1 root root 14694400 Jan 25 17:16 bu.tar
admin@busby:/jumpbox/application_portal/backup$ sudo ls -l *
total 14492
-rw-r--r-- 1 root root 14817280 Jan 25 17:16 bu.tar
admin@busby:/jumpbox/application_portal/backup$ sudo ls -l *
total 15412
-rw-r--r-- 1 root root 15759360 Jan 25 17:16 bu.tar
admin@busby:/jumpbox/application_portal/backup$ sudo ls -l *
total 22020
-rw-r--r-- 1 root root 22517760 Jan 25 17:16 bu.tar
Following other forum
Following other forum postings I ran the following commands and get nothing in the backup directory!
admin@busby:/jumpbox/application_portal/backup$ sudo ruby /jumpbox/application_portal/privileged_scripts/ubuntu/app.rb start_backup_real
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
/usr/lib/ruby/1.8/open-uri.rb:32:in `initialize': No such file or directory - /jumpbox/application_portal/backup/jb-joomla15-1.1.9-busby-0cd4b0c41fcd11deb5965f768b8ec5d2-20100125135459.tgz (Errno::ENOENT)
from /usr/lib/ruby/1.8/open-uri.rb:32:in `open_uri_original_open'
from /usr/lib/ruby/1.8/open-uri.rb:32:in `open'
from /jumpbox/application_portal/privileged_scripts/ubuntu/lib/backup.rb:261:in `start_backup_real'
from /jumpbox/application_portal/privileged_scripts/ubuntu/lib/utils.rb:176:in `send'
from /jumpbox/application_portal/privileged_scripts/ubuntu/lib/utils.rb:176:in `execute_method'
from /jumpbox/application_portal/privileged_scripts/ubuntu/app.rb:91
admin@busby:/jumpbox/application_portal/backup$ ls
====Another forum suggestion=======
admin@busby:/jumpbox/application_portal/backup$ sudo ruby /jumpbox/application_portal/privileged_scripts/ubuntu/app.rb generate_backup
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
---
- /jumpbox/application_portal/public/appmaint.html
admin@busby:/jumpbox/application_portal/backup$
admin@busby:/jumpbox/application_portal/backup$ ls
admin@busby:/jumpbox/application_portal/backup$
Joomla Backup
Did you try using a different browser to do the direct download backup? There were some browser specific bugs that prevented the created backup file from being downloaded.
Austin
I will try that but from
I will try that but from watching the script run as root a temp directory gets created and single file is growing. At the end of the script the file and the temp directory are deleted and nothing remains in the backup directory.
It also appears that if you don't configure the mail relay that the mail logs fill up and crash the VM.
My goal at the moment is to migrate to the latest joomla/jumpbox instance and hopefully these problems go away.
Any suggestions on disabling the cleanup code for the backup so I can grab the file? I assume the file is valid but something is causing a problem in the rename/mv to the proper backup name.
Joomla Backup
The mail logs should be rotated weekly so you would have to generate a significant volume of email to fill the disks. Thats actually the first question at this point, what is the output of the "df -h" command?
Lets run a lower level backup command, run the following, it should result in a backup file in /var/data/backup/test.tgz:
It would be very strange if it doesn't output an error and it does not generate the backup file. Actually, I was surprised that your generate_backup did not work. The command "start_backup_real" would not work if you had not configured your JumpBox for NFS, SMB or S3 backup.
Austin
Austin I ran the command and
Austin
I ran the command and got the same results no backup and no error messages. The instance of joomla has minimal content added to it so should not be a space issue. From an earlier post when I do a watch ls -l on the temp directory that gets created I see a growing file so it is doing something. It appears the copy/rename may be an issue. As for the mail log it appears the problem is our IT group does not have an open mail relay and does not allow for mail to be sent from servers in the DMZ unless special permission is obtained. Joomla through its normal function of registering a user wants to send an email and it took a few crashes to figure this out. The mail logs grow very quickly for each email. To fix the problem I had to go into joomla and take away the directory that points to sendmail and the crashing stopped. On this server I had backup configured trying to get backup working so each night it would try and send an email that the backup failed. It took two days before the instance crashed from mail logs filling up disk. I can send you a section of the mail log to see how quickly it was creating messages. It wouldn't hurt to have a config option in the admin panel that doesn't not allow the sending of mail. Details below for running of script and df -H command.
admin@busby:~$ sudo /jumpbox/application_portal/privileged_scripts/ubuntu/app.rb run_backup_real /var/data/backup/test.tgz
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
---
- /jumpbox/application_portal/public/appmaint.html
admin@busby:~$ ls /var/data/backup/
admin@busby:~$
Output from df -h
admin@busby:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 965M 627M 290M 69% /
varrun 125M 176K 125M 1% /var/run
varlock 125M 0 125M 0% /var/lock
udev 125M 40K 125M 1% /dev
devshm 125M 0 125M 0% /dev/shm
/dev/sdb1 9.9G 235M 9.2G 3% /storage
Joomla Backup
Good suggestion on the mail. Are you being precise on your language and you really mean it was the mail logs that were filling the disk as opposed to the mail spools themselves?
Austin
Yes it was the mail log files
Yes it was the mail log files growing with a message every 10 seconds. I saw a total of 6 mail log files all the same size and all growing with the same message. It also had two syslog files growing with the same mail warning.
Jan 21 14:04:07 griffinlab postfix/postdrop[7469]: warning: mail_queue_enter: create file maildrop/1172.7469: No space left on device
Jan 21 14:04:17 griffinlab postfix/postdrop[7469]: warning: mail_queue_enter: create file maildrop/3926.7469: No space left on device
Jan 21 14:04:27 griffinlab postfix/postdrop[7469]: warning: mail_queue_enter: create file maildrop/6987.7469: No space left on device
Jan 21 14:04:37 griffinlab postfix/postdrop[7469]: warning: mail_queue_enter: create file maildrop/10029.7469: No space left on device
The files that were growing
The files that were growing and had mail in the name were located in the /var/log directory. This action was triggered probably by registering a user in joomla in a non-production instance by the admin who is putting together the content. So no activity to speak of.
Joomla Backup
Could you check the joomla database tables and see if they are OK ... see the "show table status" on this page:
http://wiki.jumpbox.com/doc/runtime/faq/mysql_maintenance
Austin
I tried safari and do not get
I tried safari and do not get prompted for the download. Does it help that we paid for a production license but are using a free toolbox. We would really like to get this figured out so we can migrate and go back to the day job.