Closed jnummelin closed 5 years ago
We definitely need to make a backup of all the essential files too. Collecting here the list of files/dirs we need to take int account:
A "backup" option isn't useful without also having a "restore" option - would it make more sense to start with a custom pharos-cluster backup
command producing a .tar.gz
, and then allow feeding that .tar.gz
back into something like pharos-cluster up --from-backup=
? That would easily work for restoring the kube cluster metadata itself, but not things like persistent volume contents.
Using pharos-cluster backup
for automated backups from outside of the kube cluster would only need access to the SSH keys... alternatively the same logic would be self-hosted as a kube service, writing the backup somewhere where it could be retrieved for use with pharos-cluster up
.
The concept of a generic "kube backup add-on" sounds more relevant for usecases like backing up volumes?
A "backup" option isn't useful without also having a "restore" option - would it make more sense to start with a custom pharos-cluster backup command producing a .tar.gz, and then allow feeding that .tar.gz back into something like pharos-cluster up --from-backup=?
Yes, that sounds like something I had in mind too. 👍
The concept of a generic "kube backup add-on" sounds more relevant for usecases like backing up volumes?
Yeah, the issue title is quite misleading. But backing up volumes is whole different story, depends highly on the volume "provider" and many other things. Not top prio IMO for Pharos. In many cases there's some kind of a "sidekick" for data backup.
Would be nice to get some backup setup automatically as on add-on.
Not sure if we'd need to backup anything else than etcd?