backup problems?

[Tomse]

great, thanks for testing it

as you can see there's been some user additions too (manual backup)

[luca]

duh, can't find the manual backup option...

BTW in the tms_backup page i have three buttons, but only hte first one has a text in it (scheduler). the second gives the following error:

Code: Select all

7-Zip 4.58 beta Copyright (c) 1999-2008 Igor Pavlov 2008-05-05 p7zip Version 4.58 (locale=C,Utf16=off,HugeFiles=on,1 CPU) Scanning /home/sit/2011-06-27-14-02-sit-backup.sql: WARNING: No such file or directory Creating archive /home/sit/2011-06-27-14-02-sit-backup.7z WARNINGS for files: /home/sit/2011-06-27-14-02-sit-backup.sql : No such file or directory ---------------- WARNING: Cannot find 1 file Error: Can not open file /home/sit/2011-06-27-14-02-sit-backup.7z Permission denied System error: E_FAIL


which looks liek it tries to make a backup but fails?

the third one reports success and brings back to the previous page

Luca

[Tomse]

did download the i18n/ files too when upgrading. you might want to do that if you didn't.. else copy the en-GB.inc.php to your chosen default language i.e. de-DE.inc.php

Looks like you don't have permissions to write to /home/sit for the webserver user.
what do the messages from the debug log say ?

[luca]

i18n files solved the blanks... thanks.

debug output:

Code: Select all

DEBUG
CPU Time: 0.135 seconds

$paramarray[message] = tms_backup: The sqldump failed with errorlevel: 1
$paramarray[message] = tms_backup: Backup Successful


looks liek it can't run mysqldump.. while it can run it on shceduled jobs.. anywayu this would be the least of my problmes having a daily backup

Thanks for any input

[Tomse]

ok, it's pretty strange, as the manual backup is the same as the scheduled backup, except for: if you are running auto.php as root and now the webserver user.

when you check the 7z file from the scheduled backup, does it contain the SQL file ?

if you are running auto.php as root, it might cause problems with attachments

[luca]

sql file is there and readable.

auto.php is running from the sit user crontab...

[Tomse]

sit is not supposed to have a unix user, the crontab is recommended to be run as the same user as the webserver
this differs from dist to dist, default unixdists with the names are Fedora : apache, Ubuntu www-data, FreeBSD : www

When running the backup script from the interface, the permissions for working is the webuser (see above), and if you only have permissions on the destination folder for "sit" then you won't be able to write to the folder as e.g. www-data (for ubuntu)

there might be a *.sql file there, but the script only accepts the sql file made in the same instance, and if it cannot be created due to write permissions missing, then you won't get the file.


cheers

[luca]

ok thanks

(i think i can live without manual backups)

Luca