Skip to main content
Altcraft Docs LogoAltcraft Docs Logo
User guide iconUser guide
Developer guide iconDeveloper guide
Admin guide iconAdmin guide
English
  • Русский
  • English
Login
    Getting StartedAdministrator documentationFunctional characteristics
      Technology descriptionarrow
    • Architecture OverviewComponent Description
        Deployment schemesarrow
      • Basic schemeFail-safe schemeTypical Placement in Infrastructure
    System requirements
      Admin Panelarrow
      • Account areaarrow
        • Accountsarrow
        • Account UsersAccount Virtual SendersAccount Database Indexes
        TariffsExternal data configurationLDAPTasksSchedule JobsGlobal Stop ListsWebversion Store Policies
        Settingsarrow
      • Databases
          Accessarrow
        • AdminsAPI tokens
        Notifiers
          MTAarrow
        • Default rulesRetry rulesLock rulesBounce patternsStrategiesKeysISPsPools
      Nodes
        Sendersarrow
      • EmailSMSEvent generatorIntegration with SendsayENS: настройка сендера
        Reportsarrow
      • Audit JournalData Usage
        Toolsarrow
      • ARF decoderURL decoderSMID decoderLicense
      Platform installationarrow
    • Automatic installationManual installationRunning the platform in a Docker container
      Platform configurationarrow
    • Configuration fileDomain settingsLDAP access configurationSending Email via SMTP relayPixel and push domain configurationCluster and Replication SetupSystem notifications configurationProcesses UNIX sockets configurationHTTPS ConfigurationMigrating from MongoDB Community Edition to Percona Server for MongoDBAdding sender IP addressesDeduplication request settingsPostgreSQL database for account dataProxy server settingsKeycloak Integration with AltcraftGetting HTTP service statusesConfiguration MongoDB logs rotation
        Configuration of system constants and directoriesarrow
      • Filtering bot actionsDirectory of gender markers
      Platform maintenancearrow
    • Personnel requirementsPlatform maintenance processesPlatform updatingPlatform service monitoringBackup and recoveryTransferring the platform to a new serverCreating, deleting, and populating tables for statistics in ClickHouseUsage of the aktool utilityUsers and directories engaged by the platform
      Custom channels guidearrow
    • OverviewCreating and configuring a channelEntity field configurationTemplate languageEntities
        Pipesarrow
      • Pipe: Basic ConceptsResultErrorsLogPackUnpackHTTP RequestStore SetStore GetSelectorSQLEventerScheduler
        Pipelinesarrow
      • Pipeline: Basic ConceptsMessageScheduleListenerModerateStop
      Extraarrow
    • System page customizationSend Message IDИнструкция по миграции истории в ClickHouseInstructions for migrating history to ClickHouseUtility for importing push subscriptions to Firebase projectUtility for importing push subscriptions to Firebase project
    Processing HTTP/HTTPS traffic
      Administrator APIarrow
      • Accounts admin apiarrow
        • Restricted accessarrow
        • Account Activation and DeactivationAccount Freeze and Unfreeze
        Get accounts listAdd a new accountDelete the account
        Account usersarrow
      • Update an Existing AccountAdd a new accountDelete a userGet a list of usersSending a Welcome Email
        Nodesarrow
      • Synchronize node MTA configurationGet nodes listGet node MTA statusActivate node MTADeactivate node MTA
        Senders admin apiarrow
      • Create or update AKMTA senderGet AKMTA sender informationAssign account to senderGet senders listDelete senderRestore sender
          Sender queuearrow
        • Get sender queue informationHold sender queueRelease sender queueClear sender queue
        Virtual sendersarrow
      • Get virtual senders listGet virtual sender informationCreate virtual senderUpdate virtual senderClone virtual senderDelete virtual sender
    Documentation Archive
  • Platform maintenance
  • Backup and recovery

Backup and recovery

For full backup and recovery to work you will need the following data:

  • control module
  • MongoDB databases (account, control)
  • SSDB databases (actions, hb, notify, stat)
note

All of the backup methods create an archive in a user's current directory. Before executing the command, you must make sure that there is enough free space in the current directory to save the archive.

Control module​

Backup​

Archive control module data except *.pid и *.log files.

#!/usr/bin/env bash

tar -czf /backup/altcraft-$(date +%F).tar.gz /opt/altcraft --exclude=*.pid --exclude=*.log

Recovery​

Unpack the archive back on its place and restart control module.

#!/usr/bin/env bash

/opt/altcraft/akd restart
note

To restore the control module from a backup copy on a new server, you must first configure the environment necessary for the module to operate

MongoDB​

Data backup methods have their own documentation.
https://docs.mongodb.com/v3.4/core/backups/

tip

We recommend backing up using snapshots (see Back Up and Restore with Filesystem Snapshots). The method using snapshots allows you to save a lot of time when restoring "heavy" collections with a large number of indexes.

Backup​

Dump all databases and collections with the help of mongodump utility.
Use compression (--gzip) if you need.

mongodump utility description.
https://docs.mongodb.com/manual/reference/program/mongodump/

#!/usr/bin/env bash

mongodump --host 127.0.0.1 --port 27017 --gzip --archive=/backup/mongodb-control-$(date +%F).tar.gz
mongodump --host 127.0.0.1 --port 27018 --gzip --archive=/backup/mongodb-account-$(date +%F).tar.gz

Recovery​

Recower the data with mongorestore and restart systemd services.

mongorestore utility description.
https://docs.mongodb.com/manual/reference/program/mongorestore/

#!/usr/bin/env bash

mongorestore --host 127.0.0.1 --port 27017 --gzip --arcdhive=/backup/mongodb-control-2019-06-01.tar.gz
mongorestore --host 127.0.0.1 --port 27018 --gzip --arcdhive=/backup/mongodb-account-2019-06-01.tar.gz
systemctl restart mongod-control
systemctl restart mongod-account

SSDB​

tip

We recommend backing up using snapshots and then moving all data from the snapshot to an archive. Importing and exporting keys in large SSDB databases can take up to several days. Databases structure example.

/var/lib/ssdb
├── actions
│ ├── data
│ └── meta
├── hb
│ ├── data
│ └── meta
├── notify
│ ├── data
│ └── meta
└── stat
├── data
└── meta

Backup​

Archive catalogues, containing data and meta.

#!/usr/bin/env bash

tar -czf /backup/ssdb-actions-$(date +%F).tar.gz /var/lib/ssdb/actions
tar -czf /backup/ssdb-hb-$(date +%F).tar.gz /var/lib/ssdb/hb
tar -czf /backup/ssdb-notify-$(date +%F).tar.gz /var/lib/ssdb/notify
tar -czf /backup/ssdb-stat-$(date +%F).tar.gz /var/lib/ssdb/stat

Recovery​

Unpack the archive and restart systemd services.

#!/usr/bin/env bash

systemctl restart ssdb-actions
systemctl restart ssdb-hb
systemctl restart ssdb-notify
systemctl restart ssdb-stat
Last updated on Jul 14, 2023
Previous
Platform service monitoring
Next
Transferring the platform to a new server
  • Control module
    • Backup
    • Recovery
  • MongoDB
    • Backup
    • Recovery
  • SSDB
    • Backup
    • Recovery
© 2015 - 2026 Altcraft, LLC. All rights reserved.