You can define a backup policy by number of snapshots, number of weeks/months/years and other options like always keeping the latest snapshot. I recommend scheduling this with cron (see the README for an example of this). Run restic_snapshots.sh Checking Your Backup Repo
#BACKBLAZE BLOG HOW TO#
This can be scheduled with cron (see the README for a cron example and how to pipe the output to a log file). This just takes a backup snapshot using all the environment variables you already have configured. Run restic_backup.sh for this which will rely on restic_unlock.sh, restic_env.sh and restic_excludelist.txt. No data is actually sent, but a config is created with your repository details, ready to track snapshots. If you’re familiar with git, this is kind of similar to git init. Run restic_initialize_repo.sh which will create a brand new repository if data does not already exist there. Use Cases Initializing A New Restic Repository Follow the instructions in the README there, and open an issue if you have any questions or something does not work.Run restic_initialize_repo.sh or follow the restic documentation for that: Assuming you’re creating a brand new restic repository, you’ll need to start by initializing the repo before you can run backups.
#BACKBLAZE BLOG UPDATE#
You will most likely want to update /etc/fstab so that these will mount automatically on reboot. Mount any network shares you will be using as a source.In case it gives you any idea, I have been working with a ~1.6TB backup repository, adding somewhere around 200MB-500MB twice daily, and it’s using almost 8GB of cache data, consumes almost all 8GB of RAM, and a fair amount of the 8 CPU cores I allocated to that VM. Since restic does deduplication, it can be heavy on resources like CPU/RAM and also cache storage. Make sure your machine is ready to run restic jobs.I’m not going into specifics about setting up Backblaze B2 so that is an excercise for you (or any other destination you want to use). we can start with getting a machine set up to actually run the backups, checks, logging/monitoring and restores. restic features an easy way to prune old snapshots based on a retention policy that can be easily scripted (which you can see in the restic-scripts repository, restic_forgetandprune_bypolicy.sh)Īssuming you have already thought about your backup retention including how much data you are backing up, how long you want to keep snapshots, etc.restic snapshots allow me to keep many versions of my data over time without really worrying about the overall storage usage.But in my experience, these costs have been very minimal (well under $1 per month even when I use class B transactions heavily). They also do not charge egress or transaction fees based on transaction types like Backblaze does, so you can more easily wind up with additional costs using Backblaze B2 depending on how you run your backups. When I decided on Backblaze, Wasabi was also offering a similar solution for $5/month per TB, but their prices have increased slightly since then.
Fast forward to today, I’m still spending less than $10/month (but slowly reaching that threshold), while retaining encrypted, deduplicated snapshots going back to over 3 years ago. Backblaze B2 was offering pay as you go pricing for $0.005/GB so I would be saving about $5/month. Before that I was running Crashplan home edition until they increased the price to $10/month (at the time I was only storing about 600GB off-site). I have been using restic for just over 3 years with Backblaze B2 and have saved money at the expense of my time. Checkout the Github repo here My Use Case
0 kommentar(er)
