Using v. 2.2.12 Enterprise.
I'm testing backup functionality with Studio Backup Management as explained in https://www.youtube.com/watch?v=hU2UkWiDjNM.
Backup is working, I've got backups in specified folder, but not events at all. So I cannot restore.
What's wrong?
Related
is there a way to restore the backup from the backpack backup manager?
I have check the https://github.com/Laravel-Backpack/BackupManager but i can not see an option to perform this action.
That package is just an interface for creating backups using spatie/laravel-backup. It provides no interface for restoring backups - you'll have to do that manually, I'm afraid.
I have setup local installation of Moodle and i have created some courses there and did some customization. Now i want to
1.) put this under version control on an existing bitbucket project and
2.) deploy it to server.
can someone please advise how it can be done.
The code is already under version control - just pull it down using git (see https://docs.moodle.org/en/Git_for_Administrators for more details).
If, however, you are asking about how to transfer the configuration data from one site to the other - you can do that by exporting your database and importing it to the remote site (the instructions for doing this will vary depending on the database software you are using), as well as copying your moodledata directory. This assumes you are fine to completely replace the remote site with the data from your local site.
If you just want to transfer courses, then backup each course and restore them one at a time to the live site.
We have some huge changesets that are causing our migration to grind to a crawl. I am wondering if we delete those folders from the project, will OpsHub still migrate the changesets for the delete folders?
Destroying folders will remove them and all their history (in that path) from the version control data store. OpsHub won't be able to find the folders and as such will not migrate them (they don't exist). You will have to restart the migration. If folders have been renamed, you may need to destroy the data under the old name as well.
Deleting folders won't exclude them from migration. OpsHub will replay all actions and will detect these changes and their history. It will migrate all changesets for the folder up to the final delete.
You can also speed up you migration a lot by destroying old branches (branches cause a lot of drag on your migration). If you have old branches or deleted branches that you don't need to transfer over, then destroy them. Especially Feature branches and old developer branches may not be worth the trouble.
You can also up the memory allocation for OpsHub to give it a little speed bump:
Close the migration utility.
Goto location C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHubServer6.0.16\bin
open the file service.bat in notepad in editable mode. You may need to start Notepad as administrator to edit it.
search for the keyword -Xms512m -Xmx2048m and replace it with -Xms1024m -Xmx4096m, this will increase the memory for java, save the above changes (The numbers are for reference. You can set a higher amount of memory based on your available hardware)
Go to the location from command prompt C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHubServer6.0.16\bin
Run the unregisterservice.bat from command prompt as an admin to unregister the service.
Let the above command execute completely then run registerservice.bat as an admin for registering the service.
Start the utility and start the migration
Running it on you Application Tier or on a machine that's physically close to the Application Tier also speeds up migrations considerably, as it shortens the network round-trips for one side of the migration to nearly zero. Since the Application Tier receives the most requests, it makes sense to put the migration there and not close to Visual Studio Team Services (by installing it on an Azure machine for example). Ensure that the AppTier has enough disk space for its version control cache.
Also monitor your SQL server closely, querying some of the branch history can be very CPU intensive, some SQL server settings can make a big difference. Ensuring that there are multiple TempDb files is one, tweaking MaxDOP can be another. See some tips on optimizing your SQL server for TFS here.
We are moving from on-premise tfs 2012 to the visual studio online environment.
For this we need to move a lot of projects, most of them aren’t a problem with the free opshub tool.
But 2 of our projects are really big and the tool would take about 8~9 days to complete the migration, which is too long for us.
What I would like is the following:
Start the migration from on-premise to vso
Keep working in the on-premise
After the migration has finished, migrating the commits that were made in the last 8~9 days.
I’m not sure the free opshub tool supports something like this.
Is there a way to do this with the free tool? If so how does this work?
That is feasible. You just start the migration initially, as your initial run is completed, and the status of migration goes to not running, you go the View Progress page, and start the already configured migration.
This will pick the newly added changes, that were done to the on-premise instance, after the actual migration started.
Note: You will get a process vs total revision count mismatch in status page in such cases, as total count is not calculated only once at start of the migration.
How can I ensure that a TFS 2010/2012 clone doesn't interact systems from my production environment? I want to run the clone in parallel for doing an upgrade test and some further tests. The clone should not interact with production systems. Is there a way to do that, without knowing all involved systems excatly?
You will need to run the ChangeServerId command to ensure that the GUIDs for the configuration database and collection databases are changed. Here is a link to the MSDN article on the command: http://msdn.microsoft.com/en-us/library/vstudio/ee349259.aspx
NOTE: You must ensure that the app tier is not configured for the databases before running this command. If an app tier is configured, you will need to run the RemapDBs command located here: http://msdn.microsoft.com/en-us/library/vstudio/ee349262.aspx and restart the TfsJobAgent service on the app tier.