Backup and recovery procedures for 100 plus account stacks

Running a stack of 100 or more accounts is genuinely risky infrastructure. one corrupted browser profile, one provider outage, one accidental rm -rf on the wrong VPS, and you can lose weeks of account aging, dozens of dollars in proxies, and the session cookies that took months to warm up. i’ve done it. not once.

this guide is for operators running antidetect-based stacks, farming wallets, social accounts, or marketplace seller profiles at scale. if you manage fewer than 20 accounts, the overhead here is probably overkill. if you’re at 50 or more, some version of what’s below is non-negotiable. the outcome you’re aiming for: a documented, tested recovery path that gets any single account, or your entire stack, back online within 24 hours of a failure.

i won’t pretend there’s one tool that solves all of this. the actual solution is a combination of structured exports, offsite storage, automation scripts, and a recovery runbook you test before you need it.

what you need

antidetect browser with exportable profiles (AdsPower, Dolphin Anty, or GoLogin, all have export functions as of 2026)
VPS or local machine running the stack, with SSH access and at least 50 GB free disk
rclone (free, open source) configured to sync to an S3-compatible bucket, Backblaze B2, or Google Drive
Backblaze B2 or Wasabi for cold storage, B2 costs $0.006/GB/month as of 2026, Wasabi is $0.0059/GB
a password manager with CLI access, 1Password CLI (op) or Bitwarden CLI (bw) both work
a spreadsheet or Airtable base mapping account ID to proxy, fingerprint profile ID, and recovery email
cron or a task scheduler on the VPS
bash scripting basics, nothing fancy needed
optional: Telegram bot for backup status alerts (free via BotFather)

step by step

step 1: audit what you actually need to back up

before writing a single script, list every asset tied to each account. for most stacks this is:

browser profile folder (cookies, localStorage, extensions)
proxy assignment (IP, port, auth credentials)
seed phrase or private key if it’s a wallet stack
recovery email credentials
2FA backup codes
any platform-specific notes (account age, balance, status flags)

keep this in a CSV or Airtable with one row per account. this is your source of truth. without it, recovery becomes a guessing game.

expected output: a spreadsheet with columns like account_id, profile_path, proxy_host, recovery_email, 2fa_backup, notes.

if it breaks: if you can’t reconstruct this from memory, start now with what you have. incomplete is better than nothing, and you’ll fill gaps as you work through the stack.

step 2: export all browser profiles to a structured directory

every major antidetect browser exports profiles differently. in AdsPower, go to the profile list, select all, and use the bulk export option. this writes each profile as a zip or folder to a local path. in Dolphin Anty, profiles are stored locally by default under ~/.config/dolphin_anty/profiles/. GoLogin stores profiles in ~/.gologin/.

organize exports into a flat directory like /opt/stack-backups/profiles/YYYY-MM-DD/. don’t nest arbitrarily.

DATESTAMP=$(date +%Y-%m-%d)
mkdir -p /opt/stack-backups/profiles/$DATESTAMP
cp -r ~/.config/dolphin_anty/profiles/ /opt/stack-backups/profiles/$DATESTAMP/

expected output: a timestamped folder with all profiles copied, file count matching your account count.

if it breaks: if profiles are locked because the browser is running, kill the browser process first with pkill -f dolphin_anty, then re-run.

step 3: encrypt the backup before it leaves the machine

never push raw cookies, seed phrases, or 2FA codes to any cloud bucket unencrypted. use gpg symmetric encryption with a passphrase stored in your password manager.

DATESTAMP=$(date +%Y-%m-%d)
tar -czf /tmp/profiles-$DATESTAMP.tar.gz /opt/stack-backups/profiles/$DATESTAMP/
gpg --symmetric --cipher-algo AES256 --batch --passphrase "$(op read 'op://Personal/stack-backup-key/password')" \
  -o /opt/stack-backups/profiles-$DATESTAMP.tar.gz.gpg \
  /tmp/profiles-$DATESTAMP.tar.gz
rm /tmp/profiles-$DATESTAMP.tar.gz

the op read command pulls the passphrase from 1Password CLI so it never appears in your shell history. if you’re using Bitwarden, substitute bw get password stack-backup-key.

expected output: a .gpg file roughly the same size as the unencrypted archive.

if it breaks: if op throws an auth error, run op signin first. if gpg hangs, add --no-tty to the gpg flags.

step 4: push to offsite storage with rclone

install rclone (curl https://rclone.org/install.sh | sudo bash) and configure a remote for Backblaze B2 or Wasabi using rclone config. the rclone documentation covers every provider step by step.

rclone copy /opt/stack-backups/profiles-$DATESTAMP.tar.gz.gpg b2:my-stack-backups/profiles/ \
  --progress \
  --transfers 4 \
  --log-file /var/log/stack-backup.log

use b2: for Backblaze B2 or wasabi: depending on which remote you configured. for a 100-account stack, compressed profiles typically land between 2 GB and 10 GB depending on how heavy your extensions are.

expected output: rclone reports 100% transfer, file appears in bucket.

if it breaks: check /var/log/stack-backup.log. common issues are expired B2 app keys (rotate them in the Backblaze dashboard) or network timeout on large transfers (add --timeout 5m).

step 5: back up your account map and credentials separately

the profile folders are useless without the mapping CSV and the credentials. export your Airtable base as CSV weekly, or pull it via the Airtable API. back up your password manager vault export (1Password .1pux or Bitwarden .json) on the same schedule. encrypt this the same way.

# export bitwarden vault
bw export --format json --output /tmp/bw-export.json
gpg --symmetric --cipher-algo AES256 --batch --passphrase "YOUR_PASSPHRASE" \
  -o /opt/stack-backups/bw-$DATESTAMP.json.gpg /tmp/bw-export.json
rm /tmp/bw-export.json
rclone copy /opt/stack-backups/bw-$DATESTAMP.json.gpg b2:my-stack-backups/credentials/

store the decryption passphrase in a second location, a printed copy in a physical safe is not overkill for large stacks.

expected output: encrypted vault export in the bucket.

if it breaks: Bitwarden CLI sometimes requires bw unlock before export. run it and pass the session key with BW_SESSION.

step 6: automate with cron and add alerting

manual backups don’t run at 3 AM when your VPS has a disk failure. set up a cron job on the VPS.

# edit crontab with: crontab -e
# run full backup daily at 2 AM
0 2 * * * /opt/scripts/stack-backup.sh >> /var/log/stack-backup-cron.log 2>&1

put all the steps above into /opt/scripts/stack-backup.sh. add a Telegram alert at the end using a simple curl call to the Telegram Bot API:

curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
  -d chat_id="$CHAT_ID" \
  -d text="stack backup completed: $DATESTAMP, $(du -sh /opt/stack-backups/profiles-$DATESTAMP.tar.gz.gpg | cut -f1)"

expected output: daily Telegram message confirming backup size and date.

if it breaks: if cron doesn’t fire, check /var/log/syslog for cron errors. the most common issue is environment variables not being set, define them explicitly at the top of the script rather than relying on the shell profile.

step 7: document and test the recovery procedure

a backup you’ve never restored from is not a backup, it’s a hope. once a month, pick five random account profiles, decrypt and restore them to a clean browser install, and verify the sessions are intact.

gpg --batch --passphrase "YOUR_PASSPHRASE" \
  -o /tmp/recovered-profiles.tar.gz \
  --decrypt profiles-2026-05-19.tar.gz.gpg
tar -xzf /tmp/recovered-profiles.tar.gz -C /tmp/recovery-test/

open the browser, import the five profiles, launch each one, and verify the session cookie is still valid. document what broke and fix the script before the next run.

expected output: five accounts browsing normally on sessions that match your account map.

if it breaks: expired cookies are normal for platforms that invalidate sessions after 30 days of inactivity. the fix is more frequent activity cycles, not better backups.

common pitfalls

only backing up profiles, not the mapping. the profile folder is meaningless if you don’t know which account it belongs to, which proxy it was paired with, or what the recovery email is. the CSV is as critical as the profiles themselves.

storing the encryption key in the same bucket as the backup. if an attacker gets bucket access, they get everything. the decryption passphrase lives in your password manager and optionally in a physical location, never in the backup bucket.

never testing recovery. i’ve spoken to operators who ran backups for six months, had a VPS wipe, tried to recover, and found the cron script had silently failed after a B2 key rotation. scheduled backups fail silently all the time. test monthly.

backing up too infrequently. once-a-week backups mean you can lose seven days of session warming, account interactions, and aging. daily at minimum. for high-value accounts, consider a second backup mid-day.

ignoring 2FA backup codes. cookies can be re-warmed, but an account locked behind a lost TOTP seed is gone permanently. back up the TOTP secret (not just the QR code image) inside your encrypted vault, and verify the codes work against the platform before the original device is gone.

scaling this

at 10x (10-50 accounts): manual exports work, but automate the rclone push. total backup size is small, a $5/month Backblaze B2 bill covers it. the spreadsheet is manageable by hand.

at 100x (50-200 accounts): the manual anything breaks. automate the full pipeline with cron, add Telegram alerts, and use a database (even SQLite) instead of a spreadsheet for the account map. consider a secondary VPS in a different datacenter that receives a daily rsync of your backup directory before it goes to the cloud. if you’re running airdrop farming campaigns at this scale, the proxy and fingerprint management layer becomes its own operational problem, and the airdropfarming.org blog has useful operator notes on session hygiene at that volume.

at 1000x (200+ accounts): at this point you need infrastructure-as-code, not scripts. use Terraform or Ansible to provision replacement VPS nodes from a known-good snapshot. the antidetect browser becomes a bottleneck and you may be writing your own profile management layer. backup automation should be monitored with something like Grafana or a simple uptime check that pages you if the daily backup file doesn’t appear in the bucket by 3 AM. recovery SLAs become a business concern, not just an operator preference. an hourly incremental backup with daily full snapshots is the minimum reasonable posture.

where to go next

how to structure a 100-account proxy rotation setup covers the proxy layer that sits alongside your profile backups
antidetect browser comparison 2026 breaks down which browsers have the most reliable export formats for large stacks
back to the blog index for all stack-setup and infrastructure guides

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.