☁️ Duplicator: Backup and move sites

[Claus]

Before I do something wrong, let me just check. If I make a backup from my live site, can I then put that file in my local machine development site (that is identical to the live site but outdated) and have Duplicator update everything automatically?

[flydev]

Hi @Claus  

1 hour ago, Claus said:

Before I do something wrong

Don't worry, you SHOULD do it before doing something else 🙂  Duplicator will not alter anything, still.

---

Whether local or live, it's always recommended to make a copy to avoid any frustration. Duplicator will me a perfect copy of your live site and you will have possibility to either download the backup (package) from the admin page or manually from your FTP server. Inside the package you will have at hand your distant database backup and all distant files (based on the configuration -> see module's settings - using default settings is safe).

So if your goal is to update your local dev, then you must (as always) make a backup of it just in case. Once that's said proceed following theses steps:

1. make copy of your local dev 
2. create a backup on live site and download the package
3. update your local dev site - here you have two options as I don't know how your local setup work:
   • option 1 (manual):  extract the zip and import your database then adjust database settings in config.php file to use your local database server.
   • option 2 (auto)    : use the installer.php and follow the steps to import everything

Now, if you need to bring back modifications from the old dev (local) site to your new dev (based on fresh live site) then you have to do it manually. Using a diff tool make thing easier and faster. Using @bernhard migration is also a good option.

 

[Claus]

Okay, automatic option 2 sounds good (I have the whole show on Github so I’m good to go).
Just ran it – and was careful to fill in the database information from `config-dev.php` and it worked perfectly!

Very nice!

[flydev]

Glad to hear that 👍

[BigRed]

I am unable to restore a backed up site all of a sudden. I've done it many times, but this time it isn't working. After running the installer.php file, it goes through the motions, but it takes forever to extract, when it's finally done, I get a partial Step #3 page.

 

I can't do anything after that because there isn't any button or anything else to click. This hasn't happened in the past. Do you have any ideas on why this might be? Like I mentioned, the extraction takes forever, seemingly much longer than previously. It isn't a big archive (110 MB).

[BigRed]

1 hour ago, msavard said:

I am unable to restore a backed up site all of a sudden. I've done it many times, but this time it isn't working. After running the installer.php file, it goes through the motions, but it takes forever to extract, when it's finally done, I get a partial Step #3 page.

I can't do anything after that because there isn't any button or anything else to click. This hasn't happened in the past. Do you have any ideas on why this might be? Like I mentioned, the extraction takes forever, seemingly much longer than previously. It isn't a big archive (110 MB).

Sorry to answer my own question. I had to change the installer script and put 

set_time_limit(1200);

at the beginning. It was 300, then I changed it to 600 and that didn't work, so I tried 1200.

 

[HerTha]

Comrades:

Copied a site to a new server at all-inkl

All went very well so far, but when I start a backup using Duplicator, the script terminates after a minute or so.

The backup zip actually starts being written (with FTP, I can see how the file size increases) but stops at about 1GB (and file disappears).

The server is running PHP 8.1 and I have a .user.ini file in place to establish higher PHP limits already, like:

   max_execution_time = 600
   memory_limit = 1024M

Checked that it came into effect using phpinfo().

Anyone having a clue, what other limits could prevent the backup file from growing larger?

[dynweb]

all-inkl has restrictions concerning the execution of shell scripts: https://all-inkl.com/wichtig/anleitungen/skripte/sonstiges/per-skript/shellskripte-ausfuehren_304.html

I don't use Duplicator, so I know nothing about its inner workings, but the shell script restrictions at all-inkl are real (have been there).

[HerTha]

Thanks for the hint!

There is a recommendation not to exceed 5GB when running a PHP backup script:

https://all-inkl.com/wichtig/anleitungen/datensicherung/webspace/php-skript-zum-sichern-der-ftp-daten/einrichten_97.html

If that is valid, 2GB should not be a problem. Will check with all-inkl support to get this confirmed...

[dynweb]

When I encountered the problem, the limitation was execution time, not file size. Their helpful support can certainly tell you more.

[HerTha]

The process stops after 40 something seconds, don't think there is a limit already.

[HerTha]

I guess I found the trick:

Duplicator offers a setting "Flush ZIP after quantity of MBytes"

Tried setting "500" and voila, the backup finished successfully on that all-inkl server.

Happy New Year!

[flydev]

Glad you got it sorted out! Setting the “Flush ZIP after X MB” option often fixes issues like these on shared hosting environments. Congrats on the successful backup and thanks, happy new year too! 😅

[BigRed]

Problem that has been off and on for a while. 

When I click on the Backup Now button in the control panel it briefly shows the busy graphic, then it disappears and nothing happens. I've tried other browsers, clearing cache, etc. It works sometimes as I have several backups, but this time I can't get it to work.

Has anyone else had this problem? I do see an error in the console about the content needing to be served over a secure connection (https) which the link to kick off the backup process is not. Is this something that can be fixed? 

[flydev]

Hi @BigRed generally this happen on error - you should check the logs on the module and if there is nothing relevant then check PHP logs on hosting side to spot the issue. 

If you are on a shared hosting then try enabling what @HerTha lastly posted just above on 1st January.

[herr rilke]

@BigRed - same problem here. did you find a way to handle?

can't find anything in the logs, 
working on 1256 MB memory,
120 sek execution time,
set FLUSH to 500MB,
pw 3.0.240,
duplicator v1.5.4

 

[BigRed]

I was able to use http:// and the IP address, then everything worked as expected.

I was using https:// and the domain name before.

[herr rilke]

so did you call the backend via IP address?

as the installation is on a shared hosting box this is not working for my setting.

any other idea? did you manage to find a log file entry for the error @BigRed ?

[BigRed]

I just used the IP address as the URL and it worked. We have a pretty simple setup (no shared hosting, server is located on premises) so it was easy to do the IP thing. I didn't find any log entry that reported the problem though.

[BigRed]

I'm having another issue with duplicator. When I try and restore a backed up site, the files are unzipped and it looks like everything will work, then I get a page saying:

The file containing the MySQL database couldn't be found.

All the files from the backup are there. It extracted the files. I've never encountered this before. Does anyone know how to fix this?

 

[dab]

On 3/17/2025 at 9:06 PM, BigRed said:

Problem that has been off and on for a while. 

When I click on the Backup Now button in the control panel it briefly shows the busy graphic, then it disappears and nothing happens. I've tried other browsers, clearing cache, etc. It works sometimes as I have several backups, but this time I can't get it to work.

Has anyone else had this problem? I do see an error in the console about the content needing to be served over a secure connection (https) which the link to kick off the backup process is not. Is this something that can be fixed? 

@BigRed I experienced this & in my case I pinned it down to the $config->httpHosts = array('xxxxxxxxxxx'); in config.php not matching the sub-domain I has hosting the new site on. Sorry if I've stated the obvious & e.g. adding www. when it wasn't required. 

Edited October 7 by dab

[herr rilke]

@dab thank you so much for sharing!

That actually solved my problem! Because 

$config->httpHosts = array('domain.com'); 

didn't work, but

$config->httpHosts = array('domain.com', 'www.domain.com'); 

did!

[BigRed]

I don't know if this would be helpful to anyone but it saved me a lot of work so I thought I would share it.

When using Duplicator on Windows (I don't think this is a problem on another platform), the installer.php script would always hang on unzipping the files and never make it to the uploading the database stage. No matter what I changed in terms of time out or memory allocation or anything, it still would never full extract everything, and what it did extract was VERY slow.

What I ended up doing in replacing the code where it extracts the files with a native tar extract.  Starting at the $zip = new ZipArchive(); text (about line 731), I replaced the code down to the closed brace (about line 750)  with this:

$zip = new ZipArchive();
    $res = $zip->open($this->package);
    if ($res == true) {
      if (is_writable($path)){
        // ---- START: system tar extraction (replacement) ----

        $archive = escapeshellarg($this->package);
        $dest    = escapeshellarg($path);

        // Laragon ships with bsdtar, which can extract zip files
        $cmd = "tar -xf $archive -C $dest";

        exec($cmd, $output, $code);

        if ($code !== 0) {
            $this->err("An error occured while extracting the package.");
            return false;
        }
}
      else {
        $zip->close();
        $this->err("The temp folder $path is not writable. Please adjust the permissions and try again.");
        $this->btn("Check Again", 2, 'refresh', false, true);
        return false;
      }
      if ($zip) $zip->close();
      $this->ok("The package has been extracted.");
    } else {
      $this->err("An error occured! Duplicator couldn't open {$this->package}.");
    }

Once I did that, the extract took 10 seconds max for many hundreds of files, whereas before I would be waiting for many minutes only to have it abort.

I did get the code from ChatGPT so if it doesn't look quite right, blame it, but it does work. 🙂

I know I could refactor this a bit to remove the $zip variables that aren't really doing anything now, but I didn't feel like redoing more parts of the script, and it doesn't hurt anything.

I hope it helps someone. Maybe a real programmer could clean it up and put it in the options when generating the installer.php file?