Akeeba Backup for Joomla!

Monday, 21 September 2020 23:22 CDT

careytech

I am rebuilding a site afresh while the old site is being used and users are being added. When I do transition the site to use the newly rebuilt version, I will want to transfer all users from the old to the new. My approach is creating a backup of just the user-related tables (users, usergroups, viewlevels and the four other #__user_xxx tables).

I tested this transfer, and so far all seems to be working as expected. However, when I installed, the imported tables retained their previous prefix. I had declared to use the new prefix, and I tried "Drop Tables." I was able to use MyPhpAdmin to change the prefix to complete the work. But I suspect I should not have to do this. So I have two questions...

[1] If I am restoring an archive of just some tables, what settings should I make so that the new tables replace the ones already there?

[2] Do you see a fallacy in my approach - to copy select tables into a new install as a way to import users? Do you have a recommended alternative solution/approach?

Tuesday, 22 September 2020 03:24 CDT

tampe125

Hello,

Long story short: I believe what you're trying to achieve is not possible. Not because of Akeeba Backup, but because of the way Joomla implemented its own ACL system.

First of all let's start with the database prefix: when you restore your archive with ANGIE, in the database step, it will ask you the database you'd wish to use. If you change it, ANGIE will use the prefix you just put instead of the old one. In order for ANGIE to replace the tables that already exist, you have to chose the Drop option.

Regarding the partial database restore. You could do that, if (and only if) you are not dealing with users, so that's not your case. This happens because Joomla will store a reference to all users in the #__assets table, the table where all ACL permissions are located. On top of that, any item that has ACL capabilities (articles, menu items, categories etc etc) will have a reference to such table. If it gets corrupted, your whole site will be corrupted and recovering it is a real pain in the back.

My suggestion is to create a backup and work on it locally, to test all the changes you're going to make. Once you're confident of the changes you've made, manually apply them again on the new site, this time without the fear of breaking things because you already know what to expect.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Friday, 23 October 2020 01:17 CDT

System Task

system

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Edited by on 2020-10-23 01:17 CDT

Support