bakelite | Incremental backup with strong cryptographic | Continuous Backup library
kandi X-RAY | bakelite Summary
kandi X-RAY | bakelite Summary
Incremental backup with strong cryptographic confidentiality baked into the data model. In a small package, with no dependencies. This project is still experimental! Things may break or change. See below on status.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of bakelite
bakelite Key Features
bakelite Examples and Code Snippets
Community Discussions
Trending Discussions on Continuous Backup
QUESTION
ANSWER
Answered 2022-Feb-22 at 10:59I am not sure if you have seen this message in the portal when you created the account/also mentioned in the doc
"You will not be able to switch between the backup policies after the account has been created"
since you need to select either "Periodic" or "Continuous" at the creation of Cosmos Account, it becomes mandatory.
Update:
You will not see the above in portal anymore, you can Switch from "Periodic" to "Continous" on an existing account and that cannot be reverted. You can read more here.
QUESTION
What would be the consistency of the continuous backup of the write region if the database is using bounded staleness consistency? Will it be equivalent to strong consistent data assuming no failovers happened?
Thanks Guru
...ANSWER
Answered 2021-Nov-25 at 17:15Backups made from any secondary region will have data consistency defined by the guarantees provided by the consistency level chosen. In the case of strong consistency, all secondary region backups will have completely consistent data.
Bounded staleness will have data that may have stale or inconsistent data inside the defined staleness window (minimum 300 seconds or 100k writes). Outside of that staleness window the data will be consistent.
Data for the weaker consistency levels will have no guarantees for consistency from backups in secondary regions.
QUESTION
MongoDB has deprecated the continuous back up of data. It has recommended using CPS (Cloud provider snapshots). As far as I understood, snapshots isn't really going to be effective compared to continuous backup coz, if system breaks, then we can only be able to restore the data till the previous snapshot which isn't gonna make the database up-to-date or close to it atleast.
Am I missing something here in my understanding?
...ANSWER
Answered 2020-May-19 at 10:12Cloud provider snapshots can be combined with point in time restore to give the recovery point objective you require. With oplog based restores you can get granularity of one second.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install bakelite
Key generation. This step does not need to be done on the system that will be backed up, and should be done on a system you absolutely trust -- both to have a working cryptographic entropy source, and not to expose data. Choose a place to store the secret key, such as an encrypted removable device, and run: bakelite genkey backup.sec bakelite pubkey backup.sec > backup.pub Then copy backup.pub to the system(s) you want to back up using this key.
Initialization. On the system to be backed up, create an empty directory and run: bakelite init /path/to/backup.pub /path/needing/backup This will create a skeleton configuration in the current working directory. All further steps should be performed from this directory.
Configure storage. Edit the store_cmd script produced by bakelite init to something that will accept data in tar format and write it to the desired storage, reporting success or failure via exit status. For example, for local storage to mounted media: tar -C /media/backup -kxf - or appending to a tape drive: cat >> /dev/nst0 or to a remote host via ssh: ssh backup@remotehost In the latter (ssh) case, the remote authorized_keys file should force a command that stores the tar stream appropriately and disallows overwrite of existing data. For example: command="tar -C /media/backup -kxf -" ssh-ed25519 AAAA...
Configure devices. Normally, Bakelite will not traverse mount points to other devices; this avoids accidentally including transient mounts of external media or remote shares into a backup they don't belong in. If you want to include additional mounts, create a symlink to the root of each in the directory named "devices". The symlink name will serve as a "label" for the device used in the local indexing, so that changes to device numbering across reboots do not break the index. For example: ln -s /home devices/home ln -s /var devices/var
Configure signatures. Create an executable sign_cmd file that accepts data to sign on stdin and produces a signature file on stdout. For example, to use signify: signify -S -s signing.sec -x - -m -
Additional configuration. Edit the config file to change any other preferences as desired. It's recommended to at least set a label for the backup so that the signed summary files will be associated with a particular role/identity, unless separate signing keys will be used for each tree being backed up. To exclude files matching certain patterns from backups, create a file named exclude containing one pattern per line. Patterns are a superset of standard glob pattern functionality, intended to match .gitignore conventions, except that inversion using leading ! is not supported. In particular, ** can be used to match zero or more path components, final / forces only directories to match, and patterns with no / (except possibly a final one) can match in any directory (they have an implicit **/ prefix). If the directory containing backup configuration is included in the backup, it is recommended to exclude index* from this directory, since the index will be out-of-date at the time of backup and index.pending will be incomplete. Instead of backing it up, the index file can be recreated at restore time if desired.
Run the first backup. bakelite backup -v The -v (verbose) flag is helpful to see what's happening, especially for new or changed configurations. However, it does expose information about filesystem contents/changes. Setups aiming to maximize privacy should not use it in an automated setting with logging. When the job is finished, a text file named according to the label and UTC backup timestamp, in the form label-yyyy-mm-ddThhmmss.nnnnnnnnnZ.txt, should be present on the backage storage medium, along with a number of files with hex string names in the objects directory. A .sig file will be present too if signing was configured.
Setup a cron job to perform further backups on the desired schedule. For example: 0 2 * * * bakelite -C /path/to/configuration/dir backup
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page