BoldGrid WordPress Backup Plugin FAQ's | Total Upkeep
Last updated on

Total Upkeep WordPress Backup Plugin

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.

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?

Need hosting for your website?

 

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.

10 thoughts on “Total Upkeep Backup Plugin FAQ

  1. 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.

    • Hi Andy-

      The important bit of this log is the line Signal received: 15, which is equivalent to the Linux command kill -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.

      • 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.

      • 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)

        • 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.

          • Is there a way to abort the backup process? It’s hard to toubleshoot when having to wait for it to crash.

          • 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…

Leave a Reply

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