Skip to content
Strategia Informatica
Menu
  1. Home
  2. Expertise
  3. Data centre and backup

Data centre, backup and business continuity

We manage Proxmox VE and VMware vSphere virtualisation, from a single host to clusters across several data centres or two sites, together with the storage underneath (Fibre Channel, iSCSI, arrays in synchronous replication, ZFS) and Veeam backups. We also look after databases, email, public cloud and dedicated servers, and we build the monitoring.

Our best-documented work concerns failures: unreadable volumes, restarts after a power outage, disaster recovery sites shut down and powered back on remotely, stuck databases. We diagnose in read-only mode until we find the cause, work on a copy and verify the result, not the command.

Proxmox VE clusters

We install and manage Proxmox VE clusters on dedicated servers, including across several data centres: local ZFS replicated between the nodes, quorum with a third vote at another site, a private layer 2 network between data centres, VLANs carried between the nodes. We tune memory and I/O and choose hardware based on load measurements, not on the catalogue.

Technologies and products

  • Proxmox VE 8 and 9
  • ZFS
  • Corosync and QDevice
  • KSM
  • QEMU guest agent
  • Dedicated servers and providers' private networks

Examples

  1. Service cluster for several clients (5 nodes in 4 data centres) In production

    The memory the file system cache was taking

    The problem
    On one node the ZFS cache was taking up 116 GB of RAM and swap was at 100%; during backups a pool of mechanical disks pushed the load to 62 on 16 threads.
    What we did
    A cache limit on each node and memory deduplication (KSM); a write cap on the disks of the backup repositories.
    Result
    Free RAM went from 12.9 to 68 GB on the most heavily loaded node; during backups the load dropped from 62 to 22.
  2. Application platform on dedicated servers In production

    A new cluster sized from measurements

    The problem
    Choosing the second and third nodes of a cluster without buying more than necessary.
    What we did
    We installed Proxmox VE 9 through the provider’s API. We chose the second node based on the real load (0.36 cores on average), single-core performance and the compatibility of the virtual CPUs. Two nodes plus an external vote, ZFS replication every 15 minutes over a private network measured at 918-947 Mbit/s.
    Result
    The third node, installed in 15 minutes, took the place of the external vote.

VMware vSphere

We administer and troubleshoot vSphere environments, from a standalone host to multiple clusters across two sites with vSAN: HA, DRS, EVC, vMotion, vSphere Replication. We automate with pyVmomi, the vCenter APIs and PowerCLI, including installing virtual machines without opening the console.

Technologies and products

  • VMware vSphere and ESXi, from 5.5 to 8.0
  • vCenter and vSAN
  • HA, DRS, EVC, vMotion
  • vSphere Replication
  • PowerCLI and pyVmomi

Examples

  1. Industrial group, foreign site Delivered

    vMotion blocked by a kernel module

    The problem
    At a foreign site with 2 hosts and 31 virtual machines, live migrations were not working.
    What we did
    We removed the ISOs mounted on 7 machines and used cold migrations to reset the corrupted migration state of 26 machines; the root cause was an ESXi kernel module that was not loaded on one of the hosts.
    Result
    vMotion working again in both directions: 14 machines rebalanced live in 11.6 minutes, with no downtime.
  2. Manufacturing company Delivered

    Two hosts moved into an EVC cluster in four minutes

    The problem
    Reorganising a vCenter with 9 hosts and 97 virtual machines by moving two hosts into a cluster with uniform CPU compatibility.
    What we did
    We carried out a full study of the environment with a critical analysis, then entrusted the move to a tested script.
    Result
    Four minutes in total, machines down for about three, addresses unchanged.

Platform and service migrations

We move virtual machines and services between hypervisors, providers and operating system versions with short, measured downtime: an inventory of dependencies, a dress rehearsal, the old system kept ready for rollback, verification by count, DNS updated via API.

Technologies and products

  • Veeam and qemu-img
  • Proxmox VE and VMware ESXi
  • cloud-init and netplan
  • Postfix
  • DNS APIs of several providers

Examples

  1. Cloud services infrastructure Delivered

    A VPN hub moved without interrupting anyone

    The problem
    Decommissioning a virtualisation host at one provider and moving its services to a node at another provider, including the VPN hub used by many users.
    What we did
    We moved the VPN hub (33 OpenVPN clients and 63 WireGuard peers) one client at a time. We adapted the machines restored from backup to the new hypervisor and repointed 35 DNS records across three providers via API.
    Result
    Each client reconnected in about 10 seconds, all DNS zones checked again, the old host verified empty and decommissioned.
  2. Web application with a MongoDB database Delivered

    A database moved with 41 seconds of downtime

    The problem
    Moving the application backend from a virtual machine to a new server without losing data.
    What we did
    The dress rehearsal brought to light a hard-coded path, which we fixed before the switchover. While DNS was propagating, the old machine acted as a reverse proxy to the new one.
    Result
    41 seconds of downtime, 82,954 records before and after.

Storage, SAN and file systems

We work on Fibre Channel SANs, iSCSI with multipath, arrays in synchronous replication between two sites, storage that virtualises other arrays and NAS. We carry out orderly decommissioning and analyse errors and performance on ZFS, btrfs, ReFS and LVM.

Technologies and products

  • Brocade FOS
  • Dell PowerStore
  • NetApp ONTAP
  • IBM FlashSystem
  • HPE StoreOnce
  • open-iscsi and multipath
  • ZFS, btrfs, ReFS, LVM

Examples

  1. Industrial group In production

    From one path to four, without stopping the cluster

    The problem
    During maintenance on an array, 12 virtual machines had I/O errors for 23 minutes.
    What we did
    Our read-only analysis found the cause: wrong iSCSI targets in the configuration, a single path per node to the two replicated arrays. We fixed it live, one node at a time.
    Result
    From one to four paths per volume, also verified after a reboot.
  2. SAN with two fabrics Delivered

    A Fibre Channel switch replaced without conflicts

    The problem
    Replacing a failed switch in a SAN of four switches across two fabrics.
    What we did
    We brought the new switch up to the version used in the fabric with four upgrades in sequence and transferred the licences from the failed unit.
    Result
    Merged into the fabric with no zoning conflicts.
  3. Manufacturing company Delivered

    Two storage clusters decommissioned without surprises

    The problem
    Shutting down two NetApp clusters (four controllers) without taking anything away from anyone.
    What we did
    We took a full inventory through the API, then checked that no system was still using them.
    Result
    We decommissioned them only after seeing that nothing was responding any more.

Backup with Veeam

We manage Veeam deployments for VMware and Proxmox machines, agents, Microsoft 365, tape, deduplication appliances, ReFS repositories and array snapshots. We take care of capacity, retention, job chains and version changes, with automation via REST and PowerShell. And we check that the backups exist, not just that the job is green.

Technologies and products

  • Veeam Backup & Replication 12 and 13
  • Veeam Agent and Veeam Backup for Microsoft 365
  • HPE StoreOnce Catalyst
  • ReFS with fast clone
  • LTO-7 and LTO-9 libraries
  • Dell PowerStore snapshots

Examples

  1. Manufacturing company Delivered

    A full backup appliance, cleared out without losing copies

    The problem
    The 32 TB deduplication appliance had zero bytes free and the backups of more than 50 jobs were failing.
    What we did
    Before deleting, we checked, machine by machine, where another copy existed. We also discovered that the space shown by the console came from a wrong cache (898 GB against an actual 12,643): since then we decide on the basis of the direct source. Then 24 new jobs from the array snapshots over Fibre Channel.
    Result
    We freed 5.9 TiB on the appliance and more than 14 TB on a ReFS repository; backups running again.
  2. Manufacturing company Delivered

    A job that failed 211 times in a row

    The problem
    A backup job failed every time, and nobody could find out why.
    What we did
    From the logs of the individual tasks: every task that went through one particular proxy failed (160 out of 160) and all the others succeeded (269 out of 269). We excluded that proxy, with a rollback ready.
    Result
    9 out of 9 machines backed up in 38 minutes.
  3. Industrial group Delivered

    Night-time crashes and a broken job chain

    The problem
    The backup service went down at night (13 times in 14 days) and a job chain had silently broken, leaving many machines without recent copies.
    What we did
    The causes, one after another: a named SQL instance, a port resolved via UDP, memory under pressure, dropped packets. We stopped the crashes with a static TCP port; we stitched the chain back together and migrated the older jobs in order to move to version 13.
    Result
    Chain restored; 48 jobs migrated to version 13, none failed.

Data recovery after failures

When a volume will not mount or a machine will not restart, we first secure a copy, then work only on that copy and verify the result down to the byte. The first rule is not to cause irreversible damage while attempting a repair.

Technologies and products

  • ZFS (snapshot, clone, send and receive)
  • refsutil and esentutl
  • LVM thin
  • mdadm
  • Veeam Extract

Examples

  1. Services company Delivered

    Ten terabytes from an unreadable volume, verified byte by byte

    The problem
    A 16 TiB ReFS backup repository had become unreadable; it looked like a disk failure.
    What we did
    The “I/O errors” were the underlying storage running out of space; the disks were healthy. We made a full copy to another node (15.6 TB, verified). On a clone we discovered that Windows Server 2025 upgrades the volume irreversibly even without mounting it: on the original, that would have made the only tool able to read it useless. We carried out the extraction on the clone.
    Result
    1,479 files and 10.08 TB extracted with byte-by-byte verification in about 3.5 days instead of the estimated 20; Microsoft 365 backup databases repaired, backups running again, residual damage below 1.6%.
  2. Industrial group Delivered

    A production machine recovered with 14 ms of downtime

    The problem
    A production virtual machine was on a corrupted thin pool.
    What we did
    We recovered it from a clone of the array snapshot on an isolated node, then brought it back into the cluster with a live migration.
    Result
    14 milliseconds of downtime; cleaning up the pool then freed about 23 TiB.
  3. Small business after a ransomware attack Delivered

    The backups found on a disk that had dropped out of the mirror

    The problem
    After an attack, intact copies of the virtual machines were needed.
    What we did
    A disk that had dropped out of the NAS mirror months earlier held an intact backup chain: we mounted it in forced read-only mode and copied it to the new NAS.
    Result
    826 GB and 4 virtual machines recovered.

Disaster recovery and replication

We manage replication (Veeam, vSphere Replication, ZFS, synchronous between arrays) and disaster recovery sites; we measure the actual RPO and write shutdown and power-on runbooks that clearly mark the point beyond which nothing can be undone remotely.

Technologies and products

  • Veeam Replication and vSphere Replication
  • ZFS
  • Dell PowerStore Metro
  • IBM FlashSystem and NetApp ONTAP
  • Cisco UCS Manager
  • Redfish

Examples

  1. Manufacturing group Delivered

    A disaster recovery site shut down and powered back on entirely remotely

    The problem
    The DR site (virtualised storage, blade servers, 6 hosts and about 145 replica machines) had to be shut down and then powered back on with nobody on site.
    What we did
    A 10-phase shutdown plan with a script that by default only simulates, explicit confirmations for the steps that touch production and safety interlocks. Power-on through an 8-phase orchestrator; we restarted a storage controller stuck at the loader from the server’s remote management console.
    Result
    Verification by actually logging in to 30 devices: 30 out of 30. Then we measured the accumulated RPO gap (about 3 days) and reactivated the 26 replication jobs in a chain.
  2. Manufacturing group Delivered

    Replication from a foreign site that kept failing

    The problem
    Replication from a foreign site failed on every run.
    What we did
    The cause was a chain of 9 snapshots that had never been consolidated on the target side; we recreated the replicas via API.
    Result
    Replication running regularly again.

Business continuity and restart after a power outage

We prepare emergency access that is independent of the network that goes down, sentinels watching the stability of the power supply and runbooks for restarting in waves, paying attention to clusters with fencing. We also diagnose fault-tolerant systems by reading the servers’ hardware logs.

Technologies and products

  • 4G and 5G management routers
  • Dell iDRAC and HPE iLO (Redfish)
  • VMware HA and DRS
  • SUSE HA (Pacemaker, STONITH)
  • SAP HANA System Replication
  • Stratus everRun

Examples

  1. Manufacturing company Delivered

    Restarting after a power outage with the electricity coming and going

    The problem
    A plant had no stable power; the only access left was a 4G/5G management router.
    What we did
    From there a sentinel logged the drops and returns of mains power, with a simple rule: nothing is switched on until the mains has held for 30 minutes. The servers’ management controllers told us which room had power. A 9-phase restart runbook, written using IP addresses because on a cold start there is no DNS.
    Result
    On restart about 90 machines had started up on a single host (RAM at 94%): 61 redistributed live, 61 out of 61 successful. We analysed the database, which had switched over to the secondary node, and prepared the resynchronisation procedure, to be run upon authorisation.
  2. Two-node fault-tolerant cluster Delivered

    A network card that kept disappearing from the bus

    The problem
    The cluster crashed periodically and, after the takeover, one machine in three was responding.
    What we did
    The hardware logs read via Redfish (208 entries, 48 of them critical) always showed the same three PCIe errors: the 10G synchronisation card was disappearing from the bus.
    Result
    Cause proven and the behaviour after the takeover explained too; recommendation delivered.

Databases and application servers

We work on SQL Server, Oracle (including RAC, with ASM and RMAN), SAP HANA, PostgreSQL and MongoDB, and on Windows and Linux application servers: MES, file servers, collaboration, web.

Technologies and products

  • SQL Server, from 2016 to 2025
  • Oracle RAC, ASM, RMAN
  • SAP HANA
  • PostgreSQL and MongoDB
  • IIS, nginx, Docker
  • Nextcloud and ONLYOFFICE

Examples

  1. Business management software on SQL Server Delivered

    A 132-byte transaction that was filling the disk

    The problem
    The database log was reaching 267-275 GB and filling the disk.
    What we did
    The cause was an external application that left a 132-byte read-only transaction open: even in SIMPLE recovery it was enough to prevent log reuse. An emergency fix and a cap on the log.
    Result
    Disk safe; we pointed out the application fix to its developers.
  2. Oracle RAC Delivered

    RMAN blocked by archivelogs deleted by hand

    The problem
    RMAN backups would no longer start after some archivelogs had been deleted by hand.
    What we did
    We removed 22,527 orphaned records from the control file, re-registered the catalogue and terminated 11 blocked sessions.
    Result
    Test backup successful; shutdown and restart procedures written.
  3. Company file server Delivered

    Seven million permissions read in eight minutes

    The problem
    It was necessary to know who could read what on a file server that had grown over the years.
    What we did
    An NTFS permissions scanner written for the purpose.
    Result
    465,280 folders and 7.3 million permissions analysed in under 8 minutes.

Email, Exchange and Microsoft 365

We manage on-premises Exchange, edge mail gateways, Microsoft 365 tenants via PowerShell and Microsoft Graph, Microsoft 365 backups and technical communications to clients when a service changes.

Technologies and products

  • Exchange Server 2019 and SE
  • Exchange Online PowerShell
  • Microsoft Graph and Entra ID
  • Veeam Backup for Microsoft 365
  • Postfix

Examples

  1. Clients with Microsoft 365 backups Delivered

    The retirement of EWS in Exchange Online, explained to clients

    The problem
    The retirement of Exchange Web Services in Exchange Online risked stopping Microsoft 365 backups.
    What we did
    A guide for clients (tenant settings, propagation times, updates) and the script to apply the settings.
    Result
    A guide and a script that every client can apply on their own.
  2. Industrial group Delivered

    A mail gateway rebuilt alongside the old one

    The problem
    The edge mail server was running on an out-of-support operating system.
    What we did
    We built the new server alongside the old one and tested the SMTP chain before swapping the address.
    Result
    New server in service, with the old one kept ready for rollback.

Public cloud and dedicated servers

On Google Cloud we manage Compute Engine, VPC networks, Cloud VPN, Cloud SQL, snapshots, Monitoring, Logging and audit logs. On dedicated servers we install and manage machines via the provider’s API, private networks, address blocks and renewals.

Technologies and products

  • Google Cloud (Compute Engine, Cloud VPN, Cloud SQL, Ops Agent, IAM)
  • OVHcloud dedicated servers and public cloud
  • Provider APIs

Examples

  1. Google Cloud infrastructure for a public service In production

    A machine that refused SSH, and it was not the memory

    The problem
    A virtual machine was refusing administrative connections and seemed to be short of memory.
    What we did
    151 devices were connecting continuously (about 53 connections a minute) and, with the machine slowed down, they saturated the pool of not-yet-authenticated connections; the underlying cause was 16 Java processes with no memory limit. We reduced the logs, measured at 151.9 GiB over 30 days, while keeping the metrics.
    Result
    Cause clarified and load reduced; a network added to the VPN with a runbook and rollback, with 2 minutes and 54 seconds of downtime and verification from three different networks.
  2. Google Cloud infrastructure for a public service In production

    The heavy midday copy was down to a time zone

    The problem
    Agent-based backups of the Linux machines were failing and a heavy copy was starting in the middle of the day.
    What we did
    Secure Boot was blocking the kernel module used for snapshots: we rebuilt the jobs without snapshots. The midday copy was down to the wrong time zone on the backup servers.
    Result
    Nine machines backed up regularly, at the right times.

Performance, capacity and monitoring

We measure before sizing and build monitoring portals and probes that distinguish between “healthy”, “unverified” and “faulty”, with thresholds calibrated on historical data and alarms based on episodes, not on single readings.

Technologies and products

  • Python (FastAPI, SQLite)
  • nginx and systemd
  • SNMP
  • Redfish, WinRM and PowerShell
  • Linux PSI
  • Notifications via Telegram

Examples

  1. IT services provider In production

    From 250 notifications a day to zero, keeping the real alarms

    The problem
    A monitoring system for 36 nodes in 8 groups produced permanent alarms and hundreds of flapping notifications.
    What we did
    A two-tier archive (raw data for 7 days, hourly aggregates for 400), thresholds calibrated on historical data, a confirmation delay before notifying. A check on the age of the last backup, read from the database instead of from the job.
    Result
    From 5 alarms, 3 of them permanent, to 2 real ones; flapping notifications down from about 250 a day to zero; a 30-day chart opens in about 25 ms. The backup check found databases without a recent full copy while the job was reported as successful.
  2. Major international cultural event Delivered

    The monitoring wall for a major event

    The problem
    Keeping track of the devices, lines and Wi-Fi of a temporary network, with a view that can be read from a distance in the control room.
    What we did
    A Python portal with no frameworks or external databases: 20 devices checked every 60 seconds, bandwidth and errors every 10, access point radios and clients every 45; a wall with purely semantic colours, verified with screenshots; alerts on Telegram. We validated the episode-based alarm rule by replaying 24 hours of real data.
    Result
    Notifications down from about 80 to 4 a day. We also found a DNS resolver that took 3-4 seconds per name and access points pushed by weather radars onto reduced-power channels, which can be brought back to 1 W with a button.
  3. Platform on a dedicated server Study

    The new CPU was not needed

    The problem
    Working out whether a node needed upgrading.
    What we did
    Real load measurements: on average 0.41 cores out of 24. We also measured the cost of disk encryption: about 1.5% of a core during peaks.
    Where we have got to
    The limiting factor was the disk, not the CPU: the study shows where it is worth intervening.

Tell us about the problem

A network to put back in order, an incident to handle, data to make sense of: the first conversation is about understanding whether and how we can help.

Send an email Call +39 328 277 9187