Skip to content

Commit

Permalink
updating doc
Browse files Browse the repository at this point in the history
Signed-off-by: Pawan <pawan@mayadata.io>
  • Loading branch information
pawanpraka1 committed Sep 8, 2020
1 parent e3ac523 commit fa95983
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 7 deletions.
8 changes: 4 additions & 4 deletions pkg/mgmt/backup/doc.go
Original file line number Diff line number Diff line change
Expand Up @@ -21,13 +21,13 @@ The Backup flow is as follows:
- It will save the namespace information where the pvc is created also while taking the backup. Plugin will use this info if restoring without a namespace mapping to find if volume has already been restored.
- plugin then creates the ZFSBackup CR with the destination volume and remote location where the data needs to be send.
- plugin then creates the ZFSBackup CR with status as Init and with the destination volume and remote location where the data needs to be send.
- Backup controller (on node) keeps a watch for new CRs associated with the node id. This node ID will be same as the Node ID present in the ZFSVolume resource.
- The Backup controller will take a snapshot and then send the data to the remote location.
- if Backup status == init and not marked for deletion, the Backup controller will take a snapshot which needs to be send for the Backup purpose.
- if Backup status == init and not marked for deletion, Backup controller will execute the `zfs send | remote-write` command.
- Backup controller will execute the `zfs send | remote-write` command which will send the data to the Backup server which is a server running by the plugin. The plugin will read the data and send that to remote location S3 or minio.
- If Backup is deleted then corresponsing snapshot also gets deleted.
Expand All @@ -40,7 +40,7 @@ Limitation :-
* Backup status update also failed, then backup will be retried from the beginning (TODO optimize it)
* Backup status update is successful, the Backup operation will fail.
- A snapshot will exist as long as Backup is be present and it will be cleaned up when the Backup is deleted.
- A snapshot will exist as long as Backup is present and it will be cleaned up when the Backup is deleted.
*/

Expand Down
7 changes: 4 additions & 3 deletions pkg/mgmt/restore/doc.go
Original file line number Diff line number Diff line change
Expand Up @@ -16,11 +16,12 @@ limitations under the License.

/*
The restore flow is as follows:
- plugin creates a restore storage volume(zvol or dataset)
At the backup time, the plugin backs up the ZFSVolume CR and at while doing the restore we have all the information related to that volume. The plugin first creates the restore destination to store the data.
At the backup time, the plugin backs up the ZFSVolume CR and while doing the restore we have all the information related to that volume. The plugin first creates the restore destination to store the data.
- plugin then creates the ZFSRestore CR with the destination volume and remote location from where the data needs to be read
- plugin then creates the ZFSRestore CR with the destination volume and remote location as its server information from where the data will be read for restore purpose.
- restore controller (on node) keeps a watch for new CRs associated with the node id. This node ID will be same as the Node ID present in the ZFSVolume resource.
Expand All @@ -41,7 +42,7 @@ Limitation with the Initial Version :-
- If the restore doesn't have the specified backup, the plugin itself fails that restore request as there is no Backup to Restore from.
- If the same volume is restored twice, the data will be written again. The plugin should fail this kind of request.
- If the same volume is restored twice, the data will be written again. The plugin itself fails this kind of request.
*/

Expand Down

0 comments on commit fa95983

Please sign in to comment.