How to delete all file except file(s) ...
> ls
1 2 3 4 5 6 7
>
I want to delete files 3, 4, 5, 6, 7 except 1 & 2
> rm `ls * | egrep -v "1|2"`
> ls
1 2
>
Thursday, September 18, 2008
Tuesday, September 2, 2008
Backup and Restore Alfresco
Overview
Backing up an Alfresco repository involves backing up both the directory pointed to by the dir.root setting AND the database Alfresco is configured to use, as if they were a single unit. Backing up either one without the other results in a backup that cannot be successfully restored.
Similarly, when you restore an Alfresco backup you must restore both the dir.root directory AND the Alfresco database from the same backup set - restoring either one in isolation is guaranteed to corrupt your repository.
The dir.root directory is usually defined in/alfresco/extension/custom-repository.properties. By default this directory is named 'alf_data' and is located within the directory where Alfresco is installed.
[edit] Cold Backup Procedure
By default, the dir.root contains both the content and indexes, so for cold backup it is possible to backup just the content and then do a full reindex when a backup is restored. A full reindex can be a time consuming process however, so the steps below include the indexes in the backup.
1. Stop Alfresco
2. Backup the database Alfresco is configured to use, using your database vendor's backup tools
3. In parallel, backup the Alfresco dir.root directory in its entirety
4. Store both the database and Alfresco dir.root backups together as a single unit (neither is useful without the other)
5. Start Alfresco
[edit] Hot Backup Procedure
[edit] Overview
1. Backup the database Alfresco is configured to use, using your database vendor's backup tools (see below for details)
2. As soon as the database backup completes, backup specific subdirectories in the Alfresco dir.root (see below for details)
3. Store both the database and Alfresco dir.root backups together as a single unit (neither is useful without the other)
[edit] Backing up the Database
In an Alfresco system, the ability to support hot backup is fundamentally dependent on the hot backup capabilities of the database product Alfresco is configured to use. Specifically, it requires a tool that can "snapshot" a consistent version of the Alfresco database (ie. it must capture a transactionally consistent copy of all of the tables in the Alfresco database). In addition, to avoid serious performance problems in the running Alfresco system, this "snapshot" operation should operate without taking out locks in the Alfresco database.
Backup capabilities vary widely between relational database products, and you should ensure that any backup procedures that are instituted are validated by a qualified, experienced Database Administrator before being put into a production environment.
[edit] Backing up the Filesystem
Backup the following subdirectories of the Alfresco dir.root directory using whatever tools you're comfortable with (rsync, xcopy, etc.):
* contentstore
* contentstore.deleted
* audit.contentstore
* backup_lucene_index
IMPORTANT NOTE: Never, never, under any circumstances, attempt to backup the lucene-indexes subdirectory while Alfresco is running. Doing so is almost certain to cause Lucene index corruption.
[edit] Notes
* Alfresco includes a background job responsible for backing up the Lucene indexes that (by default) is configured to run at 3am each night. The hot backup process must not run concurrently with this background job, so you should either ensure that the hot backup completes by 3am, or wait until the index backup job has completed before initiating a hot backup.
* The Alfresco WCM functionality includes a background job called the 'avmOrphanReaperJob' that must not be allowed to run while a hot backup is in progress. By default this job is scheduled to run every minute, but this can be reconfigured by overriding the default schedule defined in scheduled-jobs-context.xml. Please make sure you are familiar with Alfresco's Repository Configuration mechanism before making any configuration changes. If you are not using the Alfresco WCM functionality no action is required.
[edit] Restore Procedure
1. Stop Alfresco
2. Copy the existing dir.root to temp location
3. Restore dir.root
4. If you're restoring from a hot backup, rename dir.root/backup_lucene_index to dir.root/lucene-indexes
5. Restore the database from the database backups
6. Start Alfresco
[edit] Lucene Index Restoration
Note that in addition to full restorations, the backup sets created via either the cold or hot backup procedures described above can also be used to restore just the Lucene indexes. This is useful in cases where the repository itself does not need to be restored but for some reason the Lucene indexes are stale.
The Lucene index restoration process is as follows:
1. Stop Alfresco
2. Move the existing dir.root/lucene-indexes directory out of the way
3. If you're performing cold backups, restore dir.root/lucene-indexes from the most recent backup step
4. If you're performing hot backups, restore dir.root/backup_lucene_index from the most recent backup step and rename it to dir.root/lucene-indexes
5. Restart Alfresco
Upon restarting, Alfresco will (by default) detect that the indexes are stale, and incrementally reindex just that content that has changed since the last backup was performed. As the size of your content set grows, the time savings from performing incremental reindexing rather than full reindexing will become greater and greater (incremental reindexing is typically measured in minutes, whereas full reindexing can take hours for large content sets).
Important note: in order for incremental reindexing to occur properly, you should leave the index.recovery.mode property at its default value of "VALIDATE". Setting this property to "FULL" forces a full reindex even if incremental reindexing is possible (thereby negating any benefits from this procedure).
----
Copy Paste From http://wiki.alfresco.com/wiki/Backup_and_Restore without permission.
Backing up an Alfresco repository involves backing up both the directory pointed to by the dir.root setting AND the database Alfresco is configured to use, as if they were a single unit. Backing up either one without the other results in a backup that cannot be successfully restored.
Similarly, when you restore an Alfresco backup you must restore both the dir.root directory AND the Alfresco database from the same backup set - restoring either one in isolation is guaranteed to corrupt your repository.
The dir.root directory is usually defined in
[edit] Cold Backup Procedure
By default, the dir.root contains both the content and indexes, so for cold backup it is possible to backup just the content and then do a full reindex when a backup is restored. A full reindex can be a time consuming process however, so the steps below include the indexes in the backup.
1. Stop Alfresco
2. Backup the database Alfresco is configured to use, using your database vendor's backup tools
3. In parallel, backup the Alfresco dir.root directory in its entirety
4. Store both the database and Alfresco dir.root backups together as a single unit (neither is useful without the other)
5. Start Alfresco
[edit] Hot Backup Procedure
[edit] Overview
1. Backup the database Alfresco is configured to use, using your database vendor's backup tools (see below for details)
2. As soon as the database backup completes, backup specific subdirectories in the Alfresco dir.root (see below for details)
3. Store both the database and Alfresco dir.root backups together as a single unit (neither is useful without the other)
[edit] Backing up the Database
In an Alfresco system, the ability to support hot backup is fundamentally dependent on the hot backup capabilities of the database product Alfresco is configured to use. Specifically, it requires a tool that can "snapshot" a consistent version of the Alfresco database (ie. it must capture a transactionally consistent copy of all of the tables in the Alfresco database). In addition, to avoid serious performance problems in the running Alfresco system, this "snapshot" operation should operate without taking out locks in the Alfresco database.
Backup capabilities vary widely between relational database products, and you should ensure that any backup procedures that are instituted are validated by a qualified, experienced Database Administrator before being put into a production environment.
[edit] Backing up the Filesystem
Backup the following subdirectories of the Alfresco dir.root directory using whatever tools you're comfortable with (rsync, xcopy, etc.):
* contentstore
* contentstore.deleted
* audit.contentstore
* backup_lucene_index
IMPORTANT NOTE: Never, never, under any circumstances, attempt to backup the lucene-indexes subdirectory while Alfresco is running. Doing so is almost certain to cause Lucene index corruption.
[edit] Notes
* Alfresco includes a background job responsible for backing up the Lucene indexes that (by default) is configured to run at 3am each night. The hot backup process must not run concurrently with this background job, so you should either ensure that the hot backup completes by 3am, or wait until the index backup job has completed before initiating a hot backup.
* The Alfresco WCM functionality includes a background job called the 'avmOrphanReaperJob' that must not be allowed to run while a hot backup is in progress. By default this job is scheduled to run every minute, but this can be reconfigured by overriding the default schedule defined in scheduled-jobs-context.xml. Please make sure you are familiar with Alfresco's Repository Configuration mechanism before making any configuration changes. If you are not using the Alfresco WCM functionality no action is required.
[edit] Restore Procedure
1. Stop Alfresco
2. Copy the existing dir.root to temp location
3. Restore dir.root
4. If you're restoring from a hot backup, rename dir.root/backup_lucene_index to dir.root/lucene-indexes
5. Restore the database from the database backups
6. Start Alfresco
[edit] Lucene Index Restoration
Note that in addition to full restorations, the backup sets created via either the cold or hot backup procedures described above can also be used to restore just the Lucene indexes. This is useful in cases where the repository itself does not need to be restored but for some reason the Lucene indexes are stale.
The Lucene index restoration process is as follows:
1. Stop Alfresco
2. Move the existing dir.root/lucene-indexes directory out of the way
3. If you're performing cold backups, restore dir.root/lucene-indexes from the most recent backup step
4. If you're performing hot backups, restore dir.root/backup_lucene_index from the most recent backup step and rename it to dir.root/lucene-indexes
5. Restart Alfresco
Upon restarting, Alfresco will (by default) detect that the indexes are stale, and incrementally reindex just that content that has changed since the last backup was performed. As the size of your content set grows, the time savings from performing incremental reindexing rather than full reindexing will become greater and greater (incremental reindexing is typically measured in minutes, whereas full reindexing can take hours for large content sets).
Important note: in order for incremental reindexing to occur properly, you should leave the index.recovery.mode property at its default value of "VALIDATE". Setting this property to "FULL" forces a full reindex even if incremental reindexing is possible (thereby negating any benefits from this procedure).
----
Copy Paste From http://wiki.alfresco.com/wiki/Backup_and_Restore without permission.
Subscribe to:
Posts (Atom)