On Thu, May 07, 2026 at 07:45:13AM -0600, Charles Curley wrote: > On Thu, 07 May 2026 13:32:35 +0200 > Hans <[email protected]> wrote: > > > So my solution would be, having drive images, restore them onto a new > > server and of we go. > > > > However, taking drive omages from the running servers is not > > possible, as it is not allowed to shut them down, so the idea cam in > > my mind, to create images from a running system. > > > > But as I do not know, if this is possible at all (due to possible > > changes while the drives are mounted), and could not find a way > > searching the web, I allowed me, to ask here some other experts. > > Maybe they might know, if this issue can be solved or not. > > > > But it appears, it is not, and so my question was fullly answered. > > I don't have an ideal solution to your problem, but perhaps a partial > solution.
The usual solution (we, in a small shop, have been using that in
conjunction with BackupPC) is to have some application specific
pre-backup scripts which do whatever seems necessary (e.g. run
an SQL dump of the relational databases, what not). Then those
dumps get backed up.
Still a bit of a stretch, since the database usually correlates
with "other stuff out there" (think some Wordpress web monster,
where there are lots of little images in the file system and an
SQL structure (barely!) holding that together). So if you want
100%, you have to think harder.
Some monsters (I looked after a Gitlab installation) actually do
have a script to do the back up, which freezes things for a while
while doing a copy of the relevant file structures and the SQL
database. At that time, the service is typically off.
A good RDBMS (PostgreSQL!) actually has a switch ("now starting
backup") which makes sure (disk image + write-ahead logs) describe
a consistent state. When finished copying you can release that
switch. This allows you to back up by transferring one base image
and shipping the WAL regularly. But this is only relevant for huge
(or extremely active) databases, where an SQL dump is a painful
option.
A downside is that those kinds of dump are much more dependent
on the software's version as plain SQL dumps (not that those
are totally independent: MySQL, I'm looking at you!).
That field is as diverse as the applications running on top.
If you're lucky, you get away with taking a snapshot and keeping
your fingers crossed. You better have a plan B in that case :)
Cheers
--
t
signature.asc
Description: PGP signature
