Question about expired backups

[Manuel Imperiale]

Hi,

I've some expired backups stored in an AWS S3 bucket and when I try to install velero in a new cluster the backups are removed because they expired. The command that I'm running is the next one:
```
velero install \
--provider velero.io/aws \
--bucket my-migration \
--plugins velero/velero-plugin-for-aws:v1.4.0-rc.1 --default-volumes-to-restic=true \
--backup-location-config region=eu-central-1 --snapshot-location-config region=eu-central-1 --use-restic \
--use-volume-snapshots=true \
--secret-file credentials-velero
```

Is it possible to ignore the expiration date? Why velero is removing them?

[Tiger Kaovilai]

Please check Set a backup to expire - Velero Docs - How Velero Works 

The TTL flag allows the user to specify the backup retention period with the value specified in hours, minutes and seconds in the form --ttl 24h0m0s. If not specified, a default TTL value of 30 days will be applied.

The effects of expiration are not applied immediately, they are applied when the gc-controller runs its reconciliation loop every hour.

Expiration date may not be ignored. 

--
You received this message because you are subscribed to the Google Groups "Project Velero" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectveler...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectvelero/cb195304-b950-4196-991f-99dbc8e24ea1n%40googlegroups.com.

[Scott Seago]

The purpose of the expiration date is to tell velero when it's safe to
delete backups so that ancient backups that are no longer needed don't
fill up cloud storage. You may want to keep them longer than the
default 30 days, so if you want to keep them longer, set the ttl to a
longer expiration period. You can set that period long enough so as to
effectively never delete them if you need to keep them around forever.

Scott

> To view this discussion on the web visit https://groups.google.com/d/msgid/projectvelero/CACenGS7kNJhNRXpYsmvSo1LtaCC3Y7m%3DkhfxEROjkgvz4rtj8A%40mail.gmail.com.

[Manuel Imperiale]

I was probably not clear enough. I'm trying to migrate a velero backup to a new cluster but the latest backup that I've already expired 10 days ago. So, when I try to install velero in the new cluster and make it point to the AWS bucket velero simply remove them and I can't even edit the expiration date. I did security copies of the buckets before to install and I can clearly see that when I start the installtion the backups are removed. Is there a way to change the expiration date on the fly?

[Scott Seago]

So if that bucket had been connected to the prior Velero cluster the
whole time, it would have already been deleted. As far as I know there
is no support for ignoring garbage collection within Velero itself --
you could possibly try editing the expiration in the metadata in the
bucket itself prior to adding the BSL to a new cluster, although I've
never tried this myself and I wouldn't consider that an officially
supported approach. Officially, an expired backup is treated as
invalid and/or ready for garbage collection. But for future reference,
this can be modified on existing backups prior to expiration from the
cluster itself -- but obviously that won't work here since it will be
deleted before you have a chance to edit it.

Scott

> To view this discussion on the web visit https://groups.google.com/d/msgid/projectvelero/30e922b0-a6e2-4dc3-afeb-4c50f23bbfdan%40googlegroups.com.

[Tiger Kaovilai]

Some good news

Q2: You can start the velero server in restore only mode using the --restore-only flag to the velero install command. This will disable the gc controller ensuring that none of the backups are garbage collected.

I initially wrote my answer without checking out past velero issues first.

Try follow the Q2 steps at https://github.com/vmware-tanzu/velero/issues/3042#issuecomment-719103159 to use restore only mode which disables gc controller. 

To view this discussion on the web visit https://groups.google.com/d/msgid/projectvelero/CABEVz6-qYk%3DMJMd1-NKCxui8VUkyCP7TpYjijomySSHU%3D_bT8w%40mail.gmail.com.

[Tiger Kaovilai]

In addition, if https://github.com/openshift/oadp-operator/issues/760#issuecomment-1186785690 is to go by, the flag may not work as expected.. however there is a workaround where you can mark BackupStorageLocation.spec.accessMode=ReadOnly.

[Manuel Imperiale]

Scott, that is exactly the problem, the bucket have not been connected to velero all the time. We created a new cluster and a new bucket to store the backups and now the old bucket has expired backups that were not collected.

Tiger, thank you for your help! It worked!