diff --git a/site/docs/v1.3.2/disaster-case.md b/site/docs/v1.3.2/disaster-case.md
index 88f61e7c7..3934fd4ce 100644
--- a/site/docs/v1.3.2/disaster-case.md
+++ b/site/docs/v1.3.2/disaster-case.md
@@ -10,7 +10,7 @@ If you periodically back up your cluster's resources, you are able to return to
     velero schedule create <SCHEDULE NAME> --schedule "0 7 * * *"
     ```
     
-    This creates a Backup object with the name `<SCHEDULE NAME>-<TIMESTAMP>`.
+    This creates a Backup object with the name `<SCHEDULE NAME>-<TIMESTAMP>`. The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See [how velero works][1] for more information about backup expiry. 
 
 1.  A disaster happens and you need to recreate your resources.
 
@@ -31,9 +31,11 @@ If you periodically back up your cluster's resources, you are able to return to
 
 1. When ready, revert your backup storage location to read-write mode:
 
-   ```bash
-   kubectl patch backupstoragelocation <STORAGE LOCATION NAME> \
+    ```bash
+    kubectl patch backupstoragelocation <STORAGE LOCATION NAME> \
        --namespace velero \
        --type merge \
        --patch '{"spec":{"accessMode":"ReadWrite"}}'
     ```
+    
+[1]: how-velero-works.md#set-a-backup-to-expire
\ No newline at end of file
diff --git a/site/docs/v1.3.2/how-velero-works.md b/site/docs/v1.3.2/how-velero-works.md
index 85febb1df..543ab2f94 100644
--- a/site/docs/v1.3.2/how-velero-works.md
+++ b/site/docs/v1.3.2/how-velero-works.md
@@ -57,13 +57,15 @@ For example, if the cluster being backed up has a `gizmos` resource in the `thin
 
 ## Set a backup to expire
 
-When you create a backup, you can specify a TTL by adding the flag `--ttl <DURATION>`. If Velero sees that an existing backup resource is expired, it removes:
+When you create a backup, you can specify a TTL (time to live) by adding the flag `--ttl <DURATION>`. If Velero sees that an existing backup resource is expired, it removes:
 
 * The backup resource
 * The backup file from cloud object storage
 * All PersistentVolume snapshots
 * All associated Restores
 
+The TTL flag allows the user to specify the backup retention period with the value specified in hours, minutes and seconds in the form `--ttl 24h0m0s`. If not specified, a default TTL value of 30 days will be applied. 
+
 ## Object storage sync
 
 Velero treats object storage as the source of truth. It continuously checks to see that the correct backup resources are always present. If there is a properly formatted backup file in the storage bucket, but no corresponding backup resource in the Kubernetes API, Velero synchronizes the information from object storage to Kubernetes.
diff --git a/site/docs/v1.3.2/migration-case.md b/site/docs/v1.3.2/migration-case.md
index 41afcf9ef..85ec5edef 100644
--- a/site/docs/v1.3.2/migration-case.md
+++ b/site/docs/v1.3.2/migration-case.md
@@ -10,7 +10,7 @@ Velero can help you port your resources from one cluster to another, as long as
     velero backup create <BACKUP-NAME>
     ```
 
-    The default TTL is 30 days (720 hours); you can use the `--ttl` flag to change this as necessary.
+    The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See [how velero works][1] for more information about backup expiry. 
 
 1.  *(Cluster 2)* Configure `BackupStorageLocations` and `VolumeSnapshotLocations`, pointing to the locations used by *Cluster 1*, using `velero backup-location create` and `velero snapshot-location create`. Make sure to configure the `BackupStorageLocations` as read-only
     by using the `--access-mode=ReadOnly` flag for `velero backup-location create`.
@@ -46,3 +46,5 @@ Check that the second cluster is behaving as expected:
     ```
 
 If you encounter issues, make sure that Velero is running in the same namespace in both clusters.
+
+[1]: how-velero-works.md#set-a-backup-to-expire