LSP issue when adding a new storage type

The system has a hierarchy of interfaces IStorage and its implementations. It is required to introduce a new storage type, but one of the methods (Save or Read) may be irrelevant for this implementation. If in such a situation the method throws an exception, it violates the Liskov Substitution Principle (LSP). Describe what the mistake of this approach is and suggest architectural changes that allow maintaining LSP correctness.

class IStorage {
public:
    virtual void Save(const std::string& path) = 0;
    virtual void Read(const std::string& path) = 0;
};

class FileStorage : public IStorage {
public:
    void Save(const std::string& path) override;
    void Read(const std::string& path) override;
};

class DatabaseStorage : public IStorage {
public:
    void Save(const std::string& path) override;
    void Read(const std::string& path) override;
};

class RemoteStorage : public IStorage {
public:
    void Save(const std::string& path) override;
    void Read(const std::string& path) override;
};