github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-03-09 07:13:35 -05:00
Code Issues 219 Packages Projects Releases 2 Wiki Activity

How to dump 0.24.6 data in containerised environment? #620

New Issue
Open
opened 2025-11-01 21:00:29 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-01 21:00:29 -05:00
Owner
Copy Link

Originally created by @xeruf on GitHub (Sep 12, 2025).

Description

the -p flag to set a backup target is not yet available in the latest stable version 0.24.6, and I cannot dump to the default path:

❯ kubectl exec -n stackspout vikunja-extra-58655cd9bd-twr7x -- ./vikunja dump
Defaulted container "vikunja-extra" out of: vikunja-extra, debugger-zxgdn (ephem)
2025-09-12T12:26:12Z: INFO	▶ 001 Using config file: /etc/vikunja/config.yml
2025-09-12T12:26:12Z: INFO	▶ 002 Running migrations…
2025-09-12T12:26:12Z: INFO	▶ 06a Ran all migrations successfully.
2025-09-12T12:26:12Z: CRITICAL	▶ 06b error opening dump file: open vikunja-dump_2025-09-12_12-12-12.zip: permission denied
❯ kubectl exec -n stackspout vikunja-extra-58655cd9bd-twr7x -- ./vikunja dump -p /app/vikunja/files
Defaulted container "vikunja-extra" out of: vikunja-extra, debugger-zxgdn (ephem)
Error: unknown shorthand flag: 'p' in -p
unknown shorthand flag: 'p' in -p
Usage:
  vikunja dump [flags]

Flags:
  -h, --help   help for dump

command terminated with exit code 1

since there are no other utilities on the container, I cannot work around that by entering a different directory as I used to

Which alternatives did you consider using instead?

upgrading to 1.0 without backup, yikes! (or doing a database dump but that's a bit of a hassle)

Originally created by @xeruf on GitHub (Sep 12, 2025). ### Description the `-p` flag to set a backup target is not yet available in the latest stable version 0.24.6, and I cannot dump to the default path: ```sh ❯ kubectl exec -n stackspout vikunja-extra-58655cd9bd-twr7x -- ./vikunja dump Defaulted container "vikunja-extra" out of: vikunja-extra, debugger-zxgdn (ephem) 2025-09-12T12:26:12Z: INFO ▶ 001 Using config file: /etc/vikunja/config.yml 2025-09-12T12:26:12Z: INFO ▶ 002 Running migrations… 2025-09-12T12:26:12Z: INFO ▶ 06a Ran all migrations successfully. 2025-09-12T12:26:12Z: CRITICAL ▶ 06b error opening dump file: open vikunja-dump_2025-09-12_12-12-12.zip: permission denied ❯ kubectl exec -n stackspout vikunja-extra-58655cd9bd-twr7x -- ./vikunja dump -p /app/vikunja/files Defaulted container "vikunja-extra" out of: vikunja-extra, debugger-zxgdn (ephem) Error: unknown shorthand flag: 'p' in -p unknown shorthand flag: 'p' in -p Usage: vikunja dump [flags] Flags: -h, --help help for dump command terminated with exit code 1 ``` since there are no other utilities on the container, I cannot work around that by entering a different directory as I used to ### Which alternatives did you consider using instead? upgrading to 1.0 without backup, yikes! (or doing a database dump but that's a bit of a hassle)
GiteaMirror commented 2025-11-01 21:00:29 -05:00
Author
Owner
Copy Link

@xeruf commented on GitHub (Sep 12, 2025):

I can also not use kubectl cp to move anything onto or out of the pod:

❯ kubectl cp -n stackspout vikunja-extra-58655cd9bd-pj6l5:/app/vikunja/vikunja .
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "70c7ffe9c83b19c964b574cf6095e7b9055f805d656b16fbd1133b84ce9820cc": OCI runtime exec failed: exec failed: unable to start container process: exec: "tar": executable file not found in $PATH
@xeruf commented on GitHub (Sep 12, 2025): I can also not use `kubectl cp` to move anything onto or out of the pod: ```sh ❯ kubectl cp -n stackspout vikunja-extra-58655cd9bd-pj6l5:/app/vikunja/vikunja . error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "70c7ffe9c83b19c964b574cf6095e7b9055f805d656b16fbd1133b84ce9820cc": OCI runtime exec failed: exec failed: unable to start container process: exec: "tar": executable file not found in $PATH ```
GiteaMirror commented 2025-11-01 21:00:29 -05:00
Author
Owner
Copy Link

@xeruf commented on GitHub (Sep 12, 2025):

I went into a very curious rabbithole to dig into the container using something along the lines of:

kubectl debug -it -n stackspout vikunja-extra-58655cd9bd-twr7x --image=busybox --target=vikunja-extra

and I managed to obtain a dump, yei!
if anybody is interested in the whole process, feel free to ask...

still think the -p flag should be made available in a patch 0.24.7

@xeruf commented on GitHub (Sep 12, 2025): I went into a very curious rabbithole to dig into the container using something along the lines of: kubectl debug -it -n stackspout vikunja-extra-58655cd9bd-twr7x --image=busybox --target=vikunja-extra and I managed to obtain a dump, yei! if anybody is interested in the whole process, feel free to ask... still think the `-p` flag should be made available in a patch 0.24.7
GiteaMirror commented 2025-11-01 21:00:30 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 12, 2025):

I would do a database backup and then upgrade Vikunja in place.

or doing a database dump but that's a bit of a hassle

Does that mean you don't have a job which regularly does backups? What would you do if your server hardware burned right now?

@kolaente commented on GitHub (Sep 12, 2025): I would do a database backup and then upgrade Vikunja in place. > or doing a database dump but that's a bit of a hassle Does that mean you don't have a job which regularly does backups? What would you do if your server hardware burned right now?
GiteaMirror commented 2025-11-01 21:00:31 -05:00
Author
Owner
Copy Link

@xeruf commented on GitHub (Sep 12, 2025):

we do have backups of all volumes including all databases, but the recovery is a bit of a hassle

@xeruf commented on GitHub (Sep 12, 2025): we do have backups of all volumes including all databases, but the recovery is a bit of a hassle
GiteaMirror commented 2025-11-01 21:00:31 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 12, 2025):

But you could restore from backup if things go sideways during the upgrade? If that's the case, I don't see a problem upgrading in place.

@kolaente commented on GitHub (Sep 12, 2025): But you could restore from backup if things go sideways during the upgrade? If that's the case, I don't see a problem upgrading in place.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/caldav
area/filters
area/frontend
area/gantt
area/internal-code
area/typesense
bug
changes requested
confirmed
dependencies
enhancement
good first issue
help wanted
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#620
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?