Akeeba Backup for Joomla!

Saturday, 04 June 2011 03:53 CDT

user39177

3.3.a3

When running a backup from the CLI and overriding variables when I look through the Joomla backend they are showing as obsolete and no file names listed. I thought it may be due to the backup directory being outside the web sites root folder; though if I set it to the same through the GUI and run a back up it shows up fine.

Edited by user39177 on 2011-06-06 03:29 CDT

Saturday, 04 June 2011 04:02 CDT

nicholas

If you are overriding the output directory or if the output directory does not allow file listings (its permissions are less than 0755) then this is normal.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 04 June 2011 04:08 CDT

user39177

Hmmm, though they are both writing to the same place

-rwxr-xr-x 1 root                 root                 26484890 Jun  4 09:46 201106040946.jpa
-rw-rw-rw- 1 somesite.co.uk somesite.co.uk  1971673 Jun  4 10:00 akeeba.backend.log
-rw-rw-rw- 1 root                 root                  2391136 Jun  4 09:46 akeeba.cli.log
-rwxr-xr-x 1 somesite.co.uk somesite.co.uk 18713350 Jun  4 09:47 site-www.somesite.co.uk-20110604-084741.jpa

The root owned jpa was performed from the CLI and the other via the admin interface. The later shows correctly in the GUI; so permissions must be okay. What is slightly disconcerting as-well is the difference in size of the JPAs between the CLI and GUI backups ?

Edited by user39177 on 2011-06-04 04:10 CDT

Saturday, 04 June 2011 04:14 CDT

nicholas

Can you ZIP and attache the log file from the CLI backup, please?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 04 June 2011 04:42 CDT

user39177

Attached file.

Saturday, 04 June 2011 05:25 CDT

nicholas

Look at the ownership of the file. It's owned by root. Look at the ownership of the back-end backup file (which incidentally is the user under which PHP -therefore Akeeba Backup as well- runs). It's owned by somesite.co.uk. So, PHP can not list files owned by root and Akeeba Backup is tricked into believing that the file isn't there, therefore reports the file as obsolete.

You can set up your CRON job so that it runs under the same user as your site (use su somesite.co.uk -c "your_cron_command_line_here"). This would work around this issue.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 04 June 2011 05:40 CDT

user39177

Of course it can list the files as the perms are 755; with everbody having read/execute.

Saturday, 04 June 2011 05:42 CDT

user39177

Oh, and if that were the case I would not be able to use the Discover and Import Archives facility which does allow me to import that JPA owned as root.

Will look at the database table later to see what is different between the two entries.

Edited by user39177 on 2011-06-04 05:42 CDT

Saturday, 04 June 2011 06:00 CDT

nicholas

Edit the jos_ak_stats table, find the backup entry which displays as obsolete, set the filesexist column to 1 and reload the Administer Backup Files page. Does it appear as obsolete now? When you try to download the archive from the back-end does it download?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 04 June 2011 09:16 CDT

user39177

Ah, its because it holds the absolute path in the database :(

|  8 | Command-line backup                          |         | 2011-06-04 08:46:31 | 2011-06-04 08:46:43 | complete | cli     | full |          1 | 201106040946.jpa                                  | /www/somesite.co.uk/backups/201106040946.jpa         |         0 | cli     |          0 | NULL            |   26484890 | 
|  9 | Backup taken on Saturday, 04 June 2011 08:47 |         | 2011-06-04 08:47:41 | 2011-06-04 08:47:56 | complete | backend | full |          1 | site-www.somesite.co.uk-20110604-084741.jpa | /backups/site-www.somesite.co.uk-20110604-084741.jpa |         0 | backend |          1 | NULL            |   18713350 |

Saturday, 04 June 2011 09:36 CDT

nicholas

Yes! That's why I asked if you had overridden the output directory. Akeeba Backup will look a. in the absolute path and b. for a file with the same name in the output directory defined in the profile which was used to take this backup. If it's not found in either of these locations, the filesexist column is set to 0, the entry is marked as obsolete and Akeeba Backup will never try to look for that file again. Does that make more sense now?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 04 June 2011 13:59 CDT

user39177

Then perhaps an enhancement to have both relative to the site and absolute. If running in a chrooted environment, and starting backups from the CLI, then the absolute will always be unavailable. From an enterprise perspective this would be a great feature; as it would allow the CRON kickoff and still enable the client to access their backups. Possible ?

Saturday, 04 June 2011 14:05 CDT

nicholas

I think you replied to your own question :) When running from a chroot jail, the filesystem root path is the chroot jail's path. When running from outside a chroot jail, the filesystem root path is the real /. So we are talking about what is conceptually two different filesystem structures, with different absolute paths to the same file, ergo the absolute path won't cut it.

That said, we do store the filename and do look for that filename in the configured output directory of the profile which was used to take the backup. As long as it's configured correctly (i.e. PHP code running in the web context can access it) Akeeba Backup will figure out that the file exists and not assign an obsolete status.

So, to recap:
- Your output directory must be accessible from PHP code running in the web context
- It must have 0755 permissions or greater
- The file must have 0644 permissions or greater

In your case, I think that the problem is in the output directory definition of that particular profile.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 06 June 2011 03:28 CDT

user39177

Aligning the profile definition resolved the issue. Thank you.

Monday, 06 June 2011 05:23 CDT

nicholas

Perfect! I was sure there was a logical explanation to that issue :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support