Is there a faster way to copy time machine files from one disk to another?

I'm trying to move my time machine backup files all under Backups.backupdb to another drive. I initiated a file copy overnight (b/c I saw that it took OSX forever to prepare for the copy...it basically was counting the files for hours). In the morning I saw that only certain backups(folders with dates) got copied over. I then tried to copy over the ones that didn't get copied...but the OS wouldn't allow me to do that. I got and error that "The operation can’t be completed because backup items can’t be modified." So my plan is to delete the incomplete copy on the new drive and then try to copy over the Backups.backupdb folder again.

Pretty frustrating. Is there a faster way to copy these files via a terminal command so that it doesn't perform all of that file counting prep?

I probably can tar up the entire folder and then do a copy, but will that interfere with any of the file permissions, etc.? The one thing with this approach is that I don't have any more space on my source volume for the tar.

UPDATE

I've tried some of the methods that people have suggested below, specifically using Disk Utility's restore function and it's giving me some error messages and unexpected results (at least to me). I've tried to do the restore two ways:

• With "Erase Destination" checked : Each time (I've tried twice), when the restore has finished I see a message "Could not restore - Invalid Operation" and "Could not restore - Invalid Argument". However, my destination disk does get a copy of my TM files. The weird thing is that my destination disk is EXACTLY like my source disk...even the size. My destination disk is actually 1 TB but after the restore, it shows as 200 GB when I get info from the finder. But in Disk Utility, it shows a 1 TB partition!

I then tried to verify/repair the disk and got:

    Invalid B-tree node size
    Checking Journaled HFS Plus volume.
    Invalid B-tree node size
    Volume repair complete.
    Updating boot support partitions for the volume as required.
    Error: Disk Utility can’t repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files.

Don't know if I'm even suppose to verify/repair a TM disk...

• With "Erase Destination" UNchecked : The restore never starts and I get:

    Could not restore - Operation not permitted

A normal copy (or copy via rsync or ditto) will not replicate a Time Machine fully as it will convert two directories linked together (as occurs in successive TM backups with no change between) into two separate directories.

The best way is to copy the whole the disk using Disk Utility or the block copy part of Carbon Copy Cloner and probably similar on SuperDuper.

Migrating a full 3TB Time Machine encrypted drive to a new 8TB one on macOS 10.14, I ran into all sorts of issues. Trying to do a restore in Disk Utility errored out with “unable to validate source” or “Operation not permitted.” Trying some other suggestions in this post and others, I was able to get exciting new error messages like “Catalog file on image/volume is too badly fragmented,” but no copy.

What worked in the end, at the terminal:

1. Erase the new disk with Disk Utility, matching the format of the source drive: MacOS Extended (Journaled, Encrypted)
2. Use diskutil cs list in the terminal to get the exact byte size of the Logical Volume on the old drive, and the GUID of the new Logical Volume, as well as the disk numbers for both, e.g., disk4.

3. Use the exact byte size from step2 as the size of the new volume. In my case with a 3TB drive it was 2,999,772,905,472 bytes:

   sudo diskutil cs resizeVolume $new_lv_guid 2999772905472
   

4. Using the pv command from homebrew, do a low-level block copy of the disks. This is a lot like using dd, except you get a progress meter with ETA.

   You need to get the disk numbers from the diskutil cs list output. Be careful. It’s very easy to accidentally overwrite your full backup drive with the new blank one here.

   sudo sh -c "$(which pv) --buffer-size 50M -s 2999772905472 < /dev/rdisk${source} > /dev/rdisk${target}"
   

   If you get a permission denied / operation not permitted error here, go into Security & Privacy Preferences and add Full-Disk Access for Terminal.app.

   For me this took about 10 hours—I let it run overnight—but, with pv, at least you get a progress meter with an ETA.

5. Now, expand the volume to take up all remaining space on the drive:

   sudo diskutil cs resizeVolume $new_lv_guid 0
   

   This took ~ 3 hours for me, with about 5 years of backups. Most of that time was spent by macOS fscking.

Now you can enjoy your new, more spacious Time Machine drive. You can repurpose the old one, or stow it somewhere safe in case something happens to the new drive.

The resizing steps seem to be important; skipping them resulted in a 10-hour file copy that yielded an 8TB volume containing a 3TB filesystem that I couldn’t figure out how to resize.

UPDATE One potential downside to this approach is that because it’s a bit-for-bit copy, the identifiers are the same between the old disk and the new disk. If I connect the old full disk, Time Machine thinks it’s the new disk, tries to back up, and starts deleting old backups to make room for new ones. It seems like a fine approach for moving data to a larger disk where the older smaller disk will then be wiped.

Why not just use terminal:

cp -RnpP Backups.backupdb

• -R recursive
• -n do not overwrite (if existing copy remnants remain from previous attempt)
• -p preserve ACL's, permissions, creation/mod dates, etc.
• -P preserve hard links, do not follow any hard or symlinks.