Backing Up A Block Storage Volume

There are some options that you can consider using, since our Backup Service does not work with our Block Storage option at this time. One option is to create a disk image of the volume and save this your location or another Linode. This can be done by copying the disk over a ssh connection, which we have a guide that can assist you with this process.

Copying A Disk Over SSH

The next option would be to utilize our Object Storage option to backup your storage volume. The one caveat to this is that uploading data from the block storage volume to the object storage volume might be billable and count towards your network transfer quota since this is considered to be outbound traffic. You can reference our documentation for additional insight regarding this particular option.

Object Storage
Object Storage Price & Limitations

Along with these options, there are alternative Linux backup solutions that you can consider using. While "rsync" is referenced in this documentation, this site lists 23 other backup solutions that you can consider trying for your block storage volume.

Alternative Backup Solutions

I see that there is now a Clone Volume feature available by going to your Volume page and using the ellipsis menu "…" next to your volume, and choosing Clone Volume.

You can back up your volume to object storage using borg backup or restic.

I use borg…

-- sw

@stevewi - Just wondering if you'd mind sharing a high-level overview of how you do this? If I've understood correctly (?) Borg doesn't directly work with object storage as it requires SSH. So do you backup to a Linode and use S3Fuse, or similar? Would be interesting to know a little more of your set up!

So do you backup to a Linode and use S3Fuse, or similar?

Yes…exactly…the Linode where the block storage volume is mounted to be exact.

See:

https://jthan.io/blog/borg-backups-on-linode-object-storage/

borg runs inside a shell script that takes care of the administrativia…mounts, umounts, etc.

I have 4 buckets — hourly (every 4 hours), daily, weekly and monthly — with different retentions for each. I use zstd compression.

The script implements an “exclusion list” (similar in concept to tar —exclude*) so I don’t back up transient stuff like sockets, /tmp directories, etc.

— sw

Ah cool - that's super helpful. Going to give it a go :) Thanks for your response @stevewi

How necessary is it to back up volumes from a data loss standpoint - e.g., are they resilient like we'd expect with EBS or S3, or are they loss-prone like a single Linode with backup service turned off (like an instance-store EC2, to maintain the AWS comparisons)?

Yes, I would love to understand the resiliency and need to backup Linode Block Storage Volumes if there is no support from linode for volume snapshots or backups, particularly in the context of their use with LKE.

How does one achieve uninterrupted service for an LKE pod if we have to manually rsync or backup the contents of the volumes attached to them @jchism?

Block storage can only be attached to one Linode at a time, and PVs are RWO (Read Write Once) - so I don't think you could handle it with a process from another pod or a host. So this implies attaching a sidecar or overloading every pod with backup utils, increasing the attack footprint of these containers.

The ideal and Kubernetes supported route is VolumeSnapshots via CSI, which Linode needs to implement in their block storage driver and the volume service to be an option on Linode - https://kubernetes.io/docs/concepts/storage/volume-snapshots/