If your phone's USB File Transfer mode is being slow, dropping mid-copy, or just choking on a few thousand files, ADB is the better tool for the job. It's the same protocol Android developers use to push builds to test devices, and it happens to be faster and more reliable than MTP for large batch transfers too. This works the same way regardless of brand — Pixel, Samsung, OnePlus, whatever's in your pocket.

What you need before starting

• A Linux machine (this was tested on Ubuntu, but the commands are distro-agnostic once adb is installed)
• A USB cable that actually supports data transfer, not just charging
• Access to unlock your phone's screen during setup

Step 1: Install ADB

Open a terminal and run:

sudo apt update
sudo apt install android-tools-adb -y

If you're not on a Debian-based distro, grab the platform-tools package for your package manager instead — the commands after this point are identical.

Step 2: Enable USB debugging on the phone

This is the step people skip and then wonder why adb devices comes back empty. USB debugging is a separate permission from regular file transfer, and it's hidden by default on every Android skin.

1. Go to Settings → About phone, find Build number, and tap it seven times. You'll get a toast confirming Developer options are unlocked.
2. Go to Settings → System → Developer options → USB debugging and switch it on. (On some OEM skins this lives under a different submenu — Samsung buries it slightly differently than stock Android — but the setting name is always "USB debugging.")
3. Unplug the cable, then plug it back in. This matters — the debugging permission prompt often won't fire on an already-connected cable.
4. Keep the phone unlocked. You should see a popup asking Allow USB debugging? Tap Allow, and check Always allow from this computer if you don't want to re-approve it every session.

Step 3: Confirm the connection

adb devices

A working connection looks like:

List of devices attached
XXXXXXXX    device

If it says unauthorized instead of device, your phone is waiting on that popup — unlock it and tap Allow. If the list is empty, USB debugging isn't actually on yet, or the cable swap in Step 2 didn't happen. Restarting the ADB server clears up most flaky states:

adb kill-server && adb start-server && adb devices

Still nothing? Run lsusb and check whether the phone even shows up at the USB level — if it doesn't, it's a cable or port problem, not an ADB problem.

Step 4: Pull everything

Once adb devices shows device, copy accessible storage to your laptop:

mkdir -p ~/Phone-Backup && adb pull /sdcard/ ~/Phone-Backup/

This copies photos, videos, downloads, documents, and any app media saved to shared storage — recursively, into a Phone-Backup folder in your home directory. Don't disconnect the cable or lock the phone mid-transfer; ADB doesn't handle interruptions gracefully and you'll end up re-pulling from scratch.

One thing worth knowing going in: this only reaches shared storage. ADB can't normally read protected app data at /data/data without root, so it's great for media but it won't clone a WhatsApp database or an app's internal settings.

If it looks stuck

Building the initial file list can take a while on a phone with tens of thousands of files, and the terminal won't show progress during that phase. Open a second terminal and check whether data is actually landing:

du -sh ~/Phone-Backup

Run it twice, thirty seconds apart. If the number's climbing, it's working — just be patient. If it's stuck at zero for several minutes, sanity-check that ADB can actually see the storage:

adb shell 'ls -lah /sdcard/ | head -30'

If that returns real folder names (DCIM, Download, Pictures), the connection is fine and it's just slow.

Step 5: Verify the copy, don't just trust it

A file count comparison is a fast sanity check, and you can chain the whole thing into one command:

mkdir -p ~/Phone-Backup && adb pull /sdcard/ ~/Phone-Backup/ && echo "Transfer done — verifying..." && echo "Phone files:" && adb shell 'find /sdcard -type f 2>/dev/null | wc -l' && echo "Laptop files:" && find ~/Phone-Backup -type f | wc -l

Matching counts are a decent first signal, but they're not proof every byte copied correctly — two files with the same name and different content would still "match" on count. If this backup actually matters, run a checksum comparison on top of it rather than trusting the numbers alone.

Copying files back (laptop → phone)

The same tool works in reverse with adb push:

adb push ~/MyFolder/ /sdcard/MyFolder/

If you're restoring a full backup, resist the urge to run this the moment the pull finishes. Pushing an entire backup folder back onto a phone that still has the originals can create nested duplicate folders depending on how the paths line up — verify the backup contents first, then push deliberately.

Copy, not move

Worth stating plainly since it trips people up: adb pull copies files, it does not move them. After the transfer, your phone's files are untouched and your laptop has a duplicate. If you actually want a move — copy, verify, then delete from the phone — treat that as two separate steps, not one command. Deleting originals before you've confirmed the backup is intact is how backups turn into data loss.