Strategie zálohování ArcGIS Enterprise: Je WebGIS DR stále praktický ve velkém měřítku?

ZentraleTechnik

Zajímá mě, jak ostatní správci ArcGIS Enterprise řeší zálohování a obnovu po havárii v reálných nasazeních.

V průběhu let jsme opakovaně narazili na problémy se zálohami WebGIS DR:

• Vytvoření zálohy může trvat mnoho hodin nebo dokonce dní.
• Velká prostředí mohou produkovat záložní soubory dosahující nebo překračující stovky gigabajtů.
• Zálohovací úlohy občas selhávají nebo vyprší časový limit, což vyžaduje ruční zásah.
• Testování obnovy je často časově náročné a provozně složité.
• Jak prostředí nadále rostou, okna pro zálohování je stále obtížnější udržet.

V našem případě mohou zálohy WebGIS DR trvat až 16 hodin pro přibližně 900 GB dat, což ztěžuje provádění záloh dostatečně často k dosažení cílů obnovy.

Co činí tuto situaci zvlášť náročnou, je fakt, že dokumentace Esri a podpora konzistentně uvádějí WebGIS DR jako oficiálně podporovaný mechanismus zálohování a obnovy pro ArcGIS Enterprise.

Současně většina organizací již používá vyspělé cloud-native zálohovací schopnosti poskytované Azure, AWS, GCP, VMware, úložnými platformami nebo jinými řešeními na úrovni infrastruktury. Tyto technologie obvykle nabízejí:

• Rychlejší provedení zálohy
• Inkrementální zálohy
• Obnovu založenou na snapshotu
• Ověřené postupy obnovy po havárii
• Nižší provozní režii

To vyvolává upřímnou otázku:

Jakou praktickou výhodu poskytuje WebGIS DR oproti řešením zálohování na úrovni infrastruktury, zejména ve větších nasazeních Enterprise?

Naše vlastní cvičení obnovy po havárii se primárně spoléhají na zálohy infrastruktury v kombinaci s dokumentovanými postupy obnovy. Zatímco WebGIS DR zůstává součástí celkové strategie, stále více se stává nejpomalejší, nejnáročnější na zdroje a nejméně flexibilní součástí zálohovacího procesu.

Otázky pro komunitu

1. Používáte stále WebGIS DR jako svůj primární mechanismus obnovy po havárii?
2. Kombinujete WebGIS DR s cloud-native zálohami (Azure Backup, AWS Backup, snapshoty, VMware snapshoty atd.)?
3. Pokud ano, kterému řešení skutečně nejvíce důvěřujete v reálném scénáři obnovy po havárii?
4. Přešel někdo úplně od pravidelných záloh WebGIS DR a spoléhá primárně na zálohy na úrovni infrastruktury?
5. Diskutovali jste o takovém přístupu s Esri Support a pokud ano, jaké pokyny jste obdrželi?
6. Existují organizace úspěšně provozující velmi velká Enterprise prostředí, kde je WebGIS DR stále praktický?

Nehledám rady pro řešení problémů u konkrétního nasazení.

Spíše mě zajímá pochopení, zda existuje rostoucí propast mezi oficiálním doporučením používat WebGIS DR a tím, co organizace skutečně provozně dělají v produkci.

Velmi rád bych slyšel, jak ostatní přistoupili k tomuto problému.

ryanuthoff

We're pretty much in the same situation as your described, so I'll try and answer your questions.

1. No, we stopped using WebGISDR.
2. We just use AWS snapshots. Not only does AWS take just minutes to backup (compared to hours for WebGISDR), it only takes minutes to restore (again, compared to hours for WebGISDR).
3. I trust AWS's backups more than the WebGISDR. We had a scenario where we needed to do a WebGISDR backup and restore to an isolated test environment to troubleshoot an issue. The restore of the WebGISDR failed due to a known Esri bug (which was eventually fixed by Esri). If this would have been a real-world DR situation, we could have lost everything due to the inability to restore from a backup. It was an incredibly dangerous bug for organizations that solely relied on WebGISDR.
4. As the answers above indicate, we moved to AWS backups.
5. I indirectly discussed this approach with Esri when we encountered the WebGISDR bug. The only guidance was to wait for the bug fix to be released.
6. I can't answer that one since we don't really use WebGISDR.

As I mentioned above, WebGISDR can still be useful for non-DR scenarios, such as doing a restore to an isolated test environment to troubleshoot an issue. Or perhaps machine migrations as well. But for just doing general backups, doing it at the AWS level is much more simpler, reliable, and faster.