In our artifactory-instance we have multiple huge repositories storing temporary data that do not require a backup. Currently we are exporting the repositories using the System export with the repositories listed in the exclusion and configured the export to run everyday.
However I struggle to find a good solution to ensure that the backup software we are using to archive the exported data doesn't run before the export is finished. Of course it's possible to schedule the two action with a delay of 12 hours and just hope this is enough or always preserve two exports so that there is a at least one complete export, I dislike this approaches. On the first one there is nothing that ensures there was enough time and it prevents the backup system to take over the lead in coordinating the best time to perform the backup during the day. The second approach requires up to the double amount of disk space.
I would prefer to do it the same way as on other systems where you just have a cli-command doing the export and return once it's finished. That way even if the export takes more the 12 hours the backup would be as consistent as possible and the export tool could provide a proper exit code.
We are using artifactory 7.38 and I only found a rest-api for exporting the all repositories or exclude the content at all. There is an import repository api but no corresponding export repository api that is able to export a repository as a file system structure. There is one exporting a repository as a zip-file via https but I guess it's much slow than the export to the filesystem using the system export in the UI.
Is there any other way that allows me to export a repository to the file system?
Related
It seems that Google suggests that multiple cloud functions for a project be either defined in a single index.js file, or imported into the same index.js file:
https://cloud.google.com/functions/docs/writing/#structuring_source_code
Yes, they can be deployed separately. But is importing them into a single index file with same npm dependencies efficient, in terms of sharing all npm dependencies and javascript compiling / memory usage? Does Cloud Functions do some sort of tree shaking for that? Or would it be better if there are a lot of functions using a lot of different npm dependencies to be defined in separate npm projects?
Deploying more code than is actually required at runtime is only really going to have an impact on your code start time, as all that JavaScript will have to be parsed and validated the first time a source file is loaded. It will also have an impact on the amount of memory is used by a server instance. For small amounts of extra code, these might not even be measurably significant, but it's certainly not "free".
As far as I know, there's no difference between deploying in a single file or separately. All the functions run independent from each other and do not share resources, so it makes no difference in the end. It's just a matter of what would be easier to manage, just a single file or several.
Artifactory recommends the steps outlined here when moving from an old Artifactory server to a new one: https://jfrog.com/knowledge-base/what-is-the-best-way-to-migrate-a-large-artifactory-instance-with-minimal-downtime/
Under both methods it says that you're supposed to copy over $ARTIFACTORY_HOME/data/filestore, but then you just go ahead an export the old data and import it into the new instance, and in the first method you also rsync the files. This seems like you're just doing the exact same thing three times in a row. JFrog really doesn't explain why each of these steps is necessary and I don't understand what each does differently that cannot be done by the other.
When migrating Artifactory instance we need to take two things into consideration:
Artifactory Database - Contains the information about the binaries, configurations, security information (users, groups, permission targets, etc)
Artifactory Filestore - Contains all the binaries
Regardless to your questions, I would like to add that from my experience, in case of a big filestore size (500GB+) it is recommended to use a skeleton export (export the database only, without the filestore. This can be done by marking "Exclude Content" in Export System) and copy the filestore with the help of a 3rd party tool such as Rsync.
I hope this clarifies further.
The main purpose of this article is to provide a bit faster migration comparing to simple full export & import.
The idea of both methods is to select the "Exclude Content". The content we select to exclude is exactly the one that is stored in $ARTIFACTORY_HOME/data/filestore/.
The difference between the methods is that Method #1 exposes some downtime, as you will have to shut down Artifactory at a certain point, sync the diffs, and start the new one.
While method #2 exposes a bit more complexed process, that includes in-app replications to sync the diffs.
Hope that makes more sense.
I want to uninstall Alfresco and re-install again, but I don't want to loose the accounts created in Alfresco and the other things. Is there any way to save this ?
Thanks!!
Let's assume that by re-installing you mean you want to start with a clean alfresco WAR and share WAR. If so, you can just shut down, remove the alfresco and share directories, then place the clean WARs in the $TOMCAT_HOME/webapps directory. If you had any AMPs deployed, use MMT to re-install those. Then, restart Tomcat. The content is in the content store directory and the metadata is in the database, so you can start over with fresh WARs without losing any data.
If you mean you want to delete everything in $ALFRESCO_HOME but you want to save your data, the easiest thing to do is to dump your database and tar up your content store. Then you can completely blow away your installation, and after reinstalling, you can load your database and un-tar your content store.
If you are trying to blow away some, but not all of your data, you'll have to export what you want to keep. You might go look at the docs on ACP files as one possible approach. Or you could use something like CMIS to write an exporter.
For users, specifically, it is often helpful to use an LDAP directory instead of managing them in Alfresco directly. That way you can completely start over and Alfresco will simply synchronize your users from LDAP.
If you don't want to use LDAP an alternative is to have a simple CSV file with user account data. After starting your repository for the first time you can re-import your users from the CSV file.
I'm working on migration from Alfresco 4 to 5 and applying any add-ons on Alfresco 4 for the purpose is not applicable. Database used for the both versions are different from each other. I have tried with ACP files and it is very time consuming. Is there a size limitation on ACP files? What other methods can be used?
Use Standard Upgrade Procedure
What is your main intention? "Just" doing an upgrade from 4 to 5?
In that case the robust, easy way would be to:
Install required modules having custom models in your target sytstem (or if you customized models in the extension path than you have to copy that config)
backup and restore the alfresco repo database to your new (5.x) system. If your target system uses a different db product (not just a different version) you need to manage the db migration using db specific migration tools. It is no alternative to use Alfresco export/import.
sync alf_data/contentstore to your new system (make sure the db dump
is always older or you need to do an offline sync)
During startup Alfresco recognizes that the repo needs to be upgraded and does everything. Check the catalina.out for any output during migration.
If you need a subset from your previous system it is much easier to delete the content afterwards (don't forget to purge the trash and you should configure the cleaner job not to wait 14 days).
Some words concerning ACP
It is a nice tooling to export single directories but unfortunately it is limited:
no support accross Alfresco versions (exactly your case)
no support for site metadata / no site export/import (maybe it is working after the changes in 4.x when putting site metadata in nodes but I suppose nobody tested this)
must run in one transaction. So hard limits depend on your hardware / JVM configuration but I wouldn't recommend to export/import more than some thousand nodes at once.
If you really need to use export/import a huge number of documents you should use the import/export in a separate java process which means your Alfresco needs to be shut down. s. https://wiki.alfresco.com/wiki/Export_and_Import#Export_Tool
ACP does have a file limit (I can't remember the actual number), but we've had problems with ones below that limit too. We've given up on this approach in favor of using Alfresco bulk import tool.
One big advantage this tool has, it can continue a failed import from the point of failure, no need to delete the partially imported batch and start all over again. It can also update files as needed, something ACP method can't (would fail with DuplicateChildNameNotAllowed).
I have installed Oracle XE 11g R2 on my machine. I ran few scripts which does the setup by creating schemas, procedures for our application. Now I want to clone this database so that other people by using the cloned dbf file can see the base schema on their respective machine and work on their individual requirement on top of that.
Now it has 6 dbf files
CONTROL.DBF
SYSAUX.DBF
SYSTEM.DBF
TEMP.DBF
UNDO.DBF
USER.DBF
Can i just give them the files or I need to create server parameter file (SPFILE) or Control file. What about the REDO logs.
I have very little knowledge in Database administration. Please suggest. I understand that it is not Enterprise Edition so all things might not supported but assuming cloning process is similar for XE.
While it is possible to restore a database using the data files, I strongly suspect that is not what you're really after. If you're not an experienced DBA, the number of possible issues you'll encounter trying to restore a backup on a different machine and then creating an appropriate database instance are rather large.
More likely, what you really want to do is generate a full export of your database. The other people that need your application would then install Oracle and import the export that you generated.
The simplest possible approach would be at a command line to
exp / as sysdba full=y file=myDump.dmp
You would then send myDump.dmp to the other users who would import that into their own database
imp / as sysdba full=y file=myDump.dmp
This will only be a logical backup of your database. It will not include things like the parameters that the database has been set to use so other users may be configured to use more (or less) memory or to have a different file layout or even a slightly different version of Oracle. But it does not sound like you need that degree of cloning. If you have a large amount of data, using the DataPump version of the export and import utilities would be more efficient. My guess from the fact that you haven't even created a new tablespace is that you don't have enough data for this to be a concern.
For more information, consult the Oracle documentation on the export and import utilities.
Removing content as it is not valid here