1

Can anyone that has an Exagrid in their environment let me know how to check what exactly is residing on the "Landing Zone" vs. the "Retention Zone"? Unfortunately this is not possible with the dashboard.

Paul Masek
  • 722
  • 2
  • 7
  • 16

2 Answers2

1

I received a couple more messages back from Exagrid that explain what is going on. Here they are:

Backups land on the landing space. From there they are processed (compressed and deduped) into the retention space. They remain in the landing space for as long as we can keep them (ie., the space isn’t needed to land more backups.) So, they will actually reside on disk in two different places. One is fully hydrated in the landing space and one is all chopped up in blocks in the retention space. The retention space version is only what is necessary to rehydrate at a later time if need be. The landing space version can and will be flushed from disk if it is the oldest data and more space is needed to ingest more backups, perform restores or provide copies of the data.

The actual technical details are all part of our patented algorithms.

In a nutshell, the backup lands on the landing space. The specific type of backup (determined by the application used) is detected. The processing breaks the backups into chunks. Based on whether or not there is previous data and how well that previous data is matched, the chunks will be retained or tossed out. The matching requires that the backup data is uncompressed and unencrypted. This is standard across all the backup applications. There are some exceptions where this requirement is relaxed. Those are detailed in the online documents (Help->Online Library.)

The retained chunks are all located in the retention space. The retention space data is kept for as long you specify according to the retention policies set in to the backup applications.

The original backups are all retained in the landing space. Again, the landing space is nothing more than a big caching mechanism. All data here is kept for as long as possible. It will eventually be filled to capacity but is marked 100% available because all data is subject to be flushed from the landing space as space to ingest more backups is needed.

Community
  • 1
Paul Masek
  • 722
  • 2
  • 7
  • 16
0

Either the engineer was wrong, or there was a serious miscommunication between you two. The landing zone is (by default) half of the appliance capacity. That's where the most recent backup is held. It's deduped into the retention zone, so anything older than the most recent backup has to be rehydrated, thus retrieval will take longer.

What problem are you trying to solve?

Edit - what's your backup software? It should be able to tell you for any given job what the most recent backup was. You're not generally supposed to be trying to hit the Exagrid itself via bash for backup files, it should be mediated by your backup software.

mfinni
  • 36,144
  • 4
  • 53
  • 86
  • The problem I'm trying to solve is that I want my most recent backup chain (incrementals plus corresponding full) to reside in the "Landing Zone", which is advertised as undeduplicated right on their website. In order to verify that this is happening I wanted to view it in the filesystem, as well as view where the Retention Zone files are. I only used bash to view the files, not to manually script out the backup process. We use Veeam. – Paul Masek Oct 21 '16 at 13:41
  • 1
    OK, so you want it to work the way it's supposed to work. If you don't believe them, then test it yourself. Do a restore of something big from the most recent backup. So a restore of the same thing from before that. Compare the execution times of the restores. Hopefully you're not bottlenecked somewhere besides the Exagrid on your data path. Veeam can help show that. – mfinni Oct 23 '16 at 23:32