ahaveland

Try to find out through logs and records when and how they broke in, assuming they didn’t modify that information.

Make sure to reinstall wordpress and plugins from source, as the ones you have backed up may be modified.
Make sure that there are no extra php files that are unaccounted for.

Look for files or directories beginning with “.”
Look for alien or modified php code containing text like “eval(gzinflate”, which may reveal nasty backdoor scripts like c99shell.

If the site hosts many sites, and those sites are not in dedicated VMs, or isolated by suPHP, then backdoor programs can browse the code and databases for all sites on the server, in which case your clean site can just get infected again. The server itself may be compromised, so your system adminisitrator should also be notified.
They may have to reinstall the server too.

It may be that your password was sniffed somehow, or too simple, or similar to an account that you used registering on another site and their database got hacked.
Scan your personal machines, and other machines on your network.
Never use FTP for any service, try to always use a host that supports SSH/SFTP and a control panel that uses SSL.

As for emailing backups, that is probably only OK if mailing to a gmail account which you access over SSL, and if your server uses TLS to communicate with gmail.
What’s wrong with dumping to an SQL file and downloading it over SSL with phpmyadmin?

Even better, can you log in with SSH and create a secure tunnel to the remote database port on 3306 and interact with mysql directly?

Good luck!

Are you using the memcached plugin (wp-content/object-cache.php) by any chance?

I’m seeing a problem with logging in with it enabled, which I’m trying to debug. If I rename wp-content/object-cache.php to object-cache2.php temporarily then I can log in, do stuff and then have to rename it back afterwards.

I just came across this after an update – traced it to the memcache object cache plugin. The update does not clear its own cached objects.

I have numerous live sites on my server, so restarting memcached is not an option, as users would be forced to log in again.

I just changed the cache keys so that new objects would be cached under a different name – the old ones will expire or disappear at next kernel update when I reboot the servers.
Alternatively, just rename wp-content/object-cache.php temporarily to continue admin.

I have a suggestion for the author of wp-content/object-cache.php, DB_NAME needs adding to the key, otherwise the caches of users using “wp_” prefix on different databases will clash.