SOLVED Note about File Restoration in cPanel 70

[cPanelMichael]

Hello Everyone!

This thread primarily pertains to systems on the EDGE and CURRENT build tiers.

Metadata for Backups version 2.0 is a new feature included with cPanel & WHM version 70. We document this new feature in the Release Notes for cPanel 70:

The Backup system now stores backup metadata in SQL tables. The Backup system creates metadata whenever it performs a backup.

We introduced metadata for Backups version 1.0 in cPanel & WHM version 66. Version 1.0 stores metadata as a CSV format file. If your system contains metadata files, when cPanel & WHM upgrades to version 70, the upcp script (/usr/local/cpanel/scripts/upcp) executes a background task. This task converts the version 1.0 metadata files to version 2.0. Because this task runs in the background, it does not affect the upcp script's functionality.

For more information about metadata for Backups, read the Metadata for Backups version 2.0 section of the The backups_create_metadata Script documentation.

Because they are smaller in size, metafiles allow for a faster information-retrieval method compared to using the backup archive itself. This makes it possible for us to offer features like File Restoration in cPanel & WHM.

That said, the initial implementation of Metadata for Backups version 2.0 had lead to some concerns about the amount of disk space utilized by the /var/cpanel/backups/metadata.sqlite file. cPanel version 70.0.17 includes a case to help address this:

Fixed case CPANEL-18728: Reduce size of the backups metadata database.

Due to the nature of this change, attempting to restore a file using the File Restoration option in cPanel or WHM after updating to cPanel version 70.0.17 or newer on a system already using cPanel version 70 (EDGE and CURRENT build tiers) will fail. Here's an example of an error message you might see in the cPanel or WHM user interface when this happens:

Restoration failure for file “/filename”: “The system could <strong>not</strong> find the backup file.”.

This may correspond to entries like this in /usr/local/cpanel/logs/error_log:

Argument "FILE" isn't numeric in numeric eq (==) at /usr/local/cpanel/Cpanel/Backup/Restore.pm line 409, <STDIN> line 2.
Argument "file" isn't numeric in numeric eq (==) at bin/admin/Cpanel/restore.pl line 163, <STDIN> line 2.
Argument "compressed" isn't numeric in numeric eq (==) at bin/admin/Cpanel/restore.pl line 173, <STDIN> line 2.
Argument "compressed" isn't numeric in numeric eq (==) at /usr/local/cpanel/Cpanel/Backup/Restore.pm line 733, <STDIN> line 2.
Argument "FILE" isn't numeric in numeric ne (!=) at /usr/local/cpanel/Cpanel/Backup/Restore.pm line 512, <STDIN> line 2.

To solve this issue, please follow the steps below:

Step 1: Check the size of the metadata.sqlite file and determine a location on your system that offers enough free disk space to store it:

du -sh /var/cpanel/backups/metadata.sqlite
df -h

Step 2: Once you've found a directory with sufficient available disk space, move the metadata.sqlite to the new location. I've used /home in the below example:

mv /var/cpanel/backups/metadata.sqlite /home/

Step 3: Run the following command to regenerate the metadata file:

/usr/local/cpanel/scripts/backups_create_metadata --all

This will rebuild a working copy of the metadata.sqlite file and allow the File Restoration feature to work again.

Step 4: Once you've confirmed the File Restoration feature is working properly again, you can remove the copy of the previous metadata.sqlite file that was moved to the alternate location as a backup (e.g. /home/metadata.sqlite in the example above).

More information on how the MetaData and File Restoration features work is available at:

Metadata for Backups - cPanel Knowledge Base - cPanel Documentation
File Restoration for cPanel - Version 70 Documentation - cPanel Documentation
File Restoration for WHM - Version 70 Documentation - cPanel Documentation

Note that systems updating to cPanel version 70.0.17 or newer from cPanel version 68 or prior should not encounter this issue. It only affects systems on the EDGE and CURRENT build tiers that were already using cPanel version 70 prior to updating to cPanel version 70.0.17.

Additionally, let us know if you encounter any additional issues with the File Restoration feature after applying the above workaround.

Thank you.

 

[Bashy]

Hi, is this anything to worry about? had a few over the last few days... it started after the last cpanel update i believe....

The backup process encountered the following error:
The metadata database is corrupt. Scheduling a rebuild.

Cannot find a processor module for “backups_create_metadata ” at /usr/local/cpanel/Cpanel/TaskQueue/Scheduler/DupeSupport.pm line 61.

Full log

[2018-02-23 02:24:44 +0000]
[2018-02-23 02:24:44 +0000] homesize is: 449175552
[2018-02-23 02:24:44 +0000]
[2018-02-23 02:24:44 +0000] homefiles is: 9301
[2018-02-23 02:24:44 +0000] pkgacct completed
[2018-02-23 02:24:44 +0000] info [backup] Successfully backed up account “******” to “/backup/2018-02-23/accounts”
[2018-02-23 02:24:44 +0000] info [backup] Adding metadata information for ****** to backup at /backup/2018-02-23
[2018-02-23 02:25:06 +0000] info [backup] Queuing daily backup copy of “******” for transport of “/backup/2018-02-23/accounts/******.tar.gz” to “2018-02-23/accounts/******.tar.gz”
[2018-02-23 02:25:06 +0000] info [backup] This particular transport will be queued with keep_local = 0 , based on the need to copy weekly () and/or monthly () copies as well.
[2018-02-23 02:25:07 +0000] info [backup] Queuing transport of file: /backup/2018-02-23/accounts/******.tar.gz
[2018-02-23 02:25:07 +0000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:11700
[2018-02-23 02:25:07 +0000] info [backup] leaving queue_backup_transport_item
[2018-02-23 02:25:07 +0000] info [backup] Queuing transport of meta file: /backup/2018-02-23/accounts/.master.meta
[2018-02-23 02:25:07 +0000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:11701
[2018-02-23 02:25:07 +0000] info [backup] leaving queue_backup_transport_item
[2018-02-23 02:25:07 +0000] info [backup] Queuing prune operation for remote destination daily backups
[2018-02-23 02:25:07 +0000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:11702
[2018-02-23 02:25:07 +0000] info [backup] leaving queue_backup_transport_item
[2018-02-23 02:25:07 +0000] info [backup] Scheduling backup metadata rebuild
Cannot find a processor module for “backups_create_metadata ” at /usr/local/cpanel/Cpanel/TaskQueue/Scheduler/DupeSupport.pm line 61.
[2018-02-23 02:25:07 +0000] info [backup] Queuing transport reporter
[2018-02-23 02:25:07 +0000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:11703
[2018-02-23 02:25:07 +0000] info [backup] leaving queue_backup_transport_item
[2018-02-23 02:25:07 +0000] info [backup] Completed at Fri Feb 23 02:25:07 2018
[2018-02-23 02:25:07 +0000] info [backup] Final state is Backup::PartialFailure (0)

 

[Malcmill]

I'm getting the same, seems to of started after last upgrade.

 

[John Schmerold]

I have been getting the same error message. What does it mean?
The backup process encountered the following error:
The metadata database is corrupt. Scheduling a rebuild.

 

[beddo]

I get the same error as the above people but this is not to do with restoration - it is the nightly backup:

[2018-02-26 05:38:41 +0000] info [backup] Scheduling backup metadata rebuild
Cannot find a processor module for “backups_create_metadata ” at /usr/local/cpanel/Cpanel/TaskQueue/Scheduler/DupeSupport.pm line 61.

If I read through the article you linked I have plenty of space available on all drives so don't see the relevance.

My configuration is that the default backup directory is /home/backup then I have a FTP connection to a NAS as an additional destination with "Retain backups in the default backup directory" not ticked.

 

[rodpascoe]

I get this too, definitely backup not restoration.

 

[Sew.]

Same issue here.

 

[cPanelMichael]

Hello,

I've merged additional posts on this topic into a single thread.

Here's another example of an error message that can occur during the backup process:

[2018-02-24 02:09:27 +0800] info [backup] Scheduling backup metadata rebuild
Cannot find a processor module for “backups_create_metadata ” at /usr/local/cpanel/Cpanel/TaskQueue/Scheduler/DupeSupport.pm line 61.

We have an additional internal case, CPANEL-18769, open to address this particular error message. I'll update this thread once the resolution is published. In the meantime, rebuilding the metadata file using the workaround referenced in the first post should act as a workaround.

Thank you.

 

[beddo]

Unfortunately rebuilding the metadata doesn't work for me. I simply don't have the /var/cpanel/backups/metadata.sqlite file.

 

[cPanelMichael]

I simply don't have the /var/cpanel/backups/metadata.sqlite file.

Can you verify which version of cPanel is installed on your server?

Thank you.

 

[beddo]

Can you verify which version of cPanel is installed on your server?

Thank you.

I have 70.0.17

 

[cPanelMichael]

Unfortunately rebuilding the metadata doesn't work for me. I simply don't have the /var/cpanel/backups/metadata.sqlite file.

Could you run the following commands and let us know the output?

/usr/local/cpanel/scripts/backups_create_metadata --all
stat /var/cpanel/backups/metadata.sqlite

Thank you.

 

[cPanelMichael]

Hello,

To update, the resolution associated with CPANEL-18769 is included in version 70.0.18:

Fixed case CPANEL-18769: Update call to create metadata v3.0 for backups.

Thank you.

 

[Bashy]

I have just manually updated, wont know till the morning but all being well its now fixed, thank you

 

[beddo]

The update sorted it for me too.

 

[Bashy]

Yes, it seems to be ok now, thanks folks