Data retention examples
A solid understanding of how a retention policy impacts a user's Connected files ensures that you can create policies that meet your corporate retention needs. In addition, you will have the knowledge necessary to answer questions from users about why certain versions of their files are no longer available. To help explain the retention process, this topic provides detailed examples of the process in action.
Overview
Suppose that the fictitious AcmeXYZ company uses a corporate retention policy with the following data-related values:
-
Daily versions = 10.
Keeps the latest version available for each of the 10 previous calendar days, not counting the day that retention runs.
-
Recent versions = 5.
Keeps up to the five most recent versions, starting at the time retention runs. Some of these may also be counted as daily versions.
Mark, a Connected user at AcmeXYZ, has modified several of his files many times over the past week. As a result, his Connected backup set contains multiple versions of each file. The following examples depict how the specified retention policy affects the various versions of Mark's files.
All examples in this topic use the following icons to represent different file states:
Active version, available before retention runs
Daily version retained
Recent version retained
Version retained that qualifies as both a "recent" and "daily" version
Version permanently removed by the retention process
Example 1: The basics of daily and recent versions
File A: Connected backs up the file three times a day. When the retention process runs, it retains all three of the current day's versions and the last two versions from the previous day (one of which is also considered a daily). It also retains the daily versions for the nine days before yesterday.
12 days in the past | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Current day |
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
retention runs |
File B: Connected backs up the file six times a day. For this file, the retention process retains the last five versions from the current day and the daily versions for the previous 10 days.
12 days in the past | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Current day |
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
retention runs |
Example 2: Retention of an active file
On June 1st, Mark creates a file and then updates it many times over the next several days. The following table shows all versions of his file in Connected through 11:00 a.m. on June 13th. For example, Connected stored three versions of the file on June 1st and no versions of it on June 3rd.
June 1 |
June 2 |
June 3 |
June 4 |
June 5 |
June 6 |
June 7 |
June 8 |
June 9 |
June 10 |
June 11 |
June 12 |
June 13 |
|
|
|
|
|
|
|
|
Now, suppose that the retention process runs on Mark's data at 11:01 a.m. on June 13th. It uses the corporate AcmeXYZ retention policy, which has the following effect:
-
Daily versions = 10. Keeps the latest version available for each of the 10 previous calendar days: June 3 through June 12.
In this example, Connected retains only five versions because only five of the 10 previous calendar days have versions available.
-
Recent versions = 5. Keeps up to the five most recent versions, starting from 11:01 a.m. on June 13th. Daily versions within this count are also considered a recent version.
In this example, the daily version for June 12th is also the third most recent version of the file at the time that retention runs so it counts as one of the five recent versions.
The following table illustrates how the retention process impacted Mark's files:
12 days in the past | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Current day |
---|---|---|---|---|---|---|---|---|---|---|---|---|
June 1 |
June 2 |
June 3 |
June 4 |
June 5 |
June 6 |
June 7 |
June 8 |
June 9 |
June 10 |
June 11 |
June 12 |
June 13 |
|
|
|
|
|
|
|
retention runs |
Mark makes no further changes to the file by the next time the retention process runs on June 24th. In this case, all versions of the file are past the retention period defined by the daily retention value of 10 days so the retention process should permanently remove them. However, because Connected always keeps the most recent version of an active file, regardless of its date, it retains the latest version dated June 13th. This version corresponds to the file that still exists on Mark's device. The following table illustrates the results of the second run of the retention process.
19 days in the past |
18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | ... | 2 | 1 | Current day |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
June 5 |
June 6 |
June 7 |
June 8 |
June 9 |
June 10 |
June 11 |
June 12 |
June 13 |
June 14 | June 15 | ... | June 22 | June 23 | June 24 |
|
|
|
|
|
|
retention runs |
Example 3: Retention of a deleted file
On June 2nd, Mark creates a file and then updates it two more times on June 7th. On June 12th, he deletes the file from his computer and Connected marks its latest version as "deleted". The following table shows all versions of the file through 11:00 a.m. on June 13th. Because Connected has not yet permanently removed the file, these versions are all still available.
June 1 |
June 2 |
June 3 |
June 4 |
June 5 |
June 6 |
June 7 |
June 8 |
June 9 |
June 10 |
June 11 |
June 12 |
June 13 |
|
|
|
|
|
|
delete notification received |
|
Now, suppose that the retention process runs on Mark's data at 11:01 a.m. on June 13th. It uses the corporate AcmeXYZ retention policy, which has the following effect:
-
Daily versions = 10. Keeps the latest version available for each of the 10 previous calendar days: June 3 through June 12.
Although Mark deleted the file, Connected does not automatically remove all versions of it. It applies the retention process on deleted files in the same manner as active ones and keeps those within the retention period.
Connected retains only the daily version on June 7th because it is the only one within the past 10 calendar days from the time that the retention process runs.
-
Recent versions = 5. Keeps up to the five most recent versions, starting from 11:01 a.m. on June 13th.
Daily versions within this count are also considered a recent version. Recent versions are time-bound by the daily versions value. Therefore, in this case, a recent version cannot be from before June 3rd so the only recent versions of the file are from June 7th.
The following illustrates how the retention process impacts the versions of the file stored in Connected.
12 days in the past | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Current day |
---|---|---|---|---|---|---|---|---|---|---|---|---|
June 1 |
June 2 |
June 3 |
June 4 |
June 5 |
June 6 |
June 7 |
June 8 |
June 9 |
June 10 |
June 11 |
June 12 |
June 13 |
|
|
|
|
|
|
delete notification received |
retention runs |
In this example, retention processes Mark's files again on June 22nd. On this date, all versions of the deleted file are past the policy's retention period of 10 calendar-days from the day that retention runs. As a result, Connected uses the policy's grace period to determine whether to retain the latest version of the file. Connected retains the file only if the retention process runs within the grace period of the file's deletion notification. Using a grace period in this manner ensures that Connected keeps one version of the deleted file for a minimum amount of time. The grace period always equals the number of days defined by the policy's daily versions value.
Mark deleted the file on June 12th and retention runs on June 22nd, which is within the 10 calendar-day grace period (June 13 through June 22). Therefore, Connected retains the most recent version and permanently removes the other, as shown in the following table.
15 days in the past | ... | 10 | 9 | 8 | ... | 1 | Current day |
---|---|---|---|---|---|---|---|
Grace period: |
day 1 |
2 | ... | 9 | 10 | ||
June 7 | ... | June 12 | June 13 | June 14 | ... | June 21 | June 22 |
|
|
delete notification received |
retention runs |
Now suppose for illustrative purposes that the retention process runs again on June 23rd. Once again, because the deleted file is past the retention period, the retention process uses the policy's grace period to determine whether to keep it. In this case, the retention process runs outside the 10 calendar-day grace period of the deletion notification (June 13 through June 22), so Connected permanently removes the file.
16 days in the past | ... | 11 | 9 | 8 | ... | 2 | 1 | Current day |
---|---|---|---|---|---|---|---|---|
Grace period: |
day 1 |
2 | ... | 9 | 10 | |||
June 7 |
... |
June 12 |
June 13 |
June 14 | ... | June 21 | June 22 | June 23 |
|
|
delete notification received |
retention runs |