Command-Line Utility to Backup Google Mail, Calendar and Contacts to Files

https://github.com/WeeJeWel/node-google-backup

by weejewel • 2 years ago

113 30 2 years ago

github.com

xnx• 2 years ago

What benefit does this have vs Google Takeout?

racked• 2 years ago

Scriptable, presumably incremental.

ekovarski• 2 years ago

There is also vdirsyncer for contacts and calendar, also allows you to keep it in sync between services - it's great if you want to store a copy locally on a caldav / carddav server.

AyyEye5• 2 years ago

My Google takeout doesn't work because it requires a 2FA from Google authenticator which I no longer have.

judge20202• 2 years ago

You could attempt to get that 2fa removed by trying to sign in from a new device and following the steps to recover your account.

hypeatei• 2 years ago

So when your cookie expires you're done for?

ranger_danger3• 2 years ago

Looks handy, although it only grabbed like the first 2 years of gmail for me, out of 20. Re-running the docker image did not help.

_kst_• 2 years ago

I had a similar problem. I've submitted an issue.

https://github.com/WeeJeWel/node-google-backup/issues/1

weejewel2• 2 years ago

That’s now fixed!

philipwhiuk• 2 years ago

Does the .eml file preserve Gmail labels? Does it handle the 'labels apply to messages not threads' problem?

adrinavarro• 2 years ago

got-your-back uses Gmail's API instead of IMAP with an insecure app password, which is a discouraged way of accessing Gmail and will eventually be phased out in favor of OAuth access tokens over IMAP (in fact, I thought it already had been).

As for other services beyond Gmail, there's not a great ecosystem for exporting.

For one-off exports, Google Takeout is decent enough, although there's a lacking ecosystem to import the big .mbox files back to an email provider.

DaiPlusPlus2• 2 years ago

insecure app password [...] and will eventually be phased out in favor of OAuth access tokens over IMAP

What's so "insecure" about "per-app passwords"?

I ask, because I've lost the past 5 years of my life to building and running an internet-facing OAuth2+OIDC IAM system and I'm (still) an active contributor back to the open-source OIDC framework it's built-on. I grok the grants and flows and I've got the blood-pressure to show for it (and developed a healthy opposition to SAML); but despite all of that, I appreciate simple solutions to problems where there's a very real risk of over-engineering - and especially when a simpler system (like per-app passwords) can make a system overall more secure because there will be less mistakes being made, even if some clinicaly-dry technical assessment mathematically proves the complex solution is more "secure" by some measure.

///

although there's a lacking ecosystem to import the big .mbox files back to an email provider.

Everyone I know (okay, just a handful of ("normal") people) who has done this ended-up converting the .mbox to a PST for Outlook and copied it over to any other machines they have; it's an archive mailbox after-all, so just put it in read-only mode and don't worry about data-synchronization issues.

Kinda ironic that Gmail's credibility was/is built on ex-Outlook users looking for something better, only for Outlook to be the refuge (and last resting place?) for hundred-gigabyte-sized e-mail archives.

DaiPlusPlus2• 2 years ago

I need to supply a correction: apparently Outlook does not support opening PST files[1] that are protected as read-only by the filesystem (which is both disappointing and alarming...).

[1] https://answers.microsoft.com/en-us/outlook_com/forum/all/re...

Ferret7446• 2 years ago

a simpler system (like per-app passwords) can make a system overall more secure because there will be less mistakes being made

But a mistake WILL be made, because humans are fallible, and mistakes with a long lived bearer token can be extremely damaging, and can remain latent for a long period of time (e.g., password accidentally saved on disk and "deleted").

With proper OAuth, a lot of mistakes can be practically harmless (e.g., access token accidentally saved somewhere).

weejewel2• 2 years ago

I didn’t know about that. However, I explicitly wanted to avoid having users to create an OAuth project because it’s a hassle. Also these tokens can expire if they’re not refreshed after a while.

dotancohen• 2 years ago

Can Thunderbird not import the big .mbox files?

dengolius• 2 years ago

I prefer an executable file to node.js garbage even if I have a Docker. Does anybody have a ready-to-use alternative that is not written on JS?

eterps• 2 years ago

What's the difference if you have Docker anyway?

krageon• 2 years ago

It's preferring something that doesn't come from a diseased and unhinged ecosystem that not only involves a consistent tragedy of the commons, but also has tooling that is quite honestly just horrific.

EricE• 2 years ago

sounds like you have an itch that needs scratching - go for it!

kkfx• 2 years ago

Nice but... Backup is nothing without restore and actually "restore" for third party services on a closed proprietary infra it's not possible...

My way for mails is simply having local maildirs using mails via notmuch and serving the maildir if needed via local dovecot/with an eventual MailPile/Rainloop etc webmails, for contacts Davis (like Radicale or Baikal) with DavX⁵ on Android etc, IOW the sole way I fond is being able to use someone else service if I need it (for instance not to end up in spam on all web giants mails) but still owning my infra. Just having data I can't really use it's not enough unfortunately...

Command-Line Utility to Backup Google Mail, Calendar and Contacts to Files

Related Stories