Hi quiz,
yes, it is the same situation. Data Protector will only choose an alternate device in case the primary is busy (locked by another session). Selecting the right destination device is important to have predictable results.
Regards,
Sebastian Koehler
Hi Sebasian,
so will DP timestamp logfiles? Also we are doing nightly fulls so do we need to add incrementals as well?
Also, I'm getting reports from the exchange administrators that the DP passive copy backups are not getting time stamped and he's saying that the logfiles are not clearing.
I did say that DP will truncate logs and I would expect the administrators to perform shrinks of logfiles yes? Just like MSSQL....
This is exchange 2013.
Hi KloppYNWA69,
Logs in MSSQL and Exchange are somewhat different. MSSQL has a single log file. When Exchange creates new log files it has a timestamp for creation and ast accessed etc for each of them, like any other file in a file system. Backed up logs are just removed from disk. As a result you should not see any *.log files with older timestamps in the log directory of the database correctly backed up.
The question is if this backup is correctly configured. In a DAG environment (with passive copy) you need to configure the backup against the DAG and not just the primary server.
Regards,
Sebastian Koehler
Please disbale ECC and try. If it works, you can raise a call with HP Support and enable the ECC back.
If possible, I will try this in my env and post the results by tomorrow.
Hi Sebastian,
thanks for the info. So we should see logs being deleted then after heDP backup yes? This is a dag environment and I've configured against the dag hostname. Backup policy is "back up passive copy", "lowest acitivation preference" and "Use active copy for backup if no passive copies are available"
So as I'm doing a passive copy it doesnt look like logs are truncated.
If the administrators want passive copies, how would it be best to manage the logfiles? Does an incremental passive copy truncate logs?
This should work, while the Truncation lag time might cause some additional delay. Please ask the Exchange admin to check how it is configured.
The TruncationLagTime parameter specifies how long the Microsoft Exchange Replication service waits
before truncating log files that have already been applied to the database files. The maximum value is 14 days.
Regards,
Sebastian Koehler
thanks.
The manual states that a COPY backs up the database, logs and checkpoints but without truncating the transaction logs.
Maybe I should run an incremental and maybe a backup of active databases and see how it behaves. What do you think?
You can try running an incremental, but if TruncationLagTime is causing a delay, nothing will change. The Full backup and the Incremental backup will truncate the logs.
Copy backup is another backup mode that will not truncate the logs. This is not related with a passive DAG copy.
Regards,
Sebastian Koehler
Guys,
tabrez16 brings up a valid point. This got me thinking, and I decided to check my postgresql.conf file. I see the same thing: #autovacuum = on - which, according to the .conf file itself ("Comments are introduced with # ANYWHERE on a line" [emphasis is mine]), means this is commented out.
So, HPE folks: Does this mean the autovacuum is running or not? Is there another file that I need to look at (other than \ProgramData\OmniBack\server\db80\pg\postgresql.conf)?
Thanks
Ken
Hi Ken,
I don't really know for sure, but I'd think that
# The commented-out settings shown in this file represent the default values.
would mean that all the values found in the autovacuum parameters section, while commented out, just state the compiled-in defaults. Clarification on that by HPE would be great, of course.
HTH,
Andre.
Dimitar was guiding us to the right direction already. Starting with Data Protector 8.0 we're using PostgreSQL 9.1 as the Internal Database. Even when autovacuum is commented out in postgresql.conf is will run by default. This can be seen much better on UNIX Cell Managers when looking at the ps command output.
Daily maintenance will purge obsolete items from IDB and autovacuum take care of the rest.
autovacuum (boolean) Controls whether the server should run the autovacuum launcher daemon.
This is on by default; however, track_counts must also be enabled for autovacuum to work.
This parameter can only be set in the postgresql.conf file or on the server command line.
https://www.postgresql.org/docs/9.1/static/runtime-config-autovacuum.html
Hope this helps!
Regards,
Sebastian Koehler
Hi Sebastian/Eblyn,
Kudos to you guys. Thanks for your kind responce. The issue is resolved now.
I was able to telnet the localhost on 5555 so i suspected there is something blocking at the client firewall. Upon checking the firewall settings, i discovered there was a misconfiguration in the local machine firewall rule which had to be modified.
There was rule that was blocking all the incoming connection and not letting any server to communicate with the client.
I had to remove the rule which was REJECTING ALL THE INCOMING CONNECTION, and add a new rule to specifically allow (ACCEPT) packets from the backup server which eventually made the telnet to work from cell manager to client.
Was able to successfully import the centos machine in client list and installation server list.
Even backups are running smoothly. :)
Sebastian,
So, based on earlier replies and yours, I'm presuming that finding a line like
#track_counts = on
in the postgresql.conf file means the same thing, that track_counts is actually enabled and the autovacuum process is then doing its thing, happily chugging away sucking all the crud out of my >260 GB DCBF folder structure?
Thanks
Ken
Hello all,
i'm new in HPD, and my system is using HPD 9.0 verson.
I wonder is there any way to perform a OS Image backup for my server 2k8
In case my server 2k8 have problem and the OS completely damaged, i can do a OS restore.
Please help to answer my question.
Thanks
Alex, I have tried on my test environment and GRE is working.
Test Env:
Server1: Windows 2012R2( DP Cell manager, Backup Host, media server, disk agent, GRE agent)
Server2: VCenter6 (Pushed Advanced GRE web Plugin)
DP Version: 9.07 (I have enabled encryption directly on patch level 907. In your case you are upgrading from a previous version with encryption enabled to latest version.)
--------------------------------------------
Steps I did:
1. Checked "Configuring encrypted control communication" in GREExtensionsGuide and made sure all pre-req done.
2. Right Clicked in the DP host with GRE agent and enabled Encryption with existing certificates.
3. Took a cached backup(smarcache) and non-cached backup(file library) for a windows VM.
4. Logged in to VSphere web client and slected VM -> Manage tab
5. Selected Gear box on top right of GRE window and configured GRE Settings.
6. Did a new request and did GRE
Config file: C:\ProgramData\OmniBack\Config\Server\config
Before enabling Encryption:
DPHost.myorg.com={
encryption={
exception=1;
};
};
VCenter.myorg.com={
encryption={
exception=1;
};
};
=============================================
After Enabling Encryption:
DPHost.myorg.com={
encryption={
enabled=1;
certificate_chain_file='C:\ProgramData\OmniBack\config\client\certificates\DPHost.myorg.com_cert.pem';
csr_generated=1;
private_key_file='C:\ProgramData\OmniBack\config\client\certificates\DPHost.myorg.com_key.pem';
trusted_certificates_file='C:\ProgramData\OmniBack\config\client\certificates\DPHost.myorg.com_cacert.pem';
pkcs12_keystore_filename='C:\ProgramData\OmniBack\config\client\certificates\/hpdpcert.p12';
pkcs12_keystore_password='hpdpcert';
pkcs12_ca_certificate_filename='C:\ProgramData\OmniBack\config\client\certificates\/hpdpcert.p12';
pkcs12_ca_certificate_password='hpdpcert';
pkcs12_private_key_filename='C:\ProgramData\OmniBack\config\client\certificates\/hpdpcert.p12';
pkcs12_private_key_password='hpdpcert';
cert_generated=1;
cert_trustedca='DPHost.myorg.com_cacert.pem';
};
};
VCenter.myorg.com={
encryption={
exception=1;
};
};
Hi,
You can do Disaster Recovery, to restore the OS image.
Refer guide "DisasterRecovery.pdf". Location: C:\Program Files\OmniBack\Docs Or /opt/omni/doc/
There are many methods available. I prefer EADR. Setup Data Protector in a Server and add the Server you want to protect as a Client to the DP cell. Follow the preocedure as described in the guide.
Regards,
Nigil
Hello,
I would like to ask you how to change server where is started restore media agent (RMA) . RMA is always started on server where was done backup what is OK when you are restoring on same host. In case that restore has to be done on different host in different datacenter then this behaviour is not suitable. Backup is done via SAN direcrtly to tape and I am using DP 9.06 on cell and client.
I didnt find any options in DP where I can change where will be started RMA proces during restore. Please let me know your suggestions or workarounds.
Thank you in advance!
Hi all,
I ran Nessus on Cell manager server (Redhat 6.8) and it returned
Vulnerability: TCP port 9387 plain-ssl (e.g. https, imaps, smtps) supports vulnerable SSLv2 protocol which is susceptible for SSL DROWN attack CVE-2016-0800
and
Vulnerability: TCP port 9388 plain-ssl (e.g. https, imaps, smtps) supports vulnerable SSLv2 protocol which is susceptible for SSL DROWN attack CVE-2016-0800
The /opt/omni/lbin/StoreOnceSoftware listens on these ports.
I ran script DROWN-test.sh from RedHat and it returned that everything is OK
Do you have any idea how to solve it?
Thank you very much.