Backblaze Wasabi



  1. Backblaze Vs Wasabi
  2. Backblaze Wasabi Recipe
  3. Wasabi Vs Backblaze B2 Reddit

(NOTE:This is the second of a three part series on setting up a cloud-based backup system, and describes how to use the various technologies discussed previously.The first describes criteria and reasoning for the various technologies selected for use, while the third describes setting up the backups to run automatically on schedule.)

Using the joint light-touch solution from Backblaze and MSP360, you now have a powerful backup solution that is simple to use, feature-rich, affordable. Meet Server Backup. Computer Backup Easily protect your business data through a centrally managed admin. Unlimited, secure, offsite backup for your business. Extended Version History: Retain. The S3 Compatible API for Backblaze B2 Cloud Storage allows 1000’s of integrations to work with B2 natively. If you’re new to the S3 Compatible API, please see our Getting Started Guide. If you have any trouble using NetApp Cloud Sync with B2, please let us know by emailing us at b2feedback@backblaze.com.

Setting Up “restic”

“restic” is the the backup technology we will use for its performance, deduplication, and native support for writing to various different remote backends.You can install “restic” using the apt package manager:

But I think it would be better to pull the latest version off their site, due to numerous little but useful improvements in this version vs. the ones in the Ubuntu repositories.It is Go language application that can be downloaded as a single-file statically-compiled self-contained binary for a variety of platforms.

Setting Up the Cloud Storage Service

Backblaze vs wasabi reddit
  • Wasabi: Create your Wasabi account and set up your buckets following these instructions.

  • Backblaze: Set up your Backblaze account and enable B2 following these instructions.

Making Your First Backup with “restic”

Initialization

“restic” can take all its arguments, options, and settings at run time.However, what we are going to do is to create a shell file that defines the values we need in some standard environmental variables, and we will source this file just before running any backup or backup management operations.This makes running restic as simple as, e.g., “restic init” instead of “restic init -r s3:https://url/of/repo” etc., as “restic” will just look to these variables for the information that we need.Note that you do not need to leave all these variables in there if you feel uncomfortable having them around: you can just supply them as needed.The variables you will need to define vary depending on whether you are using Wasabi or Backblaze:

  • Wasabi: Create and obtain your access ID and key pair, following these instructionsThen, create your directive file that populates the appropriate environmental variables, e.g., “~/.backup-configs/restic-wasabi-config.sh”:

  • Backblaze: After [setting up your B2 account](), you need to obtain your B2 account identifier and key.Then, create the directive file to be sourced, e.g., “~/.backup-configs/restic-b2-config.sh”:

Repository Creation

  1. Source the repository directive files to populate the environmental variables with all the information that “restic” needs;

  2. Create the backup repository using the “init” command.As we have exported the environmental variables specifying (1) the access identifier; (2) the access key; (3) the repository URL; and (4) the repository password above, the command is very simple. Otherwise we would have to specify these values as arguments, options, or enter them in when prompted.

    Also note that you could manually create the cloud storage bucket, but “restic” will also automatically create one for you if it does not exist.

  3. Create the first “snapshot” using the “backup” command (note that the “–verbose” flag does not work in the older versions of “restic” available from the Ubuntu repositories as of 2018-10-10), with path(s) to the directories on our local system that we want to backup.

  4. Check the backup using the “snapshots” command:

Making Subsequent Backups with “restic”

  1. Simply re-run the backup command to take another snapshot:

  2. And check to make sure it there:

Mounting the Remote Backup

As the saying goes, “amateurs talk about backups, professionals (or the old souls) talk about restoration”.Your backups are useless if you cannot get to them easily.Of course, you can always restore the entire backup (or the latest snapshot) through “restic”, and this is covered in the guide I mentioned above as well as the restic documentation.But what I am going to talk about here is ability the mount the remote backup in a local file system.

Backblaze Wasabi

Folks, this is really, really, really, really, really COOL!

Instead of downloading the entire backup (which you only really need to do in the event of a full machine/disk loss), you can mount the backup as a local directory, browse through the files and view/copy just the directories/files you need.

I will say, however, that I do prefer Borg’s way of handling mounting.“restic” runs in blocking mode in the shell, requiring you to open up another shell session to get to the files and then return to the first shell and send a Ctrl-C to exit.The Ctrl-C unmounts the drive and cleans up … IF you have no other process using the drive, including a shell session that you forgot about.If the latter is the case, then things get into a dirty state, and you have to force an unmount by one of the following:

In this respect, Borg seems to do it right: running the mount command mounts the drive and exits right away, freeing the same shell session for you to do other things including browse the files.And unmounting is a lot cleaner as well.

More …

  • Part 1: what programs/technologies to use, and why.
  • Part 3: scheduling the system to run for automatic backups.
Backblaze Wasabi

Backblaze Vs Wasabi

Links

Backblaze Wasabi Recipe

  • Using “restic” with Backblaze
  • Using “restic” with Wasabi

It depends on the volume of data. Running a second Synology unit at another site and mirroring changes (using something approaching the efficiency of rsync) will easily be the most economical beyond 1tb -- an amount typically included for free with just about every Office 365 subscription. It's not ideal however, unless you plan to perform DR to the cloud; that is, restore a failed local instance to a cloud platform. This is because you will be unable to get one tenth of 1tb of data that stored in the cloud in a timely fashion unless it is being restored to an adjacent platform.

Wasabi Vs Backblaze B2 Reddit

The cool thing about rsync is that the bandwidth use can be near zero as you can do a full mirror once a week but generate a differential file each night and export it to a local drive instead of applying the changes over the internet. That differential file can be used to roll the remote version forward to the time the file was generated. You would only actually apply it to the remote mirror if need be -- testing notwithstanding.