Hi All,
could you share what is the Pros and Cons, using Replica and Archive
for HCL notes client , for email backup for user
Thank you All
Best Regards
Endro
Regardless of mail db or any other db, replica is an exact copy of the original database. Depending on the settings, a document deleted in main db will delete the same from replica and vice versa.
The reason to have a replica say on local in case of mail db could be to facilitate off line working. Eventually the replicas will synchronise with the main db.
Archive would mean moving documents as per criteria into an archive database. The documents in archive are not there in the main db and vice versa. This reduces the size of working db leading to performance payoff. Any old document if required can be accessed from archive db.
Pros and cons depend upon your use case and preferences.
Using both of them together is always an option
Great ! thank you ! is it possible to use both of them ? but I guess a bit complicated right
Not at all. Both are different activities. You can go ahead with both without any consequences.
Also a replica on another server could provide a method for failover to the notes client.
Please accept the solution if it really helped you.
Hello @Alan LAM you can utilize both archive and replica. An archive database stores older documents that are moved from the primary database, while a replica is a copy of the entire database that is kept on another server
Pros of using replica:
- You can plan your replication strategy which databases need to be replicated, how often, and which servers should be involved to minimize network impact.
- You can manage replication schedules to set up scheduled replication times to avoid overloading the network during peak usage hours.
- You can implement access control to ensure consistent access control settings across all replicas to maintain data security.
Cons of using replica:
- Regularly replicating large databases can consume significant network bandwidth, impacting performance, especially in low-bandwidth environments.
- If users modify documents on different replicas without proper synchronization, conflicting versions of the same document can arise, requiring manual resolution.
- Maintaining multiple replicas across different servers increases the overall storage required.
- Managing access rights on each replica separately can be complex, especially when different security policies are needed across locations.
Pros of using archive:
- You can define what data to archive, retention periods, and access controls.
- It has efficient data management capabilities
Cons of using archive:
- Maintaining and managing the archive storage space to hold archive databases
- Controlling access to archived data and ensuring appropriate security measures are in place can be complex
Hi Sandeep, Really appreciate your thought , thank you very much
Hi,
I just wondering what happen if the replica db become max, so I need to create another db right. I am thinking about the first db and the second db, will be have redudancy.
pls advise
thank you
Regards
Endro
If maindb becomes max, all its replicas will also become max since they are synhronized immeditely if the servers are in the same cluster otherwise as per replication schedule. Replicas will provide redundancy if they are held on different servers in case the home server is down. You will have to fine tune the configuration for this.
Archiving or permanent deletion of documents along with compact are the only options to reduce size of database. DAOS will also help if attachments are moved outside the nsf. Having external view indexes also would contribute to file size reduction. (See NIFNSF tab in server document. Db should be atleast ODS 51 for this to work) this provides significant file size reduction and access speed.
Hope this helps. Replicas are not a method to control db file size or max size. That is the job of archiving which splits the main db into multiple databases as per archiving criteria.
Hi Endro,
I'm not sure you're asking the question to get the answer you need. If I understand you correctly, you have a mail database that is growing large and you wish to split it so that it does not fill. You also wish to have live redundancy, and a backup in case something happens. That's the way I understand your situation, so please feel free to correct me if I'm wrong.
Replicas, Archives and Backups are three different parts of the same solution, you don't choose one or the other, you use all three.
For your live email, you make sure you're on the current ODS version in the mail file which increases the maximum size to 256GB. This is generally way more than enough for a mail database, but some customers have neglected to upgrade their ODS and their mail files sit at the old limit of 64GB.
Your second action is to make sure that you have replicas on clustered Domino servers. This ensures you have redundancy of your live/active email. It provides failover as well as load balancing for your mail users and can also provide not only host redundancy, but site redundancy. Replicas are exact representations of the data in each database and therefore are not considered 'backups' because when you modify data in one database (e.g. Delete a document) it also deletes the document from the other replicas. Replicas are for redundancy, not backup.
Your second component in the system is to enable a backup solution. There are a variety of backup solutions out there, but the one that is built into Domino will allow you to take consistent "copies" of data and place them in a location for long-term storage. The subject of Backup Architecture is more complicated than this because you will want all three parts of a backup solution [1. OS & program backup (via snapshot or other?), 2. Data backup (via Domino Backups) and 3. Transaction log backup (Via Domino backups) Remember, the Domino backups should also be pushed off to tape or cold storage if you need longer term retention. Backups is a whole subject on its own, but the point here is that you are taking a copy of the databases, using the proper tools, and storing it elsewhere; This may be "off machine" and it might also be "off site" or even "offline". Backups are not 'live' for the user to reach and access.
Your third component in the system is Archives. Archives are used to control the age of active data in their live mail files. This reduces the stress on the server and saves cost in a variety of ways (less hardware required, less strain on the server, less backup needed and so-on). An archive will pull data out of the Live mail file, and place it in a secondary mail database, known as the archive, based on a set of criteria that you specify. This Archive database may be offloaded to a secondary, lower-power, less-redundant server, which improves performance of your primary server. The archive is still linked to the primary mail database and users can access the old data "live". Again, this is not a backup, this is just a division of old data onto other hardware. Since Archive databases are just databases, they also have a 256GB storage limit and would need to be backed up - perhaps less frequently / rigourously. Technically, you could cascade this archival process, but, really, 512GB of mail data usually indicates that a user has bigger problems than mail storage and they need to be encouraged to use company IT resources properly.
So there you have it; It's not pros & cons of using Replicas OR Archives. You should be using Replicas, Archives AND Backups for a complete system.
Hi Jordan,
Thank you ! we are used to do the archive and not a replica option. I just don't want to miss any of the email. And also I need to think about the traffic , if we use both archive and replica. I need to tell the user how to use it , etc. So I am gathering the information in this community.
Again Thank you for your thought
Regards
Endro