Support

The name of your site, as used by Joomla and your current template.

The e-mail address your site's e-mails are sent from.

The sender name for the e-mails your site is sending.

Tip

Using a sender name containing the word “duck” is strongly inadvisable due to the potential transposition of the treacherously proximate keys D and F on the standard QWERTY layout, and the unfortunate fact that said transposition results in a distinctly non-anatine, and rather vulgar noun. The words “tuck”, “ruck”, and their derivative adjectives are also strongly discouraged due to a similar scatological potential.

Each Joomla installation has a secret key stored in configuration.php which controls the name of the site's session / login cookie, the form anti-CSRF token generation, and the encryption of core and third party data in the site's database.

When making a clone of a site into a different server, subdomain, domain, or subdirectory it's generally advised to generate a new secret. This prevents authentication bypass by users who know the secret of the old site, and can log into the old site as a privileged user (they could reuse a login cookie on the new site to impersonate the same user account on the new site). In these restoration cases, this option is enabled by default.

	Note
	BRS will automatically re-encrypt Joomla's Multi-factor Authentication configuration with the newly generated secret. It cannot, however, do that for third party extensions' data.

	Important
	If you know you have encrypted third party data you may want to disable generating a new secret even if you are creating a clone of the site into a different server, subdomain, domain, or subdirectory.

When restoring into the exact same site that was backed up it's generally advised to NOT generate a new secret, as it would invalidate encrypted data in the database. In this restoration case, this option is disabled by default.

This is an optional configuration parameter, which should be left blank on the vast majority of sites.

If your site doesn't seem to work properly – e.g. missing pictures, all links resulting in 404 errors, etc – you may want to fill in your site's URL, for example http://www.example.com (include the http:// part, but not a trailing slash or index.php!).

http:// vs https:// matters. If you are going to use your site over HTTPS (recommended!), or over both HTTP and HTTPS, your Live site URL must be EITHER blank OR start with https://. A Live site URL starting with http:// will cause your site to appear broken.

Subdomains matter. www.example.com is NOT the same example.com. If you cannot leave the Live site URL blank, use the fully qualified domain name which will be used by your site in your Live site URL

	Important
	Virtually every “my restored site is broken / I can see no images / the CSS has disappeared” issue we've seen ever since our backup software was created in 2006 has been solved by telling the user to redo the restoration, but blank out the Live site URL on this page.

This badly named option –we keep Joomla's incorrect terminology in its Global Configuration– controls what happens to your site in relation to HTTPS. There are three options:

Please note that server configuration –including server configuration files such as .htaccess, web.config, and nginx.conf– as well as first and third party extensions also have a say on that. It is possible that you use None or Administrator Only but your entire site is served over HTTPS because of a redirection in the .htaccess file, the HSTS header, or a third party plugin enforcing the redirection. Remember, BRS only sets the corresponding Joomla option in Joomla's configuration.php file; it does not control the outcome of that option, or what happens on your site!

Note

The None option is incredibly bad for security on a live site. Your login cookies can be stolen and spoofed, leading to a site takeover. It's only meant to be used on localhost. The Administrator Only option is a major pitfall. It effectively offers the same non-protection as the None option since Super Users can still log into the site's frontend (where no protection exists!), something which happens automatically when Joomla's Shared Sessions option is enabled. In fact, we'd call this option misleadingly dangerous because it may make you think you are protected as a backend, privileged user when you are actually not. Only the Entire Site option is safe for live sites, as long as you have a valid TLS (HTTPS) certificate installed. On most hosts it's absolutely free, thanks to Let's Encrypt.

For most sites this should be left blank; Joomla can work it out automatically. If you have a server which does not communicate the correct domain name for your site when setting cookies you can use this setting to specify the domain name for the session cookie. Including a period (.) in front of the domain (i.e. .example.com) will allow the cookie to be set across all subdomains of the specified domain name. Please note that using the wrong domain name in this setting will make it impossible to log into your site.

For most sites this should be left blank; Joomla can work it out automatically. If you have a server which does not communicate the correct URL path for your site's root when setting cookies you can use this setting to specify the URL path to your site's root for use with the session cookie. Please note that using the wrong oath in this setting will make it impossible to log into your site.

This setting controls whether your restored site should be indexed by search engines. You have the following options:

	Note
	Joomla's Robots option is merely a recommendation to search engines. Most search engines and crawlers follow the recommendation. Some crawlers, however, blatantly ignore it, e.g. some crawlers from “AI” companies. You may want to use a third party service, such as CloudFlare, to block these misbehaving crawlers.

Should Joomla be allowed to send email? It is recommended that you turn this off when restoring a copy of a production site to a development or staging server, thus avoiding the potential problem of having a development / staging site inadvertently send live emails to real clients.

Check this box to reset Joomla's session management options to their default settings. This is recommended when you are restoring your site to a different server or user account than the one it was backed up from.

Check this box to reset Joomla's cache management options to their default settings. This is recommended when you are restoring your site to a different server or user account than the one it was backed up from.

Click this button to populate the fields in the Directories fine-tuning area with the default paths used by Joomla. This is recommended whenever you are restoring your site to a new subdirectory, subdomain, domain, or server.

Leaves the .htaccess file as-is.

Replaces the .htaccess file with the default file contents provided by Joomla, renaming your existing file to htaccess.bak. BRS will try to download the latest version of this file from Joomla's GitHub repository. If this is not possible, it will fall back to a copy of the file included with BRS.

Remove the AddHandler / SetHandler lines from the file.

You may want to do that if you are transferring the file across different hosts, or even different servers within the same host.

The reason is that the the AddHandler / SetHandler lines which select which PHP version you were going to be using on your site are specific to the configuration of the server. Different servers may have different configurations. Leaving the wrong AddHandler / SetHandler lines from a previous / different server will cause an error in the new server.

Do note that if you select this option and after clicking Next you might get an error, or you may find that the Clean Up button at the end of the restoration no longer works. If this is the case please log into your hosting control panel and select a newer version of PHP.

This is the recommended option. BRS will transcribe the AddHandler / SetHandler lines from your current .htaccess to the final .htaccess file of your restored site.

The typical use of this feature is that you start by going to your hosting control panel and select a newer PHP version before extracting your backup. What happens in most cases is that your host modifies your .htaccess file with an AddHandler or SetHandler line which tells the server to use a newer PHP version.

When you extract your backup, your original site's .htaccess file will be extracted htaccess.bak. This is on purpose. The .htaccess file from your backup may contain different AddHandler/SetHandler lines which do not work with your current server, or no such lines which would make your new server use its default version of PHP, one which might not be compatible with the restoration script and/or the backed up site. By renaming the extracted file this issue is sidestepped.

This leaves us with the problem that once the backup is complete, the htaccess.bak file would be renamed back to .htaccess, therefore the problem with invalid lines causing a server error, or the wrong PHP version being used preventing you from accessing your site would remain. By enabling this option here you are telling BRS to transcribe the known-good AddHandler/SetHandler lines into the htaccess.bak file. Therefore, when it's renamed back to .htaccess at the end of the restoration clean-up your site will be running under the correct PHP version.

It is a bit confusing, but that's how server works. What you need to keep in mind is this:

Only appears on sites hosted on Microsoft IIS. Replaces the content of the web.config file on your site's root with the content of the stock web.config.txt that ships with Joomla. The old file is renamed to web.config.bak. BRS will try to download the latest version of this file from Joomla's GitHub repository. If this is not possible, it will fall back to a copy of the file included with BRS.

Shows you the absolute filesystem path to the site's root directory. Helps you construct the directories you need to enter below.

	Tip
	You can always use the Override tmp, log and cache paths button to automatically populate the Temporary and Log directory using the Site Root.

The absolute filesystem path where Joomla will store its temporary files. Temporary files are supposed to go away at any time, usually by the time Joomla returns the request results back to the web server. It must NOT be the site's root, or any other directory where permanent files are supposed to be stored (such as the components, media etc directories). The recommended Joomla setting is your Site Root plus /tmp.

The absolute filesystem path where Joomla will store its log files. It must NOT be the site's root, or any other directory where permanent files are supposed to be stored (such as the components, media etc directories). The recommended Joomla setting is your Site Root plus /administrator/logs.

Joomla! 5.1.0 or later only. The absolute filesystem path where Joomla will store its cache files. Cache files are very similar to temporary files, but they may remain on the server longer than the end of serving the request. The recommended setting is leaving it blank; this will make Joomla use the cache directories defined in its defines.php files, by default cache under your site's root for the frontend and administrator/cache for the site's backend. It only makes sense to enter a custom directory path here if you plan on using a directory outside the web root of your server.

Important

Since Joomla! 1.5.0 (which was released back in 2007) the cache directory is meant to be customisable and its contents NOT accessible over the web. However, some badly written extensions wrongly assume that it's web accessible, and that it's always the directory cache under your site's root. If you use a custom cache directory, especially one outside your site's root, your site may not work properly. Do not contact us about it; contact the developers of the misbehaving extensions and let them know that their software is using Joomla wrong, as per the security recommendations Joomla has made for the better part of the last two decades.

	Note
	Joomla will always store some files in the administrator/cache directory, e.g. the autoload_psr4.php which tells it how to load core and third party extensions installed on your site. As a result, you must never attempt to remove that directory altogether; your site will break.

Use the domain name to access your site's FTP server

Leave the default value (21) unless your host tells you otherwise. Do note that Joomla! only supports plain FTP. If your host tells you to use port 22 – which is used only by SFTP – it won't work.

The username and password to connect to your site's FTP server

The absolute FTP path to your site's root. The easiest way to find it is using FileZilla to connect to your site and navigate to your site's root, which is usually a directory named htdocs, httpdocs, http_docs, public_html or www. Look at the right hand pane, above the folder tree (Remote site text box). Copy it and paste it in the Directory box.