Re: Backup strategies for rgw s3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Adam,
we started a github project for s3/SWIFT synchronization, backup, migration
and more use cases.
You also can use it in combination with backup solutions.

https://github.com/clyso/chorus

Joachim

  joachim.kraftmayer@xxxxxxxxx

  www.clyso.com

  Hohenzollernstr. 27, 80801 Munich

Utting a. A. | HR: Augsburg | HRB: 25866 | USt. ID-Nr.: DE2754306



Am Mi., 25. Sept. 2024 um 19:11 Uhr schrieb Shilpa Manjrabad Jagannath <
smanjara@xxxxxxxxxx>:

> starting from quincy, you can define rules for lifecycle to execute on
> Archive zone alone by specifying
> <ArchiveZone/> flag under <Filter>
>
> https://tracker.ceph.com/issues/53361
>
>
> On Wed, Sep 25, 2024 at 7:59 AM Adam Prycki <aprycki@xxxxxxxxxxxxx> wrote:
>
> > Hi,
> >
> > I'm currently working on a project which requires us to backup 2
> > separate s3 zones/realms and retain it for few months. Requirements were
> > written by someone who doesn't know ceph rgw capabilities.
> > We have to do incremental and full backups. Each type of backup has
> > separate retention period.
> >
> > Is there a way to accomplish this with in a sensible way?
> >
> > My fist idea would be to create multisite replication to archive-zone.
> > But I cannot really enforce data retention on archive zone. It would
> > require us to overwrite lifecycle policies created by our users.
> > As far as I know it's not possible to create zone level lifecycle
> > policy. Users get their accounts are provisioned via openstack swift.
> >
> > Second idea would be to create custom backup script and copy all the
> > buckets in the cluster to different s3 zone. Destination buckets could
> > be all versioned to have desired retention. But this option feels very
> > hackish and messy. Backing up 2 separate s3 zones to one could cause
> > collision in bucket names. Prefixing bucket names with additional
> > information is not safe because buckets have fixed name length.
> > Prefixing object key name is also not ideal.
> >
> > Best regards
> > Adam Prycki
> > _______________________________________________
> > ceph-users mailing list -- ceph-users@xxxxxxx
> > To unsubscribe send an email to ceph-users-leave@xxxxxxx
> >
> _______________________________________________
> ceph-users mailing list -- ceph-users@xxxxxxx
> To unsubscribe send an email to ceph-users-leave@xxxxxxx
>
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux