The Total Upkeep plugin lets you backup your WordPress website, schedule automatic backups and more. The questions below represent common backup questions that are answered with the use of the features in the Total Upkeep plugin.
Do I have a WordPress backup?
- The primary goal of making a WordPress backup is to provide yourself peace of mind by having a copy of your site that can easily be restored in case of disaster. These disasters can include your WordPress site failing, getting hacked or simply rolling back to a previous state for a number of reasons. In fact, if you do not have a backup, you should make it a priority to establish one immediately. Your backup regimen should begin when you are initially creating your website. If you do not have a backup already, we recommend running your first WordPress backup.
How Often should I Make a WordPress backup?
If you don’t have a backup, then you should immediately create one to protect your website. Once that has been done, you can use the Total Upkeep Plugin to schedule automatic backups.
It’s also a good idea to backup your site before you update WordPress, or any plugins and themes. Sometimes an upgrade to a plugin can break your site or make things look off, so it’s always a good idea to have a backup of your site before the update.
When should I make my backups?
- The frequency at which you take backups should correlate with the frequency that your site changes. If you have an informational site that only changes rarely, then it is safe to say you can limit backups and manually take them when you login to make changes. If you have a blog with a lot of membership activity, then you may want to look into scheduling daily backups.
Do I have the storage space to make backups?
- The storage space is often the main concern when making and scheduling backups, but there are also other factors that will affect your decision. You can use your hosting server interface to see the amount of hard drive space that you have used, and how much you have left. If your backups are staying on the server, then you need to make sure that you sufficient storage space.
Where should my backups be stored?
- Typically, you will want to store backups remotely, which means in a location other than the server where your website is stored. That way, if something happens to the server, then you have a backup in a safe location elsewhere to restore from. Total Upkeep provides options to store your backup copies on the web server, on your local computer, or a remote FTP/SFTP server. If you have Total Upkeep Premium , you can store a WordPress backup on Amazon S3 or automatically upload your backup to Google Drive (Premium only).
Will my backup affect my website?
- When you make backups, they use server resources such as memory, CPU processing time, and storage space. So, it is important to remember that making backups can impact the performance of your website when it is being processed. You should plan to have your backups made when you have the least amount of traffic.
What am I backing up?
- When you make a backup it typically should consist of all of your website files including the database files. If you have custom files outside of WordPress, then you may need to specify them in the Total Upkeep settings, using the Custom option. There are also times where you may want to backup only certain files. This may be due to limited hard drive space or limited time for the backup to occur. Total Upkeep allows for you to include or exclude backup files or database elements.
Don’t see your problem listed?
- Feel free to visit our Forums now, and ask your question. If you are a BoldGrid Premium user, you can also login to BoldGrid Central to submit a Support Request and we will get back to you as soon as possible.
Need hosting for your website?
- Our partners offer WordPress Hosting plans for websites large and small, complete with BoldGrid’s Website Builder.
- If you need to transfer your site, you can learn how to Migrate WordPress to another host.
SIGNUP FOR
BOLDGRID CENTRAL
200+ Design Templates + 1 Kick-ass SuperTheme
6 WordPress Plugins + 2 Essential Services
Everything you need to build and manage WordPress websites in one Central place.
Hugo says:
Hi! I’m reviewing documents to find the minimum PHP settings required for a full website migration. Could you help with these settings? Specifically, I’m looking for recommendations for parameters like memory_limit, max_execution_time, upload_max_filesize, and post_max_size.
Thanks in advance for your assistance!
Brandon says:
Hi Hugo, your web host would have the most accurate information on how to go about changing your settings and making sure you have enough resources to make the migration. Typically the recommended settings for an average sized website will vary.
Hugo says:
The Total Size of the website is about 4GB, in that caso could you give recommendations for the parameters that I need to configure in my website?
Brandon says:
Hi Hugo,
I just want you to keep in mind that these are only recommendations. For a website of about 4GB, here are the recommended PHP settings to ensure a smooth migration:
Key PHP Settings:
memory_limit:
Set this to at least 512M, but you can go up to 1024M (1G) if your hosting plan allows.
max_execution_time:
Set this to 300 seconds (5 minutes) or more to ensure the script doesn’t timeout during the migration.
upload_max_filesize:
Set this to 256M or higher, depending on the size of your largest backup file. For larger uploads, split the files into smaller chunks, if needed.
post_max_size:
This should match or exceed upload_max_filesize, so set it to at least 256M.
max_input_time:
Set this to 300 seconds or higher to allow enough time for processing uploads.
max_input_vars:
If your website uses many forms or complex themes, set this to at least 5000 to avoid issues with large amounts of input.
Database-Specific Recommendations:
Ensure your database server’s max_allowed_packet is set to 256M or higher, as this can affect the migration process.
Additional Notes:
If your hosting environment supports it, consider using a CLI tool to avoid PHP limitations altogether.
Hope this helps!
Stanislav says:
Not sure what is the benefit of this backup plugin, if automatic upload doesn’t happen (in my case with SFTP). Is it really backup or just archiving script?
Brandon says:
Hey Stanislav, if configured correctly your remote backup should fully upload to your chosen destination. You can review this guide on setting up FTP/SFTP storage locations and to inspect further you can also troubleshoot your failed backups to see if something went wrong in the archiving process.
The first thing you normally want to do is view your backup logs. You can find them in Total Upkeep > Tools > Logs. If you find any errors in the log please start a new forum topic and we will help you break the error messages down so that we can determine was going wrong.
Thanks Stanislav, we’re looking forward to assisting you further!
Eileen says:
I need to give a customer a copy of his website to take to another host. Can I use Total Upkeep backups for this? If so, where do I go to download the .zip file?
Many thanks,
Eileen
Brandon says:
Hi Eileen,
You can definitely transfer a website to a new web host using Total Upkeep. In order to do so you’ll need Total Upkeep installed and activated on both the “source site” and the “destination site” and follow the steps in this guide. A backup Zip can be downloaded from the “Backup Archives” section, Total Upkeep > Backup Archives > View Details, of your Total Upkeep dashboard in the WordPress Admin area but the best way to perform a migration is the “Magic Link” method that is explained in the guide.
I hope this helps! If you have any other questions for us please start a new forum topic and we will get to it as soon as we can.
Chris says:
A couple things I couldn’t find here:
* Does the backup to Amazon S3 on the premium product mean explicitly S3, or will it also work with S3 compatible storage (like Wasabi, for example)?
* Does Total Upkeep support WordPress Multisite?
Brandon says:
Hi Chris,
Thanks for reaching out, Amazon S3 backups are available with Total Upkeep premium and you do have the option to import other remote databases as well. As far as multi-site and Total Upkeep while the plugin isn’t rigorously tested with WordPress Multi-site it can be installed on the network and be used by the network super-admin, and it will back up the entire network, but not individual sites.
Andy says:
Now having an issue getting the successfully created backup (yay!) uploaded to Google drive. Google drive is checked and shows:
Google Drive ✓ Authorized | ✓ Configured (update)
However, a manual upload fails, and checking the google-drive-connect.log shows some errors thrown (log copied below).
Any thoughts on how to fix this one?
-Andy
[2021-04-03 00:01:49 UTC] Last error: Array
(
[type] => 2
[message] => Attempt to read property “slug” on array
[file] => /home/apierce/niade.com/wp-content/plugins/jetpack/class.jetpack-autoupdate.php
[line] => 81
)
[2021-04-03 00:01:49 UTC] PHP Version: 8.0.2
[2021-04-03 00:01:49 UTC] WordPress Version: 5.7
[2021-04-03 00:01:49 UTC] Total Upkeep version: 1.14.11
[2021-04-03 00:01:49 UTC] Boldgrid_Backup_Premium_Admin_Remote_Google_Drive::get_details Access token is valid.
[Redacted for length]
[2021-04-03 00:04:12 UTC] Boldgrid_Backup_Premium_Admin_Remote_Google_Drive_Archive::upload
[2021-04-03 00:06:18 UTC] Signal received: 15 {“signo”:15,”errno”:0,”code”:0}
[Redacted for length]
[2021-04-03 00:13:39 UTC] Boldgrid_Backup_Premium_Admin_Remote_Google_Drive::get_details Access token is valid.
Jesse says:
Hi Andy-
The important bit of this log is the line
Signal received: 15, which is equivalent to the Linux commandkill -15. This is a “clean” kill signal, which means the server has “politely” requested the process to exit. This probably means that some resource monitoring service on the server detected the upload and asked it to stop. You might be able to find more details from your hosting provider about why the server terminated the process. Since you’re using one of our Platinum WordPress Hosting partners, DreamHost, I recommend reaching out via a Premium Support Ticket so that our support team can coordinate with you and DreamHost together to try and troubleshoot further.Andy says:
Thanks Jesse. I submitted a Premium Support Ticket as you suggested. I did give it another go and got the same kill signal, so at least the issue is reproducible.
Reed says:
My backups keep on freezing partway through (at around 300MB out of 5GB). Why does this keep happening?
Jesse says:
Hello Reed,
We’ve seen this behavior on certain hosting accounts, particularly at DreamHost. Try following the instructions in this article on changing your Zip Compressor to see if that resolves the error for you.
Andy says:
Jesse,
I have the same problem (also with DreamHost). Total upkeep hasn’t worked since last year. I tried increasing the PHP memory today to 300 MB but that seems not the problem. On system zip compression the archive gets just over 70% of the way complete, then stops. It claims the backup is successful, but it can’t find the backup. Manually looking in the backups does find a backup, but there’s no database in the backup.
Logs copied below. (the log looks truncated, but it isn’t – it just stops)
-Andy
[2021-04-02 16:53:00 UTC] PHP Version: 8.0.2
[2021-04-02 16:53:00 UTC] WordPress Version: 5.7
[2021-04-02 16:53:00 UTC] Total Upkeep version: 1.14.11
[2021-04-02 16:53:00 UTC] Backup process initialized.
[2021-04-02 16:53:00 UTC] ——————————————————————————–
[2021-04-02 16:53:00 UTC] Starting dump of database…
[2021-04-02 16:53:00 UTC] Memory usage – limit / current / peak memory usage: 1073741824 / 25014680 (23.86 MB) / 25070328 (24 MB)
[2021-04-02 16:53:00 UTC] Database info: Array
[Redacted for length]
[2021-04-02 16:53:00 UTC] Dump of database complete! $status = 1
[2021-04-02 16:53:00 UTC] Memory usage – limit / current / peak memory usage: 1073741824 / 25019104 (23.86 MB) / 27611848 (26 MB)
[2021-04-02 16:53:00 UTC] ——————————————————————————–
[2021-04-02 16:53:06 UTC] Database dump file added to file list: /home/apierce/boldgrid_backup/aqua_egads_uk.20210402-165300.sql / 9600640 (9.16 MB)
[2021-04-02 16:53:06 UTC] Starting archiving of files. Chosen compressor: system_zip
[Redacted for length]
[2021-04-02 16:54:57 UTC] Chunk closed in 5.1118178367615 seconds. 74% complete closing
[2021-04-02 16:54:57 UTC] Memory usage – limit / current / peak memory usage: 1073741824 / 37443496 (35.71 MB) / 40838608 (39 MB)
Jesse says:
Hi Andy-
Thanks for reaching out! I’ve removed some parts of your log for brevity’s sake. There are a few next-steps to take to troubleshoot after you’ve switched to System Zip.
Since there were no error messages to indicate what caused the process to terminate, it’s tough to say for sure exactly what caused the failure. This is normally due to exceeding some limitation on your hosting account, for example CPU usage, Execution Time Limit, or Disk I/O. As you mentioned, it doesn’t look like the memory limit was the issue here.
A good first step is to enable the Filelist Analysis option in the Total Upkeep > Settings > Backup Process menu. This will show you if there are any “huge” files in your website that might be using up unnecessary space in your backups.
While you’re on this menu screen, also try reducing the Compression Level setting. Start with level 0, and if that succeeds try 3, and so on until you find the sweet spot. This will increase the total size of your backup archive, but reduces CPU usage and execution time.
Another tactic to try is to exclude the wp-content/uploads/ directory from your backup, since that’s normally the directory that takes up the most disk space.
If you’re still having trouble, let us know in the Support Forums so we can continue to troubleshoot.
Andy says:
Is there a way to abort the backup process? It’s hard to toubleshoot when having to wait for it to crash.
Jesse says:
Hi Andy-
Right now, this feature hasn’t been implemented yet. I’ve added your feedback to our current feature request on GitHub.
Andy says:
I think I got it working. One problem was what looked like very large temporary files created in the process of attempting backups. These looked like: pclzip-5fd5549a04a01.tmp and I’m pretty sure the backup crashed upon encountering these.
Find any temporary files with:
find ./ -name *.tmp
and delete all of those.
Look for any big files with:
find . -type f -size +100M
and delete any of those you don’t think need to be there.
Compression of the archive doesn’t really give you any meaningful degree of space saving and adds a lot of time to the backup process and introduces another thing to go wrong.
Turn off compression by going to Settings -> Backup Process
set Compressor to ‘System zip’ and set Compression Level to 0.
Push save.
Seems to work with Backup Site Now.
Just need to get the save to Google Drive working now…