Site Backups| Hitchhikers Platform

light bulb
New Release Feature
This article references the new Point-in-Time Backups feature from our October ‘22 Monthly Release. To turn this feature on in your account, navigate to Account Settings > Account Features and select the “Fall ‘22: Point-in-Time Backups (early access)” feature.

Should a bug or corrupt dataset make its way into your production site, Yext provides you with the ability to deploy a backup version of your full site. From the moment you publish a site to production, you can deploy a backup version of your site as it existed at any previous point in time - right down to the second.

Refer to our backups guide for a step-by-step walkthrough on deploying a backup.

How this works under the hood is that the Pages system maintains a mapping of pages in your site to the specific deployment and Knowledge Graph JSON documents that were used as part of static generation process.

Preview Pages with UNIX Timestamps

While this feature is technically for disaster recovery, you can also use it to quickly preview what your pages looked like previously using UNIX timestamps! Here’s how it works:

From your deploys page, you can trigger the backup activation modal by clicking “Deploy Backup”. From here, you can select a specific date and time; the Pages system will generate an ISO 8601 timestamp query parameter for you automatically! (Refer to the screenshot below)

backup-modal.png

Simply append the timestamp to the end of your page URLs, and you can preview each page exactly as it appeared at that time!

For example, observe the differences between these two URLs:

Notice how this URL redirects you to a preview version of this site, where the location name differs (we added (edit from October 12th, 3:32PM EST) so you can see the difference)!

Backups History

To view an audit history of all backup activation/deactivation, you can use the “History” tab located in the left-hand navigation menu. From here, you can observe details on each backup-related event, including the:

  • Event timestamp
  • Event action
  • Backup timestamp query parameter
  • Event Actor

backups-history.png

Backup “Limitations”

There are a few things to consider when activating a backup:

Redirects

When you activate a backup, Yext will purge the cache in CloudFlare to ensure any subsequent requests for your pages reflect the time of your backup. However, there is no way to invalidate a user’s browser cache when a backup is deployed, so it’s possible a user may encounter stale redirects. Worst case scenario, Yext’s 301 redirects are cached-controlled with a max age of 12 hours, so this edge case will be rectified either after 12 hours or if the user clears their browser cache.

Take the following example:

  • You have a location entity that powers the brand.com/a.html page; the location entity is mistakenly updated such that the page is updated to brand.com/b.html.
  • Due to this update, the Pages system will automatically create a 301 redirect for /a.html to /b.html.
  • You deploy a backup to before that entity update occurred; as such, the user should expect to see brand.com/a.html when they request the page, as the redirect did not exist at the time.
  • Due to the cached redirect, the user will be directed to brand.com/b.html, which 404s.

It is possible for page links referenced in search engine results to 404 if such pages were created after the point-in-time backup timestamp.

Take the following example:

  • On Wednesday, October 12th, you create a new page: brand.com/b.html.
  • The page brand.com/b.html starts to rank on Google Search.
  • On Thursday, October 13th, you decide to deploy a backup of your site from October 11th (back when brand.com/b.html did not exist). As such, clicking on that search result after the backup is deployed will subsequently 404. This is to be expected, but still something to consider.

Preview Environments

To guarantee that you are looking at a historical version of your site, timestamp query parameter strings should be appended to the end of your PRODUCTION URLs. To illustrate this clearly, observe the following example below:

In this example, cargo-nape-suspend.pgsdemo.com is a production domain, while aphr4pgqki-410590-d.preview.pagescdn.com is a preview domain. In the Pages system, each deploy is associated with a unique preview domain. Per the “Data Updates” section of this unit, only a subset of your deploys at any given time is in-sync with the Knowledge Graph. As such, appending a timestamp query parameter to the end of certain domains will be “stale”, so as a best practice you should always append to the production domain.

Feedback