> V1.1.0 > Explanations > How many kloset stores
Version v1.1.0

Beta Version

You're viewing documentation for version v1.1.0. Beta versions are subject to changes and may not represent the final stable release. Do not use in production environments.

How many Kloset Stores should you create?

Last reviewed: 2026-01-30 / Plakar v1.1.0

A common design question when setting up backups with Plakar is how many Kloset Stores to create.

Should you use:

  • A single store for everything?
  • Separate stores for servers, SaaS data, or cloud buckets?
  • One store per system?

There is no universal answer. The right choice depends on how your data is structured and how you want to manage it.

The key idea: Kloset Stores are deduplication boundaries

You can view a Kloset Store as a deduplication unit. Data is deduplicated within a store, but never across stores. This means the number of stores you create directly affects:

  • Storage efficiency
  • Encryption boundaries
  • Operational complexity

Understanding how similar your data is, matters more than how many sources you have.

When a single Kloset Store makes sense

Using one store is often the simplest option.

This works well when:

  • Backup sizes are relatively small
  • Data across sources is largely similar
  • You want minimal operational overhead

Example: Similar data across many servers

Imagine 10 servers, each with 100 GB of data. Most of that data is identical: operating systems, shared libraries, common applications.

By storing all backups in a single Kloset Store, Plakar can deduplicate the shared data. Instead of storing 1 TB, only the unique portions are kept.

This approach maximizes deduplication and keeps management simple.

These numbers are illustrative and do not account for compression.

When multiple Kloset Stores are better

Multiple stores are often preferable when data sets have little or no overlap.

Example: Independent data sets

Consider 10 S3 buckets, each containing 100 GB of unrelated data.

Because there is no meaningful overlap, a single Kloset Store would provide little deduplication benefit. In this case, separating data into multiple stores can simplify management without increasing storage usage.

Separating stores for security or policy reasons

Deduplication is not the only reason to create multiple stores.

You may also want separation when:

  • Different data sets require different encryption keys
  • Access policies differ
  • Data has different retention or compliance requirements

Example: Same data, different trust boundaries

You might store internal backups and external customer backups separately, even if the data structure is similar, so each store can use a different encryption key.

Small data sets and simplicity

For many small backups (configuration files, small databases, metadata), the deduplication benefit may be minimal regardless of layout.

In these cases, using a single Kloset Store is often still the right choice simply because it is easier to operate.

Summary

When deciding how many Kloset Stores to create, consider:

  • How similar your data sets are
  • Whether deduplication efficiency matters
  • Whether data needs to be isolated for security or policy reasons
  • How much operational complexity you are willing to manage

In practice, many environments start with a single store and introduce additional stores only when a clear need appears.

Found a bug or mistake in the documentation? Create an issue on GitHub