Akeeba Backup for Joomla!

Friday, 14 October 2011 22:52 CDT

user41018

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the forum before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 1.7
PHP version: 5.2.17
MySQL version: 5.0.92-community-log
Host: InMotion
Akeeba Backup version: Professional 3.3.4

EXTREMELY IMPORTANT: None generated yet - restore not yet started

Description of my issue:
I am trying to run a test restore of my development website before going into production.
The development site is in /public_html/plcms
I want to use the site transfer wizard to make a copy in
/public_html/testpl
I set up a specific ftp account on my host server and tested it successfully with filezilla. But when I use the same settings in the site transfer wizard I always get the ftp/.. not configured error. I have also tried every variation I can think of, but I always get that error.
Please could you tell me what the correct settings are for the transfer I want.

Thanks

Jim

Saturday, 15 October 2011 00:12 CDT

dlb

Actually, Nicholas answered this question for another user earlier tonight. See the thread here.

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Saturday, 15 October 2011 07:36 CDT

user41018

In my message I said that I had searched for a solution and I had read Nicholas reply. But it did not help me to find a solution to my problem. I did the test with Filezilla, successfully, and used the settings in Filezilla to complete the entries in File Transfer Wizard. But I still get the error message.

Jim

Saturday, 15 October 2011 07:41 CDT

nicholas

Please send me a personal message with the following information:
A. For your SOURCE site (the one you want to transfer FROM):
1. URL to the administrator page
2. Super Administrator username/password
B. For the TARGET site (the one you want to transfer TO):
1. URL to the site, including any subdirectory (if you are restoring to a subdirectory)
2. FTP connection information (hostname, username, password)
I will take a look and tell you exactly what was going wrong.

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, 15 October 2011 08:59 CDT

user41018

I just posted a private message with a screen capture of the data you asked for.

Many thanks

Jim

Saturday, 15 October 2011 09:17 CDT

nicholas

Hi Jim,

You did not follow my instructions on the other thread, at least not in full. If you had followed my instructions to the letter you would have connected to the remote site by FTP using FileZilla and you would have seen that the directory you need to copy to the "FTP/FTPS/SFTP directory to the remote's site root" is / (just a forward slash) instead of /public_html/yoursubdirectory. And that's the only problem I could see in your Site Transfer Wizard setup - that's a good thing, most users usually come here with 2-3 errors on that page :)

No, you may wonder, why the directory is just a slash when I use a full path in my regular FTP connection? Because you have told Akeeba Backup to connect to your site with a different FTP user than the one you are normally using. How does this make any difference? Your "regular" FTP user is defined to "see" your hosting account's root directory (a.k.a. user directory) as the root. The extra users you define will "see" only a specific subdirectory as the root. Therefore, what your "regular" FTP user sees as /public_html/yoursubdirectory is what your new FTP user sees as /. And this exactly why I have put the FileZilla step in the instructions and ask you to copy and paste stuff. This fine distinction as to what is the FTP root eludes the vast majority of people and is the most common source of errors, accounting for over 95% of FTP-related Site Transfer Wizard and Kickstart issues - the other 5% being mostly firewall woes. That's why I posted those detailed step-by-step instructions on the other thread ;)

If you still get stuck on something, feel free to post back. We're here to help!

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, 15 October 2011 10:40 CDT

user41018

Very many thanks, indeed, for that clarification, Nicholas.

I think I gave too much importance to the presence of/public_html in that field.

It all makes much more sense now.

Thanks again

Jim

Saturday, 15 October 2011 11:19 CDT

user41018

The transfer went through with no problems.
Many thanks for the help.

But it raised an important question about the database.

When I run a test for the first time, my habit is to accept all the default options, in this case in the restoration process.

But I see now that this created a problem, because the new location (fortunately it's just a test :) ) shared the same database as the original site and I assume??? that any changes I make to the developement site will now show up also on the new test site?

So here are the questions:
1. Am I right in assuming that the correct process would have been to use a different database for the test site?
2. If I had specified a different database in the installation.php process, would it have been created or should I have previously created a database for the test site?

I'm still trying to make up my mind as to the best way to manage development and production websites and my next test is going to be to use the kickstart process.

Thanks

Jim

Saturday, 15 October 2011 13:33 CDT

dlb

Jim,

You are correct that those two site are now "Siamese twins" sharing the same database. With very few exceptions, Akeeba does not have sufficient rights to create a new database, only to restore data and create tables in an existing database. You would need to manually create the database and user before doing your restore.

It probably is not useful to have the test and development sites both pointed to the same database. Changes to the development site, such as installing new components, would also affect the test site.

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Saturday, 15 October 2011 14:46 CDT

nicholas

Hi Tim,

The default settings in Akeeba Backup Installer are designed to restore on the same site. If the domain name of the source and target site are different, it will warn you before you restore your site, as the database settings are probably not correct. This leaves a borderline case, though: restoring a site in a subdirectory of the old one. In this case, Akeeba Backup Installer can't be sure if you're restoring on the same or a different site and produces no warning. Well, you just have to be careful in those cases :)

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, 15 October 2011 14:55 CDT

user41018

Thanks for the confirmation, Nicholas, Dale.
This was only a test run, and the test folder deleted now. It was a very helpful learning experience.

Thanks

Jim

Saturday, 15 October 2011 15:08 CDT

nicholas

You're welcome :)

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