alfresco备份方案.docxVIP

Alfresco 备份先把附件script奉上：alfresco_incremental_backup我们的备份要包括下面三个部分，执行顺序也要按照1，2，3严格执行。备份solr的index文件。备份alfresco使用的数据库。备份alfresco的文件库。为什么按照这个顺序？原因很简单，因为solr的index比数据库早，意味备份时文件还没及时建立索引，恢复后solr会自动建立。数据库比文件库早，意味在备份时用户还没来得及上传文件。系统基础篇在介绍备份前，首先我们先要了解一下备份所用到的核心技术。怎样做到每天备份，并且每天备份的数据都保留下来，这样日后我们可以恢复到任何一天呢？试想一下，如果你有500G的alfresco数据，就算你整个5T的硬盘，做完全备份，也只够10天吧， 并且网络的传输量，也会大的惊人。本文的解决方案是基于linux系统，利用到了linux系统中的硬链接功能。在linux的ext文件格式中，任何一个文件实际由描述文件的inode和存储文件的block所组成，这两个部分并非存储在一起。文件的inode描述了文件的属性以及用于存储文件的block的位置。通过inode，你就可以找到存储文件的block，这个block是真正存储文件内容的部分。block大小是固定的，建立系统时可以自己设定。存储一个文件，可能不止一个block。但一个block中，只会包含一个文件的内容。inode与block相比，其体积几乎忽略不计。同理，文件夹也是由inode和block组成，不同的是，文件夹的block中所写的内容，实际为文件夹所包含的这些文件的inode信息。一份文件可以被不止一个的inode索引。这意味我们在系统上看到多份文件，实际这些文件都指向硬盘上的一份block内容。说得再通俗一点，我现在有两个文件：/folder1/file/folder2/file用命令stat /folder1/file 会发现它的inode信息我123456，stat /folder2/file也是一样，并且文件的links数为2，这说明文件被两个inode指引。分别查看两个文件夹大小，你会发现，他们的体积都是比如说3G，但实际上，这个文件只占了系统3G空间，懂了吧。并且，只有当block没有被任何inode所指引时，才会被删除，意味着你删除了整个folder1，文件仍然在folder2中有效，反之亦然。只有folder1和folder2都删除了，这个文件才被删除。了解了以上原理，我们在来看下我们的备份。第一天我们做了备份，bak1，其中包含file1，第二天我们也做了备份，bak2，其中包含file1和file2，实际上两个文件内的file1是指向同一份block，所以只会占系统一份体积。但是，我们却又实实在在的拥有两个备份文件夹及其下的文件，他们是独立存在的。删除了bak1后，bak2仍然是个完整的备份。有了上面的想法，需要有工具来支持。在linxu系统中我们有rsync这个完美的备份工具，稍后我们会用到。?Solr备份篇备份solr，主要就是备份solr的index文件。关于solr的结构这里就不赘述了，本站有很多文章。solr的备份原理，请查看此文：Solr数据备份。我们的指导思想就是生成solr的index文件，然后采用增量备份的形式，把index文件同步到目标目录进行备份。备份步骤：1. 发送备份请求给solr，在linux中，我们可以用curl这个工具发出https请求。命令如下：curl --cert ${P12_PATH} --cert-type P12 -k --header content-type:Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) ${SOLR_WORK_URL}具体参数：${P12_PATH}：这里我们使用curl模仿firefox浏览器，因此要加上浏览器的证书。这个就是指向证书： /home/ecmkit/servers/alfresco-4.0.d/alf_data/keystore/browser.p12:alfresco 的路径，最后那个alfesco是证书的密码。${SOLR_WORK_URL}：solr目前都采用Restful请求的方式执行任务，该URL要求solr备份/home/ecmkit/servers/alfresco-4.0.d/alf_data/solr/workspace/SpacesStore下的index文件。我这里的具体命令是“https://localhost:8443/solr/alfresco/replication?command=backup”。发出此请求后，