The thing I hate most about #macOS is how simple problems which should have simple solutions on any other operating system almost ALWAYS have no solution at all. The #Apple Forum's super helpful too, can always count on them to give you the "welp, you should've not had that problem in the first place - too bad <3".
In this case, the context is: you cannot copy over your #TimeMachine backups from a drive to another - which seems like a very fucking logical thing to do for when your backup is growing or your drive is aging. The solution provided by everyone is to just "start a new backup on the new drive" or "you should've used a bigger drive 3 years ago". These fucking bitches.
#Backups are a complicated topic. When asked people often readily offer their own preferred solution as one-shoe that fits all. This hardly ever is the case.
First of all there are different kind of backups:
• Off-site (remote) and on-site (same host or same physical location)
• Proprietary and open source (open protocol) solutions
• Cloud based and self-hosted solutions
• File backups and full system snapshot backups
• Just straight synced copy vs incremental backups with history
A single #backup solution typically offers one for each attribute, sometimes even offering more options for some of them. Which backup solution and strategy suits which specific need varies wildly. The most important thing is:
Have periodic backups
Periodically test that you can restore the backed up data
What to back up then? The very least things you’ve produced yourself and things that would be very difficult to reacquire if they would be lost.
Personally I employ multiple different backup solutions and strategies, since I have various needs for various different systems and data. I reiterate: This is just what I use, and it definitely won’t be a solution for everyone.
• #TimeMachine backing up home Macs locally to my local encrypted file share. iPhones back up to my MacBook Pro which itself uses Time Machine.
• #rsync backup of various local / remote servers to the local encrypted file share (I do not have need for historic versions of these files, this is using dedicated ssh keys and is restricted with command="/usr/bin/rrsync -ro /",restrict)
• #Duplicity backup between home and off-site remote server (this backup is done both ways, does not include all files and is GPG encrypted with dedicated keys for which the private keys is in a safe location)
• #Syncoid backup for servers running #zfs (using --no-privilege-elevation to avoid need of root access, using dedicated ssh keys, the datasets are synced to my local encrypted zfs pool)
• The local encrypted file share is built in top of zfs. I have two zfs pools with 2 disk redundancy each. The main pool will sync the important datasets to the backup one twice per day.
I personally shy away from proprietary and cloud based solutions due to privacy and security concerns. This does not mean that these solutions are bad for everyone, this is just my personal preference and you should consider your own threat model.
I do also have separate backup strategy for work related devices but I won’t detail it here other than mentioning that is totally separate from all my other backups.