Where has the option gone to upload a archive from local computer
The same place it has been since August 2015. Components. Akeeba Backup. Import Archives.
Previously it was called Discover and you'd have to look
very hard to find it in what is now called the Manage Backups page.
Al I have now is browse the server path or upload from amazon.
This is Import from S3 which, as the name states, imports archives from Amazon S3. This is the button to the right of Import Archives in the Control Panel page. It's a different feature with a different purpose. Again, this used to be nigh impossible to find from its inception in 2010 to August 2015 when a button for it was placed in the Control Panel page. Previously you'd have to go to Administer Backup Archives, find the Discover toolbar button, then find the Import from S3 toolbar button. Yeah, not quite user friendly.
No option to browse a local drive.
This has very literally
NEVER been the case. I have been explaining that to all of three users who asked about it the last 8 years we have an import feature in Akeeba Backup but I don't mind explaining it again.
Backup archives tend to be huge, in the order of hundreds MB big to several GB big. Your servers have an upload limit which is typically in the 1-20 MB big. PHP itself also has an indirect limit for uploaded data which is the maximum POST size, also in the same area. Even a small backup of a stock Joomla! installation which is around 15 MB would fail to upload. Instead of having endless discussions with users who say that uploading should be possible but who do NOT change their server settings (or change them to even
lower values) we simply do not offer an upload feature. Having had the experience of an upload feature in Akeeba Release System and seeing how people didn't want to consider the technical limitations even when I explained them I am adamant that my choice is the only
sane one. Also why nobody else who makes backup software running on the web server that serves the site to be restored does not have an upload feature.
What the Import Archives (formerly Discover and Import and earlier called simply DIscover) feature does is look into a directory on your server (default: your output directory)
and compare its contents with what is already known to Akeeba Backup in Manage Backups. Any backup archives which are not already listed in the Manage Backups list (stored in the database - that page does NOT look in the filesystem, otherwise it couldn't work with remotely stored files or show you failed backup attempts for example) are listed and can be imported as Manage Backup entries.
Why offer such a feature? You restore an older backup of your site. Your Manage Backups is based on the database content which is now reset to an earlier version (when that backup you restored was originally taken). As a result any backups taken after that point in time and which are still on your server are not listed. You want to restore one of them? How do you do it if you can't upload Kickstart? By using Import Archives and then going to Manage Backups to restore your imported backup.
The new user interfaces are getting worse and dumbing down in my opinion.
Of course you would be right... if only we had not changed
ONLY the colors and removed the rounded corners. Seriously. What we kept is the same is
all (and I stress:
ALL) of the features, in the same place, on the same pages. The last time we made any change to the structure of the software was August 2015 when we merely rearranged and renamed some of the icons on the Control Panel page to put most commonly used items (according to user testing) in front of you and removing the ambiguity of some labels. For example, the Import Archives feature was called "Discover" and it was only accessible through a button in the Manage Backups page (which had the unwieldy title "Administer Archives").
I don't know why you think anything was dumbed down. I challenge you to download a 5.1 and a 4.7 version, install them, and compare them to version 6. You will see that
everything is in the same place. I don't like removing features. I can tell you off the top of my head which features I have removed from Akeeba Backup (Lazy Backup, Restore Points and Exclude Components) and I can give you the technical reasons why these features made marginal sense when they were implemented but could no longer work properly since Joomla! 1.7. Once we dropped support for these old versions of Joomla! these features were removed since they didn't quite work on newer Joomla! versions anyway.
Same for your support forum. Tickets are ok but this sort of question belongs in a public forum
We have not had a
forum, where multiple users can reply to the same thread, since June 2011. That's seven years ago. I had explained why back then but I can repeat myself if that's what you want. What would typically happen is that Alice would start a thread on Issue X, then Bob would jump in saying "I have the same problem, but in fact it's a completely unrelated issue Y", I would start juggling replies to two unrelated issues of two unrelated people and then Charlie would jump in to say that he has the same problem... with a different software of a different developer that actually has nothing to do with anything. In short, it was havoc. It was impossible to locate an answer or even determining if there
was an answer. Which is why in 2011 I stopped free support, moved to a ticket system and in 2012 I hired more support staff. I want to make things easier
for you, my clients.
As to whether this ticket should be private or public, this a choice
you made when filing the ticket. Our ticket system -which, by the way, has not changed a bit since its introduction in late 2011- gives you the option to file a private or a public ticket. Go ahead and try to file a new ticket. See the public / private switch when you fill in the title and other information, above the main content area?
I agree with you that most questions asked here should be public and other users can benefit from them. That's why our ticket system had Public as the default selected option. Unfortunately, the European Union voted into law the General Data Protection Regulation (GDPR) which stipulates "privacy by default". Starting May 25th, 2018 it is
illegal to have Public as the default option when we can also offer Private tickets. At this point we had to make a choice: discontinue private tickets or set the default ticket type to public. Discontinuing private tickets is impossible because it's also impossible to offer support by email unless it's encrypted (PGP or S/MIME) per the same law and we both understand just how damn near impossible it is to get two
security minded parties to set up a PGP email conversation, let alone our average user who is stressed and probably has no idea what PGP is. So the only viable choice is having private tickets by default. However we still give you the option to switch to a Public ticket. In fact, if you want, I can make this ticket public. Just give me your explicit consent and I will do it.
I tried uploading an archive via ftp and scan for files does not show archive. The path is correct.
Did you use the same name as an
existing backup archive which is already listed in Manage Backups? That's why it wouldn't show up.
If not, double check the path. Remember that you need to enter the
absolute path, not the relative path. This means that on a Linux server it would be something like /home/myuser/public_html/here/are/my/backups instead of here/are/my/backups or /here/are/my/backups (assuming that your site's web root is in /home/myuser/public_html and your backups are stored in the subdirectory here/are/my/backups inside it).
This on our staging server and I am trying to import a database from the live system. This was always very simple.
Kindly note that the import only works on JPA, JPS and ZIP files. It does NOT work on .sql files. This has always been the case except a
very brief period between 2010 and 2011 when we had an integrated restoration script for SQL files. This was very unsafe and suffered from a myriad performance and usability issues, so it was promptly axed. If you are trying to import a .sql file you should use phpMyAdmin, Adminer or any other MySQL management script you prefer.
Also note that if you take a backup of the type "All configured databases" then you do get a JPA, JPS or ZIP file which does include an installer.
Finally I'd like to point out that importing an archive you took on a different server, uploading it by FTP, in order to restore it is a very roundabout and non recommended way. Just upload the JPA, JPS or ZIP archive set and Kickstart, then use Kickstart to perform the restoration. After all, the Restore button in the Manage Backups page does nothing more than run a private copy of Kickstart to restore the backup archive. Again this has always been the case, since 2008 in fact when I first wrote Kickstart one fine evening sitting in my kitchen.
