Eugene Klimov

> Why did I get these broken backups? looks like your upload operation not finished, backup_name/metadata.json create only when upload data +table metadata complete) don't know reason (container restart maybe?),...

Unfortunately, s3 disk not full supported by `clickhouse-backup` right now During adding s3 support we didn't properly clean data in test case, and currently OK in test is false positive...

what exatcly you mean when say "partition name" ? do you mean name which generated from PARTITION BY clause during CREATE TABLE execution?

> By "partition name", I mean 'name' column from above SQL. In source clickhouse, the partition name in default disk changes from '2022_6_6_0' to '2022_1_1_0' in restored clickhouse this is...

no estimate with this feature now, don't figure out how to make it on s3 side on v2 branch we already implements `use_embedded_backup_restore: true` which allow us to backup s3...

You tried to restore in server with data and schema exists?

look like you see `warn` not `error` what exactly means "renamed" ?

did you tried `clickhouse-backup restore --rm ` ? by default clickhouse-backup operated only with objects which contains in backup metadata and know nothing about objects which already present in your...

ok. understood, ok. option make sense

@ViktorNazarenko-ST if we add `check_table_dependencies=0` then `dictionary_for_source_table_old` stay exists would be better implements delete dependencies first?