# cheap remote backup



## covacat (Nov 28, 2022)

I have a zfs pool about 400GB which i need to backup remotely daily. I create daily snapshots locally and send them to the remote box with zxfer (zfs send over ssh)
i keep 3 weeks worth of daily snapshots
The problem is that block storage is not exactly cheap mostly about $0.05 to $0.1 / GB which will be $15-$40/mo just for storage.

Then i found frantech.ca that rents block storage with about $1.5/250GB. Nice. So I get a 1GB vm + 500GB storage for $6/mo.
(ordering something on frantech.ca is a pain the ass, always out of stock, use some scripting to notify you when available)
ok so i installed freebsd 12.2 or 12.3 which was the latest 12 branch (my source box is 12 so i thought to have the same codebase for zfs as the source)
attached the block storage, encrypted with geli, created a zfs pool
now sending the data from source was always failing with out of memory (well the destination box has only 1GB ram)
then I installed 13.x and it worked better, still sometimes zfs send was failing with out of memory.
It worked for months without problem then it would bomb daily, kind of painful.
I used a malloc bomb to try to memory pressure it and force it release some memory but without much success.
The wired memory grows to about 700-800M and the malloc bomb can decrease the usage to about 500M which is not always enough.
I do not mount the backup datasets, only the default zroot pool is mounted (i should had tried with UFS on root maybe)
retrying the send sometimes works, sometimes bombs

In the end i exported the block device (da0.eli) via iscsi (ctld) and using iscsi over a ssh tunnel
and attached it to a local box with enough memory
iscsi performance is crap (RTT from office to frantech is 25ms) but I don't really care if the backup takes 2minutes or one hour
so far it works. 
other options are:
pay $3.5/mo more and get a VM with 2GB (this will probably work without trouble)
use the same 1GB VM but with UFS on root and hope will do better (too lazy to try for now)
move the iscsi initiator from office to another vm closer to frantech for a better RTT - i have a VM with enough ram which is 4ms from frantech 

i have other backups too so if frantech vanishes over night im still ok


----------



## _martin (Nov 28, 2022)

covacat said:


> In the end i exported the block device (da0.eli) via iscsi (ctld) and using iscsi over a ssh tunnel


 I've done something similar. But there's one benefit of this, especially if one is paranoid. If you export LU (not even crypto) from cloud provider to your trusted host you can create geli device there. All keys are then on trusted box only.


----------



## gpw928 (Nov 28, 2022)

Having the initiator locally encrypted is elegant.
However, there is still risk if you completely lose your local site .
The geli keys would need to be secured separately.


----------



## rootbert (Nov 29, 2022)

backblaze is cheap ... ~5USD per month per TB. I do backup with restic/rclone.


----------



## tanis (Dec 3, 2022)

pCloud might be worth a shot, in particular the lifetime packages.

My daily backup goes there using rclone, I got the 500GB package annual pricing for almost 2 years now. So far no issues.


----------



## hardworkingnewbie (Dec 4, 2022)

rootbert said:


> backblaze is cheap ... ~5USD per month per TB. I do backup with restic/rclone.


Yeah, well... Backblaze B2 is a mixed calculation. 

Storage is just at 0.005 US$/GB, so 1024 * 0.005 = 5.12 US$. That's right. 

But in case you ever need to restore that fully, you've got to pay 1024 * 0.01 US$ = so 10.24 US$. 

So for Backblaze Storage is cheap, but traffic costs extra. 

There's also rsync.net in Switzerland, which only offer zfs send. Their stuff runs on FreeBSD servers. 4 TB minimum order. https://www.rsync.net

Or Tarsnap, which is also the brainchild of a former FreeBSD developer. https://www.tarsnap.com/


----------



## sko (Dec 5, 2022)

For storage there is cheap, fast and reliable - and you only get to choose 2.

If this is business-critical data, price shouldn't be the issue - reliability and speed (for fast recovery) or proximity (so one could just drive over and grab the backups) should be the main concerns. But I assume this is private data, so you should maybe decide if all of this really needs to go into the (presumably) highest backup tier.
I'm using 3 tiers for my personal data, where everything is first backed up locally, some of it also goes to backup space at a hoster I trust and have rented root servers for 10+ years from (manitu.de) and the _really_ important stuff additionally goes to tarsnap [1].

[1] https://www.tarsnap.com/


----------



## cracauer@ (Dec 10, 2022)

1 GB of RAM is really low for a system with ZFS, to put it mildly, as is 2 GB.

You are storing the snapshots as files, right? You don't integrate them into a target ZFS?

Overall my first thought would have been iSCSI, too. Maybe you can find a filesystem that has fewer interactions/round-trips with the underlying block layer?


----------



## covacat (Dec 11, 2022)

cracauer@ said:


> 1 GB of RAM is really low for a system with ZFS, to put it mildly, as is 2 GB.
> 
> You are storing the snapshots as files, right? You don't integrate them into a target ZFS?
> 
> Overall my first thought would have been iSCSI, too. Maybe you can find a filesystem that has fewer interactions/round-trips with the underlying block layer?


the snapshots are integrated in a remote zfs pool / otherwise i could just use ufs and even less than 1GB ram
the datasets of the backup pool never get mounted and are set to readonly
zfs is kind of 'design' requirement because i like to have the snapshots/history
if i drop zfs i can drop block storage altogether and then there are  more options around the same price point
the backup speed is not that important as long as it completes in less than a day (i takes several minutes)


----------



## PMc (Dec 12, 2022)

cracauer@ said:


> 1 GB of RAM is really low for a system with ZFS, to put it mildly, as is 2 GB.


Not sure why this would be the case, if speed is not the issue.


```
Mem: 19M Active, 245M Inact, 21M Laundry, 146M Wired, 36M Buf, 43M Free
ARC: 31M Total, 12M MFU, 17M MRU, 96K Anon, 1012K Header, 1189K Other
     19M Compressed, 61M Uncompressed, 3.16:1 Ratio
Swap: 1024M Total, 2992K Used, 1021M Free

Filesystem           1K-blocks    Used   Avail Capacity  Mounted on
/dev/vtbd0p3           3043640 1629612 1170540    58%    /
devfs                        1       1       0   100%    /dev
bf/usr/obj             4970175 2191788 2778387    44%    /usr/obj
bf/usr/src             3172534  394147 2778387    12%    /usr/src
bf/usr/ports           2959769  181382 2778387     6%    /usr/ports
bf/var/log             2814028   35641 2778387     1%    /var/log
devfs                        1       1       0   100%    /var/named/dev
/usr/lib/engines       3043640 1629612 1170540    58%    /var/named/usr/lib/engines
/usr/local/lib/named   3043640 1629612 1170540    58%    /var/named/usr/local/lib/named
```

That's my nameserver. 512MB ram, 10GB disk KVM. I wouldn't get the sources onto that one without zfs compression. (I don't build there, but I do the installworld from these.)

But for a cheap offsite backup I would rent an old (it doesn't need to be fast in compute) dedicated one. Might get 2 x 2TB mechanical drives and 8 GB ram for less than 20$/month.


----------

