New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
If you read my reply, you're in another league of cheap, and the price difference between the packages doesn't make it "expensive". You're talking dollars and cents, not tens or hundreds a month.
If you resort to personal attacks, what does it make you? And don't forget what community you are in right now. This isn't WHT.
Append only is better called delayed deletion. I’ll explain how it works for Borg 1.2: Basically you are happily adding your archives and files and then pruning or removing some of those over time. Eventually there there will be many file parts that aren’t used any more. So you run ‘borg compact’ to re-arrange storage and remove those unused parts and regain the space.
With append-only permissions this deletion of old files isn’t allowed. You can even use the transaction log to go back and undelete archives that were already pruned or deleted. This includes checkpoint archives from interrupted backup runs. So it won’t recover as easily with append-only perms. That’s one reason why we have a flexible quota for all plans to prevent such a situation and make sure everything runs reliable.
I understand that, but how should files be cleaned up when append only is enabled? Is the compact operation being executed server side when the quota is being exceeded?
In append-only, you can't clean up old files. So you would need to switch to full access to clean up old files. Else nothing will ever be deleted, as the name says. 😀
Since going back and forth between keys isn't optimal or convenient, you'll be able to run compaction server-side in the future. This is already implemented and will be enabled after more testing in a few days. Looks like this in the UI:
As final step, I want to add scheduled compaction, so old data just gets cleaned every few weeks/months.
That wasn't a personal attack, just saying you're talking the difference of $5/m max between $2/m and $6.67/m, not $200/m and $667/m.
Having fixed storage plans means that he can plan and grow better than having unlimited expanding storage and not needing to have so much reserve capacity that the big clouds do.
This helps keep the costs down.
If we are talking about fixed pricing then borgbase is much more expensive than hetzner storage box which also supports borg. In addition, there is no annual commitment required from hetzner like borgbase. You get ssh access so you can setup as many repos as you want with no limitations. This is why I've been saying borgbase's pricing strategy is not friendly or competitive when compared to others. They would be in a better position if they don't need to commit people to certain fixed plans annually. For some consumers, annual plans with a pretense of being flexible can be a turn off. This isn't an argument if people are cheap or not, it is an argument about borgbase's pricing structure. But if you are fine with it, I'm glad for you. It just isn't for me.
https://www.hetzner.com/storage/storage-box
Thanks again for your great feedback and research!
We are different from Hetzner's Storage Box in that Hetzner supports many different protocols and is based on ZFS. So it's better suited to use it with a simple tool like rsync and do snapshots server-side. To use it with Borg the way we offer, will need changing ports, binary paths and adding sub-accounts to separate all your backups. You will also don't get monitoring, server-side compacts and other things we can do by supporting Borg only.
We are also very active in the open source community around Borg and actively contribute code (right now I'm working to refactor Borg's setup.py script) and money. If you care about the long term health of an ecosystem, this should be important to you. Of course, if you see yourself as free-rider, who only takes and takes and then moves on when a project is sucked dry, that's fine. It took me a while (Log4j was an eye-opener) to realize that too, so I don't blame you for not seeing the big picture yet.
Sorry m4nu, I didn't mean to derail your thread with hetzner's plug.
No problem. Always happy to explain the difference between different offerings. 😀
Whoosh. You can't compare do-it-yourself box with managed Borg service. You now have to handle the backend security, updates, backups, etc. That's substantial time and labour. No webGUI reporting, etc.
You're correct that this isn't for you. Nothing is because you're comparing Apples, oranges and berries and trying to pick the best of each and have a megafruit or something.
Did you even read their offering? It is a managed service, no need for updates and manage security, wtf this is not a unmanaged vps, lol. 10 automated snapshots with an optional 10 manual ones you can set yourself.
As for the web-gui, that is a thing going for borgbase. But you can just use borgmatic info to see all that in command line.
Oh, my bad. I was going by "You get ssh access so you can setup as many repos as you want with no limitations." to mean to also install Borg, but you literally just meant the repo setup for existing borg installation. Enjoy Hetzner!
Hello,
I have been looking for ways to improve my backups so I took this opportunity to try backups using Borg.
But so far, it just doesn't seem to work for me
I am using CentOS 7 mainly on my servers and borgmatic just doesn't seem to work with it.
Can someone please help ? @m4nu
[root@vm ~]# borgmatic --version
Traceback (most recent call last):
File "/root/.local/lib/python3.6/site-packages/pkg_resources/init.py", line 573, in _build_master
ws.require(requires)
File "/root/.local/lib/python3.6/site-packages/pkg_resources/init.py", line 891, in require
needed = self.resolve(parse_requirements(requirements))
File "/root/.local/lib/python3.6/site-packages/pkg_resources/init.py", line 782, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (borgmatic 1.5.22 (/usr/local/lib/python3.6/site-packages), Requirement.parse('borgmatic==1.1.15'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/borgmatic", line 6, in
from pkg_resources import load_entry_point
File "/root/.local/lib/python3.6/site-packages/pkg_resources/init.py", line 3266, in
@_call_aside
File "/root/.local/lib/python3.6/site-packages/pkg_resources/init.py", line 3241, in _call_aside
f(*args, **kwargs)
File "/root/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3279, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/root/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 575, in _build_master
return cls._build_from_requirements(__requires__)
File "/root/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 588, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/root/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 777, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'ruamel.yaml<=0.15' distribution was not found and is required by borgmatic
Sure, just PM me the details. I often help people setting up their stuff. (free for everyone)
Since our Ansible role is being tested and works on CentOS7, it's probably just a minor issue.
Also dropped 2 new features this morning:
You can now run
borg compactserver-side to clean up old segments. This should make pruning and deleting a good bit faster on the client. More...Replaced Rsync with SFTP for migrating repos or checking the transaction log (usually not needed). More...
Finally, World Backup Day is here and we have reached the last days of our promo for new users.
No matter which backup you end up using, take this day to check them and don't wake up a (April's) fool tomorrow. 😄