FREQUENTLY ASKED QUESTIONS ABOUT DISKOVER

Frequently asked, clearly answered.



What the two platforms are, who they are for, and how they differ.

Diskover Data offers two platforms for unstructured data, Diskover and CloudSoda, built on one shared foundation. Both index the files across your storage systems into one searchable catalog, show what you hold, who owns it, what it costs, and when it was last used, and act on it by rule. Diskover adds deep metadata enrichment, a plugin ecosystem, and advanced search. CloudSoda adds simple SaaS or cloud deployment, cost modeling and forecasting, and its own data mobility engine.
Organizations with large file estates spread across more than one storage system. The people who use it day to day are storage and infrastructure teams, data engineers preparing sets for analysis, research and production teams looking for their own work, and finance teams who want storage spend attributed to a department or project.
Media and entertainment, semiconductor and electronic design automation (EDA), energy, and life science and healthcare each have a dedicated solution page. The platform itself is not industry-specific. What differs by sector is the plugins and the metadata that matters, which is why those pages exist separately.
They share the same foundation: indexing, a searchable metadata catalog, analytics, automation, and the AI Connector. Diskover is built for depth, with business-centric metadata enrichment, over 50 plugins, file actions, and advanced queries. CloudSoda is built for simplicity and cost control, with SaaS or cloud deployment, FinOps modeling and forecasting, and a proprietary data mobility engine. Explore the platforms page to compare them.
Yes. Each platform runs on its own, with its own scanning, catalog, analytics, and automation. They also connect: a Diskover plugin can hand data movement to CloudSoda.
Vendor tools report on their own equipment. This reports across all of it. Most estates hold the same project on fast storage, on an archive tier, and in a cloud bucket at the same time, and no single vendor report sees that. One catalog across every system is the view that is usually missing.
Enterprise search indexes content so people can find documents. This indexes metadata so teams can manage storage: what exists, what it costs, who owns it, and what should happen to it next. Different question, different index, different outcome. Analysts call this data discovery, finding and classifying files by their metadata rather than by reading their contents.
Diskover has open source foundations, which is why the architecture is inspectable and built on standard interfaces rather than being a closed appliance. The enterprise platform adds the enrichment, automation, scale, and support that production estates need.
Because it carries a cost and a value, and both can be measured. A file has a storage cost you can calculate per gigabyte, and a worth that depends on whether anyone still uses it. Treating data as an asset means knowing which files earn their keep and which are only accumulating.
AI-ready data is file data that has been defined, described, and filtered so a model can use it within known boundaries, and our glossary entry on AI-ready data covers the related terms. Diskover gets you there by cataloging every file across your storage, adding the metadata that describes what each file is, and selecting the sets that should feed a lakehouse, vector database, or model pipeline.
File count is the real constraint, not capacity. Diskover has indexed 1.4 billion files in 2 hours on three nodes, about 200,000 files per second. Estates in the billions of files run in production today. The practical limit is how much read throughput your storage will give the crawler.

What happens to your files when they are indexed, and what never happens to them.

No. The catalog is built from file metadata, which is information about each file such as its name, size, type, path, owner, permissions, and timestamps. The standard scan does not open the files. Optional plugins add further metadata, for example, media attributes such as codec and duration, hash values for finding duplicates, or fields read from scientific file formats. Those plugins read the files they are set to inspect.
A crawler walks the storage, reading file metadata rather than contents, and writes it into a search index. Crawls run in parallel across volumes and repeat on a schedule, which is how a catalog of billions of files stays current rather than becoming a one-off snapshot.
A searchable inventory of the metadata for every file and directory in a storage volume, taken at a moment in time. Searching the index is far faster than searching the storage system itself. You can keep several indices of the same volume from different dates, which is what makes before and after comparisons possible.
It depends on file count rather than capacity. Crawls run in parallel across volumes, and estates in the billions of files have been indexed, so scale is not the limiting factor. The practical constraint is how much read throughput your storage will give the crawler.
It reflects the most recent index rather than the live state of your storage. Your administrator sets the schedule, and volumes are scanned in parallel so indices stay current. Hover over a volume name to see when it was last indexed. Files created since then appear after the next scan.
Crawls are scheduled, and the crawler reads rather than writes. Production storage sees a read client rather than an agent, so indexing can be timed around delivery windows, simulation runs, or any other peak period.
Indexing leaves files where they are. Both platforms move files only when a rule or an authorized user tells them to, and every move is recorded. Nothing moves because it was indexed.
No. What you are looking at is an index of metadata rather than the files themselves, so you cannot edit or delete real data from the interface. Where your organization has enabled file actions, authorized users can launch specific operations on files or directories, and those are controlled by role-based permissions set by your administrator.
It identifies files with identical content by hash value, and files sharing the same data by hardlink count. A hash is a fingerprint calculated from a file’s content, so two files with the same hash hold the same data even when their names and locations differ. Whether hash indexing is enabled depends on your deployment.

Where each platform runs, what it needs, and how it fits into your network.

Diskover runs on Linux servers with read access to the storage you want indexed, with optional Windows task workers for Windows file shares, and scales by adding workers and nodes. CloudSoda runs on-premises, in the cloud, or as a service, with agents that connect to the storage it scans and moves. Sizing depends on file count rather than capacity, so the first question is always how many files, not how many terabytes.
Diskover runs in your environment, on your own servers or in your own cloud account. Your data and your index stay with you. That is deliberate, because the estates this is built for are usually too large and too regulated to send anywhere. CloudSoda can run on-premises or as a service, depending on your plan.
No. It crawls over standard protocols as a read client. Nothing is installed on the storage platform itself, which means indexing does not depend on vendor agent support and does not modify the systems being indexed.
Yes. Diskover supports offline installation for air-gapped and restricted networks, and it needs no external service while running.
Installation and configuration are done by a system administrator and are covered step by step in the documentation. The usual path is to install, connect the first storage volume, run an initial index, review what the catalog found, then add volumes and enrichment rules once the first results look right.
Local and network file systems including Windows shares, enterprise network-attached storage including Dell PowerScale and NetApp, cloud object storage such as Amazon Simple Storage Service (S3) and S3-compatible storage, Azure Blob, Google Cloud Storage, and Oracle Cloud Infrastructure, and cloud file services such as Microsoft OneDrive, SharePoint, and Google Drive. Each indexed location can be a volume, a share, a bucket, or a mount point. Which systems are connected in your environment is set by your administrator.

Who can see what, how access is controlled, and how your data is protected.

The platform holds metadata rather than file contents, which limits exposure by design. Access is controlled by role, authentication integrates with your existing directory, and Diskover runs inside your network on infrastructure you control.
Role-based access decides which volumes, paths, and actions each person can access. Permission-aware search means a user sees the files they are already entitled to see, so search does not become a way around existing storage permissions.
No. It reads permissions as metadata and reports on them. Changing who can reach a file stays with your storage system and your directory.
No. It reads file system access timestamps, not user activity. The record is about files rather than about people, which is what keeps it usable in environments where monitoring individuals would not be acceptable.
No. It queries the catalog, which holds metadata. File contents are never opened and never form part of an answer. That boundary is what allows it to run against restricted estates.
Transfers are encrypted in transit, and the platform reads with the access it is granted rather than requiring elevated storage privileges.
It answers the question an auditor actually asks, which is where a particular kind of file is and who owns it. Auto-tagging rules label files by name, path, type, and age, which turns that answer into a figure you can report rather than an estimate. It is evidence for an audit, not a compliance product.
Access tokens for connected AI tools are managed in settings and should be treated like passwords. Users can create their own tokens, and administrators can manage every token on the platform.
The legal documents page holds the current license agreements and privacy policy. The core security point is that the platform holds metadata, never file contents. If your review needs more detail, contact us directly.

What connects to what, and what you can build yourself.

A plugin connects the catalog to another system, either reading extra metadata from files or triggering an action elsewhere. There are over 50 plugins today, for metadata enrichment, orchestration, data mobility, AI, and file actions, and using them requires no code.
Plugins fall into five groups.
Metadata enrichment: these plugins add context the file system does not hold, such as media and image details, PDF information, Windows and Unix attributes, cost, and storage attributes from systems like Dell PowerScale and Spectra Logic.
Orchestration and integrity: these plugins automate the work, such as tagging files by rule, finding duplicates, checking checksums, flagging illegal or long file names, and comparing indexes over time.
Data mobility: these plugins move data, through CloudSoda, Dell SmartSync, or Rclone.
AI enablement: these plugins connect the catalog to AI assistants and analytics tools, through the Diskover MCP Server and a Parquet ingester, so teams work from AI-ready data.
File actions: these plugins let authorized users act on files from the interface, such as previewing, downloading, uploading, exporting, or sending files to another system.
Some plugins are built for one industry. Media teams use plugins for Avid, ShotGrid, Xytech, Telestream, and OpenEXR files. Life science teams use plugins that read research formats such as BAM sequencing files. Explore the plugins page for the full list.
Yes. Plugins follow a documented interface, and they can be built by Diskover, by partners, or by your own team. What a plugin reads and what it writes back are both yours to define.
Format-level plugins read more per file than a basic scan, so they cost time proportional to what they inspect. Plugins can be scoped to specific paths or file types, which is how teams keep enrichment targeted rather than universal.
No. It catalogs and selects the files that a vector database, lakehouse, or model pipeline then consumes. It answers which data should go in, not how that data is embedded or queried afterward.
Yes. The platform indexes storage from those vendors and others into one catalog, and the catalog can be delivered onward to Snowflake so file data sits alongside the rest of your data estate. Explore the partner pages for a list of our technology partners.
Yes. Metadata can be delivered into Snowflake or another analytics platform, so file data appears alongside structured data in the tools analysts already use rather than requiring a separate interface.

See storage costs and automate what happens to data as it ages.

From a cost per gigabyte that your administrator enters, globally, per volume, or per directory. That figure usually combines hardware or cloud cost, power, support contracts, administrator time, and subscription fees. Once set, cost appears against any file or directory and can be grouped by tier, project, department, or data age.
Yes. Reporting by owner or group gives total size, share of the estate, file count, and, where cost is configured, the spend attached to each one. That is what makes chargeback or showback a conversation about numbers rather than impressions.
Select two indices of the same environment and compare them. Growth and reduction show up by location, which is how teams track new projects, replication, and changes nobody expected.
No. Most reduction comes from moving rather than deleting. Inactive data goes to a lower tier and stays retrievable, which recovers capacity on the expensive tier without anyone making an irreversible decision.
Yes. Rules written against the catalog drive moves on a schedule. The move is carried out and the catalog updates when it completes.
A dry run shows the expected storage and egress costs before any data moves. Every transfer is logged, and automatic retries and rollback protect the data if a transfer fails partway.
Yes, and most teams do. The catalog is useful on its own, and rules are added once there is enough evidence to trust what they will select.
Rules written against catalog metadata run on the schedule you set, so retention applies as data ages rather than during a periodic review that nobody has time for. The catalog records what was retained and when, which is the evidence an audit asks for.
That depends on the target and the method chosen. Movement can be transparent to users, or it can be a deliberate relocation with a communicated path change. The catalog records the new location either way, so the data stays findable.
Yes. Transfers are checked on completion, which lets you treat a move as done rather than assumed.

Pricing, seats, and how to purchase.

Because the alternative is buying storage you do not need. An estate where nobody can say which files are cold keeps paying premium rates to hold data nobody opens, every month, indefinitely.
It depends on the platform and on how many files you index. Every plan on both platforms includes unlimited seats and users, so you never pay per person.
Diskover: the price is based on your file count and the plan you choose. Each plan adds features, from indexing and analytics up to automated workflows, with optional add-ons such as the AI Connector and industry add-ons.
CloudSoda: every plan includes the full platform. The price is based on scale: how many files you index and the size of the deployment. The AI Connector is optional.
Talk to us with a rough file count and the platform you are interested in, and you will get a real number.
Through the route that suits your procurement:
Directly from us: talk to our team and we will put together a quote.
Through Dell: email dell@diskoverdata.com.
On the Snowflake Marketplace: buy through your Snowflake account.
On the Oracle Cloud Infrastructure (OCI) Marketplace: buy through your Oracle Cloud account.
Through a channel partner: find a partner on our partners page.
Every plan includes unlimited seats and users. Explore the Diskover plans and CloudSoda plans pages for what each one includes.
Yes. Upgrades can be made at any point in the term.
Annual subscriptions are the standard term. Payment arrangements are agreed when you buy.
Cancellation terms are set out in your license agreement. Talk to us and we will walk you through your options.

How to see it working on your own data.

Book one and you get a walkthrough against realistic data, with time for the questions specific to your estate.
Everyone with a stake in your files. We recommend:
Storage and IT leaders: to see whether it answers their questions about capacity and cost.
Administrators: to see how it is installed, run, and kept current.
Governance and compliance teams: to see how files are found, tagged, and tracked for audits and retention.
Data users: the researchers, engineers, or production teams who will search it every day.
Yes. A proof of concept indexes a defined part of your estate so you see your own file counts, your own cold data, and your own numbers rather than a sample.
30 days, so you can see your own data, with our team beside you each week:
Week 1, connect: we install the platform and connect your first storage systems.
Week 2, index: we build the catalog, and your data stays in place.
Week 3, find: we review cold, duplicate, and sensitive data with your team.
Week 4, decide: we share a findings report and agree on next steps together.

Licenses, support, training, and documentation after you buy.

With the license key issued when your subscription starts. The documentation covers the steps.
No. A key is issued to one organization for the agreed deployment.
No. Licensing is per deployment:
Diskover: the node terms are set by your plan.
CloudSoda: each plan includes a set number of nodes.
Support comes with every annual subscription, including software version updates during the term.
Open a support ticket, included with your subscription:
Diskover: open a ticket on the Diskover support site.
CloudSoda: open a ticket on the CloudSoda support site.
You can also call our support teams, using the numbers on our support page. Have your version number ready and, where relevant, the storage location involved, since that is the first thing support will ask for.
Yes. The learning path takes administrators from first crawl to automated workflows, with a certification at each level, from positioning the platform to building plugins.
Yes. Full documentation covers installation, configuration, searching, reporting, and automation.
In each platform’s documentation, version by version, so a change between releases stays easy to trace long after it was announced:
Diskover: release notes on the Diskover support site.
CloudSoda: release notes on the CloudSoda support site.
Scroll to Top