I also think that we should investigate how to integrate backup / restores in Sidecar rather than doing it in Cassandra. Dependency-wise, I think Sidecar already depends on s3 so that is for free already. If I am not mistaken, Sidecar already exposes a set of endpoints related to the restoration of data from S3 when running some Spark jobs, right? So this would be just a natural extension of that - a set of endpoints backuping to and restoring from an S3 bucket.
However, I think that we should make it generic enough in such a way that if somebody wants to do this against Azure or GCP they could. We should not "wire" S3 only. I am not sure how to do this though. These deps are quite "heavy", depending on their own dependency chain ... I do not have good experience with mixing various cloud libraries. What we do in our backup / restore solution is that we modularize it in such a way that a user can choose what cloud they go to deal with and they have only that cloud-specific libraries on the class path. On Tue, Oct 6, 2026 at 12:14 PM Bernardo Botella <[email protected]> wrote: > > Hi Victor! > > Thanks for bringing up this discussion 😊 > > I completely agree that a first citizen backup and restore mechanism in > Cassandra would be great. > > I’d like to explore a little bit more the solution involving Sidecar. While > it is true that it would “force” you to have yet another component running, > it definitely comes with a lot of benefits besides the current other features > it provides (control plane, analytics library, CDC over Kafka, to name some). > > It allows for a more modular approach to a Cassandra deployment. In my humble > opinion, having smaller, more specialized processes is the direction we > should be following, as opposed to keep making the core of the project bigger > and more complex. > It allows for a faster iteration in terms of software. When it comes to > version upgrades, it is definitely way easier to update just the sidecar than > the entire Cassandra core. It is also less risky. > Blast radius is also smaller. It is better to have the Sidecar affected if a > backup process stalls/breaks/misbehaves than the whole Cassandra core. > > > That’s my two cents! > Bernardo > > From: Victor Araujo <[email protected]> > Date: Monday, 5 October 2026 at 13:34 > To: [email protected] <[email protected]> > Subject: [DISCUSS] Backup and restore in Cassandra > > Hi everyone, > > I would like to discuss the possibility of having a built-in backup and > restore mechanism in Cassandra, including incremental backups and support for > external object storage such as S3. The main goal would be to provide a > supported solution while keeping the implementation provider-agnostic and > avoiding unnecessary operational overhead. > > I initially discussed this on Slack and was pointed to CEP-36 and the > previous discussions around external storage and snapshots. We also discussed > whether S3 would be too provider-specific, and whether Cassandra Sidecar > could be part of the solution. My concern with Sidecar is that introducing > another component would increase the operational footprint, which goes > against one of the goals of this work. I also have a small PoC on top of > trunk exploring some of these ideas. > > I'd be interested in hearing other opinions and any previous work I should > look at. If there is interest in pursuing this, would a draft CEP be a useful > next step so we can start working on the design in parallel? > > Link of the first slack discussion about this topic: > https://the-asf.slack.com/archives/CK23JSY2K/p1789021792614639 > > Thanks, > Victor Cavichioli
