Skip to main content

We have a k8s cluster, using Kasten K10 to backup those workloads, has a k10 sidecar “attached” to each workload.

We have a daily backup job (or policy? Sorry that I am not familiar with K10’s term, that I might use wrong terms) that is configured with a retention period of 32 days, configured to export backup daily to a storage location, let’s say, a folder /storage. 

Everyday, if I go into the Linux OS that has access to /storage, I can see a bunch of files exported by K10 into /storage. Most are them are *.f files. I think some of them are full backup files and some are delta? They are not as clear as Veeam B&R’s *.vbk and *.vib files. But what I know is, these *.f files contain those 32 days of backup. We should be able to restore data of any 1 of those 32 days from these *.f files. (correct?)

Now, we have received a request from end user, that they want to keep the backup of a specific date, e.g. let’s day 1 Nov 2024, for longer than 32 days. They want to keep it for 1 year.

From my experience of using VB&R, all we need to do is, simply copy those *.vbk and *.vib files to some other long-term storage media, like, burn them to DVD or LTO tapes, then it’s done. I can keep the DVDs / tapes as long as end user wants. Even after 1 year, we can still use VB&R to restore data of 1 Nov 2024 from those *.vbk and *.vbi files in the DVDs / tapes. Even our end user thinks it should be as simple as this.

But in this case, our operation team (responsible for all the k8s, K10 operations) told us it’s not possible for K10. They said they tried to restore K10 backup from exported files older than their original retention period, and error occurred. They said it seemed K10 has added some kinds of “expiry date” into the backup files it exported. I asked the team to show me what error it was. But they have not yet provided.

I tried to google about this K10 “expiry date” behavior. But I couldn’t find anything about it.

Is it true?

 

I know a quicker / simpler way to find out should be to do a test, e.g. create a K10 job, maybe set retention period to 1 day, then try to restore from those files after 2 or 3 days. But I am more like on the user side, all the k8s and K10 operations are carried out by the operation team. I have no environment to test it directly, while our operation team’s answer to this question is simply as above.

@newbieguy Thanks for creating this topic. 

The files you see in your location targets are all chunked and encrypted. The data storage is different from VBR and its cannot be just copied over similar to VBK files. 

This data can only be decrypted and restored by the same Kasten instance that backed it up(there are other ways migrate and restore in another cluster).

We need the restorepoints in kasten to be intact for restoring this data. Also, I am not sure if there is a way currently to hold off an existing restorepoint without being retired or specify expiry for restorepoints other than its actual retention.  I will check on this and let you know shortly. 


@newbieguy Thanks for creating this topic. 

The files you see in your location targets are all chunked and encrypted. The data storage is different from VBR and its cannot be just copied over similar to VBK files. 

This data can only be decrypted and restored by the same Kasten instance that backed it up(there are other ways migrate and restore in another cluster).

We need the restorepoints in kasten to be intact for restoring this data. Also, I am not sure if there is a way currently to hold off an existing restorepoint without being retired or specify expiry for restorepoints other than its actual retention.  I will check on this and let you know shortly. 

Thank you very much for your answer.

Then I guess we better look for other ways to serve our end user’s request first.

Still, if you have any news on this issue, we will appreciate it~~


Comment