How do I backup docker volumes?
I never found a native flow for backing up docker compose projects.
While not built in k8s has at least velero and kasten. However they are only possible because of snapshots https://kubernetes.io/docs/concepts/storage/volume-snapshots... and kasten has a plugin like architecture (because of k8s ) that supports application specific backups.
However I never found something like that for compose. And that is troublesome in bigger projects like sentry
The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling.
Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (like PostgreSQL) might also have other online backup tooling.
AFAIK volumes are nothing more than a bind mount on a private docker folder, e.g. the files for volume my-volume are stored in /var/lib/docker/volumes/my-volume/_data, so backup strategies (an problems) for bind mounts apply also to volumes
Yep, that is accurate. There is also a command/API route to find the path on disk iirc.
In my setups it just was easier to use fixed paths (or relative to project dir) from a permissions management perspective. Backup tools did not always have to/should run as root which is helpful on machines providing multiple distinct services.
Putting borg or a similar tool in a container that is part of the compose manifest file can also help. I haven't seen this used in practice though yet.
Why use a docker volume? Seems like a good way to accidentally lose your files. Just volume-mount from the external filesystem and back it up the same way you would any linux application's files - maybe stop it, maybe not, depends on how it uses files.
It's nice to be able to survive someone purging Docker by accident, and it's nice to know `/wherever/you/like` is where your files are instead of in `/var/lib/containers/some long hash/`
The latest nuclear reactor built in Europe was in France and took 17 years and its costs were 23 billion euro (roughly 27 billion $) with this amount of money you can basically install around 750000 heat pumps costing 30000€. So no it is probably not arse-backwards. (Germany alone would need 20-25 of them and it is unlikely that we can build more than 3-4 at the same time and even that is unlikely…)
Now pick the best (least costly / swiftest build) new power reactor build in the last ten years anywhere in the world.
And anyway, your numbers are disingenuous, because it ignores the fact that heat pumps need electricity to power them, and that nuclear power reactors can provide district heating and that, and that the mean time between failures for the average split system heat pump is 7 to 10 years and that heat pumps sometimes fail in ways that the ozone depleting refrigerant to escape.
It’s evident the average commenter on this subject hasn’t run the numbers on a full cost benefit of the various options.
A mix of nuclear / hydroelectric / combined cycle gas turbine power plants provided ample electricity for end-users to make use of cheap to manufacture heating technology (resistive), low maintenance, low replacement costs.
> Now pick the best (least costly / swiftest build) new power reactor build in the last ten years anywhere in the world.
Unless you can pay the workers the same rates, and it's politically acceptable to the electorate to use the same standards, this is as irrelevant as the fact (yes, I have done the maths on this) that it's *technically* possible for China to divert an affordable percentage of its aluminium output over a decade to build a genuine planet-spanning power grid with 1Ω electrical resistance so you can have your mid-winter midnight electricity supplied by the mid-summer midday on the opposite side of the planet.
> and that nuclear power reactors can provide district heating and that
I have a heat pump. It works both ways, which means that unlike district heating, it also cools down the building in summer.
> that heat pumps sometimes fail in ways that the ozone depleting refrigerant to escape.
"Can" is also doing a lot of heavy lifting even if such things hadn't been banned.
> A mix of nuclear / hydroelectric / combined cycle gas turbine power plants provided ample electricity for end-users to make use of cheap to manufacture heating technology (resistive), low maintenance, low replacement costs.
Hydro is cheap, but nuclear isn't. Hydro also works as a buffer (and pumped hydro as storage), so if you're combining it with stuff anyway, may as well combine with PV. Even small-scale domestic rooftop PV (which is the most expensive PV) is cheaper than nuclear at this point, so cheap that it makes sense to use as a fencing material even if you never get around to using it for power generation.
BTW the last day. I played with Claude to fix the simple things all by himself. Sadly we are on gitlab so I needed to tell him to use glab cli and I needed a little bit more time to setup than GitHub (why do they not support gitlab or other code forges…)
However it is definitely a time saver in these 1-3 line changes. My workflow basically was:
Let the LLM cook by doing the issues one by one. In the meantime I could start reviewing them. Checkout, running, reading.
It was definitely faster since it also correctly linked everything, etc. of course once the change goes beyond that it probably is not working.
However I really thought that a good idea would be to check for that work and implement it according to the issue description and change a Mr once the description changes, at least as long as the Mr is 1-3 lines. And even if it does not work, I can just discard it.
(A lot of these problems are often typos that do not even need a checkout, they come in through bigger Mrs that should not be blocked because of them)
It looks like you know way more than the entso report. Which mostly blamed it on governance. Mostly because a small change in a complex system can lead to cascading failures. They also included data to prevent it in the future. And yes solar and wind power makes these failures more complex but they are certainly not to blame. (Just read the article…)
The reason is that classical grids are mostly self-correcting. Rotating inertia can stabilize frequency and can produce or absorb reactive power.
"Reactive power" sounds fancy, but it just means that motors can create a drag. The power lines are giant capacitors, and capacitors have the lowest effective resistance when they are discharged. So the current is greatest when the voltage crosses the zero mark. Inductive (rotating) loads are the opposite, their effective resistance is greatest when the current starts to rise or fall. So this limits the initial inrush of the current.
But there's more! When you have a transformer and a long line, you can essentially get a boost converter. The voltage from a transformer travels through a low-resistance wire until it reaches the end, and because the line can be modeled as a series of capacitors, you essentially get a "charge pump" ( https://en.wikipedia.org/wiki/Charge_pump ). From the viewpoint of the generator you have one large capacitor, but from the viewpoint of a consumer in the middle of the line, you have two capacitors in series.
As a result, the voltage in power lines can _spike_ if there's not enough rotating load. This is called Ferranti effect, and in Spain it was the primary reason for the faults.
This is all fixable, but it requires investment and regulation. And Spain (and other countries) have been neglecting that, by incentivizing the cheapest possible generation.
I already said REE (the operator) was partly to blame, but they were reacting to something their grid was ill equipped to deal with.
Perhaps you should understand the difference between distal and proximal causes of events? Both are important. Voltage oscillation was the proximal cause. Where did this come from? It's explained in the operators own report:
> During the incident analysis, it was determined that the oscillation was not natural to the system but rather
forced. This oscillation is observed with significant amplitude at a Photovoltaic Plant located in province of
Badajoz (PV Plant A). At the time of the oscillations, the plant was generating approximately 250 MW. Since
the oscillation was forced, it ceased once the plant stabilizes it.
Looks like dotnet got hit with a critical vulnerability. That mostly affected the DataProtection package in version 10.0.6 but it’s possible to be vulnerable on older versions as well, depending on the runtime that was used.
What doomsayers or tech bros never really understand, you can’t be rich without an economy. Which basically means that if 90% of the people loose their jobs, their home, the system by itself will collapse even the stuff that the rich people are needing.
AI will basically either enrich our life like the loom did or it will outright kill the current economic system of the world which might stop poverty at all or it will sort of start a big collapse where people suffer at the beginning but than it will still have a positive outcome at the end.
Humankind always found a solution in the past and it will even do that in the future.
Sad part is, is that ad hoc unions probably won’t make it into v1. That is probably one of the only feature why I like typescript. Because I can write result types in a good way without creating thousands of sub types. It’s even more important when using Promises and not having checked exceptions.
it's for type purists, because sometimes you want the first element of the list but if you do that you will get T? which is stupid if you know that the list always holds an element, because now you need to have an unnecessary assertion to "fix" the type.
The NonEmptyList in Cats is a product (struct/tuple) type, though; I assume the Haskell version is the same. The type shown in the blog post is a sum (union) type which can contain an empty enumerable, which contradicts the name OneOrMore. The use described for the type in the post (basically a convenience conversion funnel) is different and makes sense in its own right (though it feels like kind of a weak use case). I'm not sure what a good name would've been illustratively that would've been both accurate and not distracting, though.
Well you are right of course, I just wanted to explain what they wanted to show. Of course the type would be wrong if the second entry in itself is an empty list. I just wanted to explain the reasoning what they tried to accomplish
They could’ve done the Either type which would’ve been more correct or maybe EitherT (if the latter is even possible)
I don't think they were trying to accomplish the same thing as the Scala/Haskell version; these are just two completely different things that happen to share a name because the blog post gave the example a name that is confusing when read literally. The purpose of the Cats version is “there is always a head element”. The purpose of the union in the blog post is more like “this can be a collection, but many callers will be thinking of it as a single element, so don't put the burden on them to convert it”. I do think it's a weak case for them in a type theory sense (I would tend to position that kind of implicit conversion elsewhere in the language), but I can also see it being motivating to a large class of developers…
… wait, I've made a different mistake here while trying to explain the difference, haven't I? I was describing it as a sum type, but it's not really a sum type, it's really just set-theoretic union, right?
Which also means OneOrMore is unsound in a different way because it doesn't guarantee that T and IEnumerable<T> are disjoint; OneOrMore<object> initialized from [x] will always return [[x]] from AsEnumerable, won't it? If I'm interpreting the switch expression correctly and the first case predominates, since a list is-an object? I don't have a test setup handy; someone with actual C# experience, please tell me whether that's correct or whether the compiler signals an error here or something…
Looks like it failed after a maintenance: https://www.namecheap.com/status-updates/planned-denic-de-re...
https://status.denic.de/
reply