Support

Akeeba Backup for Joomla!

#8766 Why can't I restore a backup from site A to site B?

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Tuesday, 11 January 2011 17:53 CST

user21415
Update: I was able to find the backup archives I was looking for by changing the backup and tmp directories of my dev site to the same directories as my live site in the profile configuration. Then I imported them into the dev site Akeeba and it's currently restoring, so it looks like that worked.

I'm not sure why when I tell Akeeba in the "Discover and Import" page what directory to find the archive in, it's not there.

---
Original Message
---

I have Akeeba Backup Pro 3.2.b3 on both sites below:

It's easy to restore a backup from within the same site. But, I always work on a development sandbox instead of my live site so I never mess up the live site, but no matter how many options it seems Akeeba offers to do so, it seems like it's always a massive headache to import a backup from Site A to Site B. Am I missing something?

So basically, it looks like this:

Site "A": JoomlaLiveSite.com = Live site

Site "B": JoomlaLiveSite.com/Sandbox = dev site

Both use different databases. I used to try and just copy the jba archive from the live site's backup folder to the dev site's backup folder, but they never appeared in the administer backup page. So, now that I have Akeeba Backup Pro 3.2.b3, I was encouraged to see the "Discover & Import" option. Unfortunately, it finds nothing when I point it to the backup directory on my live site, even though I can see very clearly in FTP that those backup archives are there, and it's the same server, and simply a parent directory of the Dev site.

Why am I having so much trouble?
Thanks for your time!
-Troy

unker
The backup archives from site A should be copied into the root folder of site B, then use "Kickstart" (kickstart.php and respective language file) to be placed in the same folder.
All the rest is self explanatory. That's the way I'm doing it, and it works fine.

Best Regards
Hartmut

nicholas
Akeeba Staff
Manager
The "Discover and Import" page allows you to select which directory to look in when trying to import files. In any case, that directory can not be the current site's root. You can use the Browse button to select the directory holding your backups. Do note that you have to go one level above your current site (since you're in a subdirectory of your main site) and then navigate to the backup directory of the live site. The thing is, if you point "Discover and Import" to the output directory of your subdomain it will, of course, find no files as there are no files in there.

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!

user21415
After figuring out today that most of my problems were self induced, I feel I need to explain myself a bit.

Don't get me wrong. I've been very impressed with the features and improvements that have been made in the past few months of this extension, and honestly, the extension itself. I can't think of any other extension that is more essential than this one.

However, even considering the issues on my end, Akeeba still seems to dangle the "golden carrot" of straight-forward directory-to-directory copying of archives. Ideally, the point of the "discover and import" feature should be to completely eliminate the need for the kickstart and moving any files around by FTP (within the same web server). Akeeba does such a stellar job at backing up files and databases, it should be easier to use those archives (Again, within the same web server. I have several sites that share the same disk space). I do think you guys are on the right track, though, given the vast progress made on this usability in such short time, I just need to be patient, and/or learn more.

So, that being said, most of my headache was self induced by my own ignorance in the following ways:

1. I was specifically trying to avoid downloading the archive files and re-uploading them to the proper site's backup directories via FTP because they were each about 4 GB in size and would have taken 4 hours to download on my 3 M bps connection, and then another 6 or so to upload to the other site, plus time for Akeeba to work at restoring. It didn't occur to me until today, that 4 GB is probably unusually large for my website. After looking at the files on the server realized that I had uploaded a 3.8Gb zip file sometime in the past, for someone to download, and did not remove it. Therefore, it was being included in the backup archive This would have been counter-intuitive to being able to Akeeba just being able to see a file that is on the same server as itself. I kept telling myself it would be faster to simply FTP download the entire Joomla installation and backup the database, and copy them over to the dev site manually, but that was only because I didn't realize that file was there.

2. Which brings me to the second glaring issue. My measly 3 M bps connection. Last night I upgraded my service to 24 M bps so, I shouldn't have a problem downloading/uploading 4gig archives should I need to in the future, but I won't now that I realize I have to exclude the 3.8gig zip file from back-up.


Anyway, thanks all for your time and patience, and work on this great extension!

nicholas
Akeeba Staff
Manager
You are using the wrong feature for the wrong job. It's like trying to paint your house using a toothbrush. What you are trying to do is to have Site B pull the backup from Site A in order to restore it back to Site B. That's inverse thinking. Worry not! Akeeba Backup gives you not just one but four(!) different power tools to accomplish what you want MUCH more easily.

Here's the generic (still not the easiest) procedure to backup Site A and restore to Site B:
1. Backup Site A using Akeeba Backup
2. Go to Administer Backup Files
3. Select the backup you want to restore
4. Click on Restore
5. Select "Upload by FTP" instead of writing directly to files
6. Fill in Site B's FTP connection details. IMPORTANT! The directory makes all the difference in the world. Select the directory where you want your files to be restored to. Akeeba Backup won't ask you twice and will overwrite existing files.
7. Start the restoration! It extracts the backup archives to the target directory.
8. Without closing this window, visit the http://www.SiteB.com/installation/index.php URL in a new window/tab on your browser.
9. Complete the restoration. IMPORTANT! You MUST change the database connection information to match Site B.
10. Close the restoration window when it tells you it's done and return to the other tab I told you to leave open.
11. Click on "Finalize restoration".

There are also three even easier alternatives:
a. Use the DirectFTP archiver engine to "push" all files (including the restoration script and your database dump) to Site B without producing a backup archive.
b. Use the "Upload to remote FTP server" post-processing engine to automatically "push" the backup archives from Site A to Site B's root upon taking a backup. All you have to do is upload Kickstart to Site B to... well... kick-start the restoration procedure ;)
c. If Site B is a subdirectory/subdomain of Site A and you have direct access to its files from Site A, there's no need to mess with FTP at all. Just go to Akeeba Backup's Configuration page and use the Browse button next to the Output Directory to browse to Site B's root. This will effectively put Site A's backups to Site B's root. Again, all you have to do is to upload kickstart.php (a measly 180Kb which uploads in 3 seconds flat) to Site B's root and restore the site like a breeze.

You might wonder why you are given so many choices. There are many reasons, the most important being that one solution doesn't cut it for everybody or, even, for every use case. I try to cater for all tastes and all use cases. You guys inspire me with the different ways you use or would like to use Akeeba Backup. I think that one of those choices will be the best for you :)

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 Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!