Jump to content
NAKIVO Community Forum

cmangiarelli

Members
  • Posts

    6
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by cmangiarelli

  1. The data sheet for VMware Backup and Replication 10.3 and the Supported Platforms section of the User Guide both list "Ubuntu 16.04–18.04 Server (x64)". That's not to say it won't work on the later version, but you should speak with them directly about your support options.
  2. Cool, I thought you were telling me that Ubuntu 16 was required on the appliance and that while I could patch it, I couldn't upgrade the OS. I'll plan to go to 18 as soon as I can. Thanks.
  3. It's certainly nice to hear it is in development, but hoping it will come sooner rather than later. Regarding the frequency of reclamation, as I said in my original post, we have space constraints to deal with. Our old backup application was scheduled to back up VMs weekly, but we would backup SQL databases nightly. Since Nakivo has no "agent", we have to back up the entire VM nightly; yeah we could create a job for the drives containing SQL, but that is where most of the change occurs anyway, so we keep it simple. We actually prefer the simplicity of the scheduling now and the nightly backups of entire VMs, but the testing of Nakivo in our lab didn't accurately predict the dedupe ratio's we would see in production. Separate backup storage is not available in some of our smaller, shall we say fiscally-challenged, environments so the repo is placed on local SAN and then replicated off-site. The amount of available SAN storage is limited, and with the slightly lower than expected dedupe ratios, we get close to running out of repo space after a few days if we don't run reclamation after our backups. We have SLAs around retention, so I'm keeping the bare minimum. As was mentioned in a diffent thread, the reclamation process reclaims a good portion of the available space early on in the process. Thus, with my current scheduling, I get a very good return on my reclamation period even if it gets interrupted by the next day's backup scheduling.
  4. Thanks. So please confirm what I am reading. Running "apt update' followed by "apt upgrade" is safe. Running "apt dist-upgrade", "apt full-upgrade, and/or "apt autoremove" is also safe? Running "do-release-upgrade" followed by associated apt commands is NOT safe. Sounds like you covered by 1st and 3rd points, but I'm still a little fuzzy about the second.
  5. A few months back, I was told by support that a new type of repository was being developed where space reclamation could run without blocking access to the repo. The process would be similar to how a Data Domain can run space reclamation while still accessible but at the expense of I/O performance; however, reclamation can be throttled to increase I/O performance at the expense of running a longer reclamation period. Is it possible to get an update as to the status of this technology? I run backups nightly and need to reclaim space after each run due to storage space constraints. I've designed my job calendar to maximize the reclamation time period, but it sometimes runs into the next day's schedule. While normal backup jobs will pause reclamation, the director backup will fail if it is running. While my systems often run without incident, the Director can be chatty with its alerting which reduces the effectiveness of bringing important events to my attention.
  6. Is it safe/supported to perform an (apt) update of the Ubuntu OS while using the Nakivo Virtual Appliance? I've previously performed standard updates of the Nakivo software using the "scp sh file > run update from console" process as documented. However, I couldn't find any documentation about keeping the OS patched. We recently had a security scan point out flaws that are resolved by updates available in the public Ubuntu patch channel(s). Please advise.
×
×
  • Create New...