[BUG] Dashboards moved to another folder are not deleted from storage

[arnecls]

Describe the bug

When a dashboard is moved to another folder, a file with a different name is being created when creating a backup.
However, the old file will not be removed, leading to errors during import.

It has to be noted that we use GCS as a storage.

To Reproduce

• We use GCS as a remote storage
• Create a dashboard
• Create a backup
• Move the dashboard
• Create another backup

You will see that the dashboard is now existing twice in GCS with two different filenames.
This leads to an error during restore Board with same UID was already processed.

Expected behavior

The old file should be deleted.

Debugging Data (please complete the following information):

1. gdg version

0.7.1

2. gdg tools devel srvinfo (If you are able to connect to your grafana instance)

2024-12-19 09:12:06 INF  Database=ok
2024-12-19 09:12:06 INF  Commit=5b85c4c2
2024-12-19 09:12:06 INF  Version=11.1.0

3. Redacted output of: gdg tools contexts show (Or include your config )

storage: gcs
url: ***
token: ""
user_name: ***
password: ***
organization_name: trivago
watched_folders_override: []
watched: []
connections: null
user: null
dashboard_settings:
    nested_folders: false
    ignore_filters: true
output_path: backup

[safaci2000]

Hmm, I'm not sure this is a bug exactly. There's plenty of times where you want the local or gcs storage to persist and your final upload is a union of the two folders. I'm not opposed to have a feature flag that will remove the dashboards folder prior to download to reset the state and ensure it's a 1-1 mirror of upstream.

Keep in mind another pattern of using this, is to have the git data (aka local/cloud storage) as a source of truth so local file system would trump anything on grafana. You're using it in a way that's flipped. That's perfectly fine but I think turning on that behavior should be optional.

[arnecls]

This wouldn't be much of a problem if the upload wouldn't stop after occurring a duplicate ID.

We use this currently as a replication mechanism between a MySQL backed instance and two disk backed instances. Every time a user renames or moves a dashboard the upload breaks until we delete the old dashboard.
At the moment we solve this with a lifecycle rule, but until this rule hits, the sync is broken.

Suggestion:
If a duplicate ID is detected, use the more recent dashboard, warn about the issue, and continue the upload. As this might not be desirable for all use-cases, such a feature could be enabled through a flag similar to --skip-confirmation. Maybe something like --fix-duplicate-ids?