Troubleshooting

Accessing the PPC CLI

• Permission denied (publickey): Ensure you’re using the correct private key that matches the authorized_keys in the pod
• Connection refused: Verify the load balancer IP and hosts file configuration
• Key format issues: Ensure your private key is in the correct format (OpenSSH format for Linux/macOS, .ppk for PuTTY)

Failure of init-resiliency script

Issue: When running the init_resiliency.sh script on a fresh RHEL 10.1 system as the root user, some required tools, such as, AWS CLI, kubectl, or Helm are not detected during setup. The following error appears:

[2026-03-26 06:57:15] No credentials file found at ~/.aws/credentials. Triggering aws configure...

configuring credentials...

/home/ec2-user/bootstrap-scripts/setup-devtools-linux_redhat.sh: line 297: aws: command not found

[2026-03-26 06:57:15] Step failed: Tool installation (redhat) — command exited with non-zero status

[2026-03-26 06:57:15] ERROR: Step failed: Tool installation (redhat)

Cause: On RHEL systems, the default environment configuration for the root user does not include certain standard installation directories such as /usr/local/bin in the system path. As a result, tools that are installed successfully might not be immediately available to the script during execution.

Resolution: Before running the bootstrap or resiliency scripts as the root user on RHEL, ensure that /usr/local/bin (and the AWS CLI binary path, if applicable) is included in the $PATH. Alternatively, run the script using a non-root user (such as ec2-user) where /usr/local/bin is already part of the default PATH.

Certificate Authority (CA) is not backed up leading to protector disruption

Issue: CA certificates are not backed up during cluster migration, causing SSL certificate errors for protectors trying to communicate with the new cluster.

Description: When the CA that Envoy uses is not migrated to the new cluster, protectors cannot establish secure connections. The connection fails with SSL certificate errors like “unable to get local issuer certificate”. This disrupts protector functionality and requires manual intervention to restore communication.

Workaround:

Workaround 1: Custom CA is preserved before restore. This preserved CA is replaced with the default CA in the new restored cluster.

For more information, refer to Replacing the default Certificate Authority (CA) with a Custom CA in PPC.

This ensures protectors continue to trust the cluster without any changes.

Workaround 2: Run the GetCertificates command on each protector after restore.

cd /opt/protegrity/rpagent/bin/
./GetCertificates -u <username> -p <password>

This command downloads new CA‑signed certificates which results in restoring secure communication with the cluster.

Important: This approach is functional but not user‑friendly and should be avoided in production by preserving the custom CA across restores.

When upgrading PPC from v1.0.0 to v 1.1.0, Stage 01 shows unexpected IAM policy replacement

Issue: During PPC upgrade from v1.0.0 to v1.1.0, Stage 01 01_iam_roles displays an unexpected destroy and then create replacement for aws_iam_policy.eks_backup_recovery_utility_policy and its role-policy attachment, with the plan showing Plan: 4 to add, 0 to change, 2 to destroy.

Description: The PPC v1.0.0 created the IAM policy with a trailing space in the description field. AWS IAM treats description as an immutable attribute, and any change to it forces a full resource replacement (destroy + create). The PPC v1.1.0 removes the trailing space, which triggers the replacement. The following plan output is expected:

# aws_iam_policy.eks_backup_recovery_utility_policy must be replaced
-/+ resource "aws_iam_policy" "eks_backup_recovery_utility_policy" {
      ~ description = "IAM policy used by backup service to access S3 bucket " -> "IAM policy used by backup service to access S3 bucket" # forces replacement
    }

Resolution: No action is required. This is expected and one-time behavior. The policy ARN changes as the policy is briefly recreated, and the role-policy attachment is disconnected for approximately 200ms. There is no functional impact because Stage 01 runs before any application pods that depend on this policy are started. By Stage 05, the policy is already recreated and attached. Subsequent upgrade runs show no changes.