How often should you backup your website?

With the ease of creating a self-hosted website, and the good advice of backing it up, this still leaves the question of how often you should do this? And is there such a thing as too often, or not often enough?

In short, everyone should be backing up their website periodically. But, the frequency you choose to backup your website is different for every site. Some can handle (and need) a daily schedule, while others only once a week or month. (Also, by “backup” I mean you are archiving all files, including the database. If you don’t backup your database, you are doing it wrong.)

Who is this for?

This post is aimed at self-hosted websites for individuals, small businesses or other small to medium sized sites using shared web hosting from providers such as GoDaddy, HostGator, Bluehost, or others. Millions of websites fit this bill. If you are in charge of a major brand of household name status, you are likely using a CDN/Cloud from Amazon Web Services and a backup system is already in place. So, think self-hosted WordPress, Drupal or Joomla level websites for the purpose of this article.

How to decide frequency/schedule

Know that I am skipping over the part about how to install/setup a backup system on your website. There are way too many platforms (WordPress, Drupal, Joomla) to consider them all. Plus, some web hosts offer this for you. If you need help selecting and setting up one, please perform a Google Search for that since there are likely thousands of good posts on how to do it for your specific platform.

Math based

We will use some simple math to help estimate how often you should back it up. After you run through the list, we’ll talk about what the total means.

First, you will need to figure out how large your website is (usually in megabytes or gigabytes). For every 50MB of storage your site takes up, +1. So, a 50MB site is +1, a 75MB site is +1.5.

Second, you will need to think about how often your site gets updated. Only consider manual updates, such as adding/editing content on pages and posts, additional post comments, or other such conscious edits and additions to your site (a Twitter feed is not a manual update.) Daily is -7, every 3 days is -3, and once a week or month is -1.

Third relates to average DAILY traffic to your site, so, you need to check your site’s analytics for this. No guessing! Let’s break it down to:

  • 1-500 unique visitors is a +2
  • 500-1000 is +3
  • 1000-5000 is +4

The sum total of the three steps above should tell you how many days between backups. A total of zero or less is considered daily (or every other night, if you prefer.)

Example site #1: a 100MB site that gets updated daily (on average) and has 1,050 visitors a day should backup nightly (or every other night.) That’s 2 – 7 + 5 = 0.
Example site #2: a 500MB site that gets updated daily and has 4,000 visitors a day should backup every 7 days. That’s 10 – 7 + 4 = 7.

This math doesn’t make sense!

It’s not science, but an estimator to show you how updates, size and traffic should accounted in your schedule.

I know you are thinking that a site that gets updated daily should be backed up more often, but that is not the case in example #2. For one, the size is 500MB (half a gig!) and the traffic is at a good clip of 4,000 unique visitors daily, so when you initialize your backup your server will respond slower and your visitors will experience slower load times (sometimes ridiculously slow.) Do you know how long it takes to archive 500MB of data?* So, this is something you not only want to do every 7 days, but also do during off hours for your site. While 3am is usually off hours for many sites, you may want to check your analytics for what day and time has the least visitors historically.

In example #1, the daily schedule is ok since you have a lower visitor count and 100MB shouldn’t take too long to archive, even on GoDaddy’s slow shared servers. But still, you should be choosing a time that is during a period of fewest visitors.

And seriously, I don’t expect you to be doing backups manually every 7th or 11th day. You should have access to a good plugin/extension for your site that allows you to make a periodic and automatic backup schedule.

*Be careful with some cheaper web hosts. The last time I initiated a 500MB backup via a WordPress plugin, we crashed the whole server. It was a cheap, fly-by-night hosting company, so I’m not surprised. Then again, GoDaddy shared hosting servers aren’t all that speedy either and I’ve seen them choke on a 300MB website too.

What would Tristan do?

Most of mine are weekly, and I store the previous 5-7 backups. Done, easy, no math.

Store previous backups

Whatever you do, and however you do it, be sure to store the equivalent of about a month of backups. This way you have a good buffer between when your site had problems (i.e. got hacked) and when you found out about it. If you backup every night, but don’t store more than a day or two back, you have a very short runway to notice you have problems and be able to fix it with a backup. For many users it can take a month or longer to notice you got hacked or lost dozens of pages or whatever the problem is. By that token, if you backup and store 500MB of data every night for 30 days, you’re going to have issues with your web host.

No hard and fast rule

It is my belief that 90% of websites on a shared server do not need to backup every night. On the other hand, you do not want to go longer than a month between backups. The bigger the site, the crappier the web host, and the more visitors you are serving all mean you should be backing up less often so as to not overtax the server and show your visitors a slow-loading site.

And yes, some web hosts can backup your site nightly with little to no performance degradation. This is optimal, and you should seek them out and use them. But, in most cases a user-installed automated backup system is needed, and that is what I am addressing here.


Chris S.

Great article! Thanks for taking the time to share your tips!

What are your thoughts of using a service like to backup to a cloud solution like I guess the main consideration would be how much space is available on my cloud account.

When you remove the old backups that over a month old, do you manually remove them or have you developed a different system for that?

Tristan Denyer

I have never used Backup Box, but the idea is a great way to make a free backup plugin work like a paid version. Typically, free plugins leave your backups on your server for you to manage. Paid plugins/apps/services usually store the backups on your cloud account or theirs (hopefully with redundancies.) Storing backups away from your website is seen as a safer setup, much in the way a safe deposit box is vs storing a safe in your house.

Having an automated service like Backup Box that can connect my backup files via FTP to a cloud service is great, so long as the cost of the backup plugin + Backup Box + cloud service isn’t more than just going with an all-in-one backup plan like VaultPress, BackupBuddy, or SiteVault (I have no affiliation to any of these.)

Another bonus to a third-party backup service like VaultPress is that they scan your backup files “for potential threats or exploits” and alert you to any problems they found.

As for keeping backups, you should hold onto at least a month’s worth of backup, or better worded: be able to go back a month. This is because most people I know that have had problems didn’t know for about 3-4 weeks (or until Google blacklisted them.) It also depends on the size of your backups and how much you can store. If you backup file is 100MB and you have 5GB of storage available, then you can store about 50 backups. I still recommend a weekly or twice-a-week backup plan, unless your website is updating a lot of important data/content daily (which is uncommon.)

My backups are currently scheduled to happen at set periods, and only keeping enough to go back just over a month. So, it automatically deletes the oldest one. I like automation and schedules.


Leave a Reply

Your email address will not be published. Required fields are marked *