Backup and restore profile data across anti-detect browsers

Losing a warmed account because of a failed migration or a corrupted profile folder is one of those things that feels avoidable right up until it happens to you. I’ve had it happen twice: once when I was moving from Multilogin to AdsPower mid-campaign, and once when a Windows reinstall wiped a local profile directory I forgot to move. Both times the damage was real, accounts gone, warm cookies gone, weeks of work gone.

This tutorial is for operators running more than a handful of profiles, people doing e-commerce, affiliate work, social media management, or airdrop farming at scale. If you’re managing 10+ profiles across one or more anti-detect browsers, you need a backup strategy that’s deliberate, tested, and repeatable. What you’ll get here is a practical workflow for exporting profile data, storing it safely, and restoring it to the same or a different browser without blowing up your account standing.

By the end, you’ll have a working backup routine, understand what data matters and what doesn’t, and know how to move profiles between tools like AdsPower, GoLogin, and Multilogin without starting from scratch.

what you need

An active subscription to at least one anti-detect browser. Prices as of May 2026: AdsPower starts at $9/mo (10 profiles), GoLogin at $24/mo (100 profiles), Multilogin at €99/mo (100 profiles cloud).
A backup destination: local NAS, external SSD, or cloud storage (Backblaze B2 at ~$0.006/GB/month is reasonable; S3 works too).
Basic terminal access (Windows PowerShell or macOS/Linux bash).
rclone installed for cloud sync. Free, open source at rclone.org.
Python 3.8+ if you want to automate profile export parsing.
At least read-level access to your anti-detect browser’s local profile folder or API.

step by step

step 1: understand what’s inside a profile

Before you back anything up, understand what you’re actually saving. An anti-detect browser profile is not just cookies. It includes:

Fingerprint config: user agent, screen resolution, canvas noise seed, WebGL renderer, timezone, language, platform strings.
Cookies: the actual session data from logged-in sites.
LocalStorage and IndexedDB: persistent web app state, often used by platforms to track login history.
Proxy assignment: IP, port, auth credentials tied to that profile.
Notes/tags: metadata you’ve added for your own tracking.
Browser cache: usually not worth backing up, large and non-critical.

The fingerprint config and metadata are stored in the app’s own database (usually SQLite or a JSON manifest). Cookies and localStorage live in Chromium profile folders on disk. Knowing the distinction matters because they need different backup approaches.

step 2: locate the local profile folder

Each tool stores data differently.

AdsPower stores profiles in:

Windows: C:\Users\<you>\AppData\Local\AdsPower\cwd\ads_browser\User Data\
macOS:   ~/Library/Application Support/AdsPower Global/cwd/ads_browser/User Data/

Each profile gets its own subfolder named by a numeric ID (e.g., User Data\jre2k3x\).

GoLogin stores profiles in:

Windows: C:\Users\<you>\AppData\Roaming\orbita-browser\
macOS:   ~/Library/Application Support/orbita-browser/

Multilogin uses a cloud-first architecture. Local profile data syncs from their servers. For local storage mode, check:

Windows: C:\Users\<you>\AppData\Roaming\Multilogin\mla\mlx\profiles\

Confirm the actual paths in your specific version by going to Settings inside the app, most tools expose this under “Storage” or “Advanced”.

step 3: export the profile manifest

The folder on disk only has the browser state. You also need the fingerprint config and proxy assignment, which lives in the app’s database.

Most modern anti-detect browsers offer a bulk export via UI or API. In AdsPower:

Go to Profiles, select all or a batch.
Click “More” then “Export”.
Choose JSON format, which exports profile metadata including fingerprint settings and group assignments.

In GoLogin, use their API to pull profile objects programmatically:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.gologin.com/browser \
  > profiles_export.json

This JSON is the source of truth for fingerprint configs. Back it up alongside the profile folders.

step 4: create a consistent backup archive

Combine the manifest JSON and the profile browser folders into a single archive per profile or per batch. I do it in batches of 50.

#!/bin/bash
PROFILE_DIR="/home/user/.adspower/User Data"
MANIFEST="profiles_export.json"
BACKUP_DIR="/mnt/backup/antidetect/$(date +%Y-%m-%d)"

mkdir -p "$BACKUP_DIR"
cp "$MANIFEST" "$BACKUP_DIR/"
tar -czf "$BACKUP_DIR/profile_folders.tar.gz" "$PROFILE_DIR"
echo "backup complete: $BACKUP_DIR"

On Windows with PowerShell:

$src = "$env:LOCALAPPDATA\AdsPower\cwd\ads_browser\User Data"
$dest = "D:\backup\antidetect\$(Get-Date -Format 'yyyy-MM-dd')"
New-Item -ItemType Directory -Force -Path $dest
Copy-Item "$src" "$dest\UserData" -Recurse
Write-Output "backup done"

Expected output: a dated folder with your manifest JSON and the compressed profile data. Total size for 100 profiles with cookies is typically 200MB to 2GB depending on session activity.

If it breaks: if tar throws permission errors on Windows, run PowerShell as administrator. On Linux, check that the anti-detect browser is fully closed before archiving, open file handles will cause incomplete reads.

step 5: sync to remote storage with rclone

Local backup isn’t enough if the machine dies. Set up rclone to push to Backblaze B2 or S3.

# configure rclone once
rclone config

# then sync your backup folder
rclone sync /mnt/backup/antidetect b2:your-bucket-name/antidetect --progress

Schedule this after your nightly backup script. On Linux, add to crontab:

0 3 * * * /home/user/scripts/backup_profiles.sh && rclone sync /mnt/backup/antidetect b2:your-bucket/antidetect

If it breaks: if rclone authentication fails, re-run rclone config and refresh your B2 application key. B2 keys expire if not used.

step 6: restore profiles to the same browser

To restore, reverse the process. Close the browser, extract the archive back to the original directory, then reopen the app.

tar -xzf /mnt/backup/antidetect/2026-05-10/profile_folders.tar.gz -C /

The app should detect the restored folders automatically on next launch. If profiles don’t appear, check that folder names match the IDs in the manifest JSON. Some browsers index profiles in a local SQLite database, you may need to re-import the manifest JSON through the app’s import UI.

If it breaks: if restored profiles show as “corrupted” in AdsPower, it usually means the Preferences file inside the profile folder is malformed. Delete just that file and relaunch; the browser recreates it with defaults.

step 7: migrate profiles to a different anti-detect browser

This is the harder case. There is no universal profile format across tools. What you can port cleanly:

Cookies: use a cookie editor extension (EditThisCookie or Cookie-Editor) to export cookies as JSON from inside a profile, then import into the new browser’s profile.
Fingerprint config: manually re-enter or script via the destination tool’s API.
Proxy assignment: re-map in the new tool.

For cookies specifically, most anti-detect browsers support the Netscape cookie format or JSON. Inside an open profile:

// paste into DevTools console to export cookies as JSON
copy(document.cookie)

For a more complete export including HttpOnly cookies, use the browser’s built-in cookie export, or a script that reads the Cookies SQLite file directly:

import sqlite3, json, shutil, os

profile_path = "/path/to/profile/Default"
cookie_db = os.path.join(profile_path, "Cookies")
tmp = shutil.copy2(cookie_db, "/tmp/Cookies_backup")

conn = sqlite3.connect(tmp)
rows = conn.execute("SELECT host_key, name, value, path, expires_utc, is_secure FROM cookies").fetchall()
cookies = [{"domain": r[0], "name": r[1], "value": r[2], "path": r[3], "expires": r[4], "secure": bool(r[5])} for r in rows]
print(json.dumps(cookies, indent=2))
conn.close()

If it breaks: Chromium locks the Cookies file when the browser is open. Copy it first (shutil.copy2), then read the copy, as shown above.

step 8: verify the restore worked

After restoring, always verify before putting a profile back into active use.

Open the profile and navigate to a site you were logged into.
Check that cookies are present (F12, Application tab, Cookies).
Confirm the fingerprint matches your expected config, not browser defaults.
Run a quick fingerprint check at browserleaks.com to confirm canvas, WebGL, and timezone are as configured.

Don’t skip this. Putting a restored profile into use with wrong fingerprint settings is how you get flagged.

common pitfalls

Backing up only the folder, not the manifest. The folder has cookies and localStorage, but without the fingerprint config JSON, you’re restoring a naked Chromium profile. The account might load but the fingerprint will be wrong.

Not closing the browser before backing up. Chromium keeps SQLite databases open with write locks. A backup taken while the browser is running can produce a corrupted or partial Cookies database. Always close profiles before archiving.

Assuming cross-browser portability. AdsPower profiles do not drop into GoLogin natively. The internal IDs, folder structures, and database schemas differ. Factor in manual cookie re-import time if you’re switching tools.

Skipping remote backup. Keeping backups only on the same machine that runs the profiles is not a backup. A ransomware hit or SSD failure takes both out simultaneously.

Over-relying on cloud sync. Tools like Multilogin offer cloud profile sync, but that’s not the same as a point-in-time backup. If a profile gets corrupted in the cloud, the bad state syncs everywhere. Maintain independent exports.

scaling this

At 10 profiles: manual export and a dated folder on an external drive is fine. Do it weekly.

At 100 profiles: automate the nightly backup script and rclone sync. Store manifests and folders separately so you can restore just the metadata without unpacking gigabytes of browser data. At this scale, budget about 5-10GB of storage per month depending on session activity.

At 1000 profiles: you need a proper backup orchestration layer. Options: Restic with a B2 backend (deduplication is critical at this scale, restic.net), or a purpose-built pipeline that pulls manifest exports via API, diffs against the previous day’s export, and only archives changes. You’ll also want to tag profiles with their last-verified-working date so stale restores are identifiable. If you’re running airdrop or social farming at this scale, the profile management tooling becomes as important as the farming strategy itself. The airdropfarming.org blog has operational writeups on managing identity infrastructure at volume worth reading alongside this.

Regardless of scale, test your restores. Run a quarterly drill where you restore three profiles from backup to a clean machine and verify they work. A backup you’ve never tested is a liability, not an asset.

where to go next

How to set up rotating proxies in AdsPower and GoLogin - proxy assignments are part of the profile, this shows how to structure them so backups stay portable.
Anti-detect browser comparison: Multilogin vs AdsPower vs GoLogin - if you’re evaluating a migration, this covers the real tradeoffs on storage model, API quality, and pricing before you commit.
Back to the article index

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.