Restoring MacOS device from a snapshot with APFS (2017)
maclovin.org
maclovin.org
The snapshot was restored really fast, but the OS was still broken. I guess APFS snapshots exclude a number of files (as the remote time machine backups do).
It was also when I discovered you can reinstall macOS without losing any data.
I discovered this as well - nice surprise!
I've switched to (almost) all Win10 boxes at my residence, except for one 2014 15' rMBP. The Windows machines have the freeware 'Veeam Agent for Microsoft Windows' connected to an internal 3.5' 1TB drive (or 2.5 500GB drive for the two laptops that had optical drives and were removed and replaced with a 2.5 HDD caddy), that isn't running the OS. The OSS/C:\ is on an SSD.
Finally, the Windows machines are backed up via CloudBerry Labs Desktop Edition to Backblaze B2, in case the house burns down.
(I wish there was a product to remotely store time machine files, but based on the linking structure, I don't think this is possible? Carbon Copy Cloner is nice, but I wish I had incremental images)
Obviously there is more functionality with an iCloud backup. But, the overhead of re-configuring my TimeMachine after upgrading from an AirportExtreme seemed pretty onerous.
How are you using it? Through an Airport, plugging in a USB drive, some other method?
As an aside, I tried out Dolly Drive a few years ago (think cloud-based TimeMachine) but I was a bit concerned about having all of my personal info sit in someone else’s hands.
Though, in addition, I'm a pretty big utilizer of the ecosystem: iCloud Music Library, Photos, etc.
Wat?
Time Machine is for backing up a macOS machine incrementally to local/local network storage.
iCloud Backup is for backing up iOS devices to remote storage.
There is zero overlap between these tools.
I have a dotfiles git repo I use, in addition to personal repos I check into.
I'm not sure what I'm missing (I don't spend a lot of time messing around with manual configurations that aren't checked into my dotfiles git repo).
Being able to reinstall MacOS without losing your data can be helpful too.
After the smooth upgrade experience of Sierra (the first in a while), High Sierra has been worth holding off on for folks with existing setups that they depend on.
It's not a bad idea to avoid APFS until it has had time to mature - it's inability to play nice with other non-APFS Macs is too disruptive at the moment when it comes to backups and accessing them, etc.
Highly recommend anyone wanting to try out High Sierra take a full backup before upgrading in case the APFS doesn't play nice with the HFS realities that still may exist in your environment.
sudo tmutil snapshot
You can view the dates of your local snapshots dates with:
tmutil listlocalsnapshotdates /
Why is this especially useful for VM lovers ?
With APFS snapshots have come to the hardware level and that is really exciting.
But beware that this is not a backup. If you loose your main disk then you still might have lost your data. Time machine can help very well here. Regular TM backups are a good way of protecting yourself against data loss.
Unless.. we're talking VMs again. In that particular scenario it turns out that VMs and Time Machine do not go that well together. VMware even advices you to exclude your virtual machines from VMs [0] and [1]. The problem is that your VM consists of large binary files that change over time. If TM makes a backup it will always see your VM as changed and start copying the virtual disk files. Problem is that if the machine is running that the risk is high that you end up with corrupt virtual disks in your time machine.
Another problem is that if your TM backup storage runs out of storage space. TM can delete part of your virtual disks. Another problem is that with VMs you run out of disk space really quick.
Anyways I'm getting off topic. Probably because I wrote Vimalin [2] to backup VM's for VMware Fusion and counter the VM backup issues ;)
[0] https://kb.vmware.com/kb/1013628
[1] https://docs.vmware.com/en/VMware-Fusion/10.0/com.vmware.fus...
The way it works is that it makes a temporary snapshot of the VM when it is running. Parts of the disk from before the snapshot are now closed and new data is written as Copy on Write. The data that is safe to copy (which includes your VM state and memory) is then copied to your backup location. After Vimalin is finished copying the data it will also commit that temporary snapshot. On restoring a backup it gets back to the state from before the backup started, just like with a snapshot, except this was written on an external disk.
You can schedule when it is convenient for you to run the backups. Like Time Machine it makes full copies of the disks. But because you can schedule how many copies you want to keep you can prevent your backup storage from getting overrun.
It's nice to just take a snapshot and then do whatever task you wanted to do. If everything gets screwed up, it's no big deal. Just roll back to that last snapshot you made and start over.
I do the same thing on my FreeBSD machines when installing updates (thanks to ZFS).
They also save a ton of time when performing upgrades (reverting on failure) or when I need to load a customers configuration files.
I spend most of my day in VMWare workstation and use snapshots almost every day.
If you accidentally change or delete a file from a file system on a VM image, rolling back the change means restoring the entire VM image from backup. That may mean a multi-GB restore, even if the file is only a few kB (rsync won’t help much, as it still would require you to read the entire backup and the entire changed VM image)
With a COW snapshot, rolling back that accidental change can be even faster than restoring the file from backup, as it only means changing some on-disk pointers (of course, you would still need the backup, as that COW snapshot isn’t a backup; it would die if your disk died)
The snapshot will then grow at the rate you delete or modify local files. Conceptually, your drive now has to hold the "before" and "after" versions of its state.
This is why even if you are making encrypted backups of your phone, which Apple claims are full backups that store passwords and everything, your Google Authenticator data will be completely gone when you restore. So if you thought that, for example, there would be no reason to store the 16 digit codes 2FA codes as long as you had a multiple backups of your phone, what happens is that you just get locked out of every single website you use for a month.
It also means that if an app is no longer in the app store, there is no way to get that app back even if it would otherwise still work on your phone.
If you look at the text of how the backup process is described in iTunes, they are clearly claiming that a full backup of the phone is getting made, and yet in reality nothing could be further from the truth. It's amazing there aren't multiple billion-dollar class action lawsuits currently pending on this issue.
You appear to be talking about iOS.
Not. The. Same. OS.
The other poster has a fair point to be upset, it's not at all obvious to a consumer why Google Authenticator would not restore a backup properly to a new device.
Not at all true [1].
Everything in the app's container gets backed up with the exception of the app bundle, Library/Caches/, tmp/, and other things the developer explicitly opted out.
[1] https://developer.apple.com/icloud/documentation/data-storag...
It doesn't matter how the phone works or how the apps work. If you can't restore, you don't have a backup. End of story.
Did you restore a iOS backup to a different device then the backup was originally created on?
The way that sensitive data is encrypted on iOS (when the proper API's are used), certain types of data can be marked to be only able to be decrypted on the same device. That is, if a backup is restored to a different device, the unique device ID will have changed, and some encrypted items will not be able to be decrypted.
This is intentional. More details at https://www.apple.com/business/docs/iOS_Security_Guide.pdf
Yes, I had my phone replaced. And if it's intentional that it's supposed to work that way, then Apple shouldn't tell people that they have a full backup and are good to go when that isn't actually the case.
Especially since it makes zero sense for it to even work that way. If the backup is encrypted on your computer, then it should make zero difference whether the phone itself is different.
Regardless though, how it works and why it works the way it does is irrelevant. The issue is with Apple telling users that they have a backup when in fact they do not.
tl;dr: If you restore your encrypted backup to the phone that created it, you get your full keychain back. If you restore it to another phone, you only get keychain items that opted in to iCloud syncing.
This is what I hate since iOS 10 and the removal of app sync in iTunes (and with the latest iTunes, apps are completely out without any alternatives). I've avoided upgrading iTunes as well as macOS for this reason. I don't want to sacrifice convenience and waste time spending hours re-downloading all apps from the App Store when I could get it a lot more quickly from a local copy. Apple just doesn't seem willing to recognize how bad connectivity is in most places around the world.
I wait in the hope that Apple will bring out some kind of "Sync" app that's separate from iTunes but works with it to easily backup apps as well as data on computers for quicker restores.