Nothing in this world is for granted. There is always that .01% chance the database or your profile might get hacked and so on.
Some of the options that might save your content include:
- Creating and saving blog posts locally using markdown or code editors/IDEs. Ideally backing them up in some external drives.
- Pushing them to GitHub repo/-s where you store your articles
- Syncing local files to Google Drive, Dropbox and others
- Creating posts on the blogging platform itself and using back-up methods provided by them
When it comes to last one, currently DEV.to offers export content feature in settings. You can export your posts and comments. They will be emailed to your inbox.
Where do you back-up your posts currently (if you do) and what would be the ideal way you would recommend for DEV to implement?
Top comments (16)
I don't do that, I like the risk 🌝
I only store few things of my life on an HDD not plugged to my PC, copied to GDrive and Mega, about 2Gb. The rest of data can burn down and I'll not be sad. It was nice while it lasted 😆
The markdown format is fantastic because it's freaking portable. I also like versioning both template and data in GIT.
You cannot completely trust your machine or even any external device. Hardware fails.
I would say one backup is not enough, but it's always better than 0. You have to replicate things. Of course, it should be automatic (e.g CRON jobs), but you have to use multiple backup strategies (at least 2) regularly if you want to be "sure".
I would add you have to make sure you can recover your data. It might seem obvious, but sometimes you get nasty surprises with archive formats.
I love MD since it's easy syntax plus highly supported and used in modern stacks 🔥🔥
Currently I post on both DEV and Hashnode so there's 2 copies floating around.
Then with Hashnode's GitHub backup feature there's a 3rd copy on a public repo.
I write on Notion so the 4th copy is the notion workspace.
After I submit my posts I keep a copy with all the assets on cloud storage so there's 5!
Might start storing them locally once I build my nas this black friday / Christmas 😊
That might hurt your SEO as Google can crawl public repos and treat it as a duplicate content. To be sure I spoke with Hashnode co-founder about this on Twitter and he recommended setting back-up repo as private to be safe.
Of course, always point canonical URLs to the original if you x-post somewhere.
Interesting! Thanks for the tip Madza!
No worries! Happy to help 😉
I'm currently trying two strategies:
I would like email backups to be regular.
Mine is locally + GitHub, not sure why but I trust GitHub.
And then dev.to and hashnode both have duplicates as well 🤟
I'd be curious about the use case for dusting off old content. IOW, say the database crashes and you lose your posts, comments, etc. Why is it anything other than ¯\(ツ)/¯ ?
I'm not making a rhetorical point -- I'm genuinely curious. Is it just for archival/set-completion purposes? Do people have plans to repurpose it somehow?
FWIW, if the worry is DEV (or any platform you don't control) collapsing in on itself like a neutron star and eating your content, I'd suggest not "backing up" the content from that platform, but rather creating it on a platform you control and syndicating it here (or wherever).
We just build a repo for our engineering team at SinnerSchrader. From now on we want to store and publish our posts trough github:
github.com/sinnerschrader/s2engine...
This approach helps us also to review post if someone need one :)
Dev.to is my backup for S.O. posts, and LinkedIn posts.
I source my posts through a blog based out of a github repository. Further, this means that I can just push from local, and through CICD and RSS I can get it piped to the dev dashboard effortlessly.
Occasionally I make sure things are saved in archive.org.
It's a good idea because if your links ever break, that's also where other people are going to be looking for it.
I have everything under git in a private github repo. I don't even use the web-editor. I have a helper script which publishing my articles via api to dev.to