Ууу, эт тебе к Хрычу, он у нас большой спец по хадупам, кассандрам

не надо провоцировать хрыча

по дефолту их нет, есть сторонние тулзы, либо второй вариант, бэкапить дату

в принципе бекапить data самый простой вариант, а потом просто тупо с ней запускать ноды, очистив коммит лог

но это путь говно, правильно делать rap3, и на каждый dc иметь хотя бы по 3 ноды

А у veeam ничего нет, случаем? Нагуглить не удалось, а саппорт/сейлов через заказчика долго пинать будет

нет ничего, есть у датаскакса но это говно, проще делать отдельный раздел\subvol под data и его бэкапить

восстанавливаешь дату, удаляешь коммит лог и запускаешь

да и то это плохая практика, хорошая практика это dc на каждую локацию и 5 нод, 3 ноды так терпимо

в случае если нет зависимости от rtw, кассандру лучше заменить на scylladb

тк на много, очень много быстрее компакшен и работа с томбстоунами

и опять же, каждая гео точка это отдельный DC, если в дс не в 1 стойке находятся ноды, то ещё и отдельный rack

документация параша, половина ошибок разобрана в гугл рассылках, и даже спустя 2 года дока не обновлена

с другой стороны я не знаю твои нагрузки, и не знаю как вы её используете, поэтому многие ошибки возможно ты даже не увидишь

напиши хоть кейс  свой, сколько геолокаций, сколько врайт\апдейт\делит операций планируется, какой обьём данных

Да, сорри, отвлекли:) Кейс следующий - платформа, на её базе ряд сервисов. К платформе подцеплен внешний кластер в качестве хранилища конфигураций и событий. У меня сейчас они попарно полгодика поживут, 1+1 под каждый сервис на 2 геоудалённых цода. Думаю снапшотить инкрементно vm + время от времени снапшоты киспейсов снимать. Самое веселье начнётся в следующем году, нужно будет собрать кластер, первоначально штук 20 будет, по 10 в  каждом цод , в конфиге планирую разнести по dc, но ограничиться 1 стойкой (хотя думаю про выделение отдельных стойки под каждый из сервисов, но тут нужно взвесить +/-/подводные камни). Сверху это всё будет балансироваться haproxy (в силу архитектуры фэйловера платформы нужно под 1 хостнейм упихать все ноды). rf3, cl each_quorum на запись, local_quorum на чтение, данные по random partitioner распределяются. Собственно, задача следующая - обеспечить сохранность данных и оперативное восстановление в случае падения бомбы на 1 из цодов :)

А, ну и да, бэкапы нужно выносить в третье место (читай - схд)

😕то есть 2 dc, где 10 кассандр(плохо правда, лучше либо 9 либо 11) в 1 стойке?

да, всё так. А почему ассиметрично лучше?

убей архитектора