Velero: Display backup's StartTimestamp in `ark backup get` output

Created on 27 Sep 2018  Â·  9Comments  Â·  Source: vmware-tanzu/velero

When importing back ups in to a cluster from object storage, the Kubernetes API server assigns a new creation time stamp to the Backup resource. This can be confusing when importing backups from a previous cluster and seeing that the creation times don't match.

Using the StartTimestamp field makes this consistent across all clusters.

-- ORIGINAL ISSUE --

What steps did you take and what happened:
I've created an scheduled backup running the command ark create schedule myns-backup --schedule="30 * * * *" --include-namespaces myns to try to create a backup for a given namespace.

After few hours, if I run ark backup get, I can see the following:

NAME                         STATUS      CREATED                          EXPIRES   SELECTOR
myns-backup-20180927093049   Completed   2018-09-27 11:30:49 +0200 CEST   29d       <none>
myns-backup-20180927083029   Completed   2018-09-27 10:30:29 +0200 CEST   29d       <none>
myns-backup-20180927073027   Completed   2018-09-27 09:30:27 +0200 CEST   29d       <none>
myns-backup-20180927064327   Completed   2018-09-27 08:43:27 +0200 CEST   29d       <none>
myns-backup-20180926163024   Completed   2018-09-26 18:30:24 +0200 CEST   29d       <none>
myns-backup-20180926153024   Completed   2018-09-26 17:30:24 +0200 CEST   29d       <none>
myns-backup-20180926143024   Completed   2018-09-26 16:30:24 +0200 CEST   29d       <none>
myns-backup-20180926142953   Completed   2018-09-26 16:29:53 +0200 CEST   29d       <none>

Later, I deployed Ark in other cluster with the same bucket configuration. However, if I ran the same command, it will show you this:

NAME                         STATUS      CREATED                          EXPIRES   SELECTOR
myns-backup-20180927093049   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180927083029   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180927073027   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180927064327   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180926163024   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180926153024   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180926143024   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>
myns-backup-20180926142953   Completed   2018-09-27 12:11:40 +0200 CEST   29d       <none>

The creation date doesn't match with the actual creation date of the scheduled backup in the original cluster.

What did you expect to happen:
See the actual date when the backup was created.

Environment:

  • Ark version (use ark version): Version: v.0.9.5
  • Kubernetes version (use kubectl version): v1.10.7
  • Cloud provider or hardware configuration: GKE
Good first issue Help wanted

Most helpful comment

Can I help to fix this? I'm able to help you

All 9 comments

Thanks for the report @marctc.

I think what you're seeing here is Ark in the 2nd cluster importing the backup JSON from the bucket, then registering the Backup objects in the API server of the new cluster, which updates the creation timestamp for that copy.

@heptio/ark-team @rosskukulinski Does it make sense to have our own, independent creation timestamp so we have a record of what the backup was originally made, instead of just when it was introduced to the cluster?

Yes, I think this is a good idea. I believe we previously discussed it although I don't remember where/when.

Yep - we definitely discussed and I'm +1 to doing this. It would fit nicely into v0.11.

Actually. we already have a StartTimestamp in the status. We probably just need to update the CLI to display it!

Sounds like y'all are already set, but a +1 from me as well. Ties in nicely to the work scheduled for 0.11, so +1 from me for the milestone as well.

Can I help to fix this? I'm able to help you

Yes please & thanks!

On Fri, Sep 28, 2018 at 4:18 AM Marc Tudurí notifications@github.com
wrote:

Can I help to fix this? I'm able to help you

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/heptio/ark/issues/883#issuecomment-425359824, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAABYiIKoivwDtPZ9BUMcLAlmWVKkw_fks5ufdttgaJpZM4W8hzU
.

@marctc let me know when you start on this so I can move it to in-progress.

I'm working on it. You can move it.

Was this page helpful?
0 / 5 - 0 ratings