I have a backup of a firebird database. I would know which version of gbak has made it and which version of firebird comes from.
Is it possible know this information?
PS: I googled a lot but I don't found a solution; the only workaround I found is try to restore with different version of firebird and gbak
The gbak utility of a Firebird version will be able to read all backup formats of earlier versions (in theory since InterBase 4.0, although that isn't tested anymore). So if you want to restore a backup just use the latest version of Firebird to restore the file.
Also if you need to restore to an earlier Firebird version, you can use the gbak of the latest Firebird. When restoring to an older Firebird version it is capable of restoring a new backup format to an older server (although if the backup contains features of newer Firebird versions those parts will not be restored or the backup might fail, and you will also need to recompile all stored procedures).
The only potential snag is if the backup was from a different endian system, and the backup was not made transportable (the default is transportable though).
Usually Firebird backups are stored in External Data Representation (XDR) format.
That means file contain only XDR backup version, not Firebird version or even Gbak version. Backup version is not directly related to Firebird version.
Also, XDR backup is back FB version compatible. If your DB doesn't have any new specific FB features, you may downgrade it freely by restoring it using old version gbak.
Related
I executed a repair using flyway and deleted the file that caused the error.
Since I have executed the repair, it's not possible to migrate any other files anymore, although there is only one version present in the flyway info, which is just the flyway-baseline itself.
With the command flyway migrate, it says that the schema is up to date, so there is no migration necessary, although I provided textfiles in the sub-folder "sql".
It worked properly before I had executed the repair command...
Hope someone can help!
Cheers,
Yasmin
The system I have is a local machine for development with the dev DB and a number of remote servers with the production database. While looking for a system to manage the versions of my SQLite database I found Liquibase but I can't understand if it will work for what I need. Which is updating the schema of the production databases when i release a new version, adding the changes configured in Liquibase's changelog file for that version. Ofcourse all the rest code is under GIT so, if Liquibase only needs the changelog files I can put them in the repository, but if it needs something else it could become a problem.
Yes it should work. If you are using liquibase for first time it will run all the migrations and will store information in your database by creating seperate table for itself. Though you should verify the structure at both local and production is same and migrations won't cause error.
We have a database created on SQL Server 2017 (Express edition) on one of our servers and we are trying to move this database to our another server which has SQL Server 2014 (licensed version) installed on it. We have tried to restore the backup, detach/attach database files and also tried generating the script and running them on new server.
But unfortunately we are not able to restore the database. For backup/restore, we are getting following error message.
For generating scripts and running them on new server; the problem is that the file size of the scripts is around 3.88 GB. We are not able to edit this file before executing it because file size is too large. We have also tried to first generate scripts without data and then with data but the file size with only Data comes up to 3.88 GB (there is only very little difference when only Data is selected).
What are the options we have?
Since you probably already have the schema and data scripts.
You could use VSCode with SQL Server extension to execute the scripts against a previous SQL server version. Sublime is also able to handle large files. See this question for all editors with large file support.
But only if you generated the scripts using the correct compatibility level.
Be aware that with the script not everything is scripted by default like triggers. So you might want to change other options.
I'm reading the documentation on Scylla's upgrade procedures (
reading the dochttp://docs.scylladb.com/upgrade/upgrade-guide-from-2.0-to-2.1-ubuntu/ for example), and I'm seeing the standard "Stair-Step" path is required from 1.6->2.0->2.1, etc.
As a general question, if I have a backup from an older version of scylla 1.6 (or 1.4 or 1.5), is can I load that into a newer release and the data be migrated automatically? Is there a manual process or a tool that I can use?
Or is the only way to get data from 1.6 to 2.1 to load data into a 1.6 database, do a 1.6->1.7 upgrade, a 1.7->2.0 upgrade, then a 2.0->2.1 upgrade.
You can restore older backups into newer versions just fine. The stair-step procedure that is listed is intended for online migrations (without downtime). If you are doing offline migrations, you can skip versions just fine.
Note that there is a caveat with that: if the tables you are moving come from a different cluster (if you completely wiped out this cluster, for instance) then you have to be mindful of the token ranges of each node when copying the files: just because you had 5 nodes before and have 5 nodes now, it doesn't mean that those nodes own the same token ranges.
Aside from that small caveat, you are good to go!
I have an eshop running PS 1.3.6 version. On my local I've updated to 1.4 first and then to 1.4.1...
Now I would like to update on server... is it possible to just upload files from my local 1.4.1, adjust the settings file and run the update script from 1.4.1 directly (without the middle step to 1.4)?
I can see there are database update scripts for each version, so it should be safe to do it like that, but I want to be sure before I run it on server.... thanks
I am usually doing the major upgrades this way:
Take a snapshot of the current site (tar.gz) & backup database using mysqldump tool (for compatibility);
Download all the files and setup the site on your local server machine using database dump (via mysql command) and downloaded snapshot. Adjust settings if necessary.
Perform an upgrade on your local site, thoroughly test it and test it again with your code & theme.
Repackage your updated files and database (tar.gz & mysqldump) and upload them to the server.
Erase the old site and untar upgraded site to its folder to take its place.
Replace old database with an upgraded one (using mysql command on the server).
Adjust settings if necessary. Test and run it! :)
That should be all. If you're more advanced you could optimize most of the steps. Give me a shout if you need all the useful commands to back up and restore files & DB.