To start with, I am not 100% sure what is exactly stored in ^ix-applications^.
I think all data related to:
- Kubernetes
- Docker
- Apps
- more !!??
- what not !!??
What ever it is an important dataset to backup. And the backup should be such that you can recover Docker, Apps and Kubernetes, in case of a severe event
I think there backups should be there on three levels:
1) regular ^ix-applications^ data set snapshots
2) backups on an other local dataset or even better on a remote dataset
3) backups from a particular app / docker instance
At the moment I am busy with the upper two levels.
If you look at the dataset GUI, than you see one ^ix-applications-folder^, however that is false representation of the real situation .... there is a lot invisible below that ^folder^. You really have to tell what ever backup method used, that it should work ^recursive^ !!!
Related to regular snapshots (1):
- I assume that they include everything within the dataset
- And I hope that nothing goes wrong in you recover that dataset
For the second level (2), I choose a replication task, which does recursively copy's the content of the dataset to a dataset on an other disk. For that purpose snapshots are used, and I think that it is vital that you use backups with a dedicated naming structure there e.g. 'LocalBackUps-<date-time-str>. If not the backups will be created against e.g. old snapshots, what is IMHO not the intention.
I hope, think, but did not test, that I could recover this way, recreate a working dataset on a new drive, even if the original data set get lost for whatever reason!
Does the described method, full fill my requirements:
- restoring to an earlier moment in time for kubernetes, apps and docker
- even when the original dataset is lost!?
Edit: added a screenshot from the ix-applications data set .... and from the replicated version of that dataset .,... which do look quite different.
I think all data related to:
- Kubernetes
- Docker
- Apps
- more !!??
- what not !!??
What ever it is an important dataset to backup. And the backup should be such that you can recover Docker, Apps and Kubernetes, in case of a severe event
I think there backups should be there on three levels:
1) regular ^ix-applications^ data set snapshots
2) backups on an other local dataset or even better on a remote dataset
3) backups from a particular app / docker instance
At the moment I am busy with the upper two levels.
If you look at the dataset GUI, than you see one ^ix-applications-folder^, however that is false representation of the real situation .... there is a lot invisible below that ^folder^. You really have to tell what ever backup method used, that it should work ^recursive^ !!!
Related to regular snapshots (1):
- I assume that they include everything within the dataset
- And I hope that nothing goes wrong in you recover that dataset
For the second level (2), I choose a replication task, which does recursively copy's the content of the dataset to a dataset on an other disk. For that purpose snapshots are used, and I think that it is vital that you use backups with a dedicated naming structure there e.g. 'LocalBackUps-<date-time-str>. If not the backups will be created against e.g. old snapshots, what is IMHO not the intention.
I hope, think, but did not test, that I could recover this way, recreate a working dataset on a new drive, even if the original data set get lost for whatever reason!
Does the described method, full fill my requirements:
- restoring to an earlier moment in time for kubernetes, apps and docker
- even when the original dataset is lost!?
Edit: added a screenshot from the ix-applications data set .... and from the replicated version of that dataset .,... which do look quite different.
Attachments
Last edited: