Support

Please watch Restoring a Site on Any Server

If you want to use the integrated restoration it's more complicated. You need to upload the backup archive file(s), you do NOT need to copy the log file (the log file is not used for anything, it's just for us to help you troubleshoot).

Then you need to go to Components, Akeeba Backup, Import Archives. Browse to the directory where you uploaded your backup archive file(s) and click on Scan for Files. If there are any backup archive files Akeeba Backup doesn't know about yet it will show you the files.

Note: if you have a multipart archive (e.g. it has several files with the same base name and extensions .jpa, .j01, .j02 and so on) only the last archive part file with the extension .jpa, .jps or .zip will show up on this page. This is normal. Akeeba Backup imports all of the archive parts without bothering you with the minutiae of doing so.

Select the files you want to import and click on Import the files. Now you will see that as the latest backup archive in the Manage Backups page.

Ah! Now I understand the use case.

Actually, you should use Kickstart. You just don't need to download the backup archive and then upload it back again, which is what was wasting your time 😉

When you run Kickstart its first option is the Archive Directory. Right now it points to your subdomain's root folder. We can have it point to your main domain's backup archive folder.

Let's say that your subdomain's root is /home/foobar/subdomain and your live site's root is /home/foobar/public_html. Let's also say that you are using the default backup output directory (administrator/components/com_akeeba/backup) for your live site. Edit the Archive Directory to read /home/foobar/public_html/administrator/components/com_akeeba/backup and click on the Reload button next to it. You will now see the backup archives from your live site. You can select the backup archive you want and restore it; it will be restored in the directory kickstart.php lives in, i.e. your subdomain.

If you are unsure please tell me what is the backup output directory you are using in your live site's Akeeba Backup configuration and what is the Archive Directory displayed by Kickstart when you run it in your subdomain. I can help you figure out the Archive Directory you need to use.

After the archive is extracted and you're into the site restoration please remember to change the database connection information. You must use the database connection settings for your subdomain.

> I shall start kickstart.php (after renaming it, as I know), and can change the directory information for the backup to the live site backup

Correct.

> But my main problem is, that kickstart seem not to delete the directory and the subdirectories before.

Also correct. But! We have a solution for that.

> What really cost a lot of time is to delete via SSH the directory before installing the new backup version. 

Agreed, this is very slow. That's why I will suggest an alternative.

Delete the subdomain's files from your web host's control panel. There should be a file manager there which is at least two orders of magnitude faster than deleting the files over FTP / SFTP.

> I hope you can follow my unperfect English ;-)

Your English is just fine! I can understand you perfectly. I am not grading grammar and punctuation, I am more interested in reading something I can understand so thank you for putting the effort into making it possible, it is very much appreciated!

There is an alternative method BUT it requires having access to your dev site. If you break your dev site you will have to fall back to the previous method. It is also more steps. That said, there is a method so here we go.

1. On your dev site go to Components, Akeeba Backup, Options, Back-end and set ‘Show the “Delete everything before extraction” option’ to Yes. Click on Save & Close.
2. Go to Components, Akeeba Backup, Import Archives.
3. Use the Browse button to find the backup output directory of your live site.
4. Click on Scan for Files.
5. Select the backup you want to import (you only see the .jpa, .zip, or .jps file — this is OK, the entire backup will be imported!) and click on “Import the Files”.
6. Go to Components, Akeeba Backup, Manage backups. You now have a backup entry for the imported backup. Select it and click on Restore.
7. Set the ‘Delete everything before extraction’ option to Yes.
8. If you need to change any other settings do it now.
9. Click on Start Restoration.

> What would happen, if I rename the live site backup in the same way a test site backup that has been made, and restore it? Would that make troubles with the database?

It wouldn't work :) It's not about the file name. Akeeba Backup stores the backups it knows about in the database. You need to go through Import Archives to create the database record for the backup archive of the live site.

Also note that BOTH alternatives I gave you — using Kickstart or using Import Archives — DO NOT copy the backup archive. The backup archive stays in place on the live site. This means that it DOES NOT take up extra space on your site and you don't need to delete files to make space for it. That's the point of these features. They allow you to operate on a backup archive stored outside your site without copying or moving the file itself. 

Setting up a CRON job requires a few things I don't know but your host does:

• Do they offer real CRON jobs with CLI scripts or just pseudo-CRON where they access a URL on a schedule?
  • In the latter case only you'd need to know the maximum timeout for that URL, whether it supports redirections and your Joomla version to tell you what to do next: legacy frontend backup URL, Joomla 4 scheduled tasks or look for a third party service such as mySites.guru or Watchful.li
• Do they have an interface to set up CRON jobs or do we need to connect to the server by SSH and run crontab -e ourselves?
• What is the path to the PHP CLI executable for PHP 7.4 or a later version?
• What is the path to your site's root? Well, this is communicated to you by Akeeba Backup, Schedule Automatic Backups so you don't necessarily need to ask your host.
• What is your timezone and what is the server's timezone? For example, if your server is in London (GMT+0) and you are in Wien (GMT+1) your midnight is 23:00 for the server, therefore the backup should be set to run for 23:00 GMT. Likewise, if your server is in the East Coast of the USA (GMT-5) your midnight would be 18:00 in the server time zone.

Usually you can show your host the output of the Schedule Automatic Backups page, the section about CLI backups and they can help you set it up.