Restoring from a backup location using 1p4_zip files vs folder sync
While I use a 1Password account for most of my data, I have a small set of items that I'm disallowed from copying outside a particular set of storage resources. Luckily I only need to use the restricted items on one machine, so while I need to keep them backed up, active sync'ing between multiple instances of 1Password is not a concern.
The local backup .1p4_zip files will be backed up via my normal full machine backup strategy, but I'd also like to keep a backup of the vault on a network location for extra security. AFAICT I have two options:
1) Periodically sync the .1p4_zip backups to the target location. If a restore is needed, download them, create a brand new empty local vault, use the "Find Backup" button to point 1Password to the backup file, and then restore it.
2) Turn on Sync to the target location. If restore is needed, create a new empty vault and sync it from the target location.
I think (1) is the more robust solution and the solution that doesn't go against the supported instructions for using Sync. But in my case, the network location will normally always be available (it's something closer to a VM/host mapped drive than a NAS or other network share) and I would not have any other instances of 1Password trying to write to it. If the problems associated with (2) (i.e. the reasons it's not supported) mainly have to do with unavailable network mounts or file access conflicts, then that solution would avoid me having to schedule a script to periodically copy over the backup files.
I realize you can't give a blessing to using Sync to a network location, but maybe you could provide some hints as to what types of problems one should expect here? The support page only mentions problems if the target location goes offline, but doesn't mention whether those problems would just be sync failures and annoying behavior, or something worse like affecting primary vault content.
FWIW the continued support for local vaults is what allows me to keep using 1Password for this use case rather than having to splinter off and use a second [inferior] tool just for managing a few items -- so thanks for the continued local vault support!
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
If a restore is needed, download them, create a brand new empty local vault, use the "Find Backup" button to point 1Password to the backup file, and then restore it.
I'm not sure you're clear on how backup/restore works in 1Password. You may be, but "create a new empty vault" makes me think you might not be. The .1p4_zip file isn't on a per-vault basis. It's EVERYTHING. Meaning: all vaults, etc. Of course, if you only have the one Primary standalone vault, then that amounts to the same thing, but if you've got other vaults on that one Mac, they would be replaced by whatever is in the .1p4_zip file.
Sync and backup are also two separate things in standalone 1Password. Sync means your active data file (the internal encrypted sqlite database) which gets written out to a sync keychain when you choose Dropbox or iCloud or the like, and can then be used to exchange real-time updates with other devices that use the same sync keychain. .1p4_zip file backups are created about once a day by 1Password as a safety measure, and those are not intended to be synced. You can of course sync or manually copy them out of their location (
~/Library/Group Containers/2BUA8C4S2C.com.agilebits/Library/Application Support/1Password/Backupsif you're using 1Password 7 for Mac) using some third-party strategy of your own, from a cron job to something like ChronoSync or rsync...but we can't really advise you on that, since it's not part of 1Password's functionality. "Syncing to a network location" is not a good idea for actual 1Password folder sync...but it wouldn't cause problems for copying/syncing the Backups folder to some other location.0 -
@Lars thanks for the clarifications. You're right, I thought that the .1p4_zip backups would only be the primary (local) vault - I didn't realize it would include the vaults from a 1Password account logged in on the same Mac (I assume this is included in "everything" and you're not just referring to all local vaults). That's not a showstopper in my situation but does mean I'd need to be very careful doing a restore, since I would never intend for a restore in this use case to overwrite 1Password account content. That's an important caveat, but at least Restore functionality for these backups is built into the app. And this is kind of nice too since it means there is actually a way to keep local backups of 1Password.com account content too which I was not aware of (and I realize this is not required for data safety).
But it sounds like the safer option for me would be to use Sync because I can limit that to just the vault I really need to keep backed up. The only question that remains is whether I absolutely need to Sync to a local folder and use a cron job to copy out the sync'd content, or whether a "1 way" folder Sync to this permanently mounted network location would trigger the problems that cause that solution not to be supported.
I realize I'm not going to get an OK from support on doing that but I wish there were a way that I could learn more about the specific risks and determine whether they would be a problem in my specific case.
0 -
I realize I'm not going to get an OK from support on doing that...
True. We can't support this option, even though it is possible to do. However, many (though by no means all) of the problems from this type of setup come from either
- having the network share be not mounted when you launch 1Password, or having it become unavailable while 1Password is running, or
- having multiple devices syncing (perhaps simultaneously) to the same OPVault in the same folder on the network share.
I'm still not 100% certain I understand exactly how you'd be setting such a thing up, but IF you have no other devices syncing to this network share AND you take pains to make sure the share is not only running but mounted and accessible at all times on the machine you use 1Password on, when you've got 1Password actively running, it may work fairly smoothly for you.
0 -
Thanks -- that makes sense. The scheme I'm using is basically local storage that's exposed as a network drive as part of a corporate shared storage syncing system (similar to Dropbox but not Dropbox, although Dropbox's client uses a different model from this one). I believe it uses network shares in effectively the same way that desktop virtual machine packages do, when you choose to share folders between the host and guest operating systems. If there's some kind of problem with the syncing software then the share could be unavailable (and I'll have to be careful to keep extra copies of the data around for that reason) but generally the share should be up (i.e. regardless of actual network/wifi connection status) and so I think this will probably be relatively safe, and very simple, for general day to day casual backup.
I really appreciate you providing the caveats. Availability issues with network shares are easy to understand, but I know that some systems (SQLite for instance) have further issues at a protocol level, where certain near-guarantees made by normal file systems don't apply when using SMB or NFS or whatever to access network shares. I'd guessed that this kind of issue is somewhere down the list of reasons why this is an unsupported scenario. It does sound like the risk is small enough in my case at least to warrant some experimentation.
0 -
I know that some systems (SQLite for instance) have further issues at a protocol level, where certain near-guarantees made by normal file systems don't apply when using SMB or NFS or whatever to access network shares.
Yeah, those too. :) That's why we've described this approach as (forgive the technical jargon) "a bag of hurt" and don't try to support it. ;) If you're careful, know what you're doing and use it in a limited fashion with the understandings above...well...it might still go south on you. But you'd have a better-than-average chance of that NOT being the case.
0
