Improve filename for generated backups #366

Closed
opened 2022-12-10 19:23:33 +00:00 by 3wordchant · 3 comments
Owner

Currently, running abra app backup foo.bar.com db, where foo.bar.com has a STACK_NAME set to keycloak results in a backup name like keycloak_db_623701256.tar.gz.

Two improvements:

  1. Use the app name instead of STACK_NAME (STACK_NAME isn't really visible to operators elsewhere, and the ability to override it is mostly for legacy purposes?)
  2. A human-readable date, e.g. like the output of date +"%FT%T%z", e.g. 2022-12-10T04:22:44-0000
Currently, running `abra app backup foo.bar.com db`, where `foo.bar.com` has a `STACK_NAME` set to `keycloak` results in a backup name like `keycloak_db_623701256.tar.gz`. Two improvements: 1. Use the app name instead of `STACK_NAME` (`STACK_NAME` isn't really visible to operators elsewhere, and the ability to override it is mostly for legacy purposes?) 2. A human-readable date, e.g. like the output of `date +"%FT%T%z"`, e.g. `2022-12-10T04:22:44-0000`
3wordchant added the
enhancement
abra
labels 2022-12-10 19:23:34 +00:00
Owner

Use the app name instead of STACK_NAME (STACK_NAME isn't really visible to operators elsewhere, and the ability to override it is mostly for legacy purposes?)

It is kind of awkward to do because we have some code in the core that honours this edge case / legacy practice but then we'd have to implement a special case for not honouring it for backups. It would simplify the code if we didn't have to do this ofc. So, do we think it's worth it? Or should we aim instead to migrate recipe configs away from this STACK_NAME usage?

> Use the app name instead of STACK_NAME (STACK_NAME isn't really visible to operators elsewhere, and the ability to override it is mostly for legacy purposes?) It is kind of awkward to do because we have some code in the core that honours this edge case / legacy practice but then we'd have to implement a special case for not honouring it for backups. It would simplify the code if we didn't have to do this ofc. So, do we think it's worth it? Or should we aim instead to migrate recipe configs away from this `STACK_NAME` usage?
Owner

With the following:

func TimeStamp() string {
	ts := time.Now().UTC().Format(time.RFC3339)
	return strings.Replace(ts, ":", "-", -1)
}

I was able to get:

2023-01-22T17-47-16Z

Certainly more useful, anything that can be improved?

With the following: ```go func TimeStamp() string { ts := time.Now().UTC().Format(time.RFC3339) return strings.Replace(ts, ":", "-", -1) } ``` I was able to get: > 2023-01-22T17-47-16Z Certainly more useful, anything that can be improved?
Author
Owner

Great improvement for now, nice one!

Great improvement for now, nice one!
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#366
No description provided.