Forum Replies Created

Viewing 4 replies - 16 through 19 (of 19 total)
  • Thread Starter yinxingmaiming

    (@yinxingmaiming)

    Update

    I switched to using a different sqldump format for the db backup (which is very large) and was able to successfully backup/restore with WF active.

    Let’s wrap this – I think the issue is probably related to how Duplicator handles very large db’s.

    Thx for all your prompt responses…

    Cheers

    Thread Starter yinxingmaiming

    (@yinxingmaiming)

    Tim – thx again for the quick reply.

    I can try that, but am I correct that learning mode is a temporary ‘status’, i.e. doesn’t WF eventually turn off learning mode?

    Also, that kind of defeats the purpose of WF, doesn’t it? My understanding of learning mode is that it limits blocking.

    What I’m really looking for is some kind of white list that would recognize Duplicator.

    Otherwise, I think I’m stuck with adding an IP block in htaccess, de-activating WF, backing up, then re-activating WF and reversing the IP block every time I backup…seems like there must be a better way…

    FWIW, the folks at Duplicator have suggested they’re aware of a conflict – I’m still trying to get the details…

    Thread Starter yinxingmaiming

    (@yinxingmaiming)

    Hi- thx for the prompt reply. Not sure if I was clear about the nature of the error and the context:

    Use case – restore a dev environment that had been previously backed up with WF active.

    In order to do this, I followed the following steps:
    – routine backup of dev (with WF activated)
    – determine dev needs to be restored (unrelated to WF or Duplicator)

    – del and recreate dev database
    – del all files in dev dir

    – at this point, WF is not active, since dev has been completely wiped out

    – restore dev using previously backed up db and files
    – as part of restore, duplicator restores WF
    – WF detects some threat and issues 403
    – restore abends (in an unknown state)

    I’m afraid I didn’t see any option for further details from WF – duplicator announced the 403 err – but there was a summary msg w/i the restore window indicating that the origin was WF and that WF had issued the 403. And TBH, since the restore abended, I didn’t look at WF’s dashboard – the “restored” site was not fully functional. And also, TBH, the duplicator log doesn’t provide any info about the err…

    I realize this is really tricky to diagnose – WF only starts running toward the end of the restore. It’s not running prior to the restore, since the entire dev environment has been wiped clean.

    I’ve sent the restore log to SnapCreek (duplicator vendor) and I’m still waiting for a response from them. Later today, I will try making 2 backups (one w/ and one w/o WF activated) and then try to replicate the err to see if I can find any further details in WF (if I can access it from a partially restored state).

    For the moment, I’ve deactivated WF in dev and I’m using an IP block in htaccess, so I can continue working in dev. But I don’t think this is a viable solution for prod (once I migrate).

    From your end, may I ask:
    – other than the whitelist option (which your doc says doesn’t work with dynamic IP’s), is there some param I can set that can detect a “retore in process” situation?
    – is there a log file somewhere in the WF sub-dir that I can access and send to you?

    Finally, I believe Duplicator has the ability to deactivate plugins during the restore – I suspect the final solution may be for Duplicator to:
    – restore WF
    – de-activate WF during the remainder of the restore
    – re-activate it

    Any thoughts on the above?

    Thx

    Thread Starter yinxingmaiming

    (@yinxingmaiming)

    Update –

    The only workaround for this was to:
    – restore to a local machine (WF apparently has a separate threat assessment for local restores)
    – de-activate WF
    – backup
    – restore to host
    – re-activate WF

    And now, on an ongoing basis:
    – add IP deny all, allow <my IP addr> to htaccess
    – de-activate WF
    – backup
    – re-activate WF
    – remove IP deny from htaccess

    Obviously, this is less than an ideal solution.

    I’m kind of stuck between 2 vendors, but one way or another, either Duplicator or WF has to have some awareness that a restore is underway and not block the completion of the restore. Either:
    – Duplicator has to temporarily de-activate WF during the restore process, OR

    – WF needs some kind of handshake option to limit how aggressively it blocks perceived threats during a restore.

    Thx in advance

Viewing 4 replies - 16 through 19 (of 19 total)