Common WP Backup Fails …. and How to Avoid Them

Everybody needs a WordPress backup. Most of us have a WordPress backup. However, when a WP backup fails it creates a sudden temporal paradox: you realize, that something valuable is broken – yet maybe you won’t need it. This dissolves its value. Your reason, that the last 6 successful backups are there, creates the illusion, that the 7th – the unsuccessful – is less important. And maybe you don’t need it today. What are the chances of something go wrong until the next WP backup runs?

Well, let’s remain in the same line of positive thinking and logic (and without jinxing things). You have a missing WordPress backup. Let’s investigate why this happened, so we can eliminate this bad karma cycle of WP Backup Fails.

1 – Cheap Hosting Account

Poor hosting server performance is the main culprit against your successful WP backups. Too many customers, on the same single physical server USE AND SHARE the same resources. Therefore, it is evenly distributed, with a rationing, that is not enough when a backup starts. When you use 50% of your resources, when you have the least customers visiting your site, then your hosting server is extremely underpowered. Running a backup – for that short period of time – creates a burst of resource consumption – doing file copying and archives.

If you run out of resources, the failure reason can wary (out of memory, process hung, never finished, was forcefully closed, remained unresponsive, etc). However, any of the reasons can be solved, by upgrading your hosting account to a better performing one.

2 – Outdated dependencies

Outdated dependencies on your hosting server also use up more resources. Resource consumption between smaller versions of the same dependencies (of PHP, for example), are huge in comparison (up to 40%). Consuming more resources can prevent the backup to successfully finish, because there are no more resources, that the backup can use to finish its task. Upgrading your hosting account, for this reason, it’s just a waste of money. Ask your provider to upgrade everything or hire a professional to do it for you. An hour of work can save your money by preventing an unnecessary upgrade, that doubles/triples your hosting invoice.

3 – Huge Database

Huge Database is always a problem. First affected is your website performance. Second is the backup process. How can you tell if your DB is suspiciously big and most importantly if it’s without reason? Well, there is no simple formula for this, but consider this approach:

• add 1MB for each 100 posts you have
• add 1MB for each 100 pages you have
• add 1MB for each plugin you have

When you add up your MB for your estimated DB size, using these exaggeratedly huge numbers and IT’S STILL SMALLER than your actual DB, then you have a problem. It’s time to consider some immediate spring cleaning. And this can be an urgent thing, because … most probably you will hit some server limit soon and won’t be able to do anything on your site.

4 – Security override

Security, even exhaustive security is ok. However, when it starts to interfere with normal, daily operation and affect long-term functionality, it’s time to reconsider. Statistically, the “Server Timeouts” are the number one culprit for failed backups. And with a huge percentage considering all other cases, also. Make sure, that whateverbackup solution or approach you implement it will be able to:

• access all the files and DB
• archive files into single, much smaller sized file
• successfully store the created archive in “your safe place”
• communicate with external cloud storage, to upload the archive
• delete older archives, as they are obsolete

5- Whale hunting

This is the case for big websites and huge databases (and mostly both of them, simultaneously). When dealing with this scenario, it is vital to approach it with a tailored solution. Under no circumstances use a standard “install and forget” solution. It will fail you when you need it the most. Methodologies differ from case to case – but always consider your resources and storage.

Work backward with requirements. Forget hourly backups if space is limited, or far away, or slow to transfer. Forget last x full backups when you are in a tight storage space. If traffic/ bandwidth/space is a problem, maybe you want to do first the archive, then transfer. If speed/time is the problem, then do the archive first, then transfer. If the backup process interferes with normal site usage, (even outside business hours), then clone and do there the backup. It’s less reliable though because you’re doing a backup of something else, then your live environment.

6 – Complex arhitecture

This is the case for websites built with several independent pieces. Like the main website is a WordPress, and the blog is another WordPress (maybe on a subdomain) and the e-commerce shop is another WordPress (maybe also on a subdomain) and so on. Do you’re planning on the individual pieces, when you hatch your master backup plan, but always consider the backup process from the other pieces.

Process orchestration is the key and a safe approach to successfully run several WP Backups. Make sure, no two backup processes run simultaneously. The pieces must fit together AND most importantly, recheck after time passes by if they still fit the same plan, as they individually grow. Fine tuning mostly is needed after a few months. Allow time to finish, then start the next.

7 – Hindsight revelation

This is the case for websites that modified anything in the hosting platform. Not necessarily migration, like changing the hosting company or even the hosting account. Just a simple account upgrade. These things mostly disturb the backup at a level, that renders it obsolete. It is needed to do a manual review, and delete everything and initiate a full setup again. Backup is a “better safe, then sorry” strategy; so should be the whole process too.