Why my backup is an old version of my site?


I had a problem with my user account on windows 10, so i had to create one new and i’ve deleted the old folder account.

After some hours… I managed to reinstall my website with my old Local Sites folder.

But all my work since the 01-31 was lose, i’ve seen my sql files was dated from 01-31 but i worked a lot on the site after this date…

So why the date of my SQL files are from 01-31 if i worked until the 02-16 on my website ?
Some data are located in another folder ?
I’ve lose definitly my old appdata files, so I hope any important data was in this folder …

Sorry for my English and thanks for your support

Did you ever get answers to this problem? I’m going through this problem right now and freaking out!


Sorry but after I’ve found any solutions for this problem :confused:
I had to redo all the changes from the last version of my website.

Exact same issue here - this is the second time I’ve encountered this with two different websites.

It’s really frustrating and confusing. I’m looking at changes I know were updated 6+ months ago.

In one case I was looking at a website that has since had a full refresh (theme, layouts, content all updated) 2 separate times over a year apart.

Would love to know why this is happening and how to prevent.

Trying to recover the raw/active SQL data is going to be pretty tricky. The files that you see in the app/sql are not going to guarantee you the most recent copy of the database. The only way to ensure that you have the database is to use Local’s Export function (right-clicking on a site and select Export).

Otherwise, using Adminer/SequelPro/other SQL utility connected to the live site is a legitimate option to get a current SQL backup of the site.

OK Got a solution and answer here after troubleshooting with the Local support team.

Flywheel local looks for SQL Files in a backup and imports them sequentially. If your site backup has another SQL file anywhere in the backup directories, this will replace the main Flywheel backup.

Both the sites here I’m looking at have used backup plugins at one stage like UpdraftPlus, BackupBuddy etc that actually save SQL backups.

To solve:

  1. Unzip the backup archive, look for any SQL files that aren’t the primary Flywheel SQL backup file.
  2. Delete these SQL files, re-zip the backup and add to Flywheel.
  3. Fixed - you should be looking at the right backup and not an older version of the site.

Here’s the full explanation from Local support, explains also why sequential loading is necessary.

After inspecting the log and the backup file that was sent over. What has happened is that Local searches an archive for all available SQL files and imports each one sequentially. Since Local is designed to be compatible with other archive systems that save each table in its own SQL file, this is a necessary process. In this case, it’s pretty clear that Local is finding an additional SQL file in the archive that shouldn’t be imported. Basically, Local finds both the backup.sql file from the archive, processes that one, and then finds an old database backup in the root folder of the site, called ‘EXTRA-SQL-FILE.sql’ and imports it. Since that file appears to be an old database backup, it has the same tables as the correct SQL file that was imported first but wiped out with the older tables due to the processing order.

If you unzip the backup and remove ‘EXTRA-SQL-FILE.sql’ from the /files/ directory, and then zip it back together, you should be able to drop it into Local again, with a proper import.

Hopefully this can help anyone who is experiencing the same issue!

1 Like