Can't you use dbbackup to perform an online backup? I believe that is what was used in some software that I previously used.
No. And the issue is universal. In an app like EagleSoft, SQL Anywhere is embedded, there is no RDBMS. So no software of this nature can work around the limitation. It's like JetDB (Access) or SQLite in that way, in this situation.
For any software like that to work you have to have a DBMS that handles access control and locking for that kind of tool to work. If you had Sybase SQL Anywhere the RDBMS then yes, that would work perfectly. Just as the similar tools do for SQL Server or MariaDB.
If you follow that link they have that mentioned in the first paragraph - online backups limited to "running" databases (e.g. not embedded.) There's no running database in this case, only a driver built into EagleSoft.
@scottalanmiller I have not had to do that before with a normal backup to a .bak and then restore. Not some an place move like it seems you are doing.
Happens if going to a space with a different storage layout. If you are coming from Linux you are probably fine. But Windows injects the drive letter into the path (obviously) and so going from one machine to another that doesn't keep identical storage path names causes the issue.
Remember.... just because you are virtual does not imply that your storage is virtual, nor does virtual storage imply that the storage will be shared between workloads or VMs. None of that is implied or suggested in going virtual. You still maintain all proper storage management decision making when virtual as you did physical. You don't get to give any of that up.
In restrospect, I probably ought not have included the System Center Dude stuff in the discussion, since it seemed to just cause confusion about what I was curious.
You still maintain all proper storage management decision making when virtual as you did physical.
I believe this is the greatest takeaway from the discussion. Regardless if the environment is like the one I'm in where ultimately one physical storage device is hosting all of the virtual storage within the VMs.
Tried your link. Results:
yum install /tmp/FirebirdSS-2.5.9.rpm
Loaded plugins: fastestmirror
Examining /tmp/FirebirdSS-2.5.9.rpm: FirebirdSS-22.214.171.124139-0.amd64
Cannot add package /tmp/FirebirdSS-2.5.9.rpm to transaction. Not a compatible architecture: amd64
Error: Nothing to do
Kernel and CPU Linux 3.10.0-1062.18.1.el7.x86_64 on x86_64
Looks like their packages are bad at this point. You definitely have the right, matching architecture there. Seems that they are having a lot of problems these days. It's such a niche product, I'd be super wary of every using it in production or any software the depends on it. Using it as an option, sure, but requiring it I'd consider a non-starter. Absolutely no one supports it.
I've seen that a lot. When I import Drupal databases, I learnt to use its Backup and Migrate module instead, it works flawlessly. Downside is you need to do clean Drupal installation first, but that basically is just creating blank database and putting brick on enter key.
There used to be a lot of databases like SQLite. Often called database engines. dBase was probably one of the first.
Later Microsoft Jet engine (aka Microsoft Access) became popular when Visual Basic ruled the world.
Basically it's a one user database. You can have more than one user but it's done by multiple users accessing the same database file.
Or by having an application on top that accessing the file and shares it out. That thing can be called a "database management system" or any application, really.
All databases use database engines. MySQL, for example, isn't a database. It's a database management system. It uses one or more database engines to talk to the files on disk. MyISAM and InnoDB are two database engine options for the MySQL platform.
At the end of the day, all databases work like SQlite. You can easily build your own database management system that uses SQlite as the engine and it could work just like MySQL or Oracle or SQL Server. Those are all single users to a file, under the hood. They just have the "multi-access" management built into an extra layer, instead of letting an application handle it.
But for most things, you only access a database from a single app anyway, so that extra layer is often unnecessary as it is redundant. Just adds overhead.
So, easy fix, the ca_stag2 was a staging DB that was not needed and was not current. The whole thing appears to have corrupted. So I simply "moved" that entire directory to /tmp (just in case I had to put it back) and then MySQL could fire up.
Is it possible for a File server to run a database server ? how would that be classified at that point ?
No, conceptually that would not mean anything. A file server and a database server are discrete concepts.
A single operating system can run neither, either, or both. But as servers themselves, they are discrete.
I gotcha. It was one of those hypothetical questions
What's messy is that technical file servers are a very, very specific form of database server. Because a file server presents a file system over a network. And a file system is a special case database.
No one really thinks about this and absolutely no one will talk about file servers this way, but for understanding what is actually happening... file servers are special purpose database servers. And that is very easy to prove.
So a file server is a database server, but a database server is not a file server. But file servers are so common, unique, and discrete, we treat them as totally different animals and no one considers the two to even be similar.