Hi Bernardo and Stefan, Thanks for the feedback. I agree that there are several benefits to having backup and restore in Sidecar, especially regarding isolation, dependencies, and being able to evolve the feature independently from Cassandra itself. I would be happy to explore and contribute to that direction, potentially in my free time, and I may also be able to bring this discussion to my company later.
My main concern is more about the entry point for users. In my current environment, we are actually trying to reduce our use of Sidecars and other additional processes to reduce the overall footprint. I also think there may be users who would prefer having a basic built-in solution in Cassandra rather than having to deploy another component just to get backup and restore. Maybe there is a middle ground here. We could have an opt-in, generic backup/restore capability in Cassandra core, similar in spirit to the unified repair solution, without bringing any third-party cloud dependencies into Cassandra. For example, the core could provide the backup/restore abstractions and lifecycle, with a pluggable storage implementation provided by the user or another component. This could serve as a simple entry-level solution, while a more complete implementation with cloud-specific integrations could live in Sidecar. I don't know yet whether this split makes sense from an architectural perspective, but I think it could be worth exploring. I would be interested in hearing what others think about this approach. Thanks, Victor Em ter., 6 de out. de 2026 às 07:49, Štefan Miklošovič < [email protected]> escreveu: > 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 >
