Trait backup_cli::storage::BackupStorage[−][src]

pub trait BackupStorage: Send + Sync {
    fn create_backup<'life0, 'life1, 'async_trait>(
        &'life0 self, 
        name: &'life1 ShellSafeName
    ) -> Pin<Box<dyn Future<Output = Result<BackupHandle>> + Send + 'async_trait>>
    where
        'life0: 'async_trait,
        'life1: 'async_trait,
        Self: 'async_trait;

    fn create_for_write<'life0, 'life1, 'life2, 'async_trait>(
        &'life0 self, 
        backup_handle: &'life1 BackupHandleRef, 
        name: &'life2 ShellSafeName
    ) -> Pin<Box<dyn Future<Output = Result<(FileHandle, Box<dyn AsyncWrite + Send + Unpin>)>> + Send + 'async_trait>>
    where
        'life0: 'async_trait,
        'life1: 'async_trait,
        'life2: 'async_trait,
        Self: 'async_trait;

    fn open_for_read<'life0, 'life1, 'async_trait>(
        &'life0 self, 
        file_handle: &'life1 FileHandleRef
    ) -> Pin<Box<dyn Future<Output = Result<Box<dyn AsyncRead + Send + Unpin>>> + Send + 'async_trait>>
    where
        'life0: 'async_trait,
        'life1: 'async_trait,
        Self: 'async_trait;

    fn save_metadata_line<'life0, 'life1, 'life2, 'async_trait>(
        &'life0 self, 
        name: &'life1 ShellSafeName, 
        content: &'life2 TextLine
    ) -> Pin<Box<dyn Future<Output = Result<()>> + Send + 'async_trait>>
    where
        'life0: 'async_trait,
        'life1: 'async_trait,
        'life2: 'async_trait,
        Self: 'async_trait;

    fn list_metadata_files<'life0, 'async_trait>(
        &'life0 self
    ) -> Pin<Box<dyn Future<Output = Result<Vec<FileHandle>>> + Send + 'async_trait>>
    where
        'life0: 'async_trait,
        Self: 'async_trait;
}

Required methods

Hint that a bunch of files are gonna be created related to a backup identified by name, which is unique to the content of the backup, i.e. it won’t be the same name unless you are backing up exactly the same thing. Storage can choose to take actions like create a dedicated folder or do nothing. Returns a string to identify this operation in potential succeeding file creation requests.

Ask to create a file for write, backup_handle was returned by create_backup to identify the current backup.

Open file for reading.

Asks to save a metadata entry. A metadata entry is one line of text. The backup system doesn’t expect a metadata entry to exclusively map to a single file handle, or the same file handle when accessed later, so there’s no need to return one. This also means a local cache must download each metadata file from remote at least once, to uncover potential storage glitch sooner. Behavior on duplicated names is undefined, overwriting the content upon an existing name is straightforward and acceptable. See list_metadata_files.

The backup system always asks for all metadata files and cache and build index on top of the content of them. This means:

  1. The storage is free to reorganise the metadata files, like combining multiple ones to reduce fragmentation.
  2. But the cache does expect the content stays the same for a file handle, so when reorganising metadata files, give them new unique names.

Implementors