Archive doesn’t include all db files!

Hey @wpress2010,

Nothing should have changed except that the database.sql file should be in a folder named dup-installer, did you happen to see the file in that folder?

Thanks~

I just looked: there are four folders, none of which contain the
sql file:

assets
classes
ctrls
lib
views

The entire archive file is about 357MB – a big one, and it takes a long time to ftp to the site via Filezilla, but I have repeated this a few times, and Filezilla reports no errors.

When I start to build the Duplicator package, and look at the database (I don’t check ANY boxes, so nothing is being excluded…) it contains the exact number of tables as I can see via phpMyadmin in the originating site.

And yet, when the installer is done, and I try to login to the transferred site, I get a “Too many redirects” error, which is not exactly indicative of what’s going on. A look at the new site shows only 26 of the 46 existing db tables have been moved! They have data in them, but many crucial tables are missing.

As I said, Duplicator is one of my favorite plugs. I just can’t seem to fathom what’s going on here.

• This reply was modified 6 years ago by wpress2010.

Hey @wpress2010

If you want to submit a support ticket for this issue we can have a closer look at your setup. Please provide a link to this thread when submitting the ticket.

Thanks~

The initial problem apparently had to do with the time it took to upload via FTP (Filezilla). I went to a colleague’s office where he has high speed fibre, and we were able to both download the archive and installer files, and upload those two files to the correct empty folder on the new host site.

But, when I ran the installer, it brought up the first screen, which had me add the .zip suffix to the archive. I ran the installer again, and now it says:
The expected archive size should be around [339.98MB]. The actual size is currently [4KB].

I watched on the high speed fiber line as this archive (339.98Mb) uploaded to the site. It ran through the various folders, and took over a half hour. And yet, there is not much there! I am desperate at this point, as I have 1 more day to launch this site, no more.

I had the guy with the fibre line send me a copy via one of those FTP services, and it indeed contains 340Mb of data.

Any clue as to what is going on here? I am going to contact the web host as well.

Not really sure what is going on via the downloads. Duplicator doesn’t really control how fast the upload/download speed of the servers behave.

Yep. The archive is intact when it is sent, and FTP is FTP. I’ ve tried to FTP via both Filezilla and Fetch, same result each time. Looks like it works, no error logs, yet file does not reach its intended server space.

I sent myself a WeTransfer link to the files, and then forwarded THAT to the web host via email, as it is obviously something wrong with their system. After all, if both Mac-based and PC-based FTP attempts result in the same failure, and noting is amiss in the transfer logs of each program, on both super high speed and no so high speed lines, it pretty obvious that it’s the receiving system that’s mucking up the procedure.

At this point, I’m pretty crazed, all things considered…

The initial problem apparently had to do with the time it took to upload via FTP (Filezilla). I went to a colleague’s office where he has high speed fibre, and we were able to both download the archive and installer files, and upload those two files to the correct empty folder on the new host site.

But, when I ran the installer, it brought up the first screen, which had me add the .zip suffix to the archive. I ran the installer again, and now it says:
The expected archive size should be around [339.98MB]. The actual size is currently [4KB].

I watched on the high speed fiber line as this archive (339.98Mb) uploaded to the site. It ran through the various folders, and took over a half hour. And yet, there is not much there! I am desperate at this point, as I have 1 more day to launch this site, no more.

I had the guy with the fibre line send me a copy via one of those FTP services, and it indeed contains 340Mb of data.

The web host ftp’d the archive into the right folder for me. It isn’t recognized as ANY kind of archive, and I cannot unpack it, even if I give it a ZIP suffix.

Dead in the water, I’m afraid.

Hey @wpress2010,

You might try and do a two-part install if getting the files to the host is problematic.

? ? – https://snapcreek.com/duplicator/docs/quick-start#quick-060-q

Hope this helps~

It’s definitely that larger archive that’s the issue. I am uncertain as what to do next, but it better be quick….

There is also the DupArchive format (see settings > packages > archive engine), it may behavior slightly different than the zip one.

Hope that provides another route as well…

It’s a truly crazy world. First the lame host’s system wouldn’t allow to unzip the files automatically, well, beacuse their configuration is broken. I did it manually, which worked.

I ended up tracing all of my later problems to inconsistencies in WordPress MySQL database table settings. I had to manually transfer the relevant SQL tables, because somehow some of the SQL tables were using different CHARSET and COLLATE statements, which were incompatible with the new host’s, which I think was utf8.

Really oddly, though, the only SQL tables that imported without a hitch were ones left over from deleted plugs – the main WP install’s tables wouldn’t go because of the inconsistencies. I had to manually edit all 25 SQL tables, search and replace CHARSET and COLLATE STATEMENTS, no really big deal, but just ridiculous. If I wasn’t reasonably conversant with SQL, I’d be dead in the water….

On Step 2 of the installer under options, there are a few options that try to help with backward compatibility issues for older SQL servers. It doesn’t work in all instances but has helped some people.

Cheers~