Multi-Drive Storage for Your Social Media Archive in 2026

A serious social media archive eventually outgrows a single hard drive. The usual fix is some manual workflow: split your library across two folders, point new downloads at the new drive, hope nothing breaks. v1.10 makes that workflow a first-class feature instead of a workaround. Register more drives, files spread automatically, paths survive Windows changing drive letters, and removing a drive only unregisters it, never deletes the files.

Why a Single Drive Eventually Stops Working

If you've been archiving social media seriously for any length of time, you've probably hit the wall. The library that fits comfortably on a 1TB drive when you start tracking 20 creators is uncomfortable on the same drive at 80 creators, full at 200 creators, and broken at 500. Live recordings compound this: a TikTok creator who streams for a few hours a day produces several gigabytes of footage even with hardware compression.

The historical workarounds are all manual. Move the library to a bigger drive (assuming you can buy one). Symlink half the library to a second drive (assuming the downloader follows symlinks correctly). Split the library by platform across two folders and run two instances (assuming you like running two of everything). Each option has friction and each one breaks when Windows shuffles drive letters or the downloader's path-resolution logic doesn't expect a multi-drive setup.

v1.10 makes the multi-drive case a first-class feature of the app, not a workaround on top of one.

What v1.10 Ships

Six concrete pieces, each addressing a specific friction in the manual-workaround approach:

• Explicit drive registration (opt-in). Multi-drive support is opt-in: turn it on in Settings → Storage, then use Add Drive to register each additional drive. Each drive is recorded by its volume GUID and serial rather than its current drive letter, so the registration is stable across reboots, USB unplugs, and SATA reshuffles. v1.10 deliberately moved away from auto-scanning every fixed volume for a matching folder, because passive auto-detection could let writes (or worse, a creator-purge rmtree) reach an unrelated drive that merely held a backup copy of the library. Drives are added by user action only.
• Fill-primary-first writes with creator-stick. New downloads go to the first registered drive (your primary) that has room. When the primary fills, overflow goes to the next-registered drive, then the next. The exception: once a creator's files have been written to a drive, subsequent downloads for the same creator stay on the same drive as long as that drive has room. That keeps each creator's archive contiguous on one drive (useful for archival, also useful for browsing the file system directly) while still letting the library naturally fill drives in registration order.
• Free-space headroom + overflow. When a drive's free space drops below the headroom threshold (~1 GB on a media drive, larger on the drive that holds the database), StreamStash stops writing new files to it and shifts new writes to the next drive with room. Existing files stay where they are; only new writes shift.
• Drive-letter resilience. Stored file paths resolve dynamically across registered drives at access time, using the volume's GUID and serial rather than its current drive letter. If Windows changes a drive letter (a USB drive remounts as F: instead of E:, a SATA reshuffle changes D: to G:), playback, thumbnails, search, analytics, and deduplication keep working.
• Add-drive validation. The Add Drive flow rejects network paths (UNC), non-fixed drive types, and any drive that's already in the library, and runs a write-test on the destination before accepting the registration. Cloud-sync drives (Google Drive, OneDrive, Dropbox, iCloud, Box, Mega) aren't hard-blocked in the explicit add flow, but the strong recommendation is don't register one, because they cause slow uploads and placeholder-file conflicts when used as live archives. (The legacy single-drive auto-detection path does exclude cloud-labelled drives by default.)
• Settings → Storage UI. Each library drive is listed with free space, online status, and a link to the multi-drive guide. Adding a drive registers it. Removing a drive only unregisters it; the files stay on disk untouched and are still readable via the resolver. The primary drive can't be removed (it holds the database and shared config).

The DB-Drive Safety Reserve

The drive that holds StreamStash's SQLite database gets a larger free-space reserve than other library drives. The reason: if the database runs out of space, the app is in trouble; if a media drive runs out of space, only new writes to that drive fail.

Two thresholds:

• Floor (at least 2 GB). When the database drive falls below this, media stops being written to that drive. Recordings on the DB drive stop. Media writes to other drives keep going.
• Critical (1 GB). When the database drive falls below this, all downloads pause regardless of where the media was going. The database itself is now at risk of running out of space, which would cause far worse damage than a brief pause.

Both thresholds scale with the live database size so a larger library reserves more headroom.

Safer Library Relocation

If you'd rather move the whole library to a different drive (instead of just adding a second drive), v1.10 also makes that flow safer:

• Pre-flight checks compare the destination's free space against the library size and warn if there isn't room.
• A Browse button picks the destination instead of forcing you to type a path.
• Automatic rollback on failed same-drive moves: if the relocation aborts halfway, StreamStash returns the library to its pre-move state instead of leaving you with a half-moved mess.

For cross-drive moves, the simpler workflow is usually to register the new drive as an additional library root, let writes naturally migrate over time, and (optionally) move existing files manually if you specifically want to consolidate.

Why This Matters for the Archivist Audience

If you're archiving for personal completion, this is convenience. If you're archiving as part of an actual research, journalism, or preservation workflow, this is structural.

• Researchers and archivists hit the multi-drive case early. A creator-focused archive that tracks dozens of accounts across multiple platforms with their live recordings included accumulates fast.
• Drive-letter resilience matters for long-term archives. A library you're going to be running for years will see hardware changes. Drives die and get replaced. USB enclosures get swapped. Windows reinstalls renumber drives. An archive that breaks every time a letter changes is not actually an archive.
• The remove-drive-without-deleting-files rule matters for trust. When you're trusting an app with hundreds of GB of accumulated content, the cost of accidentally losing the lot is asymmetric. v1.10's rule that removing a drive only unregisters it is a guarantee that aligns with how archivists actually think about their data.

For the broader storage-size planning picture, see Social media archive storage size planning. For the self-hosted-vs-cloud framing, see Self-hosted vs cloud social media archiving.

Honest Limits

Three things worth flagging:

• Existing files don't redistribute themselves. When you add a drive, only new downloads spread across drives. Already-archived files stay where they are. If you want existing files spread, you have to move them manually (and StreamStash's path resolver will find them on the new drive).
• The database stays on one drive. The library media spans drives, but the SQLite database itself does not. This is by design; spanning a database file across drives would either break or be a lot slower than not. The DB-drive safety reserves above are how StreamStash handles the case where the DB drive runs low.
• Cloud-sync drives aren't recommended as library roots. StreamStash keeps them out of the drive suggestion list, and the legacy single-drive auto-detect skips them by label, but the explicit Add Drive flow won't stop you pointing at one. Writing to a Google Drive or OneDrive folder is a footgun (slow, placeholder files, potential conflicts), so don't.

How This Compares to Other Approaches

• Single-drive archivers (4K Tokkit, 4K Stogram, most browser-extension downloaders). No multi-drive concept; if you outgrow the drive, you're on your own. Workarounds vary from "move the whole library manually" to "split your workflow across two installations".
• yt-dlp + scripts. You can configure separate output directories per script and write multi-drive logic yourself. Works if you're comfortable maintaining the wrapper; doesn't survive Windows shuffling letters without further work; no built-in failover, free-space tracking, or sticky-per-creator allocation.
• NAS / file-server setups. A NAS is a valid answer for a multi-drive archive, but it shifts the problem to a different physical box and adds network-storage performance overhead on every read. For a Windows-local workflow on a desktop with multiple internal drives, in-app multi-drive support is usually the simpler answer.
• StreamStash v1.10. Native multi-drive with an explicit user-managed drive registry, drive-letter resilience via volume GUID/serial, fill-primary-first writes with creator-stick, and a safe library-relocation flow. No scripts, no manual moves, no external dependencies.

Why StreamStash for Multi-Drive Archives

• Explicit registration, not silent auto-scan. You add drives by user action in Settings → Storage. The library never quietly absorbs an unrelated drive just because it happens to have a matching folder.
• Fill-primary-first with creator-stick. New writes fill your primary drive first, then overflow to the next registered drive, but each creator's body of work stays contiguous on one drive once started.
• Drive-letter resilience via GUID/serial. Files resolve across registered drives regardless of which letter Windows assigned them this boot. The registry is keyed to volume identity, not to a drive letter.
• DB-drive safety reserves. Two-tier protection (2 GB floor + 1 GB critical) keeps the database from running out of space even on a busy library.
• Add-drive validation. Network paths (UNC), non-fixed drives, duplicates, and non-writable destinations are all rejected at registration time with a clear reason.
• Remove-drive-without-deleting-files. Unregistering a drive in Settings doesn't touch the files; they stay readable via the resolver. The primary can't be removed (it holds the database and shared config).
• All tiers. Multi-drive support ships on Free, Personal, and Power for every platform that tier supports.

Getting Started

1. Update to v1.10 or later. Multi-drive support ships in v1.10; earlier versions handle a single drive only.
2. Mount the second drive. Any local fixed or removable drive works. Avoid cloud-sync drives (Google Drive, OneDrive, etc.) as library targets; they cause slow uploads and placeholder-file conflicts.
3. Open Settings → Storage and turn multi-drive on. The toggle is off by default. Enabling it seeds your current recordings drive as the primary.
4. Click Add Drive and point to the new drive. StreamStash records its volume GUID and serial, runs a write-test, and registers it. The same library subpath your main install uses is applied automatically.
5. Let new downloads fill drives in order. Writes go to your primary first, overflow to the next registered drive when the primary fills, with each creator staying on one drive once started.
6. Optional: run Optimize Database. Compact the database file and remove redundant engagement-history rows once your library has been growing for a while.

For the broader storage-planning picture, see Social media archive storage size planning. For background on why local storage matters more than cloud, see Self-hosted vs cloud social media archiving.

FAQ

How do I add a second drive to my StreamStash library?

Open Settings → Storage and turn on the multi-drive toggle (it's off by default, so existing single-drive installs aren't affected until you opt in). Toggling it on seeds your current recordings drive as the primary. Then click Add Drive and pick a path on the second drive. StreamStash records the drive's volume GUID and serial, runs a write-test, and adds it to the registry. The same library subpath your main install uses (whatever you picked at install time) is applied to the new drive. Cloud-sync paths like Google Drive or OneDrive shouldn't be registered as library drives because the app would stream and transcode from a remote service on every access; there's no specific block in the add flow, so the registration is up to you, but the recommendation is don't.

What happens when one drive fills up?

New downloads fail over to the next registered drive automatically. StreamStash tracks free space per registered drive and stops writing to a drive once it falls below about 1 GB of headroom, then shifts new writes to the next drive in registration order that has room. The drive that holds the database has a larger reserve (at least 2 GB floor, with a 1 GB critical line that pauses all downloads if the database drive itself runs out of space). Your existing files stay where they are; only new writes shift.

Does it survive Windows changing drive letters?

Yes. StreamStash resolves stored file paths across registered drives at access time, not at write time. If Windows changes a drive letter (a USB drive remounts as F: instead of E:, for example), playback, thumbnails, search, analytics, and deduplication keep working because StreamStash looks for each file across all registered drives by relative path rather than relying on the original drive letter.

Will it write to my Google Drive or OneDrive folder?

Strongly advised not to. Cloud-sync drives like Google Drive, OneDrive, Dropbox, iCloud, Box, and Mega report as fixed disks to Windows even though they're really backed by a remote service, so writing to one would cause StreamStash to stream and transcode from the cloud on every access (slow, and sometimes the local file is just a placeholder). The legacy single-drive auto-detection path explicitly excludes drives with these labels, but the explicit Add Drive flow in multi-drive mode doesn't hard-block them, so the user is in charge of what they register. The recommendation is unchanged: don't register a cloud-mounted path as a library drive.

What happens if I remove a drive from the library?

Only the registration is removed; the files on disk stay exactly where they are. Removing a drive in Settings tells StreamStash to stop looking for that drive's contents and to stop writing new files there. If you later re-register the same drive via Add Drive, StreamStash recognises it by its stored volume GUID and serial and the existing files resolve again as if nothing changed. (Note: the primary drive can't be removed in the Settings UI because it holds the database and shared config.)

Can I move my whole library to a new drive?

Yes. v1.10 also makes the same-drive library relocation flow safer: pre-flight checks compare the destination's free space against the library size, a Browse button picks the destination, and the move can automatically roll back if a same-drive copy fails partway through. For a move across drives, the simpler workflow is to register the new drive as an additional library root and let the writes naturally migrate over time.

Is multi-drive support on all tiers?

Yes. Multi-drive storage is a library-management feature, not a Power-tier feature. It ships on all tiers (Free, Personal, and Power) for every platform that tier supports. Storage management generally lives outside the tier paywall in StreamStash; the Power tier differentiates on the dashboard widgets, AI semantic search, cross-platform deduplication, and identity matching.