One of the advantages of using AEM is that your data is safe in the SFU Data Centre. The same data protection and recovery options that are used for other critical systems at SFU also protect AEM's website data. While of course we have ways to restore data in the type of catastrophic situation the SFU Data Centre was designed to address, there are many data protection mechanisms and recovery options within AEM itself and those "disaster recovery" backups are not needed in normal usage.

In typical usage, page updates are automatically saved on AEM Author whenever you make a change in a component and close or "click out" of the editing mode, so you rarely have to explictly think of "saving" a page as you do in a desktop application. When you activate a page after making several changes, AEM automatically creates a "version" of that page that you can restore at a later time if you make some edits that, in retrospect, you'd rather not have made.

But what happens when you need to get something back that you've deactivated or deleted, or you just liked a previous version of a page better than after you've made recent changes? This page will give you some background on how SFU's AEM system protects your website data, and what to do in various situations if you think you've lost something.

Basic Undo and Redo

Like most desktop applications, the AEM Author application supports basic functions to let you undo or redo your last actions while editing a page. For example, if you paste text over a large block of text that you accidentally/unintentionally selected, you can simply undo that change as you would in most other environments.

See our documentation on Undo and Redo in CMS Basics.

Versioning in AEM

Every time you make a change to a page in AEM's Author environment, and then activate the page, the state of the page is saved as a "version" in AEM.

If you make an error on an AEM page like changing the text to something that you don't actually want, or even deleting all the components of a page and then activating that page, you can easily restore to previous versions of a page to restore it to a previous state.

While versions are automatically created when you activate a page, you can create versions on your own if you want to experiment with layout or content versions and want to be able to revert to a state between activated page versions. 

See the CMS Basics section of our documentation for more information on using versioning.

Activation and Deactivation of pages

AEM is designed so that you can make several changes to a page, or a set of pages, and have all of the changes go to the live site at once: when you make the new version of a page appear on the public www.sfu.ca website, that is referred to as "activating" a page. The activation process takes a copy of the current page in AEM Author and puts that information on the publishing servers for the rest of your audience to see.

Deactivating a page does two things: 

1. Removes the copy of the page from the publishing servers, so that that page is no longer visible to your audience
2. Updates any pages across the entire AEM instance that refer to that page so that links on those pages no longer reference the deactivated pages (this includes modifying menus/etc. within your site to reflect the removal of the page)

Deactivating a page does not delete the data from the authoring server. You can easily restore the page online by activating the page in AEM Author again.

understanding Deactivations

One thing to be aware of is that when you activate a page, only the page that you are activating will be affected. This enables you to expand content within a section of your website at a time. However, when you deactivate content, AEM must also remove any references or dependencies on the page that you are deactivating. That means that if you deactivate a page that is the parent of a subsection of other pages (such as your home page), the pages below it must also be deactivated for the site navigation that Author builds to be valid. It is therefore very important to fully read the dialog boxes that AEM will present to you when deactivating a page. Typically AEM will present you with a list of all the other pages that will need to be updated or deactivated when you deactivate the current page. It is important to check this list carefully to ensure that you will not deactivate something that you still want online that happens to be a dependency on the current page. 

Recovering Deleted Pages

It is also possible to completely delete a page if you know that you will never need to reactivate/use that content again. Of course, that means it's possible that in the course of your editing session to accidentally delete the wrong page. AEM handles this situation by providing a way to recover deleted pages. 

If you want to recover a page that was deleted, it is possible to restore the page if the following conditions are met:

1. The page has been deleted within the last 30 days.
   
2. The page has a version saved. It is not possible to recover a page that has no version. If the deleted page was activated at least once, it will have at least one version. To learn versioning best practices, visit Versioning.

Generally it is easy to restore a single deleted page, but if you have deleted an entire sub-section of your site, we suggest contacting the CMS Help team to assist with the restore. 

Note that deleting a page will normally first deactivate your page first. See the section above on "Understanding Deactivations" if you have deleted a parent page to a subsection since the deletion may trigger the deactivation of sub-pages as well. 

You can read more about how to Recover a Deleted Page in our Advanced CMS Help documentation.

In a Disaster Situation

AEM leverages the SFU Data Centre's file systems which, behind the scenes, handle redundancy and reliability by using special file systems and spreading the responsibility for data integrity between multiple large clusters of storage devices. Data is stored in multiple physical locations as well to help protect against data loss in disaster scenarios or other cases where catastrophic damage could occur. These backups happen without need of your intervention, automatically, and independently, of the AEM system.

The AEM data repository is hosted on an institutional file storage server that uses a snapshot mechanism to keep up-to-date states of the file system daily for use in short term recovery in a crisis situation. The daily backup is created and copies are kept for 30 days. Further, for twenty weeks, backups are available in the form of weekly snapshots. Both daily and weekly snapshots are kept at a separate physical location from the primary filespace that is used by AEM for data in active use.

While this method of data backup is effective and reliable, the size of the systems involved necessarily means that what they provide are snapshots of an entire system at a point in time as opposed to being site specific. These backups/snapshots are also huge: AEM Author data alone is over one terabyte.

Using this data is possible in extreme cases to restore the full AEM instance in cases of emergency, but doing so is time consuming and expensive in terms of people-time.  The data is intentionally segregated from "live" production systems — in part, to protect it — so restoring it can take some time. In a sense, this is the nearest thing to a simple "backup" that one might be familiar with from a desktop or laptop system. 

Using this kind of backup is the last resort of data recovery in AEM and is almost never the right solution to restore the contents of a single website: not only is it cumbersome and resource-intensive to use, the restored site won't have the granularity and options for recovery that one gets by using the layers of backup above this basic infrastructure layer. But in the case of a issues much bigger than data problems within a single AEM website, it is there as a safety net to ensure SFU's website can be restored.