Problem/Motivation

When we currently restore the default Drupal database, a status message appears noticing the user about the successful restoration of the database.

This notification will not show up under the watchdog page ("/admin/reports/dblog"), since the restoration message will be logged first, but reset afterwards by the restoration process

Steps to reproduce

  1. Restore the default drupal database via uploaded backup file
  2. See the status message "Restore complete ..." on page after restoration
  3. Check if the status message is shown under "recent log messages in "/admin/reports/dblog"
  4. The status message is not there

Proposed resolution

Log the restoration message after the watchdog reports get reset.

The log entry should include information about:

  • What was restored (backup name)
  • Status of restore (success, ...)
  • When it was restored
  • Who restored

Additionally, we could discuss if a "Description / note" would also make sense on restore like on backup creation. This could also simply be logged with the watchdog entry!

CommentFileSizeAuthor
#19 3305094-restore-msg.png92.27 KBdanrod
#19 3305094-restore-msg.png92.27 KBdanrod
#17 Apply-MR-3305094.png795.81 KBnikhil_110

Issue fork backup_migrate-3305094

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

Grevil created an issue. See original summary.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes

Important point to see restores in Watchdog! Wondering this wasn't done yet.

I added some details and ideas for the log entry.

tamerzg made their first commit to this issue’s fork.

tamerzg’s picture

tamerzg commented
Assigned: Unassigned » tamerzg

tamerzg opened merge request !27

tamerzg’s picture

tamerzg commented
Status: Active » Needs review

Added status message to Drupal log:

Restore completed using {backup_name} from {backup_location} into {destination} at {time}.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Assigned: tamerzg » Unassigned
Status: Needs review » Needs work

Thanks @tamerzg - I added two comments. LGTM at all. Could you explain your choices?

tamerzg’s picture

tamerzg commented

@Anybody thanks for the review. I replied inside PR.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Thanks, moving both into the t() is just what I expected. Perfect! :)

tamerzg’s picture

tamerzg commented
Assigned: Unassigned » tamerzg
tamerzg’s picture

tamerzg commented
Assigned: tamerzg » Unassigned
Status: Needs work » Needs review

@Anybody I just updated PR, now $message string is built dynamically so we don't mix it with context variable. Please note that $message is not wrapped in t() as it shouldn't be, log messages are translated on display, but they are always stored in english/system language.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

I personally don't really like this cluttered text approach, but other maintainers may see it different. Let's wait for further feedback.

grevil’s picture

grevil commented

OK, I think this needs further work.

I agree with @Anybody. Not really a fan of the concatenated string approach. Furthermore, the log message text doesn't display the correct parameters.
For the test, I made a backup of my site using the backup_migrate module and saved the backup in my private files directory. Afterwards I used the "Restore" option.

This is my file dir / name : files/private/backup_migrate/backup-2023-02-13T10-35-05.mysql.gz

And this is the log message result:

Restore completed using backup_migrate_restore_upload from Upload into Default Drupal Database at Monday, February 13, 2023 - 10:37

grevil’s picture

grevil commented
Status: Needs review » Needs work

Not really the expected outcome, but fairly close! :)

grevil’s picture

grevil commented

Update: The incorrect message only appears when restoring a backup using the "BackupMigrateRestoreForm" ("/admin/config/development/backup_migrate/restore" => the one with the file upload field). But the message appears correct, when restoring through the "BackupRestoreForm" ("/admin/config/development/backup_migrate/backups").

The reason behind this is, that inside "BackupMigrateRestoreForm", "backup_migrate_perform_restore()" is called with hardcoded parameters for correct file usage of the file uploaded in the file upload field.

Since this is working flawless for the "BackupRestoreForm":

Restore completed using backup-2023-02-13T10-35-05.mysql.gz from Private Files Directory into Default Drupal Database at Monday, February 13, 2023 - 11:01.

And we can not easily get file and destination IDs through the "BackupMigrateRestoreForm" without heavy refactoring, I suggest, we either display a static log message, keep it as is or remove the logging if the restoration was performed through the "BackupMigrateRestoreForm".

Any other ideas or an easy fix for this problem are also welcome! :)

grevil’s picture

grevil commented
Status: Needs work » Needs review
nikhil_110’s picture

nikhil_110 commented
StatusFileSize
new Apply-MR-3305094.png795.81 KB

The above MR is applied successfully for Backup and Migrate v5.1.x-dev.
Attaching the screenshot for reference.

Review Step

  • Setup Drupal 10.x with Backup and Migrate Module - 5.1.x-dev
  • Apply MR
  • Go to Administration > Configuration > Development > Backup and Migrate > Restore (Tab) > Restore now
  • After Go to Administration > Reports > Recent log messages > Backup and Migrate > Check backup_migrate Type log.

The Backup is still not added in the log message as was suggested by @Anybody in #2.
Review it too and let know if that is required.

xmacinfo’s picture

xmacinfo
he/him
Primary language French
Location Canada
commented

Using Backup and Migrate 5.0.3 to restore a file (related to issue https://www.drupal.org/project/backup_migrate/issues/3264580), using the file picker, I expected to see a confirmation message.

I did not see any message on the screen.

In searching for another confirmation I looked at the watchdog and I did not see any entry related to restore or any Backup and Migrate entries.

The only way I was able to confirm that Backup and Migrated did the restore successfully was to look at the content and check for recent changes.

danrod’s picture

danrod
Location Ottawa
commented
StatusFileSize
new 3305094-restore-msg.png92.27 KB
new 3305094-restore-msg.png92.27 KB

Tested this MR for 5.1.x and I can see the confirmation message after I restored an old backup, can be moved to RTBC.

danrod’s picture

danrod
Location Ottawa
commented

I rebased the branch and tested the changes again and I can see the log message in watchdog table, setting this to RTBC and merge it to branch 5.1.x

danrod’s picture

danrod
Location Ottawa
commented
Status: Needs review » Reviewed & tested by the community

  • danrod committed e1abcb6b on 5.1.x authored by tamerzg 
    Issue #3305094: Log "backup restored" to watchdog after restore finished
danrod’s picture

danrod
Location Ottawa
commented
Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • danrod committed 38ceb606 on 5.0.x 
    Issue #3305094: Log "backup restored" to watchdog after restore finished...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.