WebGISDR tool vs. snapshot

[BarryG]

I understand that the WebGISDR utility backs up files of the following components of your ArcGIS Enterprise deployment:

• Your portal items and settings
• GIS services and settings
• Service webhooks
• The relational data store and tile cache data store

With that, if an ArcGIS Enterprise upgrade has gone wrong, the application must be rolled back prior to restoring those items above, correct?

versus a snapshot, in which the ArcGIS Enterprise application and items above will be restored?

[Brian_Wilson · Accepted solution]

You can do a live backup any time with webgisdr because uses the backup tools designed to do safe backups on running services.

If you do a snapshot of a running machine it might be just fine but you ccould end up with corrupted databases if you have to roll back.

When doing an upgrade the best approach is to stop the components (the Server, Portal, DataStore, and whatever GeoDatabase (SQL Server for example-- if you run that in the same VM) and then once they are all down, do a set of VM snapshots. That way there are no databases in inconsistent states if you have to drop back -- they are all stopped when you bring up the snapshot.

I do both -- belt and suspenders -- I do the webgisdr first then shut everything down then do snapshots. Just makes me more comfortable. Means more downtime but no one minds that here.

[RyanUthoff · Accepted solution]

I'm assuming you're referring to server/VM snapshots? If so, here is how I like to think of it. WebGISDR takes care of backing up ArcGIS Enterprise at the software level. While a snapshot backs everything up at the server level.

If you are doing an upgrade and it goes wrong and you have to restore from a backup, a snapshot restore is much easier than dealing with a WebGISDR in my opinion. You just restore the VM(s) and you're done.

With WebGISDR, you have to go back to the version of ArcGIS Enterprise you took the backup on (potentially meaning you have to downgrade already upgraded Esri components), and then run the WebGISDR tool. I've done plenty of VM snapshot restores, but not a WebGISDR, so I might be incorrect on that. But that's my understanding of how it works.

[BarryG]

But, I assume that, say for instance, you may have missing map services, etc., post-upgrade, can then be imported using the WebGISDR tool and then restored? I guess that is the point of the WebGISDR tool after all, in addition to incremental backups, correct?

[RyanUthoff]

You cannot use WebGISDR on a different version of ArcGIS Enterprise from when the backup was taken. So, if you have a WebGISDR backup taken on 10.9, upgrade to 11.0 and discover services are missing, you cannot use the WebGISDR on 11.0 to recover them. You would have to revert back to 10.9 to recover the missing services.

If that happened, something must have gone wrong with the upgrade and would recommend either restoring completely back to the previous version, re-create the missing services, or reach out to Esri support to troubleshoot further.

[simoxu]

WebGISDR is unique and useful although VM shapshots are very popular these days:

If you have a distributed GIS deployment (servers, storage, etc), which can be overwhelming for snapshots, resulting in inconsistency in the snapshots if you don't have a good understanding of the GIS IT architecture. WebGISDR removed all these IT infrastructure level complexities when backing up your GIS.

It is a GIS level backup, GIS administrators can do it whenever needed. because the GIS administrator doesn't need to engage with IT, it's very flexible.

It is also useful when you need to duplicate your GIS, for example, creating a test enviornment.

[RyanUthoff]

My views of WebGISDR have changed since I previously replied to this post. I definitely agree with what you said, but now I believe that WebGISDR should be used to supplement other forms of backups, and not be used as a replacement. We were affected by a bug in the WebGISDR that resulted in an inability to do a restore. It took Esri 10 months to fix it and release a patch for it......

Luckily we were using WebGISDR to duplicate our environment to a test environment and not actually restore in a disaster recovery scenario. But if we needed to do a recovery, our ArcGIS Enterprise deployment would be gone and we would have lost everything because of bugs within Esri's software. 

So my advice for those wondering about DR solutions is to use Esri WebGISDR to supplement other DR backups, such as VM snapshots, but to not solely rely on it.

[AdamRice]

Just an FYI, if you check the doco for backups - VM/EBS Snapshots are for infrastructure level with WebGISDR for application-level backups, and they're both useful for different reasons -

WebGISDR is super handy for incremental backups at app-level, and for migrating between infrastructure stacks;
VM/EBS Snapshots are amazing for replicating infrastructure stacks, testing updates/blue-green deploys etc.

You shouldn't be relying on either backup as a catch-all though. WebGISDR functionally just *.zips your base ESRI stack (not Jupyter/GeoEvent etc.), while Snapshots can break Portal/DataStore content if you don't set to read-only or stop services while a snapshot is occurring.

[simoxu]

Simply put, I'll use WebGISDR as part of the business continuity plan (make sure to test it on a new deployment to make sure it works). and when I need to do an ArcGIS upgrade, I'll engage the IT department to do VM snapshots, plus a full WebGISDR backup.

[AdamRice]

WebGISDR (set to INCREMENTAL) will handle your daily/scheduled data changes. It's cleaner to only track incremental changes to your backups to reduce overheads.

VM/EBS Snapshots whenever you darn well please (try not to create when services in-use lol).

When you want to upgrade your ESRI stack, basically treat it like a Highly Available stack.

1) Take your VM snapshot(s) and replicate it into a secondary region/availability zone/VPC/group etc. [or importSite your WebGISDR backup(s)].

2) Perform any infra/ESRI upgrades you want.

3) Check upgrade worked.

4) Swap DNS/Load Balancer/Route53 over to new stack.